Sahoo's Blog

Why do I not have to use .par file to bundle my EJB 3.0 entity beans?

Public Review version of the Java Persistence API (JPA) spec suggested a new extension par be used to bundle EJB 3 persistence entity beans. It also suggested a new module type called persistence to be used in application.xml, if user uses an application.xml in their ear file containing persistence entity beans. (Note application.xml is optional starting with Java EE 5.)

Lot of developers still believe that .par is needed. Looking at the comments in theserverside.com to an earlier posted tutorial showing how to use JPA in web application it is very clear that user community do not want a proliferation of extensions used in Java EE platform. Here is a good news:
.par is not needed any more -- take a look at latest XML schema of application.xml posted in project glassfish web site. There is no mention of persistence module type.

Here is a simple convention (rule you may say) followed in Java EE platform from early days:
Any jar-format file that packages classes that can be directly loaded by a class loader ends with a .jar extension. e.g. jar files containing EJB classes, application client classes, utility classes all end with .jar extension (not even .zip). This is precisely why, bundled optional libraries must only be .jar files as mentioned in chapter #8 of the Java EE 5 platform spec available here .

As you can see .ear, .war and .rar do not fall into this category, as they do not package classes directly inside them which are used by a standard class loader. Note that although .war sometimes directly contains classes that are used by an applet, but the applet container is not given the .war file, instead it downloads the classes from the web server.

I must say having this convention prevented introduction of .par file and it is a relief. This kind of convention is also getting into Java SE, because I have heard in Java SE 6 (mustang) there is going to be a facility to specify a directory in the CLASSPATH environment variable and VM will look for all *.jar files in that directory and add it to CLASSPATH automatically.

So if you want to write portable applications, stick to these principles. Sun's next version of application server which is being develped in open sorce project named glassfish does not require any such extensions like .ejb3 or .par.

As a result of this not requiring .par files, the most notable simplification is:
You don't always need an .ear file to use EJB 3 persistece entity beans in Java EE platform. You can bundle them in .war files and deploy .war directly if you are developing such an app. e.g. see tutorial showing how to use JPA in web application. You could even take such a war file and use it in a Java web server, if that supports JPA. You can bundle the entity classes along with ejb classes in an ejb-jar and deploy the ejb-jar directly.

Similarly many developers think EJB 3 session beans have to be packaged in a jar file with extension .ejb3. Let me tell you, that was JBoss specific. I am not up-to-date with recent developments in JBoss, so not sure if they still require this and what are their plans.

Comments

• Thanks for the explanation! It is great to have this spelled out. And, of course, it is great not to have to worry about .par.

  Not having to worry about .ear is even better. But when I tried it, it didn't seem to work for session beans. I just use a .war file, exactly as in your persistence example. I have a JSF-managed bean with an @EJB-annotated session reference field. The session bean interface and implementation are defined inside a JAR file in WEB-INF/lib. Unfortunately, the dependency injection fails in GlassFish build 30.

  If I use a .ear file that contains separate .war and .jar files, everything works ok.

  Is this a temporary glitch, or is .ear required for getting dependency injection to work?

  Thanks,

  Cay

  Posted by: cayhorstmann on December 07, 2005 at 07:06 PM

• ear is not required to get dependency injection to work. The issue is you can't bundle SessionBeans inside war file. You have to package session beans/cmp entity beans in a separate ejb-jar file and then (unfortunately) package both in an ear file. So I don't think it is a dependency injection issue. By the way, give a try with verifier. You run it like this:

  $GLASSFISH_HOME/bin/verifier /home/foo/example.ear/war/jar

  I am in the process of posting another example that shows war->ejb->entity. Watch out in this section.

  --Sahoo

  Posted by: ss141213 on December 07, 2005 at 08:08 PM

• Sanjeeb, you rock in so many ways. Thanks for this explanation!
  Dan Greening

  Posted by: greening on December 07, 2005 at 11:39 PM

• "Any jar-format file that packages classes that can be directly loaded by a class loader ends with a .jar extension"

  This is actually not fully true for the now dead par archive.
  As part of the container / persistence manager contract is the notion of classfile transformer and the fact that the entities has to be loaded by a specific classloader in order to be enhanced.

  Posted by: epbernard on December 08, 2005 at 10:18 AM

• You mentioned:
  ----
  "Any jar-format file that packages classes that can be directly loaded by a class loader ends with a .jar extension" This is actually not fully true for the now dead par archive. As part of the container / persistence manager contract is the notion of classfile transformer and the fact that the entities has to be loaded by a specific classloader in order to be enhanced.
  ----

  Can you please explain how ClassFileTransformer is coming into picture. I know a persistence provider can set up ClassFileTransformer when container calls PersistenceProvider.createEntityManagerFactory(PersistenceUnitInfo) and in such a case a container must use that transformer to transform classes before loading them. But how is it making the original statement incorrect? It's actually container which provides a class loader to the persistence provider to read the original byte code.

  
  Thanks,
  Sahoo

  Posted by: ss141213 on December 08, 2005 at 10:29 AM

• Some notes:
  Correct, next version of spec .pars are gone, but a persistence.xml file is required. Persistence Jars will be deployable almost anywhere: EAR/lib, ejb.jar, and WEB-INF/lib.

  As for the .ejb3 file name in JBoss? We used this extension in JBoss 4 so that our EJB 3 container could be installed into JBoss 4 as a snap-on extension and still live side-by-side with our older EJB 2.1 container without breaking backward compatibility or any J2EE 1.4 requirements. We have not gotten any complaints or that this was such a big deal (it is not). JBoss 5 will be Java EE 5 compliant and will support such deployments. Until then, EJB 3 is a proprietary add-on to JBoss 4and cannot change the J2EE 1.4 EAR packaging requirements.

  Bill Burke
  JBoss Inc.

  Posted by: patriot1burke on December 08, 2005 at 11:33 AM

• I guess the "that can be *directly* loaded by *a* class loader" confused me and I read it in different ways. The way you load entities is constrained when implementing a persistence provider loading a persistence archive.
  Apparently, I should have read this sentence only in the light of the zip archive structure used :-)
  

  Posted by: epbernard on December 08, 2005 at 02:35 PM

This work is licensed under a Creative Commons License.