Search code examples
javahibernatetomcatwebspherejava-ee-6

Hibernate without Java EE 6

I have Websphere 7 server, and it don't support JPA 2.0. So I can't run on WAS 7 JPA 2.0 applications.

But I'm wondering how Spring users run Hibernate on Tomcat or Jetty? This servlet-containers also (as WAS 7) doesn't support Java EE 6.

So it's mean that I can run Hibernate on WAS 7 with the same results as on the Tomcat or Jetty?.

If yes, what are benefits of using app-servers for JPA? Why all developers don't use servlet-containers instead app-servers?

Also I heard about "container-managed" stuff, that allows some additional features and functionality. So it's mean that many developers (who uses Spring on Jetty and Tomcat) don't get benefits of using container-managed features of app-servers?

P.S. I know about available Feature Pack patch for WAS 7 for JPA 2.0 support, but question not about it.

Solution

  • Application servers offer a set of services "out of the box", so they are easier to use if the offered services are the ones you need. You just package and deploy your application and the thing works. Furthermore, most of the technologies are instantiated by the application server, so you avoid a lot of classloader issues.

    The problem with application servers is that sometimes (quite often, actually), you need to pick and choose particular versions of particular frameworks, services, etc that are incompatible with those which the application server offers. In those cases, you usually need to fiddle with the application server, and in some cases, what you would like to do might not even be possible with your application server.

    For example, Weblogic 10.x is a Java EE 5 application server and so it will offer by default JSF 1.2 and JPA 1. If you want to use something newer, you need to manually deploy some additional libraries (JSF 2.0), or patch the server (JPA 2.0).

    Another example: with Glassfish 3.1 I have not been able to use Tomcat EL intead of Glassfish EL. Tomcat EL supports varargs method call while Glassfish EL does not.

    That rigidness of Java EE application servers makes a lot of people prefer developing for a standalone servlet container such as Tomcat or Jetty, where you have nothing out of the box but the Servlet and JSP APIs, but you can manually put everything inside. You can also package it with your application, which is more comfortable when you are developing, but can give you problems if you deploy more than one application per container (waste of resources, classloading issues, classloader leaks, ...)

    UPDATE:

    There are some differences in using JPA in a SE environment (such as Tomcat) when compared to using JPA inside a Java EE container. Basically:

    • You have to manually manage EntityManagerFactory and EntityManager instances.
    • Tomcat does not do injection so @PersistenceContext annotation and similar ones do not work.

    Note that some containers (such as Spring) can be configured to hide these details, so you can work exactly as if you were inside a Java EE container.

    Read the JPA spec for details on running in SE environments instead of EE environments.

    Regarding another libraries, in general you will find some minor differences. For example, JAX-WS requires registering a servlet and a listener for your webapp, but anything else should be identical. Usually you can search the documentation for instructions on how to run the thing inside a standalone servlet container.