Well unfortunately serialization is used in two distinct scenarios that
have vastly different de-serialization needs.  The current code is
written to handle both scenarios.  

The first scenario is serialization of the Hibernate Session itself such
that when that Session is then de-serialized all the proxies are
properly re-attached and usable.  

The other scenario is serialization specifically to send across a
class-loader boundary.  Theoretically we could just replace the proxy
with some "stand-in" object that just always throws a
LazyInitializationException.  But "this thing" still needs to be typed
correctly upon de-serialization in order to fulfill this role, so not
sure how to do that without the library being used for lazy proxy
generation being available on the client-side anyway.

Hibernate 3.2 does have the ability to use Javassist as the bytecode
library instead of CGLIB.  Hibernate 3.2 is the version I am expecting
to be used in EJB3 moving forward, so there is no problem if you are
fine with requiring Javassist on the client-side...

BTW, even with collections there is a possibility to still need access
to the proxy generation library on de-serialization.  This is because it
is *possible* to have a collection containing proxies in the case of
many-to-many associations.

-----Original Message-----
From: Scott M Stark 
Sent: Thursday, February 16, 2006 2:08 AM
To: jboss-development@lists.sourceforge.net
Cc: Steve Ebersole
Subject: RE: [JBoss-dev] client libraries on EJB3

But here we are talking about what exists after the object in question
has been serialized outside of the jvm. Does what your talking about
still apply in that situation? Regardless, I think this discussion just
further pushes for a unified javassist based proxy framework sometime
before ejb3 is finalized. 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Max Rydahl Andersen
> Sent: Wednesday, February 15, 2006 11:56 PM
> To: jboss-development@lists.sourceforge.net
> Cc: Steve Ebersole
> Subject: Re: [JBoss-dev] client libraries on EJB3
> 
> Hi guys,
> 
> Just bumping in here to tell the "whole" story about the 
> needed dependencies.
> 
> Here are the reasons for ever neededing any hibernate 
> specific stuff on a "client" side:
> 
> 1. Managing persistent collections
>     To track how a collection mutates so when the object 
> comes back to the server
>     hibernate can be more efficient when detecting and 
> executing changes.
> 
> 2. Handle lazy loaded objects
>     If lazy="true" on a class (it is by default) the object 
> can be a simple proxied
>     shell only containing the id. This allows us to use the 
> object in associations
>     without loading it (e.g. child.setParent(proxiedParent);) 
> and to throw an exception
>     if it is accessed without being previously loaded or in a 
> session (e.g.  
> proxiedParent.getName() goes boom)
> 
> #1 does not require proxy libraries AFAIK but I have not tested it.
> 
> #2 requires the proxy libraries (in 3.2 either javaassist or 
> cglib), I don't know if it is feasible
>     to generate something that is not dependent on the proxy 
> library and still be able to reassociate it
>     when it comes back to the server.
> 
> These are important issues that should be handled in 
> Hibernate 3.2 if at all possible. (cc'ed steve)
> 
> /max


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to