Lucas Jellema has written an article called "Getting Started with EJB 3.0 Persistence out-of-container using the Reference Implementation (GlassFish)," which shows step-by-step how you can use the reference implementation to persist data with EJB3.0 persistence, including a service class and a data model.

It's good to see people documenting their experiences with the various containers; now we need to start seeing use cases and things that don't work with EJB3, so we can start building guidelines for when it should or shouldn't be used.

"EJB 3.0 persistence out-of-container"

WTF??? You can do that???

But I remember more than one TSS thread from a while back where people so much more knowledgeable and intelligent than I were explaining to me how that would never be possible!

What's going on here? You mean I can't believe everything I read on TSS anymore??

My world is crumbling around me.

Gavin, you're quite the kidder, ain'tcha! :)

The jokes. Always with the jokes.

...is the people who poke fun at TSS and its worth seem to be the most avid readers and posters. :)

What goes around, comes around. Has it ever not? So next time, watch what your INTELLIGENT heads spew from your mouth's. Better shut up and just put up.

"EJB 3.0 persistence out-of-container"WTF??? You can do that???But I remember more than one TSS thread from a while back where people so much more knowledgeable and intelligent than I were explaining to me how that would never be possible!What's going on here? You mean I can't believe everything I read on TSS anymore??My world is crumbling around me.

People have been criticizing EntityBean since it's inception. The main reason was you don't want to corrupt your domain/entity obejcts with some funny EJB interfaces. Besides this your domain object should not be constraint on any kind of container. Go and check the very early posts of serverside.com era. I am bit amaze what kind of people you have been arguing with lately.

People have been criticizing EntityBean since it's inception. The main reason was you don't want to corrupt your domain/entity obejcts with some funny EJB interfaces. Besides this your domain object should not be constraint on any kind of container.

Bear in mind that EJB3 entities are very different than EJB2 and prior entity beans. EJB3 entities do not have any interface requirements, and certainly do not rely on the presence of a container.

-Patrick

--
Patrick Linskey
http://bea.com

People have been criticizing EntityBean since it's inception. The main reason was you don't want to corrupt your domain/entity obejcts with some funny EJB interfaces. Besides this your domain object should not be constraint on any kind of container.

Bear in mind that EJB3 entities are very different than EJB2 and prior entity beans. EJB3 entities do not have any interface requirements, and certainly do not rely on the presence of a container.-Patrick-- Patrick Linskeyhttp://bea.com

Yes I know. The only thing is that it took almost 6 years what could have been easily done in very early days of EJB.

People have been criticizing EntityBean since it's inception. The main reason was you don't want to corrupt your domain/entity obejcts with some funny EJB interfaces. Besides this your domain object should not be constraint on any kind of container.

Bear in mind that EJB3 entities are very different than EJB2 and prior entity beans. EJB3 entities do not have any interface requirements, and certainly do not rely on the presence of a container.-Patrick-- Patrick Linskeyhttp://bea.com

Yes I know. The only thing is that it took almost 6 years what could have been easily done in very early days of EJB.

It is very easy to say that afterwards, but fact is that it took many trials and then two really good OR mappers (Hibernate and Toplink) to find out what is working and which approaches are dead end.
If anyone ever had anything to do with the really lousy early Object db standards you know what I mean (ODMG1.0)

But afterwards everybody is always wiser than upfront.

It is very easy to say that afterwards, but fact is that it took many trials and then two really good OR mappers (Hibernate and Toplink) to find out what is working and which approaches are dead end.

Not to mention the various JDO vendors and experts who were on the JSR 220 expert group, and presumably contributed to the specification.

People have been criticizing EntityBean since it's inception. The main reason was you don't want to corrupt your domain/entity obejcts with some funny EJB interfaces. Besides this your domain object should not be constraint on any kind of container.

Bear in mind that EJB3 entities are very different than EJB2 and prior entity beans. EJB3 entities do not have any interface requirements, and certainly do not rely on the presence of a container.-Patrick-- Patrick Linskeyhttp://bea.com

Yes I know. The only thing is that it took almost 6 years what could have been easily done in very early days of EJB.

It is very easy to say that afterwards, but fact is that it took many trials and then two really good OR mappers (Hibernate and Toplink) to find out what is working and which approaches are dead end.If anyone ever had anything to do with the really lousy early Object db standards you know what I mean (ODMG1.0) But afterwards everybody is always wiser than upfront.

My friend I am not here to win "who is wiser" contest. At least that is not my intention, specially in a community where people still can have a war on the text editors:-)

I don't know how long you have been particpating on TSS forum, but believe me many Java developers have been up front and criticizing entity beans way before you can imagine as well as way before many famous EJB vendors implemented the container managed persistence:-) Besides that Some of these developers also implemented the container managed persistence for some early EJB containers not to mention that most of them vainshed in the dot com bubble blast era. Besides that you don't need a trial and error to figure out every thing, some time it is just common sense.

BTW I just want to let you know I am not criticizing any one here. If it is any thing, it's an appreciation that finally we all learned how to do things in the right way.

My friend I am not here to win "who is wiser" contest. At least that is not my intention, specially in a community where people still can have a war on the text editors:-) I don't know how long you have been particpating on TSS forum, but believe me many Java developers have been up front and criticizing entity beans way before you can imagine as well as way before many famous EJB vendors implemented the container managed persistence:-) Besides that Some of these developers also implemented the container managed persistence for some early EJB containers not to mention that most of them vainshed in the dot com bubble blast era. Besides that you don't need a trial and error to figure out every thing, some time it is just common sense. BTW I just want to let you know I am not criticizing any one here. If it is any thing, it's an appreciation that finally we all learned how to do things in the right way.

Well the problem as I see it is less, that the implementation was broken and people saw it, that happens often (ODMG 1 I mentioned early is the perfect example of such an unusable spec) but to get it right.
Face it, at the time the entity beans were implemented first
to my knowledge there was no real well working object persistence layer experience on the java side.
ODMG 1 was a desaster, hugely to blame on the half baked OQL and a standard with holes bigger than a fishnet to ensure vendor apis have to be used.
Some of the stuff still was under research (lifecycle conditions how does the object lifecycle handling works best on an OO DB/ORM environment etc...)

So you have a broken implementation of a somewhat not fully
researched area, people said its broken, the standard was altered, people still said its broken. In the meanwhile several ORM implementations have arrived which got things finally right. The standard is altered a third time to adjust to this experience and got things finally dead right, and then people complain it should have been done right the first time.

Sorry, but that is somewhat harsh given the full situation.
And yes you are right some things are common sense, but many things not (having to define a query language on an OODB system which works really well is not a trivial task, hence the early oql implementations got the basic ideas right bug crumbled upon day to day needs, which also have to have set operations and reverse referencing in mind)
The query languages are the perfect example of saying this is common sense, but yet it took many years and trial and errors to got something scalable up and running in those systems, and yet there are still fallback options into lower parts of the query system just in case you need them (which you sometimes do)

Face it, at the time the entity beans were implemented firstto my knowledge there was no real well working object persistence layer experience on the java side.

your favourite TOPLink was there for Java, way before any one heard the EE's in Java. The Toplink people have brought years of experience(with all the trail and errors) from some other OO languages and gave us a pretty reasonable O/R mapping tool even then. It seems to me good or bad after so many years of trial and errors we are back to square one. We could have shorten the path, if we would have been open enough to learn from other people experience too.

in almost every EJB3 related topic at least one or two posters basically mention that you do not need a container for ejb3 persistence ;-)

http://www.javapolis.com/confluence/display/JP04/Gavin+King

Got questions? Contact sales at jboss dot com!

Soz man, hope you can take it lightly ;)

Gavin, I don't think you understood the article initially. Just saw "out-of-container" and rushed to conclusion without reading the whole article. May you need some more sleep, man! :)

I still LOVE JDO.
I'm sorry, but I find JDO is simpler and Better than EJB3.

While this capability is great, I really think the pursuing point from all vendors is a renewed 'out of the box' feature set with JSE 5. The EJB 3 spec is 'the new POJO'. With built-in support in all containers, you will probably see a rebirth of frameworks that piggy back on on EJB's interceptor stack and event model with simple annotations.

Again this "container"-thing...

I think in times where most of the so called "containers" implement their functionality using some sort of AOP-stuff, it is complete nonsense to make this distinction of "in container" and "out-of-container" ...

Wow, that's pretty nifty... It's nice to know we can develop STANDARDS-based J2SE ORM solution with EJB 3.0... Can't wait!

Wow, that's pretty nifty... It's nice to know we can develop STANDARDS-based J2SE ORM solution with EJB 3.0... Can't wait!

You have been able to do this for years with JDO, although now with the JDO 2.0 and EJB 3.0 standards things have certainly improved.

Well, it is nothing spectacular that entity beans can be used now outside of an ejb container: thanks to EntityManager ;) What I think is really valuable is that we finally have a standard and lightweight O/R mapping mechanism, hence application will not be coupled with proprietary frameworks (which can evolve in their own directions) but everything is abstracted by a standard.

Of course it really depends how providers are implementing the specs. Depending of the underlying mechanism that provider is doing to proxy the entity-bean can have a huge impact of the application performance. Remember that EJB 3.0 annotations have RetentionPolicy set to RUNTIME which means that reflection is used in there. What I would be interested to know is if provider is using dynamic proxies (loadtime weaving style which I would prefer because it performs qute well - or it should ) or plain reflection using java Proxy or something similat.

All we have to do now is wait for verdors to provide mature implementations of the specs (hopefully we'll have a lot of vendors to choose :D).

Remember that EJB 3.0 annotations have RetentionPolicy set to RUNTIME which means that reflection is used in there.

Any reasonable implementation will probably minimize the use of reflection to initialization / deploy time, so looking up annotations probably won't be that big of a performance hit.

-Patrick

--
Patrick Linskey
http://bea.com

Any reasonable implementation will probably minimize the use of reflection to initialization / deploy time, so looking up annotations probably won't be that big of a performance hit.

And also, reflection has been highly optimised in recent versions of Java - it doesn't have the performance hit it used to.

Remember that EJB 3.0 annotations have RetentionPolicy set to RUNTIME which means that reflection is used in there.

Any reasonable implementation will probably minimize the use of reflection to initialization / deploy time, so looking up annotations probably won't be that big of a performance hit.-Patrick-- Patrick Linskeyhttp://bea.com

Refelction needs to be used to introspect annotations, however I would think that a reasonable implemetation would use it, only for initialization time to create the proxy (loadtime weaving - AOP style). Once proxy is there during runtine the beans should be managed quite effective and without any reflection. You could contradict me saying that reflection (on Java 5.0) improved quite well (or JRockit is quite efficient) but still can't be really compared with dirrect bytecode method invocation (invokevirtual etc.). So at the end of the day, reflection is just one concern.

Marius

Your assumption is wrong.
Annotations (class retention and runtime retention) are structures that are in the bytecode. You can read them without ever loading the class or using java.lang.reflect, and this can thus be very fast without any kind of reflection related concern.
Of course, the reflect API also allow you to read the runtime ones - but that does not mean that all annotation based runtime / framework will use and possibly suffer from reflection in general.

Side note: interestingly out of the container Glassfish EJB3 (ie Oracle Toplink) requires a -javaagent option, which is a hint that bytecode manipulation is probably going on under the hood (and there is excellent ASM again as a dependency).
Kodo I think is quite similar with an enhancer, and Hibernate is using a cglib based proxy approach. So I am not sure someone is actually heavily using reflection there.
Left aside the impact delta between reflection and network roundtrip to database...

MariusYour assumption is wrong.Annotations (class retention and runtime retention) are structures that are in the bytecode. You can read them without ever loading the class or using java.lang.reflect, and this can thus be very fast without any kind of reflection related concern.Of course, the reflect API also allow you to read the runtime ones - but that does not mean that all annotation based runtime / framework will use and possibly suffer from reflection in general.Side note: interestingly out of the container Glassfish EJB3 (ie Oracle Toplink) requires a -javaagent option, which is a hint that bytecode manipulation is probably going on under the hood (and there is excellent ASM again as a dependency).Kodo I think is quite similar with an enhancer, and Hibernate is using a cglib based proxy approach. So I am not sure someone is actually heavily using reflection there.Left aside the impact delta between reflection and network roundtrip to database...

Alex, thanks for your reply. I am aware about Java 5 annotations and their retention policies ergo I should not have said "needs" in there (the right word probably would be "may" - sorry about the confusion). It is correct that this information exists at bytecode level, but it does not mean that vendors will not use reflection. I know that today's vendors for other appsrvs/frameworks (as you mentioned above) are using bytecode level manipulation using diferent tools, but the fact that EJB3 specs indicates that annotations have retention-poicy set to RUNTIME, nothing prevents a vendor to use reflection. All I'm saying is that before adopting a vendor for our applications, would be wise to ask the vendor how different concerns are addressed. As I said, reflection is just one concern. You correctly pointed that delta between reflection and network roundtrips can not really be compared but still we want fast application and we need to know the impact of EJB 3 O/R vendor implementation.
One other concern that one may have is when dealing with queries - remember N+1 query problem ? (there are solutions on the market today to solve this problem - one would be eager loading but that causes other problems that we may complain about - too much data :) ). So let's not forget that we are discussing entities outside of a Java EE container. This is why certain questions/concerns may rise.

Refelction needs to be used to introspect annotations, however I would think that a reasonable implemetation would use it, only for initialization time [...]

What I've seen so far is that Annotations reading at init time even through java reflection is faster than XML reading. So there is no real concern here.

Refelction needs to be used to introspect annotations, however I would think that a reasonable implemetation would use it, only for initialization time [...]

What I've seen so far is that Annotations reading at init time even through java reflection is faster than XML reading. So there is no real concern here.

I think you are correct, but the point was reflection vs. dynamic proxies via bytecode manipulation.

Refelction needs to be used to introspect annotations, however I would think that a reasonable implemetation would use it, only for initialization time [...]

What I've seen so far is that Annotations reading at init time even through java reflection is faster than XML reading. So there is no real concern here.

Out of curiosity: how much? A little bit faster, considerably faster or ashamingly faster?

Tried to compile and run the app. Got NPE the first time since in persistence.xml xmlns="http://java.sun.com/xml/ns/persistence" is not a valid url. Removed the the xmlns from the file and tried again. Got No Persistence provider for EntityManager named pu1. Used the last promoted build.

check out Hibernate EntityManager

Many topics, I've seen this Persistence out-of-container. I don't know why? Persistence in EJB 3.0 is very nice and powerful. For this post, no comments!

It's good to see people documenting their experiences with the various containers; now we need to start seeing use cases and things that don't work with EJB3, so we can start building guidelines for when it should or shouldn't be used.

This is a good point.

I want to emphasize first that I'm very positive on the app development options the Java Persistence API brings to the table. (While often referred to as "EJB3 persistence", the official spec name is Java Persistence API -- it is a separate spec distinct from the EJB3 "core" spec, precisely because the JSR220 expert group envisioned a future where it could be used both inside and outside of JavaEE environments.)

As with most technical endeavors, definining how the Java Persistence API programming model was going to work involved some tradeoffs. These were all made consciously by the expert group for very good reasons and no doubt many developers will happily accept them (certainly those already using Hibernate, TopLink, JDO, etc.), but it is still good to know what those tradeoffs are. When using the Java Persistence API, your application must handle some things that the container previously handled for you.

- There is no (visible) interception performed on the Java Persistence API object methods. So, any security auth checking, transaction starting/completing, etc. needs to be performed by whoever is calling the method. Since it was best practice already to call entity beans from behind some kind of facade such as a servlet or session bean, this shouldn't be a big change.

- Java Persistence API object instances are local-only. You can pass them by-value to another process, but they then lose their association with the EntityManager in your process. Any updates you make to that object after that point won't be made persistent unless you re-associate the object with its EntityManager. (You can re-associate the object with the EntityManager at a later time by using the merge() API.)

- Your application controls the instance lifecycle of Java Persistence API objects, and interacts directly with the "real" instance of your object.

- If you have a bi-directional relationship defined between two persistent objects and remove one of the objects, your application is responsible for updating the pointer in the "other" object.

Like I said, anyone already using Hibernate, TopLink, or a similar product is already familiar with these, but developers currently using pre-3.0 entity beans will need to be aware of them.

Perhaps I'm in the minority, but I don't see what the benefits of using annotations are here. Consider 2 domain classes that really would be reusable - a Path class that has a list of Location classes, where each Location has a latitude, longitude, and an elevation. And the Location class would have nice methods like "getDistanceTo(Location)" and other things that do nice math stuff for you. Domain objects that could really be reused on other systems. And I'd like to be able to save instances of Path to a database. But in making this code reusable, the last thing I'd want to do is specify table/column mappings that other developers would have to use (and I don't want to hand over the source code, in order to prevent it from being forked on a bunch of other projects). I assume there's some ability to override annotations, but wouldn't that be done externally, like in an XML file? In which case I'd find that more confusing - some mappings would be done in annotations, some would be overridden externally.

Are persistence annotations really an improvement over having all of the mappings externalized in XML files? I've been using Hibernate for a few years, and even on a project with over 100 classes mapped using Hibernate, the amount of XML was really quite easy to manage.

Maybe there's just some annotation Kool-Aid to drink and I've yet to do so. Part of me wonders if annotations are a reaction to how .NET developers could make a method a web service through some annotation-like syntax. That never seemed useful to me - sure, it's nice and easy, but on a large system, is that really the best way to manage what gets exposed as a web service? Same question for annotations - sure, a lot of cool things can be done with them, but are they really the best choice in the long run? Would like to know why others are excited about using annotations, and hopefully the answers are more than "XML is ugly", as there are some significant benefits to having metadata externalized in XML as opposed to inlined via annotations.

Rob

You will find divided opinion about using annotations to specify table and column names. Using annotations to specify table or column names is not very different from using embedded SQL in an application which was a common practice not so long back and many of those systems are still very much active in this internet world. Like every feature, this feature also have some valid use cases and it is not so useful in some cases (e.g. the one you pointed out).

I don't think there is anything wrong in having such a facility in Java EE platform. More over, I don't think Java EE 5 platform says any where that XML is ugly. Let users choose what they want to specify using annotations and what using XML DD. I see large applications using a mixed approach. In real world applications the way I see it being used is that the information that is taken at development time should be provided using annotations. Deployment time configuration information will be done using XML.

Finally as you pointed out, annotations certainly help in developing applications easily and quickly. This is where J2EE was loosing to .NET. One of the goals of Java EE 5 is to make the platform easy to learn/use. The reason you are seeing so many articles talking about annotations is probably because it is a relatively new language feature and people are trying to educate people about how to use it.

-- Sahoo

Well the poster before me pointed out that annotations help to develop apps more quickly.
The two most famous examples probably are
@Webmethod
and
@Transactional

in one case you do not get the whole wsdl-xml mess which is really lousy to handle, no stubs and no skeletons

in the other case all the transactional code is moved into one declaration above the method.
What happens here, is that the glue code, which was most of the times hidden in the pre web application area and suddenly moved into the app coding layer in the web application area, is moved back into the place where it belongs, the engines, and the libraries and the people finally can concentrate back on the application logic instead of having to juggle around glue code 80% of the times.

The other huge advantage of all this is, that generally if well designed (and the ejb3 annotations are really well designed) annotations are way less verbose than xml. They have a tighter syntax, are there where you need them most, right at the code and for most things introspection does the trick. A typical ejb3 entity bean usually has 2-3 annotations per class, compared to 10-15 glue field declarations in xml in the same xml file + a tld heading + the usual xml verbosity + you have to juggle two files at the same time constantly.

The only disadvantage you get is that you lose the central config point xml gives you, which can be a huge issue.

Don't forget also all the people who were happy XDoclet users, which have used annotations way before .Net came up, and may gladly migrate to standard annotations now in EJB3. Whomever prefers XML will be able to keep using it too, so I think this is a win-win solution.

Perhaps I'm in the minority, but I don't see what the benefits of using annotations are here. Consider 2 domain classes that really would be reusable - a Path class that has a list of Location classes, where each Location has a latitude, longitude, and an elevation. And the Location class would have nice methods like "getDistanceTo(Location)" and other things that do nice math stuff for you. Domain objects that could really be reused on other systems. And I'd like to be able to save instances of Path to a database.

I'm not keen on annotations here too. It is not actually transparent POJO persistence like Hibernate used to be for years. You have to import all that annotations into Your source code (On the other hand it's incredibly convenient, and IMO far better when it comes to maintenance).

Latest spec. provides alternative way using xml. But i'm still missing things like Hibernate's 'named entities'. There is no way to map one class few times in different contexts, thus really reuse basic entities within application. Typical problem is for example Address class. There is no need to have OfficiallAddress, and LivingAddress classes but only one class - Address reused in different contexts...

Artur

There is no way to map one class few times in different contexts, thus really reuse basic entities within application. Typical problem is for example Address class. There is no need to have OfficiallAddress, and LivingAddress classes but only one class - Address reused in different contexts...Artur

You have to get out of the xml thinking in this case, interfaces do the trick here...
two different interfaces on the same class basically give
the same result than having two different entity definitions
upon the same class with different attributes...

There is no way to map one class few times in different contexts, thus really reuse basic entities within application. Typical problem is for example Address class. There is no need to have OfficiallAddress, and LivingAddress classes but only one class - Address reused in different contexts...Artur

You have to get out of the xml thinking in this case, interfaces do the trick here...two different interfaces on the same class basically givethe same result than having two different entity definitionsupon the same class with different attributes...

But it doesn't resolve the problem. Consider this (assume, for sake of brevity it's unidirectional):

<code>
@Entity
public class Person {
  @OneToOne
  Address livingAddress;
}

@Entity
public class Enterpise {
  @OneToOne
  Address address;
}
</code>

Now assume that both addresses are stored in different tables or are 'components' (like in hibernate's "component" mapping) of their entities.

Additionally it's completly non intuitive. Why do I need to have an interface plus two clasess just to implement the same thing - Address. How Enterprise's Address is different from Person's Address or how living address is different from official/other address when thinking about domain model? I just don't want implement two classes + interface that abstracts exactly the same thing because of limitations of persistence layer. Just my opinion.

I think notion of named entities is one of the biggest improvements of hibernate since 2.0. And Gavin doesn't adds unecessary features - believe me :))).

Artur

How Enterprise's Address is different from Person's Address or how living address is different from official/other address when thinking about domain model? I just don't want implement two classes + interface that abstracts exactly the same thing because of limitations of persistence layer.

Why is it represented in different tables in your relational model. There must be a reason for that.

Why is it represented in different tables in your relational model. There must be a reason for that.

There might be plenty of reasons:

1. security (only authorized users can view/change personal data, but everyone can view Enterprise address) - speaking about security I mean phisical database security (roles/grants) ruled by law in many countries.

2. Sometimes it's convenient to store this type of data as a component (true one-to-one relation).

3. sake of normalisation, it's is not an elegant way to mix all addresses into one table (IMO) sometimes. For example what if i had select only enterprise addresses within NYC but not those connected to people, or what if had to send christmass postcards to people living in Poland, but of course it makes no sense to send it to both addresses (Living, Official)? And many, many use cases. (Of course I can use some kind of "type", but it's not elegant IMO).
 
4. lagacy database...

etc. etc.

Artur

I'm not keen on annotations here too. It is not actually transparent POJO persistence like Hibernate used to be for years. You have to import all that annotations into Your source code (On the other hand it's incredibly convenient, and IMO far better when it comes to maintenance).

Well, "convenient" and "maintainable" are real requirements - "transparent" is not. It's not like XML-based Hibernate applications had no dependency to Hibernate ;-)

Latest spec. provides alternative way using xml. But i'm still missing things like Hibernate's 'named entities'. There is no way to map one class few times in different contexts, thus really reuse basic entities within application.

Funnily enough, my original proposal for the EntityManager API actually did have support for named entities in it. And this was actually in the spec for quite a while (it might have even made it into the first spec draft, I forget now).

But what happened was that Oracle and Solarmetric wanted it taken out, and I figured "well, Hibernate did not even have this feature until 3.0, so clearly it was not such a critically huge issue for most people". So we took it out.

And I don't recall anyone emailing the EJB feedback alias asking for this feature - so you have only yourselves to blame if you need this j/k ;-)

A workaround is to use multiple EntityManagerFactory instances. But of course you can't then have associations...

Workaround is to duplicate class definitions and to use common interface. It is not a problem if code is generated :)

With EJB 3.0 writing an Entity bean and Session bean is just more than a cake walk... Really i love the EJB 3 specifications...