[jboss-user] [EJB 3.0] - Re: Detach entities - Obtaining a clear pojo

Some really nice stuff in there, James. I like how you've removed the need for a base class. I wonder how far we can take this now... The latest revision of our class is now in package org.hibernate.collection to take advantage of the internal members of other classes in this package - I see some benefits to that design choice. However, there's a method in there requiring @Entity to be imported, and now we've made the EJB3 JARs a dependency on the classpath. I don't think we can do that. :) Hibernate isn't always (and most times isn't) being used strictly within EJB3. I'd like to come up with something that doesn't involve us crossing that boundary. Which got me to thinking. Why, if we're using EJB3 to manage our POJO Entities, it is acceptable to return an object with Hibernate classes to the client in the first place? JBoss itself is requiring EJB3 clients to know Hibernate's involved?! Shouldn't the container be removing all of that stuff for us once the object leaves the session/transaction? Then Hibernate would be completely transparent as the storage mechanism for CMP, and the application wouldn't need to know anything about it. Is it possible for the container to call some form of the utilities we've been talking about once a transaction is committed? It's smart enough to flush all necessary updates via the EntityManager. Would this break some rule? Once the transaction is done and the EntityManager flushed, session closed - remove all Hibernate Impls from the (now detached) entity. Same case for is the entity crosses a (network | JVM) boundary, leaving the session entirely. Would this prevent a reattach? Seems like we want something pretty simple: 1) Remote client requests object. 2) EJB3 looks it up, does appropriate (configured) cascades for CMRs, returns it. 3) Client can access all members of the object returned. Not too much to ask, is it? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969989#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...