Implementation components used by various Java EE servers

There are quite a lot of Java EE server implementations out there. There are a bunch of well known ones like JBoss, GlassFish and TomEE, and some less known ones like Resin and Liberty, and a couple of obscure ones like JEUS and WebOTX.

One thing to keep in mind is that all those implementations are not all completely unique. There are a dozen or so Java EE implementations, but there are most definitely not a dozen of JSF implementations (in fact there are only two; Mojarra and MyFaces).

Java EE implementations in some way are not entirely unlike Linux distributions; they package together a large amount of existing software, which is glued together via software developed by the distro vendor and where some software is directly developed by that vendor, but then also used by other vendors.

In Java EE for example JBoss develops the CDI implementation Weld and uses that in its Java EE servers, but other vendors like Oracle also use this. The other way around, Oracle develops Mojarra, the aforementioned JSF implementation, and uses this in its servers. JBoss on its turn then uses Mojarra instead of developing its own JSF implementation.

In this post we'll take a deeper look at which of these "components" the various Java EE servers are using.

One source that's worth looking at to dig up this information is the Oracle Java EE certification page. While this does lists some implementations for each server, it's unfortunately highly irregular and incoherent. Some servers will list their JSF implementation, while some others don't do this but do list their JPA implementation. It gives one a start, but it's a very incomplete list and a list that's thus different for each server.

Another way is to download each server and just look at the /lib or /modules directory and look at the jar files being present. This works to some degree, but some servers rename jars of well known projects. E.g. Mojarra becomes "glassfish-jsf" in WebLogic. WebSphere does something similar.

Wikipedia, vendor product pages and technical presentations sometimes do mention some of the implementation libraries, but again it's only a few implementations that are mentioned if they are mentioned at all. A big exception to this is a post that I somehow missed when doing my initial research from Arun Gupta about WildFly 8 (the likely base of a future JBoss EAP 7) which very clearly lists and references nearly all component implementations used by that server.

A last resort is to hunt for several well known interfaces and/or abstract classes in each spec and then check by which class these are implemented in each server. This is fairly easy for specs like JSF, e.g. FacesContext is clearly implemented by the implementation. However for JTA and JCA this is somewhat more difficult as it contains mostly interfaces that are to be implemented by user code.

For reference, I used the following types for this last resort method:

  • Servlet - HttpServletRequest
  • JSF - FacesContext
  • CDI - BeanManager
  • JPA - EntityManager
  • BV - javax.validation.Configuration, ParameterNameProvider
  • EJB - SessionContext
  • JAX-RS - ContextResolver, javax.ws.rs.core.Application
  • JCA - WorkManager, ConnectionManager, ManagedConnection
  • JMS - Destination
  • EL - ELContext, ValueExpression
  • JTA - TransactionManager
  • JASPIC - ServerAuthConfig
  • Mail - MimeMultipart
  • WebSocket - ServerWebSocketContainer, Encoder
  • Concurrency - ManagedScheduledExecutorService
  • Batch - JobContext

Without further ado, here's the matrix of Java EE implementation components used by 10 Java EE servers:

Vendor Red Hat Oracle Apache IBM TMax Caucho OW2
Spec/AS JBoss/WildFly GlassFish WebLogic Geronimo TomEE+ WebSphere Liberty JEUS Resin JOnAS
Servlet Undertow Tomcat derivative & Grizzly Nameless internal Tomcat/Jetty Tomcat Nameless internal Nameless internal Nameless internal (jeus servlet) Nameless internal Tomcat + Jetty*
JSF Mojarra* Mojarra Mojarra MyFaces MyFaces MyFaces* MyFaces* Mojarra* Mojarra* Mojarra (def) + MyFaces*
CDI Weld Weld* Weld* OWB OWB OWB* OWB* Weld CanDI (semi internal) Weld*
JPA Hibernate Eclipselink+ EclipseLink+ OpenJPA OpenJPA OpenJPA* OpenJPA* Future version will be EclipseLink* Eclipselink* Eclipselink* Hibernate (def) + EclipseLink (certified with)*
BV Hibernate Validator Hibernate Validator* Hibernate Validator* BVal BVal BVal* BVal* Hibernate Validator* Hibernate Validator* Hibernate Validator*
EJB Nameless internal Nameless internal (EJB-container) Nameless internal OpenEJB OpenEJB Nameless internal Nameless internal Nameless internal Nameless internal EasyBeans
JAX-RS RESTEasy Jersey Jersey Wink CXF Wink* Wink* Jersey* - Jersey*
JCA IronJacamar Nameless internal (Connectors-runtime) Nameless internal Nameless internal (Geronimo Connector) Nameless internal (Geronimo Connector) Nameless internal -Nameless internal Nameless internal Nameless internal
JMS HornetQ OpenMQ WebLogic JMS (closed source) ActiveMQ ActiveMQ SiBus (closed source) Liberty messaging (closed source) Nameless internal Nameless internal JORAM
EL EL RI* EL RI EL RI Apache / Jasper / Tomcat(?) EL Apache / Jasper / Tomcat(?) EL Apache / Jasper / Tomcat(?) EL* Apache / Jasper / Tomcat(?) EL* EL RI* Nameless internal EL RI + Apache / Jasper / Tomcat(?) EL*
JTA Narayana Nameless internal Nameless internal Nameless internal (Geronimo Transaction) Nameless internal (Geronimo Transaction) Nameless internal Nameless internal Nameless internal (jeus tm) Nameless internal JOTM
JASPIC Part of PicketBox Nameless internal Nameless internal Nameless internal (Geronimo Jaspi) - Nameless internal - Nameless internal - -
Mail JavaMail RI* JavaMail RI JavaMail RI (Geronimo?) JavaMail (Geronimo?) JavaMail JavaMail RI* - JavaMail RI* JavaMail RI* JavaMail RI*
WebSocket Undertow Tyrus - - - - - Nameless internal (jeus websocket) - -
Concurrency Concurrency RI* Concurrency RI - - - - - Nameless Internal (jeus concurrent) - -
JBatch JBeret JBatch RI (IBM)* - - - - - JBatch RI (IBM)* -
(asterisk behind component name means vendor in given column uses implementation from other vendor, plus behind name means the implementation used to be from the vendor in that column, but the vendor donated the implementation to some external organization)

Looking at the matrix we can see there are mainly 3 big parties creating separate and re-usable Java EE components; Red Hat, Oracle and Apache. Apache is maybe a special case though, as it's an organization hosting tons of projects and not a vendor with a single strategic goal.

Next to these big parties there are two smaller ones producing a few components. Of those OW2 has a separate and re-usable implementation of EJB, JMS and JTA, while Resin has its own implementation of CDI. In the case of Resin it looks like it's only semi re-usable though. The implementation has its own name (CanDI) but there's isn't really a separate artifact or project page available for it, nor are there really any instructions on how to use CanDI on e.g. Tomcat or Jetty (like Weld has).

Apart from using (well known) open source implementations of components all servers (both open and closed source) had a couple of unnamed and/or internal implementations. Of these, JASPIC was most frequently implemented by nameless internal code, namely 4 out of 5 times, although the one implementation that was named (PicketBox) isn't really a direct JASPIC implementation but is more a security related project that includes the JASPIC implementation classes. JTA and EJB followed closely with 8 respectively 7 out of 10 implementations being nameless and internal. Remarkable is that all closed source servers tested had a nameless internal implementation of Servlet.

At the other end of the spectrum in the servers that I looked at there were no nameless internal and no closed source implementations of JSF, JPA, Bean Validation, JAX-RS, JavaMail and JBatch.

It's hard to say what exactly drives the creation of nameless internal components. One explanation may be that J2EE started out having Servlet and EJB as the internal foundation of everything, meaning a server didn't just include EJB, but more or less WAS EJB. In that world it wouldn't make much sense to include a re-usable EJB implementation. With the rise of open source Java EE components it made more sense to just reuse these, so all newer specs (JSF, JPA, etc) are preferable re-used from open source. One exception to this is however JEUS, which despite being in a hurry to be the first certified Java EE 7 implementation still felt the need to create their own implementations of the brand new WebSocket and Concurrency specs. It will be interesting to see what the next crop of Java EE 7 implementations will do with respect to these two specs.

An interesting observation is that WebSphere, which by some people may be seen as the poster child of the closed source and commercial AS, actually uses relatively many open source components, and of those nearly all of them are from Apache (which may also better explain why IBM sponsored the development of Geronimo for some time). JavaMail for some reason is the exception here. Geronimo has its own implementation of it, but WebSphere uses the Sun/Oracle RI version.

Another interesting observation is that servers don't seem to randomly mix components, but either use the RI components for everything, or use the Apache ones for everything. There's no server that uses say JMS from JBoss, JSF from Oracle and JPA from Apache. An exception to the rule is when servers allow alternative components to be configured, or even ship with multiple implementations of the same spec like JOnAS does.

We do have to realize that a Java EE application server is quite a bit more than just the set of spec components. For one there's always the integration code that's server specific, but there are also things like the implementation of pools for various things, the (im)possibility to do fail-over for datasources, (perhaps unfortunately) a number of security modules for LDAP, Database, Kerberos etc, and lower level server functionality like modular kernels (osgi or otherwise) that dynamically (e.g. JBoss) or statically (e.g. Liberty) load implementation components.

JEUS for instance may look like GlassFish as it uses a fair amount of the same components, but in actuality it's a completely different server at many levels.

Finally, note that not all servers were investigated and not all components. Notably the 3 Japanese servers NEC WebOTX, Fujitsu Interstage and Hitachi Cosminexus were not investigated, the reason being they are not exactly trivial to obtain. At the component level things like JAX-RPC, JAX-WS, SAAJ, JNDI etc are not in the matrix. They were mainly omitted to somewhat reduce the research time. I do hope to find some more time at a later stage and add the remaining Java EE servers and some more components.

Arjan Tijms

Comments

  1. Very excellent post! The genealogy of app servers is one of my favorite subjects. Your observation on the overlap for Geronimo and WebSphere is quite keen. In fact the Geronimo/WebSphere CE team was a key part of bringing projects to Apache so they could be used in both Geronimo/WebSphere CE and potentially WebSphere. A particularly proud moment was getting BEA to open source Kodo as OpenJPA -- a product they had just purchased and made part of WebLogic. That's a footnote in history, however, as clearly WebLogic no longer uses OpenJPA for obvious reasons.

    Couple confirmations on the questions: Yes, the JavaMail implementation in Geronimo and TomEE is from the Geronimo project. Written almost entirely by Rick McGuire, (unsung hero in Java, but prolific in the Rexx community) and is the only non-Sun implementation of JavaMail I'm personally aware of.

    The JASPIC, Transaction and Connector implementations in Geronimo and used in TomEE, were largely written by David Jencks -- in the Geronimo project of course. David is another unsung hero and between him and Rick I couldn't say who I respect more. David was an early member of JBoss, a co-founder of Geronimo and now works on Liberty.

    Yes, EL in Geronimo and TomEE is supplied by Tomcat. Also note, TomEE and Tomcat both support WebSockets. That code is part of Tomcat. Geronimo, however is not using that version of Tomcat and does not yet support it.

    ReplyDelete
  2. Thanks a lot for the extra info :) It's interesting to learn Geronimo has its own JavaMail implementation. They don't seem to advertise it as much though and it was actually a surprise to find it. Since there are not really any project pages for the separate components of Geronimo I wasn't quite sure how to call it. There was btw one other JavaMail implementation once. GnuMail, but it hasn't been updated for like forever.

    I saw the name David Jencks popup a number of times when looking at Geronimo's JASPIC implementation a while back. Unfortunately there doesn't seem to be that much activity around Geronimo these days. I tried to contact them about a few JASPIC issues, but never got any reply. Specifically this issue has been silent for a long time: https://issues.apache.org/jira/browse/GERONIMO-6423 Is David still involved with Geronimo and specifically JASPIC?

    The question mark for the Apache EL entry was mostly because I couldn't easily find a reference to its official name. It's part of jar files having different names and I couldn't find the canonical project for it (my guess is that it doesn't have one, but that it's part of the Jasper project, but I wasn't 100% sure).

    About the WebSocket support in Tomcat/TomEE, it's not the Java EE standardized version, is it? I scanned all jars in TomEE for "ServerWebSocketContainer" and "Encoder" but couldn't find them.



    ReplyDelete
  3. Comprehensive summary of app servers Arjan!

    You may want to rename JBoss to WildFly or JBoss/WildFly. JBoss is EAP and that is only Java EE 6 compliant. WildFly OTOH is Java EE 7 compliant.

    Also the complete list of Java EE 7 implementations in WildFly is listed at:

    http://blog.arungupta.me/2013/10/java-ee-7-implementations-in-wildfly-tech-tip-3/

    Batch implementation in WildFly is not Batch RI, instead its JBeret (https://github.com/jberet/jsr352).

    ReplyDelete
  4. Thanks Arun!

    I know about WildFly and JBoss, but I tried to keep the matrix a bit general. Probably sooner than later JBoss EAP will be there and it will have the same components of course. For the same reason I didn't have a column for WebShere CE (it's the same code as Geronimo, but released as a kind of snapshots between major Geronimo versions).

    But maybe just calling it JBoss was a bit unclear, so I named it JBoss/WildFly now and clarified it a little in the text. Thanks for suggestion!

    Somehow I missed your blog entry this time around. Crazy, since I normally always read every entry on your blog. Yes, that specific blog entry is exactly what I was referring to. If every vendor wrote it down like you did the few hours it took me to compile the component matrix could have been reduced to a few minutes ;)

    I also corrected the WildFly batch entry right away.

    One thing that I wonder about btw is why the EJB implementation of WildFly/JBoss doesn't have a real name. The JBoss guys are clearly really eager to come up with creative names (IronJacamar, HornetQ, ...), but for some reason EJB has been left a bit in the cold here. I guess it's mainly historical, but just curious.

    ReplyDelete
  5. Thanks for the update!

    EJB implementation is not available as a standalone component and so there is no need to name it. Its just like JSP and Servlet.

    One point that may be worth highlighting is that Undertow is more than just Servlet/WebSocket implementation :)

    ReplyDelete
  6. Somebody pointed out a minor typo as well, "JAX-WS" instead of "JAX-WAS".

    ReplyDelete
  7. Actually the EJB implementation in JBoss does have a name, this is where JBoss comes from. The project was originally called EJBoss. Back in "the day" (2000), the two of the main open source EJB implementations were EJBoss (Marc, Rickard) and OpenEJB (Richard, me). Sun asked us to change our names because "EJB" was trademarked. EJBoss became JBoss. OpenEJB stayed OpenEJB as we liked our name and pointed out only "Enterprise JavaBeans", not "EJB" was actually trademarked in the specification.

    Marc made the wiser choice :) Had it stayed "EJBoss", it wouldn't have done half as well. It was a blessing in disguise.

    ReplyDelete
    Replies
    1. That's a quite interesting story really. I indeed remember reading that the JB in JBoss originated from EJB, but didn't make the connection that the current implementation of EJB within JBoss thus originates from the original EJBoss.

      Reminds me about another historical thing that the "no user threads allowed in EJB" actually was intended to mean "no user threads allowed in J2EE", but EJB at the time was taken to be the foundation of all that's J2EE (or so they said).

      I'd still like to write an article one day that goes a bit more in-depth into the history and very beginnings of Java EE, e.g. the story about WebLogic and BEA, about the now mostly forgotten IronFlare and its Orion Server (that became OC4J later), maybe even try to dig up what the story is behind the "evermind" that was still present in the very last stack traces of OC4J, about how CMP originally could have been quite what JPA is today and even had a prototype running on top of TopLink (if I remember correctly Mike Keith wrote about that some while ago), etc etc.

      Would be quite cool I think :)

      Delete
    2. Correct on the "no user threads allowed in EJB". I mentioned that and the "can't touch files" restriction in my EJB talk at Devoxx BE this year. Both are now appropriately moved to the Java EE spec and are now just warnings in EJB. Only took 15 years for us to get that one fixed :) We can blame stackoverflow for that. I can't even count the number of times I've seen people say "use a servlet instead, you can't do that in an EJB" and that answer is the accepted answer and has 10 up votes!

      I think you could write a series on the history and I'd love to see that. I had an interesting talk with Paul Ambrose, creator of WebLogic, maybe a year ago asking for advice. Was very interesting to hear about his biggest challenges and it really opened my eyes on 1) how far we've come and 2) you can't copy anyone else's path to success. He said one of his biggest challenges and struggles was convincing people that Java could be used on the server side. As much as we think things don't change, the fact is they can change quite quickly.

      The most interesting part of these various histories is when it was just the one or two people working. Even if there's a large company involved, all stories start that way.

      Delete
  8. This is exactly the information I have been looking for! Thank you for your work in putting this together!

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Arjan: Activity on Geronimo has pretty much ceased. As mentioned in my "Feed the Fish" blog post, IBM cut commercial ties with Geronimo about a year before Oracle eventually did the same cutting commercial ties with GlassFish. The difference being Geronimo did not have the benefit of a diverse community or being the RI to keep it going, so that project has effectively halted. David and my fellow Geronimo cohorts that are still at IBM are now working on Liberty. There are quite a lot of people in IBM who still care deeply about Geronimo, just have no time to work on it.

    The parts that TomEE uses will live on however. JASPIC isn't on that list yet, but it will be.

    On the Tomcat/WebSockets question, right, the official API is in Tomcat 8. Tomcat 7 has the identical code, but not in the javax package to respect certification requirements.

    ReplyDelete
  11. On the Tomcat/WebSockets in fact all the code for certification is in the latest version (7.0.53),.
    Actually we can't calm we pass JSR 356 because ASF doesn't have a standalone TCK for WebSockets...

    ReplyDelete
  12. You can identify 3 generations of the JBoss EJB implementation:

    A) the 2.x - 4.x EJB implementation, tight with the server.

    B) the 5.x -6.x implementation. Carlo de Wolf (EJB3 lead at the time) made a significant effort to componetize and take the EJB implementation outside the server while implementing the new EJB3 standard, under the name JBoss EJB3. The effort was successful but resulted in a large and somewhat hard to manage amount of components.

    C) the AS7 & now WF8 EJB3 implementation. To a large extend this was a re-write but some parts of the 6.x implementation were used. Bringing the EJB3 implementation back in the server simplified things.

    EJBs are traditionally very central to the AppServer architecture with many touch points, so the benefit of having it as an independent implementation is not clear. At least in JBoss we've tried both approaches and we ended up with the embedded version.

    ReplyDelete
  13. Hi.
    According to this http://www.oracle.com/technetwork/java/javaee/overview/waslibertyprofile8556-2587134.html WAS Liberty uses Weld as CDI and not OWB

    ReplyDelete
    Replies
    1. Thanks for the comment. It's true, the Java EE 7 compatible 8.5.5.6 uses Weld. However, the version tested here was the Java EE 6 compatible 8.5.5, which at the time used OWB. See http://oracle.com/technetwork/java/javaee/community/ibm-javaee6-web-tested-configs-1961333.html

      I surely would need to do an update specifically for Java EE 7 as some dependencies have indeed changed. Thanks again for the comment.

      Delete

Post a Comment

Popular posts from this blog

Implementing container authentication in Java EE with JASPIC

Jakarta EE Survey 2022

What’s new in Jakarta Security 3?