Using Jersey in Wildfly: best practice when migrating applications?

[milspec]

Hi all,

I've been tasked with moving a legacy application JavaEE (fka "J2EE") from jboss 4 to wildfly .

My goal is to get it up and running with minimal immediate coding changes. medium term: the dev team should modernize

One issue: jersey. The current application depends on jersey libraries (jersey 1.16 or Jax-RS 1.1) packaged in the ear. The code imports com.sun.jersey packages (e..g "com.sun.jersey.api.Responses").

I read a one 'glassfish to wildfly' post which menteioned the need to rewrite some items

-What are our options?

-If I switch the implementation to resteasy, will these imports fail? Should I stop including the jersey-* libraries from the ear.

-Can I define a 'jersey-module' and 'swap out' resteasy with jersey?

thanks in advance

[mayerw01]

Jersey is natively supported only by Glassfish. Jersey provides it’s own API that extend the JAX-RS. JAX-RS 2.0 API is not supported before Jersey 2.23.1.

RESTEasy instead is bundled with JBoss/Wildfly and completely integrated as per the requirements of Java EE (RESTEasy JAX-RS).

You will therefore not need any add'l libraries when deploying a JAX-RS Application to Wildfly using RESTEasy.

Refering to jersey 1.16 this is a quite old version which will probably cause issues in a WildFly environment with Java SE 8. And migrating to Jersey 2 would mean some work (Chapter 28. Migration Guide) as well.

I therefore think the only practicable option is to migrate to RESTEasy when moving to WildFly.

[milspec]

Thanks wolfgang.

I wanted to confirm that this approach is not viable.

• disable all jax-rs in wildfly
• load jersey jars from application (i.e. in ear file)

This is the approach the team used for Jboss 4

Clearly it's suboptimal..just delays upgrade work, but I wanted to understand why it would not succeed in wildly.

thanks and best regards