Attaching and dettaching EJB3 Entities

[dparrilla]

Hi,
we are trying to build an app using the new EJB3 specification on JBoss, and we have the following scenario:
1) A JBoss Server running the PAR component and several SLSB as a facade to the POJOs.
2) Several TOMCAT instances running remotely.
3) We don't want to build new Transfer Objects: we just want to recycle the already created POJOs in the PAR component.
4) The POJOs are transfered from the JBOSS server to the remote TOMCAT server and viceversa.

We have found that the POJOs Entitities have (strong) dependencies with Hibernate libraries, due to the lazy intialization, I suppose. Even using EAGER initialization of dependendencies between POJOs, the dependendencies are still there. So, we need to put several Hibernate libraries in the remote TOMCAT server (hibernate3, asm, asm-attr, cglib...) that should never be there.

I think I need some way to 'dettach' the Hibernate infrastructure from the POJOs when transfering to the TOMCAT server.

Anybody knows how to do this? Is this the right forum?

Thank you in advance
Diego

[gavin.king]

This is normal. Put the jars on the client.

[dparrilla]

> This is normal. Put the jars on the client.

Do you mean that we have to put all the plumbing around Hibernate in order to use Plain Old Java Objects remotely? If I want to get a little object graph from a remote server, why do I need them?

I think we need some kind of 'detach' process in order to remove the dependences in our POJOs before sending them through the network. Then, when I get them in the remote side, I can work with them without taking care of hibernate libraries and dependences.

In the other way around, from remote client to jboss server, it already exists the 'attach' concept thanks to 'merge'.

I think that if POJOs implement LAZY loading strategies, then it make sense to carry on with the Hibernate libraries. But why for EAGER?

Thanks for the quick response
Diego Parrilla

[ppc]

This is normal. Put the jars on the client.

Normal? why the client should know about _hibernate_ when the object should a POJO?

only to got org.hibernate.LazyInitializationException ??

[treespace]

They may be nothing more than decorative ornaments on the client side but the class loader will need to load runtime and class-resident annotations. That sets up a dependency right out of the box. That a class is required to extend a specific super type is what makes something lose its PO quality. A class that adds a type Complex can still get its POJO on. Dependencies aren't the defining characteristic IMO. EJB 2.0 required a magic super-type, a MOJO if you will.

[epbernard]

"ppc" wrote:

This is normal. Put the jars on the client.

Normal? why the client should know about _hibernate_ when the object should a POJO?

only to got org.hibernate.LazyInitializationException ??

Useful for collections too (especially DELETE_ORPHAN collections)

[ppc]

What I feel is some kind of contract violation in this implementaion (im not an ejb3 expert) but when for example using lazy loading strategy and accessing form a remote client you got an hibernate exception I feel that my client is not anymore indipendent from the underlayer implementation.
Ejb3 has been announce as back to "Plain Old Java Object" but this in the reality is not true.

[bill.burke]

I agree the specification should handle this problem, but the vendors on the commitee each had their own way of doing this and nothing could be agreed upon. I suggest sending some feedback to [e-mail]

[epbernard]

Actually LazyInitializationException will be replaced by EntotyNotFoundException in a future release of HEM, but this does not mean Hibernate.jar will not be required on the client side.
Your programmation model is POJO.