- Posted by: Amit Kasher
- Posted on: November 28 2006 11:41 EST
- Re: EJB3 Persistence API: POJO entities' dependencies in clients by Nicke G on November 28 2006 14:49 EST
- Re: EJB3 Persistence API: POJO entities' dependencies in clients by Amit Kasher on November 30 2006 08:42 EST
- Hmm, perhaps check with the vendor by rob bygrave on November 29 2006 02:42 EST
Your pojos should only depend on the classes they extend. They do not per default depend on any persistance libraries, unless you specifically have made them to do so. Your pojos should be mapped using the non intrusive means of wireing that Hibernate supplies. Doing it correctly will give you none dependencies on other than business classes. After serialization and transporting to external clients, the pojos are in a non persistant state, and are not related to any db transaction or hibernate session. Regards N
Thanks for the reply! You say that my "pojos should only depend on the classes they extend" and that "They do not per default depend on any persistance libraries, unless you specifically have made them to do so". This is not 100% accurate, since per default they do depend on the annotations used to make them entities (at least the following annotations: javax.persistence.Entity and javax.persistence.Id). The concept of putting persistence-api.jar or any other jar in which these annotations reside (and others, if exist) inside any client working with these POJOs sounds broken to me. In some cases, this is at all impossible (like the GWT issue). However, I guess that this is the disadvantage of annotations vs XML. I just wished there was a good practical solution to it... Thanks again, Amit.
So you are using the Google Web Toolkit and it doesn't have javax.persistence.* hence your compile issue. Perhaps the only other suggestion to this problem would be to 'trick' the Google Web Toolkit somehow. You could compile against beans without any annotations and then later add the annotations back in perhaps? In regards the general question of POJO dependancies in a remote JVM. I'd suggest this is a little vague in the EJB3 Spec. Refer to section 220.127.116.11 Detached Entities and Lazy Loading. I can't see anything in the EJB3 spec to define what your serialization options are so I think you just have to ask your vendor. Lazy loading generally requires method interception (Some byte code enhancement via ASM/CGLib etc). So a detached POJO is likely to be 'enhanced' and not really very plain. That is it will have dependancies on vendor code to perform the lazy loading. The vendors could enable you to control the serialization so that you either get a 'enhanced lazy loading capable bean' or a plain java object with no lazy loading capability but also no vendor dependancies. I'm not which vendors support this level of control. I also don't think this would remove dependancies on the annotations as they are already part of the 'plain class'. (This serialization control is what I put into Ebean - check the Package com.avaje.ebean.io at http://www.avaje.org/static/javadoc/pub/index.html) Sorry, not sure if that helps you any - Rob.