In various EJB3-related discussions, there's been mention of two different module types: ".ejb3" and ".par," with rare explanations of the two module types. In "PAR Module - DOA," EJB evangelist Debu Panda formally announces the death of the ".par" module type, with ".ejb3" being a JBoss-specific extension (due to go away when EJB3 support is finalized, in all likelihood.) Sahoo Sandeeb had already made the proclamation, but apparently the message didn't go out.

So be aware that existing deployments (if there are any!) that rely on the .ejb3 and .par deployments (as described in the JBoss Trailblazer application, for example) will not conform to the final EJB specification.

I have to say I am glad that the .par is going the way of the Dodo. One of my early reactions when I began researching the JBoss EJB3 implementation was to wonder why there was a need for a seperate entity bean archive.

I did quite like the .ejb3 extension though. It is descriptive and to the point. In my opinion, keeping .ejb3 but making it a deployment archive for both session and entity beans would be preferable to two different archives.

In my opinion, keeping .ejb3 but making it a deployment archive for both session and entity beans would be preferable to two different archives.

You can package EJB3 session and entities in ejb-jar modules and you do not need a special extension like .ejb3. The ejb-jar allows packaging both EJB 2.x and EJB 3.0 beans so it will allow you interoperate between these versions and thus providing capabilities of incremental migration of your applications.

Also you probably do not want to leave the version# of technology you are using with your application module.

In Java EE 5.0, you do not even have to provide an application.xml in the EAR. The containers can introspect a module and findout its content. See my blog on this topic.


-Debu

So be aware that existing deployments (if there are any!) that rely on the .ejb3 and .par deployments (as described in the JBoss Trailblazer application, for example) will not conform to the final EJB specification.

JBoss uses the .ejb3 suffix because it is being deployed on JBoss 4.0. JBoss 4.0 is a J2EE 1.4 certified application server and we can only provide EJB 3.0 as an add-on feature because of this. In order to have a clean separation of the old EJB 2.1 container and the new EJB 3.0 container as well as letting people deploy EJB 3.0 on a production-ready application server (instead of a beta or alpha product like Oracle), we use the .ejb3 suffix to differentiate them to the deployer.

Bill

P.S. This has got to be the lamest blog I've ever read. Why not talk about some of the more complicated things that have changed, like the refactoring of Interceptors, instead of this superficial stuff? Better yet, why is TSS wasting our time with this junk?

This has got to be the lamest blog I've ever read. Why not talk about some of the more complicated things that have changed, like the refactoring of Interceptors, instead of this superficial stuff? Better yet, why is TSS wasting our time with this junk?

Hey Bill,
You may find this lamest blog but you can see the utter confusion in the development community about PAR module. Two customers asked me about this after couple days release of EJB3 Proposed Final Draft specifications. Not everybody has time to read the specification in the first week. You can see some postings in latest TSS threads including this one .

Some of these are due to your implementation and you never did care to clarify that this is your implementation specific (:

When I got a call about PAR module again from a consultant, thought I have a moral responsibility to clarify the confusion (at least for our customers and who read my blog), me being one of the first person who blogged about PAR module.

-Debu

Bill,
At some stage I think you did this choice to avoid too much latency at deployment time. Your EJB 3 container beeing based on the JBossAOP layer, you are crawling every class to find if there is an EJB3 annotation in there, which is time consuming.

I am sure you fixed that since my last try but this specific archive extension is already an interesting gotcha early EJB3 adopters needs to be aware of when using your tech preview.

Alex

Bill,At some stage I think you did this choice to avoid too much latency at deployment time. Your EJB 3 container beeing based on the JBossAOP layer, you are crawling every class to find if there is an EJB3 annotation in there, which is time consuming.I am sure you fixed that since my last try but this specific archive extension is already an interesting gotcha early EJB3 adopters needs to be aware of when using your tech preview.Alex

Well, you ahve to pay for this crawling somewhere, either with a deployment tool, or at runtime like we do. There is no way around this. As it turns out, it is insignificant compared time sink.