On Dec 6, 2010, at 11:02 PM, Gurkan Erdogdu wrote:

> Hello David,
> 
> I understand that some classloader problems have been occured on an OSGI 
> based 
> application/server.

As I tried to indicate in my post, these problems will occur in any environment 
that tries to isolate application and server classes.  While I ran into them in 
an osgi context, the particular classloader feature that causes the problem has 
nothing to do with osgi.

> 
> Using javassist was decided at the start of the project. All OWB modules have 
> been implemented/updated with respect to javassist usage. Therefore it may 
> not 
> possible to remove javassist completely and use other bytecode library in a 
> near 
> time. 
> 
> 
> But we can add some SPI interfaces for generating proxy classes and defaults 
> to 
> "javassist". If you wish to use another bytecode library, you could easily 
> implement those SPI interfaces that we did for other things. It may be 
> contained 
> in 1.2.0 (not 1.1.0)

I'm not understanding what you are saying.  Surely it is less work to replace 
javassist than put an spi layer between OWB and javasisst.  Are you saying that 
if I say tomorrow removed javassist in favor of proxy creation that did not 
require exposing server classes to applications that would not be acceptable 
for the next OWB release?  If so, why?

Hoping you can clarify what you mean,
david jencks

> 
> Regards;
> 
> --Gurkan
> 
> 
> 
> ----- Original Message ----
> From: David Jencks <[email protected]>
> To: [email protected]
> Sent: Tue, December 7, 2010 2:50:23 AM
> Subject: Proxy problems
> 
> I think there might be a problem with using javassist to build proxies.
> 
> jsr299 allows proxying default or package access classes.  
> 
> A very definite although hard-to-find-the-documentation-for requirement of 
> classloaders is that all the default access classes and subclasses of default 
> access classes in a package have to be loaded from the same classloader (not 
> just be in the same package).  (this has nothing to do with osgi and split 
> packages).
> 
> javassist proxies require access to some javassist classes.
> 
> Therefore any default access classes that need to be proxied need to be 
> loaded 
> in a classloader that can also load javassist classes.  This certainly 
> prevents 
> isolating application classes from server libraries and may be difficult to 
> arrange in some circumstances.
> 
> I think there are a couple of solutions available that use asm to construct 
> class proxies that only use normal jdk classes.  Is there any good reason to 
> use 
> javassist rather than something else?
> 
> thanks
> david jencks
> 
> 

Reply via email to