I know about Newton, but I can't look too closely as I'm working on a LGPL-licensed project, whereas Newton is GPL'ed. But I know that they've been basically re-implementing RMI to work within OSGi, which sounds a bit heavy-handed.
I thought about loading a class from the bundle, mind you, but I'm installing bundles from users of our framework, so there's no class name I can look for by default : there might be anything in there. Now I could ask users to provide a class name in a custom manifest header, but that seemed too intrusive somehow. So my unintrusive kludgy workaround is this: I use a BundleProxyClassLoader, and I just need the equals() method to return true when comparing the real class loader to my proxy (well it would be nice to have hashCode() work too but to be any use it would need to be the same as the real class loader's before the proxy gets to load classes, which I didn't manage to do). So the first time a class is loaded by my proxy, it will look at the effective classloader of the loaded class, and if it's not one of the system class loaders (boot, extension, classpath, and the one of my framework's bundle), keeps a reference to said class loader. After which I can delegate equals() to the real thing. I hope you now understand I'd prefer to just have a getClassLoader() method in Bundle :) - Olivier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave Sent: 03 August 2007 17:56 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Rationale for not having a getClassLoader()methodin Bundle Also, if you really want the class loader of a bundle, it is not too hard to get. Just load a class (Bundle.loadClass) or otherwise get a class from a bundle (someObjectFromTheBundle.getClass) and then call Class.getClassLoader. As long as there are class loaders (and security does not prevent you from calling getClassLoader), you can always get a bundle's class loader that way. I just don't see introducing a Bundle.getClassLoader method for example. RMI support is a topic the OSGi Enterprise Expert Group is looking at. Paremus has already done much with OSGi and RMI. You might want to look at their Newton[1] project. [1] http://newton.codecauldron.org/ -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 "Stuart McCulloch" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-08-03 12:18 Please respond to OSGi Developer Mail List <[email protected]> To "OSGi Developer Mail List" <[email protected]> cc Subject Re: [osgi-dev] Rationale for not having a getClassLoader() methodin Bundle On 03/08/07, Pernet, Olivier <[EMAIL PROTECTED]> wrote: > Well, to my mind OSGi as a platform is meant to allow you to write more > fully-fetured components on top of a minimal environment. I think I've > read on the OSGi blog something like "there is no problem with not > including feature X, but there is a problem if feature X cannot be > implemented as a bundle" (sorry about paraphrasing, I cannot find the > blog post anymore). > > The decision to leave out ClassLoader access this cripples this ability > quite a bit. Existing Java APIs do make use of ClassLoaders (RMI being > my problem child here). this topic will become more important as OSGi moves into the enterprise space, but imho exposing the raw ClassLoader in such a public API could risk people grabbing it and expect it to behave like a standard delegating classloader. as you say, a lot of existing Java APIs make use of classloaders - perhaps it's possible to build a standard OSGi extension (with minor core changes?) that will help everyone by providing a way to inter-operate with such code. this would avoid an explosion of classloader adapters / bridges and could define a standard approach (and be just as useful as the ServiceTracker) > It's not that bad, as I said, I devised a kludgy workaround... But it's > certainly annoying. > > Also, I'd like to point out that "programmer use" is quite different > from "systems/framework programmer use". Which you want to enable too, > with the likes of Jboss, WebSphere... And our own SmartFrog too :) > making use of OSGi as an underlying platform. > > - Olivier > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave > Sent: 03 August 2007 13:46 > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] Rationale for not having a getClassLoader() > methodin Bundle > > I think the main reason is that it is generally thought that programmer > use of ClassLoader is a BAD idea. It is a tool for module systems (like > OSGi) to interact with the VM for class loading but the application > (i.e. > bundles) should not be using ClassLoader direcly. Thus after much > discussion in the OSGi expert groups, we concluded that directly > exposing a ClassLoader object from the OSGi API was a bad idea. Instead > we placed the necessary methods (load class, get resource) directly on > the Bundle object. > > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev > -- Cheers, Stuart _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
