Customizing JSON marhsalling with GlassFish v4 - glassfish

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

Related

How do I get a connection string in a .net core standard class library from the configuration file in a .net core 2.0 web app?

I have .net core standard class library which is essentially a DAL with several class methods that return collections and objects from a database. The connection string is in the appsettings.json file of the ASP.net 2 core web app. I also want to access this class library from a console app project where the configuration file with the connection string will be present in that console app project.
This was simple in .net prior to .net core. The DAL class library would just access the web.config from a web project and an app.config from a console application as it the library is referenced in both the web app and console apps. But it doesn't seem like this is at all possible.
I'm looking for the simple solution in .net core to get a connection string from web app or console app as the case may be.
Where you're probably going wrong is that you want to access configuration from your class library, but then you want to leak details specifically about the caller (That it will have a web.config).
But what if you decide in your Web Application you want to use Azure Key Vault or another secrets mechanism? Does your class library need to then change it's entire implementation to use Key Vault? And then does that mean your console application also has no option but to use Key Vault too?
So the solution is to use dependency inversion. Put simply, let's say I have code like the following :
interface IMyRepositoryConfiguration
{
string ConnectionString {get;}
}
class MyRepositoryConfiguration : IMyRepositoryConfiguration
{
public string ConnectionString {get;set;}
}
class MyRepository
{
private readonly IMyRepositoryConfiguration _myRepositoryConfiguration;
public MyRepository(IMyRepositoryConfiguration myRepositoryConfiguration)
{
_myRepositoryConfiguration = myRepositoryConfiguration;
}
}
Now in my startup.cs I can do something like :
services.AddSingleton<IMyRepositoryConfiguration>(new MyRepositoryConfiguration {//Set connection string from app settings etc});
And now my class library doesn't need to know exactly how those configuration strings are stored or how they are fetched. Just that if I request an instance of IMyRepositoryConfiguration, that it will have the value in there.
Alternatively of course, you can use the Options class too, but personally I prefer POCOs. More info here : https://dotnetcoretutorials.com/2016/12/26/custom-configuration-sections-asp-net-core/
It is very much possible to access "connection strings" or other configuration data easily in .Net core without much additional effort.
Just that the configuration system has evolved (into something much better) & we have to make allowances for this as well (& follow recommended practices).
In your case as you are accessing the connection string value in a standard library (intended to be reused), you should not make assumptions as how the configuration values will be "fed" to your class. What this means is you should not write code to read a connection string directly from a config file - instead rely on the dependency injection mechanism to provide you with the required configuration - regardless of how it has been made available to your app.
One way to do this is to "require" an IConfiguration object to be injected into your class constructor & then use the GetValue method to retrieve the value for the appropriate key, like so:
public class IndexModel : PageModel
{
public IndexModel(IConfiguration config)
{
_config = config;
}
public int NumberConfig { get; private set; }
public void OnGet()
{
NumberConfig = _config.GetValue<int>("NumberKey", 99);
}
}
In .net core, before the app is configured and started, a "host" is configured and launched. The host is responsible for app startup and lifetime management. Both the app and the host are configured using various "configuration providers". Host configuration key-value pairs become part of the app's global configuration.
Configuration sources are read in the order that their configuration providers are specified at startup.
.Net core supports various "providers". Read this article for complete information on this topic.

register server wide javax.ws.rs.client.ClientRequestFilter on JBoss EAP 7

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.

Is it possible to test Portlet Controllers using Springs MockMvc?

You can test your "normal" Spring MVC Controllers using the MockMvc class like so:
mockMvc
.perform(get("/my/fine/path"))
.andExpect(status().isOk());
From the Spring Reference on Handler Mappings:
Since there is really no such thing as a URL within a Portlet, we must use other mechanisms to control mappings. The two most common are the portlet mode and a request parameter, but anything available to the portlet request can be used in a custom handler mapping.
Is MockMvc only for "normal" Controllers or is there a way of using it when testing Portlet Controllers?
Checkout spring-test-portlet-mvc (https://github.com/markusf/spring-test-portlet-mvc), which exposes the features of MockMvc to the Portal context!

Jboss 7.1.1 - Jackson ContextResolver<ObjectMapper> works only on one deployment

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...

Apache CXF REST Services w/ Spring AOP

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