>>>Gurkan, I too still do not 100% understand why the classloader access is a >>>problem (from the spec side). Actually, classloader is not a problem. Javassist generated proxies depend on Javassit classes. Therefore, javassist library must be visible to application.
Java EE Specification does not define ClassLoader hierarchy of Java EE servers. I see no problem for using javassist in OWB. Problem is not on using Javassist or other libraries (cgilib, asm etc.). Problem is on the integration side. You can look at "Java EE Specification EE 8.3, Class Loading Requirements". for futher details of ClassLoaders From SPEC: The Java EE specification purposely does not define the exact types and arrangements of class loaders that must be used by a Java EE product. Instead, the specification defines requirements in terms of what classes must or must not be visible to components. A Java EE product is free to use whatever class loaders it chooses to meet these requirements. Portable applications must not depend on the types of class loaders used or the hierarchical arrangement of class loaders, if any. Applications should use the techniques described in Section EE.8.2.5, “Dynamic Class Loading” if they need to load classes dynamically. In addition to the required classes specified below, a Java EE product must provide a way to allow an application to access a class library installed in the application server, even if it has not expressed a dependency on that library. This supports the use of old applications and extension libraries that do not use the defined extension dependency mechanism. ........ Thanks; --Gurkan ----- Original Message ---- From: Mark Struberg <[email protected]> To: [email protected] Sent: Tue, December 7, 2010 2:11:54 PM Subject: Re: Proxy problems 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 > > > > > > >
