Eclipselink MOXy in WildFly

[noahwhite]

Related to #92 an example of using Eclipselink MOXy, specifically for JSON marshal/unmarshalling of entities exposed by a JAX-RS Resource endpoint would be useful.

[lennartj]

I just completed doing this. Still interested in an example?

[arjantijms]

As MOXy is EclipseLink specific, shouldn't that be better demonstrated in a separate repo that's intended for vendor specific functionality and/or 3rd party technology that works together with Java EE?

[lennartj]

MOXy is EclipseLink's implementation of the JAXB standard, just like Metro is the Reference Implementation. Neither of the two organisations represent a vendor, in the strict sense of the word, and neither requires you to use anything other than the JAXB standard within your codebase.

However, the reason this is important is that MOXy is also a JSON provider - implying that it can be used to marshal JAXB-annotated classes to and from JSON as well as XML. This is quite important to JAX-RS services that frequently need to emit JAXB-unmarshalled payloads to JSON for use within the JavaScript framework of a browser.

As most of the other JSON providers (Jettison, Jackson) do not originate from JAXB annotations - application servers require an adaption layer to enable the JAXRS framework JSON rendering - this implies that the structure of JSON rendered by WildFly's default provider differs from the structure of the XML emitted by the same codebase. This is not only confusing but also causes big pains for cross-deployment; your browser presentation layer receives two different JSON payloads depending on the application server used to render it. Really far from portability .... unless an example is shown on how to integrate alternative providers.

Hence the need for it.

[arjantijms]

Thanks for the explanation. What I meant with the question above is that this particular repository has been set up to demonstrate the Java EE API itself. So just wondering what the MOXy test really tests.

If it's how to integrate an alternative provider (e.g. from a jar in WEB-INF/lib) in a Java EE standard way and then test/demonstrate that it indeed works on every server supported by this project (JBoss, GlassFish, WebLogic, Liberty, TomEE partially), then that would be a great test indeed.

But if it shows some MOXy specific functions only on those servers that happen to ship with EclipseLink, or if it only demonstrated how WildFly can be configured to use MOXy in a WildFly specific way, then that woud be less ideal for this specific project.

Sorry for not phrasing my question above more clearly in the first place.