Such an extension would be nice indeed. If you've got an idea about how to do it, I'm interested. That would probably have to be implementation-specific though. You'd need access to the internals of the framework.
- Olivier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart McCulloch Sent: 03 August 2007 17:19 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Rationale for not having a getClassLoader() methodinBundle 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) _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
