The Apache Software Foundation has released Apache TomEE 1.5. Apache TomEE, pronounced "Tommy", is a JavaEE 6 Web Profile Certified Tomcat stack.  Aimed at allowing developers to spend less time building servers and more time building applications, TomEE cuts the time to integrate popular technologies like CDI, Transactions, or WebServices on Tomcat to zero and provides portability to and from any other Java EE 6 Web Profile certified server.

The 1.5 release features a new Java EE certified download that includes the Web Profile plus JAX-RS for RESTful Web Services. The new 'TomEE JAXRS' distribution shows TomEE's commitment to progressing its certification efforts beyond the Web Profile and is a great alternative to the TomEE Plus distribution. See the comparison for a view of all Tomcat and TomEE distributions.

Other new features include:

• Extended support for database connection pools adding transaction aware pooling semantics to the native Apache Tomcat and BoneCP connection pools which offer great alternatives to applications under heavy load.
• Enhaced JMX monitoring and statistics for connection pools.
• Deploy-time enhancement for JPA Entities via Apache OpenJPA.
• A powerful new TomEE Maven Plugin which can provision servers, install libraries, deploy webapps and more.

See the release notes for a complete list of the impressive number of improvements and fixes in the 1.5 release.

Most serverside Java users don't need a full-fledged Application server platform but a full-fledged Web application platform. That's what TomEE delivers.

interesting. they did away with the absurdly complicated packaging of ejb, war, jars, and manifest entries,etc...  still better off using Spring as once you start using the bloated mess of JEE, if TomEE goes belly up you will have to deal with all the complexity of packaging your app to get it to run on a JEE server not to mention all the server specific descriptors and configuration needed for the JEE bloat.

'Web Profile' (implemented by TomEE) is the successor.

Nathaniel -

interesting. they did away with the absurdly complicated packaging of ejb, war, jars, and manifest entries,etc...  still better off using Spring as once you start using the bloated mess of JEE, if TomEE goes belly up you will have to deal with all the complexity of packaging your app to get it to run on a JEE server not to mention all the server specific descriptors and configuration needed for the JEE bloat.

You misunderstand entirely:

1) TomEE is an open source application server with a business-friendly license (and governed by the open source and non-profit Apache Software Foundation) that implements a portable standard (Java EE). That means the app that you deploy on TomEE will also deploy on JBoss, Glassfish, WebSphere, WebLogic, and another eight or so implementations of the Java EE specification.

2) Compare that to Spring, an open source project govererned by and sold by EMC/VMWare.

3) If you really need the extra complexity that you gain with Spring, it will also run on TomEE -- and JBoss, Glassfish, WebSphere, WebLogic, and another eight or so implementations of the Java EE specification.

I hope that clarifies for you the benefits of Java EE, whether you choose to lock yourself into Spring or not.

Peace,

Cameron Purdy | Oracle

(Working for Oracle, but writing my own opinions.)

interesting. they did away with the absurdly complicated packaging of ejb, war, jars, and manifest entries,etc...  still better off using Spring as once you start using the bloated mess of JEE, if TomEE goes belly up you will have to deal with all the complexity of packaging your app to get it to run on a JEE server not to mention all the server specific descriptors and configuration needed for the JEE bloat.

How is something that is free and open gonna go belly up?  How many years have we had Tomcat and did it "belly up"?  

Even if it did, you have the source code, you have the binary, unless you have an itching requirement to change the container, you can still run your app without any re-packaging.

I'm typically an advocate for pragmatism in these situations.  There are plenty of people who happily use Spring on TomEE.

True, some people have found they can reduce the size and configuration overhead of their Spring applications with TomEE.  Then on the other side there are amazing things in Spring like Spring Data for which there is no equivalent in Java EE 6.  This is absolutely fine as Java EE 6 is not meant to be the only thing you need to write an app, just the base.  Unlike previous Java EE versions, it's designed to be extended!

There are CDI bindings for Spring Data which is an absolutely perfect example of Java EE as a base and Spring for powerful extensions.  Just as TomEE turns the old "Tomcat or JavaEE" debate on its nose and makes it "Tomcat and JavaEE", I really hope the stale "Spring or JavaEE" debate ceases and people begin to see how Spring and JavaEE can be used together.

The future is pragmatism, not dogmatism.

Spring and JavaEE are not tools, they are tool boxes.  Those who have the freedom of thought to use the best of the tools in front of them will dominate the next 10 years.

I have to agree with David here. The JEE v Spring debate with all the rhetoric of JEE is heavy and Spring is lightweight is turning into mythology with no basis in fact. There's also a whole load of ignorance and conflation of technolgoies which are not directly comparable.

5 years ago there may have been a point. Although as a company that specialises in performance tuning, the old so called full fat app servers of that time could still churn out a Hello World JSP, calling a Session Bean accessing an Entity Bean in sub 10ms so everything else was developer fat! Also Tomcat is and always was an App Server, just not a J(2)EE compliant app server and Spring is a framework that can run on most if not all App Servers JEE compliant or not and always did. Never mind getting me started on Hibernate vs JPA (it's been JBoss' JPA since JEE5)

As someone who crosses "the divide" a lot as we deal with Non-functional requirements, in large scale middleware, to be honest it makes not a jot of difference to your NFR's whether you use either, as bad code is bad code whether in Spring or JEE. I cringe when someone parrots the usual (JEE == heavy && Spring == light) argument as it dates them to the noughties and they embarass themselves ;-)

I'll calm down now and find Peace like Cameron.

Steve Millidge
C2B2