EJB3 Persistence API: POJO entities' dependencies in clients

Discussions

EJB programming & troubleshooting: EJB3 Persistence API: POJO entities' dependencies in clients

  1. Hi, I was wondering about the ways to use entity POJOs outside their "base classpath location". The "base classpath location" is the one which was used when they were managed by (attached to) an EntityManager context. For example, using them as value objects when serialized and passed to remote clients, or just passed as parameters to local clients. In these cases, these clients will have to depend not only on the JAR where the entity POJOs are, but at least also on the JAR where the javax.persistence annotations are. In addition, if any other dependencies exist (like hibernate annotations for validation, for example, or any other dependency), these JARs should be in the runtime classpath of the client. Is there any neat workaround or some design pattern for this? In order to partially avoid the need to put these dependencies in the runtime classpath I can think of 2 non-neat solutions: 1. Building simpler POJOs that will be a true value object. 2. Using xml instead of annotations wherever possible. Both of these options remind me of EJB2.1 (means this can't be a good thing...). Amit ~~~~~~~~~~~~~~~~~~~~~~ BTW, The initial incentive for the question is places like Google Web Toolkit, which translates Java into Javascript, but allows a subset of the Java language. javax.persistence annotations are obviously not part of this subset and therefore fails to compile.
  2. 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
  3. 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.
  4. Hmm, perhaps check with the vendor[ Go to top ]

    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 3.2.4.2 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.