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
