felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Using felix on the server side
Date Wed, 16 May 2007 20:46:00 GMT

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" <gnodet@gmail.com>
Subj:  Re: Using felix on the server side
Date:  Wed 16. May 2007 16:06
Size:  3K
To:  dev@felix.apache.org

On 5/16/07, Karl Pauls <karlpauls@gmail.com> 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 <gnodet@gmail.com> wrote:
> > On 5/15/07, Guillaume Nodet <gnodet@gmail.com> 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
> karlpauls@gmail.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/


--- message truncated ---


Mime
View raw message