Before all, TomEE Embedded is a way to start TomEE and deploy applications in an Embedded manner. It is fully based on Tomcat embedded and just integrates it with OpenEJB/TomEE.

However, to make it easier to use, TomEE provides a shade of the whole container. Historically it has been named “uber”. This uber jar includes and sets by default a Main to be able to use it directly. To be concrete, with that jar you can deploy your war as easily as:

java -jar tomee-embedded-7.0.0-uber.jar --path myapp.war

The uber jar includes most of TomEE i.e. JAX-RS, JAX-WS, JMS …

However, today, with microservice trend, it is common to only require web resources handling and JAX-RS/JPA for the backend or only contain a webservice. That is why TomEE 7 got two new flavors on a user request:

  • jaxrs: simple webprofile of EE 7 without JSF
  • jaxws: simple webprofile without JAX-RS and JSF plus JAX-WS

This means you can have a lighter runner now.

This also provides few more advantages: typically when you do a shade to make a fatjar or a fatwar (explained here), you will include the server in your binary. This is great, but the bigger the server is, the longer your build will be, and the slower your development iterations will be. That is why having a more adapted packaging makes it nicer for end users.

Finally, for fatjars using maven-war-plugin, the dependencies are not handled. So, you would need to list a bunch of dependencies to do it right without that shades. And here again it makes it simpler and even enable it - not sure you would try the adventure without it.

Last point: the provided Main supports --as-war option, which means “deploy current classpath as a war”. It can use classpath META-INF/resources as web resources directories, given that Servlet 3 added it. But you can also specify using --doc-base option to specify an external folder:
 

java -cp myapp.jar:tomee-embedded-7.0.0-jaxrs.jar \
   org.apache.tomee.embedded.Main \
   --as-war --doc-base /opt/frontend/app

This command will deploy the classpath as a web application, and use /opt/frontend/app as additional frontend resources, like an Angular2 application for instance ;)


To conclude, keep in mind that using an embedded container opens several doors, but it also brings its own problems and more responsibilities on the developers. Depending on the organization you evolve in, you may need to think to other teams like operation ones, before going this way. You may also need to ensure they will support you in this movement. This can also mean they find a company able to support this deployment mode which is not something obvious since it is almost a custom deployment in all cases.

From the same author:

In the same category: