CODEWITHSUNDEEP
jakarta-ee
Rasha Elsayed
Rasha Elsayed

Reputation: 740

Jakarta ee application best practice: should one use container-specific implementations?

I am building my first Jakarta ee 8 App. Actually I come from Spring-Framework background, so I am focusing on the key differences and best practices. I read that Glassfish, Wildfly, JBoss EAP etc. provide implementations to the Jakarta ee Specifications. This raised the question:

Would the application be dependent on the server it runs on? If an upgrade or change of the application server is necessary, should one consider incompatibility bugs?

I will make the question more concrete, using the following example.

I created two versions of a web application with a hello world JAX-RS Webservice. It runs on JBoss EAP 7.2.2. The first pom file looks like

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>8.0.0</version>
  <scope>provided</scope>
</dependency>

The second pom file

<dependencyManagement>
   <dependencies>
     <dependency>
        <groupId>org.wildfly.bom</groupId>
        <artifactId>wildfly-jakartaee8-with-tools</artifactId>
        <version>${version.jboss.bom}</version>
        <type>pom</type>
        <scope>import</scope>
     </dependency>
   </dependencies>
</dependencyManagement>
....
<dependency>
   <groupId>org.jboss.spec.javax.ws.rs</groupId>
   <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
   <scope>provided</scope>
</dependency>

According to the following link>: http://www.mastertheboss.com/javaee/jakarta-ee/getting-started-with-jakarta-ee, the second pom should be used if one wants to use Wildfly extensions to the Jakarta ee.

Running the above applications on

I know I can include a specific JAX-RS library in my pom as a dependency and run container-independent. But If I run on Enterprise Application server like JBoss EAP or Glassfish would that be a best practice? In the same time I still think about server portability.

Note: I think when one takes the approach of including all implementations as explicit dependencies in the WAR (e.g. certain version of easyrest or Jersey), then one should think about switching to a more light-weight servlet container as Tomcat, as it would be no benefit of running on an Exnterprise Application server without using its features. I am talking here about the JAX-RS example. Ofcourse when other J2EE Features are needed e.g. EJBs tomcat will be certainly excluded.

Upvotes: 0

Views: 1040

Answers (1)

rieckpil
rieckpil

Reputation: 12021

Whenever you use vendor-specific features like RESTEasy dependencies for WildFly, you can't port your application that easily to a different application server (e.g. Payara/Glassfish/Open Liberty).

As a best-practices, just start with the Jakarta EE API dependency:

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>8.0.0</version>
  <scope>provided</scope>
</dependency>

This includes the JAX-RS 2.1 specification, which all application server support out-of-the-box. If you just use this, you should be able to easily port your application to a different server.

The JAX-RS 2.1 specification covers a lot of features, which most likely are enough.

There might be some edge cases, where the specification does not provide an easy-to-use solution and you might want to include vendor-specific implementations, which are not part of the formal JAX-RS specification.

A good example is missing support for MultiPart data of JAX-RS to e.g. upload files to your backend. RESTEasy provides a solution for this if you import the following to your Maven project:

<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-multipart-provider</artifactId>
  <version>3.6.3.Final</version>
  <scope>provided</scope>
</dependency>

The downside here is that once you make use of any import which does not come from javax.ws.rs/jakarta.ws.rs you are using something outside the specification.

On the other side, you should also think about how likely it is that you will switch your application server.

UPDATE:

What if e.g. the upgraded server implementation is still not bug-free?

Nobody knows if an implementation is bug-free. You should still plan some time to verify/test when you upgrade your server version. That's also true if you rely on the plain Jakarta EE 8 spec. In general, the server vendors also invest time in testing everything (having a big test suite) and might already find some bugs to fix. But still, you can't be 100% sure that after you upgrade the server everything works bug-free.

Speaking of bugs after upgrading the application server and JAX-RS, I had one with Payara where all my JAX-RS request filters were executed twice for an incoming request.

And btw. you should not take Tomcat into consideration. Tomcat is a just a servlet container and not a fully Jakarta EE compliant application server. On the Jakarta EE homepage, you can have a look at all Jakarta EE 8 compatible servers.

Upvotes: 2

Related Questions