TomEE is partly composed of Blevins' previous projects, as well as associated bits and pieces from existing open source projects. According to Blevins:
Aside from Tomcat itself, the main parts are MyFaces, OpenWebBeans, OpenJPA, OpenEJB, BeanVal, and TransactionManager. In TomEE+ we also have ActiveMQ and CXF. As for how much is unique code, I suspect the question is how much code did it take to tie them all together. The answer is not much, but it was incredibly difficult to cross the t's and dot the i's.
Blevins notes that besides freeing you from the work of "build your own app server," TomEE contains performance improvements:
The more things you drop into Tomcat the more third-party libraries you have scanning your Web app for annotated components: Tomcat scans for @WebServlet; MyFaces scans for @ManagedBean; OpenJPA scans for @Entity; CXF scans for @WebService and @Path; OpenEJB scans for @Stateless, etc. Scanning literally means opening each jar in the Web app and reading each class file, parsing it with something like ASM, and seeing if it has an annotation that is interesting. You really don't want to do this five times each startup. For just this reason alone we find some people reporting that their Tomcat apps start faster after moving them onto TomEE where those libraries are better integrated. We also do things like integrate JAX-WS security onto Tomcat Realms so everything is nicely ready to go out of the box.
Java EE has been both pushed forward and hobbled by the Java Community Process. I asked Blevins what he thought about the JCP post-Oracle. His reply:
Shortly after Apache and others left the JCP, Oracle, with significant help from others, put together a plan for reform. This is JSR-348, which is now implemented and mandated and really is just the beginning. If you haven't at least read the JSR description for 348 I strongly recommend it. It takes concrete action to ensure transparency and create openness for all JSRs, going to the level of requiring basic things like open mailing lists for every JSR, requiring public issue trackers, and even putting measures in for Spec Leads that may not be active enough.
What I find interesting is that the long trip of Java EE always comes back to Tomcat. This is more or less where it started and more or less where it is ending up, with multiple vendors providing Tomcat+ offerings. TomEE is both an argument for and against Java EE's programming model -- and its use as a spec for a big, fat monolithic app server like WebSphere or WebLogic. Blevins' pragmatic play will yield new remixes of not only Java EE, but Spring and probably some of the newer stuff like the Play framework.
This article, "Can TomEE save Java EE?," was originally published at InfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.