Gurkan, I too still do not 100% understand why the classloader access is a problem (from the spec side). Otoh I'm with David that it's easier to drop javassist and use cglib instead, because the real problem is not the proxy creation but the javassist specific MethodHandlers...
Otherwise I'd have dropped it in favour to James commons-proxy a long time ago... LieGrue, strub --- On Tue, 12/7/10, Gurkan Erdogdu <[email protected]> wrote: > From: Gurkan Erdogdu <[email protected]> > Subject: Re: Proxy problems > To: [email protected] > Date: Tuesday, December 7, 2010, 8:34 AM > >>>>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 >>>them in an > >>>>osgi context, the particular classloader > feature that causes the problem has > >>>>nothing to do with osgi. > > Java EE does not specify how application server classloader > works. Some servers > allows application class loaders access to server class > loader, some not. In > OWB, you are correct that proxy classes must access > javassist classes, because > we use javassist as an underlying bytecode library. We do > not implement OWB for > specific environments and classloader scenarios. > > Is it really pain that application classpath (classloader) > access javassist jar? > If so, what is problem? > > > >>>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. > >>> > What I was saying is that we may remove javassist > dependency from webbeans-core > project and put SPI that is responsible for returning > proxies. > You can implement SPI via ASM or any other byecode library > that produces proxy > objects that does not depend on any server classes. > > >>>Areyou 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? > > I did not mean that using other stuff would not be > acceptable. Just I > emphasized that OWB uses javssist heavily. It may not be > easy to remove > javassist code from proxy creation and use other bytecode > libraries. > > > Surely, we can do best to run OWB in Geronimo correctly. > > Thanks; > > --Gurkan > > > ----- Original Message ---- > From: David Jencks <[email protected]> > To: [email protected] > Sent: Tue, December 7, 2010 9:48:04 AM > Subject: Re: Proxy problems > > > 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 > > > > > > >
