I have two rest webapps I want to deploy on Jboss 7.1.1. server.
Rest requests in both apps produces and consumes Json. I use jackson provider to serialize and deserialize objects.
Now, I need custom ObjectMapper configurations for each webapp.
So to resolve this problem I added #Provider classes implementing ContextResolver. One for each project. Fe. One of my class looks like that:
#provider
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public class JacksonConfig implements ContextResolver<ObjectMapper> {
private final ObjectMapper objectMapper;
public JacksonConfig()
{
objectMapper = new ObjectMapper();
objectMapper.configure(SerializationConfig.Feature.WRAP_ROOT_VALUE, true);
}
#Override
public ObjectMapper getContext(Class<?> objectType) {
return objectMapper;
}
}
It works well when I deploy only one of this projects on jboss. When I try to deploy both, only first initialized project use defined objectMapper. Other one never calls getContext method from ContextResolver class. What could I do wrong?
EDIT!:
After a lot of trials I decided to change method of parsing json from jackson to staxon. I hoped at least this method will work well. But not... Serialization works perfectly on both deployed applications. But again, somehow jboss decided to use jackson instead of staxon in deserialization process. Again always application which I call first after deployment works well. But Second one using jackson (no idea why...) which calls exceptions. Always...
Is there any problem with Jboss? Probably I'm just doing something wrong but I have no idea where. Anybody has idea where should I look?
Looks like I found solution for this problem.
It was known issue of resteasy, that can be removed by build-in option:
To solve this problem I just had to add param to web.xml of my projects:
<context-param>
<param-name>resteasy.use.deployment.sensitive.factory</param-name>
<param-value>false</param-value>
</context-param>
I found this solution in Resteasy jira. It's really strange for me that there is no info in any jboss or resteasy related documentation...
Related
I'm attempting to wire up Hangfire in my ASP.NET application (not Core) using the Global.asax.cs route explained in their documentation. However, none of their extensions methods on GlobalConfiguration.Configuration seem to be working for me. It appears, for one example, that SetDataCompatibiltyLevel() method extends Hangfire.IGlobalConfiguration, which my GlobalConfiguration.Configuration does not inherit from. I even backed off a few versions of Hangfire and it doesn't seem to make a difference. When I attempt to access the extensions method directly, I get this:
Prefix GlobalConfiguration class with the Hangfire namespace – System.Web.Http namespace defines its own GlobalConfiguration class, so you get a conflict. And that another class is referenced, most likely because you have the System.Web.Http namespace included in the beginning of the file.
Hangfire.GlobalConfiguration.Configuration
.SetDataCompatibilityLevel(CompatibiltyLevel.Version_170);
You can also combine all the calls to the GlobalConfiguration class in a single chain:
Hangfire.GlobalConfiguration.Configuration
.SetDataCompatibilityLevel(CompatibiltyLevel.Version_170)
.UseXXX()
.UseYYYStorage();
Is it possible to register a javax.ws.rs.client.ClientRequestFilter server wide on JBoss EAP 7? I would like to intercept all outbound JAX-RS calls to dynamically add some context information in HTTP headers.
For JAX-WS calls I was able to do this with https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html-single/developing_web_services_applications/#jax_ws_handler_chains. I can't find any documentation on a similar mechanism for JAX-RS.
Or alternatively, is there maybe another way to intercept outbound HTTP calls in general?
For a per server solution, according to Using HttpHandler class in Undertow "you need to package your handler(s) into a module, and configure custom-filter in undertow subsystem."
The module.xml example and undertow configuration has been given as well as filter source code!
Update
There's an example of using the HTTPExchange here though I dont really care much for that site. SO also has this slightly related example - it does look like it can work similarly to the JAX-WS Handlers/Interceptor How to properly read post request body in a handler
Another good example file upload using httphandler I know they're different that dealing with JAX-RS but still may apply.
I implemented it by creating a module with the following contents:
package be.fgov.kszbcss.tracer.jaxrs;
import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder;
public class TracerResteasyClientBuilder extends ResteasyClientBuilder {
#Override
public ResteasyClient build() {
return super.build().register(TracerJaxRsClientRequestFilter.class);
}
}
/META-INF/services/javax.ws.rs.client.ClientBuilder
be.fgov.kszbcss.tracer.jaxrs.TracerResteasyClientBuilder
And registering it as a global module on JBoss EAP.
I am using StructureMap.WebApi2 nuget package for Web API 2 project for managing the depedency injection.
The Web API controllers use constructor injection to inject a UrlHelper dependency which should be resolved by StructureMap Ioc.
I am trying the following approach to set the UrlHelper for web api controller:
public class FooController : ApiController
{
private UrlHelper _UrlHelper;
public ModelFactory(HttpRequestMessage request)
{
_UrlHelper = new UrlHelper(request);
}
}
But with the above code I am getting the following error:
No default Instance is registered and cannot be automatically determined for type 'System.Net.Http.HttpMethod' There is no configuration specified for System.Net.Http.HttpMethod
Can anyone suggest me the best possible ways to resolve the above issue?
Your problem is that StructureMap tries to resolve the greediest constructor first, in this instance taking a look at the source code for HttpRequestMessage reveals the following constructors:
public HttpRequestMessage(HttpMethod method, string requestUri);
public HttpRequestMessage(HttpMethod method, Uri requestUri);
This is where your HttpMethod issue is coming from. StructureMap tries to create an instance of HttpRequestMessage but has no idea how to resolve the method and requestUri dependencies.
In this instance you need to manually configure your dependency within your StructureMap configuration so it knows how to create an instance of HttpRequestMessage like so:
this.For<HttpRequestMessage>().Use(new HttpRequestMessage());
Alternatively, to create instances of overloaded constructors then you'll need to manually resolve the overloaded dependencies (I would recommend using a factory for this in order to keep your SM configuration nice and clean. Here is an example of how you can do this).
We've got a JAX-RS application that runs on Apache TomEE. We slightly customize the default Jettison provider to better adhere to JSON conventions used by JavaScript frontend. TomEE allows to do it via its resources.xml file:
<resources>
<Service id="jettison" class-name="org.apache.cxf.jaxrs.provider.json.JSONProvider">
serializeAsArray = true
dropRootElement = false
arrayKeys = members,roles
supportUnwrapped = true
writeXsiType = false
</Service>
</resources>
Now we are migrating to GlassFish v4.1, and we notice that JSON output differs from what we had in TomEE - thus completely breaking frontend. I'm looking for similar mechanism to customize JSON marshaller in GlassFish. In fact, I'm already a little bit stuck with Jersey, MOXy, Jackson, Jettison. How do we know which JSON provider is actually used? How do we select one? How do we customize the behavior?
The application is pure JAX-RS and does not use any JSON processor directly, instead relying on marshalling of JAXB-annotated classes. Introduction of any non-JavaEE dependencies is highly undesirable, since the application is intended to be portable across containers (TomEE, GlassFish, some day WildFly). Config-file method, similar to TomEE, is preferable; programmatic way is acceptable, too - but only if portability is maintained.
Glassfish uses MOXy as the default provider. Internally it has the libraries to handle Jackson, Jettison, and MOXy, but the default is MOXy. There are two ways to disable MOXy
Set the Jersey property jersey.config.server.disableMoxyJson to true.
Register a different XxxJsonFeature that disables MOXy. For instance the JacksonFeature that comes with jersey-media-json-jackson
Note that Glassfish comes with a Jackson provider, but it is Jackson 1.x. If you want to use 2.x, instead of the using the jersey-media-json-jackson dependency listed above, it would be better to use the underlying Jackson provider dependency, which is
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.6.0</version>
</dependency>
You can register the JacksonJsonProvider or the JacksonJaxbJsonProvider for JAXB annotation support.
To configure Jackson, the easiest way to implement a ContextResolver, as seen in this answer. The JacksonJsonProvider will lookup this ContextResolver to retrieve the ObjectMapper used for (de)serialization.
You will also need to remember to disable MOXy, as mentioned above.
Also one thing to note is that this solution is portable. With JAX-RS, the only portable application configuration is through an Application subclass
#ApplicationPath("/api")
public class MyApplication extends Application {}
That being said, the disabling of MOXy in the case of Glassfish, is nothing more than setting a property. In the Application class, you can override getProperties() which returns a Map<String, Object>. This is where you can set the property. And because it s nothing more than a String (no outside dependencies), it remains portable
#ApplicationPath("/api")
public class MyApplication extends Application {
#Override
public Map<String, Object> getProperties() {
Map<String, Object> props = new HashMap<>();
props.put("jersey.config.server.disableMoxyJson", true);
return props;
}
}
As far as the above Jackson dependency, it is also a portable solution. It it nothing (JAX-RS) implementation specific. It implements and uses standard JAX-RS APIs
I'm trying to get Apache CXF JAX-RS services working with Spring AOP. I've created a simple logging class:
public class AOPLogger {
public void logBefore(){
System.out.println("Logging Before!");
}
}
My Spring configuration (beans.xml):
<aop:config>
<aop:aspect id="aopLogger" ref="test.aop.AOPLogger">
<aop:before method="logBefore" pointcut="execution(* test.rest.RestService.*(..))"/>
</aop:aspect>
</aop:config>
<bean id="aopLogger" class="test.aop.AOPLogger"/>
I always get an NPE in RestService when a call is made to a Method getServletRequest(), which has:
return messageContext.getHttpServletRequest();
If I remove the aop configuration or comment it out from my beans.xml, everything works fine.
All of my actual Rest services extend test.rest.RestService (which is a class) and call getServletRequest(). I'm just trying to just get AOP up and running based off of the example in the CXF JAX-RS documentation. What am I doing wrong?
You just need to have your resource class implementing some simple interface with a method
#Context
void setMessageContext(MessageContext mc) {}
this will enable the CXF SpringAOPHelper to discover the method