Hello David, I understand that some classloader problems have been occured on an OSGI based application/server.
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) 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
