2 Replies Latest reply on Aug 1, 2016 11:34 AM by milspec

    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

        • 1. Re: Using Jersey in Wildfly: best practice when migrating applications?
          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.

          • 2. Re: Using Jersey in Wildfly: best practice when migrating applications?
            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