I don't think this would work because the issue is not related to the class loader of bundles, since what they see from their parent is severly limited. The issue is the class loader of the framework and what it can see.
The real solution will be to somehow create a mechanism that creates the desired class loader for loading framework classes rather than relying on the application class loader. -> richard -----Original Message----- From: "Guillaume Nodet" <[EMAIL PROTECTED]> Subj: Re: Using felix on the server side Date: Wed 16. May 2007 16:06 Size: 3K To: [email protected] On 5/16/07, Karl Pauls <[EMAIL PROTECTED]> wrote: > > Good to know it actually works :-) > > FYI, classpath extension bundles do work as of the current trunk > provided Felix has been loaded using an URLClassloader (which is the > case in most situations e.g., JSE, JBoss) - just keep it in mind in > case you want to embedded Felix and use a custom classloader. > Bootclasspath extensions, however, are not supported. The same is true > for extension bundle refreshes in regard to automatic restarts of the > framework (updates are effective after a manual restart only). Could this be fixed by adding the bundle in a custom classloader and make all bundles use this classloader as the parent ? This would work wether Felix is loaded with a known classloader or not I guess. Furthermore, I have one more outstanding patch that fixes a > performance issue in case more then one (actually more like > 50) > Felix instances are embedded and are using the same extension bundles. > I intent to commit it soonish. > > regards, > > Karl > > On 5/16/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > On 5/15/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > Hi everybody ! > > > > > > We 're considering building the next version of ServiceMix ( > http://incubator.apache.org/servicemix/ > > > ) > > > on top of OSGI, and Felix sounds like a natural choice. > > > I've downloaded the code and build it and discussed a bit with Carlos > at > > > JavaOne who told me > > > about the new plugins. > > > So I've written a few osgi bundles ( > http://svn.apache.org/repos/asf/incubator/servicemix/branches/osgi/servicemix-osgi/ > > > ) > > > that are quite redundant with the MOSGi work. However when trying to > work > > > on a bundle for a JNDI implementation > > > based on xbean-naming, i have problems where the needed classes (the > jndi > > > initial factory class) are not available from > > > the client osgi bundle. Is there any way to solve this problem ? I > don't > > > really want to import the needed package > > > in all the bundles :-( > > > > > > I have used an extension bundle so that the needed bundle is added to > the > > container classloader and is available > > to all the other bundles without any modifications. It seems to work > > nicely. > > FYI, the config in the pom to generate the needed artifact is the > following > > > > <instructions> > > <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> > > <Export-Package>*;version=${pkgVersion}</Export-Package> > > <Import-Package>!*</Import-Package> > > <Fragment-Host>system.bundle; > > extension:=framework</Fragment-Host> > > </instructions> > > > > Btw, the MOSGi work seems nice, but there are some references to things > not > > > checked in. Is this part still > > > maintain ? Can someone check in the needed modules or I can provide a > > > patch to remove these references. > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Principal Engineer, IONA > > Blog: http://gnodet.blogspot.com/ > > > > > -- > Karl Pauls > [EMAIL PROTECTED] > -- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ --- message truncated ---
