Inconsistent JSON serialization of Item vs. List<Item>

[dpastore]

Hello All,

I'm using stock WildFly Full 27.0.1.Final with included RESTEasy version 6.2.1.Final and default configuration.

I'm experiencing an issue where the JSON generated on methods that return a Response containing a single object T differs from the JSON produced on methods that return a Response containing a List<T>. In one case, T is abstract and requires polymorphic type handling. The serialization on the List method honors the @JsonbTypeInfo and @JsonbSubtype annotations, whereas the single item method does not. There are no other annotations on the classes.

For Example:

@GET
@Path("")
@Produces(MediaType.APPLICATION_JSON)
public Response getItems() {
    return Response.ok(getAllItems()).build();        // List<Item>
}

@GET
@Path("/{id}")
@Produces(MediaType.APPLICATION_JSON)
public Response getItem(@PathParam("id") String id) { 
    return Response.ok(getItemById(id)).build();      // Item
}

I've discovered that (in my case) RESTEasy is using org.eclipse.persistence.jaxb.rs.MOXyJsonProvider to serialize the single object response and org.eclipse.yasson to serialize the list/array response.

Any idea why it would do this, and how can I prevent it from using MOXy? I tried adding org.eclipse.persistence.jaxb.rs.MOXyJsonProvider to the Wildfly JAXRS configuration 'Resteasy Disable Providers' list, but no luck.

POM dependencies

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-web-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.6.0</version>
</dependency>
<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>4.0.2</version>
</dependency>

Note: I created a sample project without org.eclipse.persistence in the POM and don't see the same behavior. I'm assuming the MOXy provider embedded in eclipselink is coming into play.

[jamezp]

Is there a reason you're using EclipseLink rather than Hibernate? In WildFly Hibernate is the default Jakarta Persistence implementation.

Maybe you could try excluding the org.eclipse.persistence:org.eclipse.persistence.moxy from EclipseLink.

[dpastore]

Hello James,

It was my default choice because I'm reworking an existing EclipseLink project, along with my personal history/experience with the implementation.

I tested with Hibernate, and the issue goes away (but it creates a list of unrelated issues in my case). There is consistent JSON serialization in both single and list cases (honoring @JsonbTypeInfo and @JsonbSubtype annotations). For anyone who's experiencing this same issue on a fresh project, switching to Hibernate may be a viable workaround.

I don't seem to be having any luck with the exclusion. MOXy is still getting picked up by RESTEasy.

Thank you for your response, James! Much appreciated!

[jamezp]

I'm definitely going to guess this isn't an option, but I'll put it out there :) You could list the types you want in your jakarta.ws.rs.core.Application.getClasses(). That's not a great solution.

Actually, since this is WildFly this might work. If you don't already have a jboss-deployment-structure.xml, create one or add something like this to the existing one.

<module name="deployment.your-deployment.war" >
    <resources>
         <resource-root path="jersey-media-moxy.jar" >
               <filter>
                 <exclude path="org/eclipse/persistence/jaxb/rs/" />
               </filter>
         </resource-root>
    </resources>
</module>

I'm don't recall off the top of my head if the exclude path can be a file or not. I have a feeling it must be a directory. I also don't know if the resource-root path should be lib/jersey-media-moxy.jar either.

FWIW I think it would be a good feature/enhancement to add a property/context param which would hold a list of classes to ignore/exclude too. That seems reasonable to me. I'll keep looking to see if something like that already exists.

[dpastore]

I wasn't able to get the deployment descriptor to make a difference (assuming I defined it correctly, which is a stretch e.g., I referenced the eclipselink jar in resource-root path as I found the MOXy Provider is embedded directly in the jar.

However

I was finally able to work around this issue by removing EclipseLink from my pom and adding it directly to my Wildfly instance for general availability. In hindsight, maybe that's what I was supposed to do on Wildfly, rather than packaging it with the war?

For anyone out there hitting the same issue (or other inconsistent JSON serialization), here is what I did:

1. Remove EclipseLink from your project. For Maven, remove it from your POM or set the dependency scope to 'provided'

2. Download the eclipselink-n.n.n.jar and copy it to your Wildfly instance subdirectory /modules/system/layers/base/org/eclipse/persistence/main

3. Edit the module.xml file found in the above directory and add the eclipselink-n.n.n.jar to the resources section along with two additional dependencies ref: Stack Overflow

Full module.xml file:

<module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.9">
    <properties>
        <property name="jboss.api" value="public"/>
    </properties>

    <resources>
        <resource-root path="jipijapa-eclipselink-27.0.1.Final.jar"/>
        <resource-root path="eclipselink-4.0.2.jar"/>
    </resources>

    <dependencies>
        <module name="java.logging"/>
        <module name="java.management"/>
        <module name="java.naming"/>
        <module name="java.rmi"/>
        <module name="java.desktop"/>
        <module name="jakarta.annotation.api"/>
        <module name="jakarta.enterprise.api"/>
        <module name="jakarta.json.api" optional="true"/>
        <module name="jakarta.persistence.api"/>
        <module name="jakarta.transaction.api"/>
        <module name="jakarta.validation.api"/>
        <module name="jakarta.xml.bind.api"/>
        <module name="org.antlr"/>
        <module name="org.jboss.as.jpa.spi"/>
        <module name="org.jboss.logging"/>
        <module name="org.jboss.vfs"/>
    </dependencies>
</module>

+++

Thank you again, James, for taking the time to reply. I appreciate it! I spent more time on this issue than I would ever care to admit...

[jamezp]

I'm not 100% sure what the right way is, but adding it as a module will allow you to use it in other deployments. It's probably a little better at least :)