|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 47
Messages: 47
Messages: 47
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
"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.
|
|
|
Message #195375
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I still LOVE JDO.
I still LOVE JDO.
I'm sorry, but I find JDO is simpler and Better than EJB3.
|
|
|
Message #195380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
"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.
|
|
|
Message #195381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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" ...
|
|
|
Message #195387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well
in almost every EJB3 related topic at least one or two posters basically mention that you do not need a container for ejb3 persistence ;-)
|
|
|
Message #195388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nifty!
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!
|
|
|
Message #195390
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nifty!
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.
|
|
|
Message #195391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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).
|
|
|
Message #195397
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What I find most funny...
...is the people who poke fun at TSS and its worth seem to be the most avid readers and posters. :)
|
|
|
Message #195402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
Got questions? Contact sales@jboss.com!
Soz man, hope you can take it lightly ;)
|
|
|
Message #195405
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
check out Hibernate EntityManager
|
|
|
Message #195418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hahaha
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.
|
|
|
Message #195420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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
|
|
|
Message #195421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 entities are very different
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
|
|
|
Message #195422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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!
|
|
|
Message #195428
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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...
|
|
|
Message #195435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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.
|
|
|
Message #195448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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?
|
|
|
Message #195451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 entities are very different
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.
|
|
|
Message #195465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Afterwards
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.
|
|
|
Message #195466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB 3.0 persistence
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.
|
|
|
Message #195474
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Afterwards
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.
|
|
|
Message #195480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Afterwards
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.
|
|
|
Message #195481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Afterwards
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)
|
|
|
Message #195482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Afterwards
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.
|
|
|
Message #195488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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! :)
|
|
|
Message #195495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations
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
|
|
|
Message #195504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations
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
|
|
|
Message #195508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another advantage of annotations
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.
|
|
|
Message #195513
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another advantage of annotations
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.
|
|
|
Message #195514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations
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
|
|
|
Message #195515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
adjust your though patterns
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...
|
|
|
Message #195520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
adjust your though patterns
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
|
|
|
Message #195524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
adjust your though patterns
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.
|
|
|
Message #195529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
adjust your though patterns
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
|
|
|
Message #195561
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Getting started with EJB 3.0 persistence out-of-container
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...
|
|
|
Message #195658
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations
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...
|
|
|
Message #195678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Annotations
Workaround is to duplicate class definitions and to use common interface. It is not a problem if code is generated :)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
