The public draft of EJB 3.0 that was released last week introduces the concept of a new module type for Java EE, the persistence archive (PAR). Debu Panda describes the structure of the PAR module in his blog entry entitled "PAR - Birth of a new archive."

A PAR is essentially another JAR module meant for packaging a persistence unit or EJB3 entities. A PAR may contain the entity classes or references other JAR files that contain the classes.

He looks at the structure of the PAR module and dives into details of its deployment descriptor - i.e., persistence.xml - and how it can make EJB 3.0 compliant persistence providers plug-able with any application servers.

The provider element in the persistence.xml defines the persistence provider's implementation class for javax.persistence.spi.PersistenceProvider class and hence provides plug-ability of persistence engine with third-party J2EE containers. For example, many customers use Oracle TopLink CMP engine with Weblogic and Websphere and this integration are provided by TopLink in a proprietary manner. It will provide persistence providers like Oracle TopLink, JBoss Hibernate, JDO vendors implementing EJB3 persistence API to plug-into third-party application servers in a standardized manner.

I'm not against the use of another archive, but I was wondering if someone can point me to some materials so I can read *why* it was necessary.

From reading Debu's blog I understand what will be in it, but it seems like that information could just have easily be included in the ejbjar file? Like I said above, I'm interested in the reason why it couldn't/shouldn't be in the ejbjar file.

Was it because the future of the PAR is to be more then just J2EE? Maybe a future J2SE standard?

One last point: it seems like EJB3 beans have a ability to be more then just J2EE Entity Beans. I still think calling this spec EJBanything was a bad idea.

I'm not against the use of another archive, but I was wondering if someone can point me to some materials so I can read *why* it was necessary.From reading Debu's blog I understand what will be in it, but it seems like that information could just have easily be included in the ejbjar file? Like I said above, I'm interested in the reason why it couldn't/shouldn't be in the ejbjar file.Was it because the future of the PAR is to be more then just J2EE? Maybe a future J2SE standard? One last point: it seems like EJB3 beans have a ability to be more then just J2EE Entity Beans. I still think calling this spec EJBanything was a bad idea.

The biggest reason for the par is so that you do not have to specify the list of classes that will be persisted in metadata. If you are solely using annotations, then it becomes really easy to code your entities. YOu annotate your classes, jar them up, add a tiny persistence.xml to the jar, and deploy.

For many containers, like JBoss EJB 3.0, you don't even need to specify a persistence.xml file in your .par if you have defined the needed defaults within the JBoss global.

BTW, this .par file works in non JEE environments. So, if you have a bunch of .par files in your classpath, EJB3 Persistence will find them automatically.

The biggest reason for the par is so that you do not have to specify the list of classes that will be persisted in metadata.

Hmm... but someone's going to have to specify that list of classes, right?

At first glance, it appears that you have simply shifted that responsibility from the EJB configuration file to the build configuration file (e.g. build.xml) that will be packaging the PARs.

Given the choice, I probably would rather store the info in application configuration rather than build configuration, and simplify the packaging.

Hmm... but someone's going to have to specify that list of classes, right?At first glance, it appears that you have simply shifted that responsibility from the EJB configuration file to the build configuration file (e.g. build.xml) that will be packaging the PARs.Given the choice, I probably would rather store the info in application configuration rather than build configuration, and simplify the packaging.

Actually, the PAR allows you to do either one. As Bill mentioned, you can simply toss the classes in a PAR file and away you go, or you can list them in the deployment persistence.xml file so that they include classes in another JAR in the application. You can choose if you want it to be done at configuration-time or build time. Whatever fits in with your dev process.

-Mike

The biggest reason for the par is so that you do not have to specify the list of classes that will be persisted in metadata.

Hmm... but someone's going to have to specify that list of classes, right?At first glance, it appears that you have simply shifted that responsibility from the EJB configuration file to the build configuration file (e.g. build.xml) that will be packaging the PARs.Given the choice, I probably would rather store the info in application configuration rather than build configuration, and simplify the packaging.

Corby, you have a point, but it really depends on how you define your package structure, now doesn't it? You still have to make decisions on what your JAR structure will look like if you want to reuse any part of your application at all. I've always considered J2EE packaging a strength, not a weakness, both in theory and in practice.

Also, minor note...In JBoss EJB 3.0 we have had, and will continue to allow packaging of entities and peristence.xml within an EJB archive. This option may help a little with your concerns, but not totally.

Was it because the future of the PAR is to be more then just J2EE? Maybe a future J2SE standard?

It may or may not become more than a Java EE standard, but it does not depend on the fact that EJB components are being used. Whether it gets picked up to become a Java SE standard is a different question, but it can certainly be used outside of Java EE right now so we are ready for it to go wherever people want it.

YOu annotate your classes, jar them up, add a tiny persistence.xml to the jar, and deploy. For many containers, like JBoss EJB 3.0, you don't even need to specify a persistence.xml file in your .par if you have defined the needed defaults within the JBoss global.

The spec actually defines that the persistence.xml file be optional in the container, so all compliant containers should accept par files without one. Defaults would apply.

BTW, this .par file works in non JEE environments. So, if you have a bunch of .par files in your classpath, EJB3 Persistence will find them automatically.

To be more specific, in Java SE environments the persistence provider may locate just the persistence.xml files but not necessarily the PAR files. Some vendors may choose to provide a mechanism to auto-load par files similar to the container case where persistence.xml is not required. Outside the Container they may not even be packaged in PAR files, though. They could just as easily be in regular JAR files.

-Mike

Was it because the future of the PAR is to be more then just J2EE? Maybe a future J2SE standard?

It may or may not become more than a Java EE standard, but it does not depend on the fact that EJB components are being used. Whether it gets picked up to become a Java SE standard is a different question, but it can certainly be used outside of Java EE right now so we are ready for it to go wherever people want it.

YOu annotate your classes, jar them up, add a tiny persistence.xml to the jar, and deploy. For many containers, like JBoss EJB 3.0, you don't even need to specify a persistence.xml file in your .par if you have defined the needed defaults within the JBoss global.

The spec actually defines that the persistence.xml file be optional in the container, so all compliant containers should accept par files without one. Defaults would apply.

BTW, this .par file works in non JEE environments. So, if you have a bunch of .par files in your classpath, EJB3 Persistence will find them automatically.

To be more specific, in Java SE environments the persistence provider may locate just the persistence.xml files but not necessarily the PAR files. Some vendors may choose to provide a mechanism to auto-load par files similar to the container case where persistence.xml is not required. Outside the Container they may not even be packaged in PAR files, though. They could just as easily be in regular JAR files.-Mike

Thanks for the insight. I'm big on annotations, so the PAR file sounds like a good thing to me. I can create my classes w/annotation, use ANT to jar them into a PAR file, include it with my EAR, and publish.

Sounds good ;)

I guess we developers have a really hard time putting those map files in our class path and the putting the master xml cfg file in the classpath too. And then the hard part - jarring them up. Im in awe.

I guess we developers have a really hard time putting those map files in our class path and the putting the master xml cfg file in the classpath too. And then the hard part - jarring them up. Im in awe.

And what happens if you have made a slight mistake in your annotation/configuration? The usual unchecked exception?

Are you making a case for CHECKED exceptions? oh god.

The biggest mistake SUN made?

What does that have to do with PAR. The great "new archive".

Not that I care if its re: checked exceptions are good.

I guess we developers have a really hard time putting those map files in our class path and the putting the master xml cfg file in the classpath too. And then the hard part - jarring them up. Im in awe.

And what happens if you have made a slight mistake in your annotation/configuration? The usual unchecked exception?

Hopefully! Do you perfer Checked Exceptions?

EJB Annotations are meta-data about something that can't be checked at compile time. I don't unit test as much as I should, but I do write unit tests to check that all my entity beans function as I expect before I publish them. A few tests against each bean, and things are usually problem free by the time they get to the J2EE container.

Hopefully! Do you perfer Checked Exceptions?

I prefer no exceptions. Annotation/configuration just introduces additional complexity and new points of failure without much real benefit.

EJB Annotations are meta-data about something that can't be checked at compile time.

A liability, not a feature.

I don't unit test as much as I should,

Wo does?

but I do write unit tests to check that all my entity beans function as I expect before I publish them. A few tests against each bean, and things are usually problem free by the time they get to the J2EE container.

... until the next slight refactoring. This kind of programming doesn't scale beyond a petshop.

I prefer no exceptions.

and I would prefer to be rich and have magical powers.

Annotation/configuration just introduces additional complexity

Additional complexity compaired to what?

I would say they introduce different complexities. Working with relational databases is always going to create some level of complexity. JDBC, O/R Mapping tools, EJB3, and JDO, all have their complexities.

and new points of failure without much real benefit.

I don't think that there are new (added) points of failure, just different points of failure. If you use annotations then you are trading a potential failure of a SQL statement or XML file, for the potential failure of an annotation. Annotations have uses beyond EJB3, but *to me* some of the benefits of Annotations with respect to an EJB3 env are:

They provide a simple in-class way to override persistance defaults. For example, in general I only need to add annotations to a class when: there is a relationship, when I want to use a variable name that differs from a column name, or when I'm adding tuning parameters about how data should be loaded. When mapping to a schema that contains tables with well defined relationships and good column names I usually only end up with a handful of annotations. And the annotations are in the class right next to the block of code that they affect. As opposed to being off in some overly expressive XML file.

EJB Annotations are meta-data about something that can't be checked at compile time.

A liability, not a feature.

PL/SQL is the only langauge that I know of that allows for compile time checking against a database. For everone else working with RDBMS systems is a coding "liability". Annontations are no more prone to runtime exceptions then SQL statements in JDBC, or XML in a bean mapping file. If you write bad Annontation then you get an error. If you write bad sql you get an error. If the XML in your bean mapping file is wrong you get an error. etc.....

I don't unit test as much as I should,

Wo does?

People who work in larger teams on enterprise applications. In general the same people who like standardized API's and are looking forward to a persistance spec that includes the features and abilities of powerful and accepted technologies like Hibernate and Toplink.

Why? This seems like EJB 2-style thinking, i.e unnecessary complexity

Hibernate and JDO seem to work just fine without having to package everything up in .par.

It might make sense in a J2EE-environment but why do I need all the complexity and overhead of creating a .par in my development environment.

Chris

Enterprise POJOs blog - http://chris-richardson.blog-city.com
Author, POJOs in Action - http://www.manning.com/crichardson

It might make sense in a J2EE-environment but why do I need all the complexity and overhead of creating a .par in my development environment.

Uh, are you incapable of reading, or just trying to FUD away? No one is forcing you to use PAR files. You don't have to use them. They're not a necessity, they are optional for those who feel it is a better way to organize their app (which will be the majority I suspect). You don't *have* to use PAR files. Re-read the thread, it's been stated at least 3 times already. Three. At least three times. You don't HAVE to use PAR files. They are absolutely not required. It's already been stated clearly several times.

 - Don

It might make sense in a J2EE-environment but why do I need all the complexity and overhead of creating a .par in my development environment.

Uh, are you incapable of reading, or just trying to FUD away? No one is forcing you to use PAR files. You don't have to use them. They're not a necessity, they are optional for those who feel it is a better way to organize their app (which will be the majority I suspect). You don't *have* to use PAR files. Re-read the thread, it's been stated at least 3 times already. Three. At least three times. You don't HAVE to use PAR files. They are absolutely not required. It's already been stated clearly several times. - Don

Are you incapable of a civil reply, or just a total AH? Java EE advocates need to do the community a service by answering the real concerns of developers tired of being burned by complexity. Your attitude won't help convince anyone. Be an advocate, not an AH.

Be an advocate, not an AH.

Better an AH than a GH I suppose. FUD's fud. I'm going to call it when it's so blatant.

How's the JDO book coming by the way?

 - Don

Be an advocate, not an AH.

Better an AH than a GH I suppose. FUD's fud. I'm going to call it when it's so blatant.

Wikipedia (http://en.wikipedia.org/wiki/FUD) defines FUD as "a sales or marketing strategy of disseminating negative but vague or inaccurate information on a competitor's product".

So I'm not sure how that would apply to someone such as myself who is a user - not a vendor or open source developer with a particular product to push - of enteprise Java frameworks and makes an honest mistake of missing a sentence or two in the thread.

Moreover, wikipedia defines GH to be growth hormone or the IATA code for Ghana Airways so I'm confused by that part of your comment.

Having said that, as far as I can tell, the EJB 3.0 spec leaves the issue of packaging in a J2SE environment somewhat open - perhaps a .par, perhaps not. I would sincerely hope that vendors make it as simple as possible.

Chris

not a vendor or open source developer with a particular product to push

Yeah, except for the SIG you use which points to the books you're trying to hawk or the "Professional Services" (wikipedia that) you're trying to sell. Gee, nope, a book on POJO something or other, or "Professional Services", wouldn't benefit at all with a bit of rampant fuddage. LOL

Fud the fudding fudders.

 - Don

While many consultants and other sources of best practices have gone screaming from EJB (as it would seem Chris has), some have not. In fact, I'd expect a few of the less ethical oned to try to bilk developers with some poor quality books, just because they can ride the marketing tide and get on the shelves. If Chris was really "hawking" his material for the fast buck, and if his material was low quality, I'd expect him to ride the corporate wave. But he seems to be taking more of a grassroots approach.

By the way, congrat's on Toplink being the new EJB3 reference implementation.

-geoff

Hibernate and JDO seem to work just fine without having to package everything up in .par.

FYI, Hibernate has had the .har packaging format for a quite a while now. It's perhaps not quite perfect yet (the .par format is maybe a bit better thought out, frankly), and unfortunately it only works in JBoss.

But certainly a number of Hibernate users believe there is real value in the notion of a persistence archive, so please don't knock it until you tried it.

Chris, based upon my experiences with you in the past you have thrown a lot of stones at EJB 3. I am prepared to give you the benefit of the doubt now, though, and assume that you really are asking questions and not just casting badness for the sake of doing so.

Why? This seems like EJB 2-style thinking, i.e unnecessary complexity

EJB 3 packaging is exactly the opposite of EJB 2. In EJB 2 we were forced to create lengthy descriptors for every single aspect of every bean. It was compex and unnecessary. EJB 3 persistence archives allow little or no XML descriptors, no requirements to specify anything other than what you want to override the default value of, no limitations as to whether the classes are actually contained in the archive or just referenced there, shareable POJO class definition across multiple archives, and so forth. They allow for the simplest possible packaging strategy imaginable, while still providing more complex means of overriding and specifying more deployment information.

Hibernate and JDO seem to work just fine without having to package everything up in .par.

Hibernate provides some different deployment possibilities, one of which is to use a .har file for better integration with the JBoss server. JDO allows for a host of different and complicated deployment possibilities of .jdo files at varying levels of definition and location. TopLink also provides a combination of deployment and XML mapping files that allow for advanced mapping and deployment flexibility. The point is that all of these add value but none of these is absolutely required. They exist in case people need/want to use them. In EJB 3 you can simply take your .JAR file and change the "J" to a "P" and presto you have a container-supported persistence archive.

It might make sense in a J2EE-environment but why do I need all the complexity and overhead of creating a .par in my development environment.

It is neither needed nor complex. I think you have already been answered on this one, although I am a little dissappointed because when you got the answer that you actually did not have to use the complexity of changing a letter in your filename then in your last post you complained that EJB 3 was not specified very well because it left the issue of packaging too open. Not sure EJB 3 can ever satisfy you, then.

Hope this is enough to help you write that book of yours. BTW, I noticed that you added EJB 3 on the end of Spring, Hibernate and JDO. Don't feel like you need to add it just to satisfy the public if you don't really think that it is a good API, but if you do end up adding it please just ensure that you understand and correctly represent it.

Thanks,
-Mike

Chris, based upon my experiences with you in the past you have thrown a lot of stones at EJB 3.

And why not take a critical and objective look at any new technology? Its absolutely essential for the success of enterprise Java to do that and to understand the technology's benefits, drawbacks and when to use it. That's far better than following the hype and blindly adopting the technology and discovering N years later that it wasn't a good idea after all.

One goal of my book is to do just that. In the chapters about JDO, Hibernate and EJB 3.0 there is are sections about their strengths, their weakness and when to use them. Despite the hype that is all too prevalent these days every framework has its weaknesses, even EJB 3 (and Hibernate and JDO for that matter), and I think its necessary to discuss it.

Moreover, I'm writing the book from the perspective of someone who has spent the past 20 years building applications with all kinds of technologies - not as a consultant trying to spread and benefit from FUD.

With regards to my book's coverage of EJB 3/JDO/Hibernate: I'm human and therefore capable of making mistakes and misunderstanding things. I'd would welcome it if folks such as yourself reviewed chapters.

Chris

And why not take a critical and objective look at any new technology? Its absolutely essential for the success of enterprise Java to do that and to understand the technology's benefits, drawbacks and when to use it. That's far better than following the hype and blindly adopting the technology and discovering N years later that it wasn't a good idea after all.

Absolutely right. This may have been one of the problems with the early EJB specs ;-) We welcome constructive criticism from you and everyone else. It's the people that throw stones just to make the water splash that are not helpful. For those that are offering feedback because they do want a stronger Java I hope they will send their feedback to the feedback list ejb3-pdr-feedback at sun dot com so we can get their input directly and know of their concerns.

With regards to my book's coverage of EJB 3/JDO/Hibernate: I'm human and therefore capable of making mistakes and misunderstanding things.

Yes, of course we all are. You are just one of the few that are big enough to admit it.
 
-Mike

Seriously?
PAR?:) Who comes up with these ridiculous ideas?
ejb-jar.xml should have had this info starting with spec 1 (or at least in spec 2)
EJB is going to die people. It is a container-dependent architecture. Run away from EJB and embrace Spring and Hibernate and things will be all ok..Very flexible and extensible arch, I find.

Evolution is good...but EJB3 is a late evolution and copied loads from in-the-meantime-popular-Hibernate which many have already adopted(hence nobody sees value in going back to EJB:). EJB missed the boat! If spec2 had come up with things we saw in Hibernate things would have been different.

Evolution is good...but EJB3 is a late evolution

Later is much better than never! Most application developers I've spoken are excited about EJB3 and eagerly waiting for EJB3 spec to be finalized.

and copied loads from in-the-meantime-popular-Hibernate which many have already adopted(

EJB 3.0 looks lot similar to TopLink as well. But many customers do not like to use Hibernate or TopLink because these frameworks are proprietary and prefer to use a J2EE standard API and those users will have choice to use a POJO persistence API in the Java platform.

Do you know that Hibernate is a member of EJB 3.0 expert group?

hence nobody sees value in going back to EJB:). EJB missed the boat! If spec2 had come up with things we saw in Hibernate things would have been different.

Probably you are unaware or do not want to acknowledge the attention EJB3 has been getting

regards
Debu Panda

EJB is container-centric.
And each container has its own specific way of doing things (I know the trouble because I have ported an Orion app to JBoss and Weblogic)
If there was ONE official container I would agree with all you said. Using Spring and Hibernate (at least for now) there is only one setup one has to fight with.

So the late evolution of something already cumbersome is still cumbersome. EJB is one thing I could point out -from practical experience - as going against Sun's slogan : Write once and run anywhere:)

I have no clue why big companies waste time with EJB3 spec..beyond me. Using Tomcat, Spring and Hibernate any industrial strength application can easily be developed. So why use a high-priced (free) EJB server?

EJB is container-centric.

EJB 3.0 isn't.

I have no clue why big companies waste time with EJB3 spec..beyond me. Using Tomcat, Spring and Hibernate any industrial strength application can easily be developed. So why use a high-priced (free) EJB server?

Because it is always better to be able to get things from more than one source, and you won't need a server. There will be many implementations of EJB 3 persistence, including Hibernate. Many of these will be free and open source as well.

If there was ONE official container I would agree with all you said. Using Spring and Hibernate (at least for now) there is only one setup one has to fight with.

I like Spring too, it allows me to get a lot of milage out of a servlet container. That said there is no one offical persistance implementation in Spring. Spring/Hibernate is probably the most common, but there are many different combinations: Spring/Hibernate, Spring/IBates, Spring/Toplink, Spring/OBJ, Spring/JDO, Spring/JDBC. If you like Spring that is fine, but I'm sure you can understand why big corporations (or the industry as a whole) would have interest in a standarized persistance API. Spring adds persistance convience, but not persistance standardization.

** I'm sure, in the future, Spring will end up providing you the same persistance convience for EJB3 ;) **

I really don't know why big corporations throw money out the window buying pricey servers.

Because big pricey servers can provide lots of performance and reliability.

Big corporations hesitate to embrace open-source

Which is directly contradicted by the considerable use of Linux by such corporations.

because the blame can't easily be stuck on to one person or a group of persons if a technology goes south --also managers can't live without server-company-tech-support.

Well, yes.

That any sturdy, scalable, secure , easily modifiable(well all those things said in a J2EE arch book :) web application can be written with Tomcat, Spring and Hibernate is a fact.

No it isn't. Tomcat doesn't have many features of other apps servers. Certain fault-tolerance and failover features.

The 'everything can be done on the cheap with open source' idea is attractive, but unrealistic.