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 "Pernet, Olivier" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-08-03 07:10 Please respond to OSGi Developer Mail List <[email protected]> To "OSGi Developer Mail List" <[email protected]> cc Subject [osgi-dev] Rationale for not having a getClassLoader() method in Bundle Hi, I've came across postings on the jsr-291 mailing list (http://www2.osgi.org/pipermail/jsr-291-eg/2006-August/000169.html) that referred to a discussion taking place before the R4 release about giving access to a bundle's classloader through the Bundle interface. As it seems, it has been decided not to include it. What was the rationale for that ? I'm asking because this it proving quite inconvenient for me, as I'm trying to get RMI to work again in our system (www.smartfrog.org) after integrating with OSGi. I've used a proxy classloader just like this one: http://wiki.eclipse.org/index.php/BundleProxyClassLoader_recipe, but this causes problems with hash tables as the wrapped proxy obviously does not have the same hashcode as my wrapper. I've worked around the issue but it's quite kludgy. - Olivier _______________________________________________ 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
