karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Moulliard <ch0...@gmail.com>
Subject Re: Classloading question (Spring DM + Felix)
Date Tue, 24 Sep 2013 19:53:10 GMT
In my case, one of the bundle is also a Spring DM bundle and most probably,
the way that Spring DM uses to load the classes is not synchronized with
OSGI Refresh ?


On Tue, Sep 24, 2013 at 9:38 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Hi Charles,
>
> I don't have a Karaf 2.3 ready, but I tried this on 3.0/trunk:
>
> It contains the following bundles:
> [  39] [    Active] [   30] Apache Karaf :: JAAS :: Modules
> (3.0.0.SNAPSHOT)
> [  55] [    Active] [   30] Apache Karaf :: JAAS :: Command
> (3.0.0.SNAPSHOT)
> 55 depends on 39 (imports package org.apache.karaf.jaas.modules)
>
> I go:
> karaf@root()> uninstall -f 39
> karaf@root()> refresh -f 55
>
> Then, when I do:
> karaf@root()> list -t 0 | grep 55
> I get:
> [  55] [ Installed] [   30] Apache Karaf :: JAAS :: Command
> (3.0.0.SNAPSHOT)
>
> which means that bundle 55 could not be resolved...
>
> Cheers,
>
> David
>
> On 24 September 2013 20:12, Charles Moulliard <ch007m@gmail.com> wrote:
> > Hi David,
> >
> > I have done a test on Karaf 2.3 but running refresh on the bundle having
> > dependencies with a bundle which is not longer there doesn't and status
> of
> > this bundle is still "active"
> >
> > 1) Installed
> > [ 304] [Active     ] [            ] [Started] [   60]
> > plainAndSimple-context.xml (0.0.0)
> > [ 306] [Active     ] [            ] [       ] [   60]
> > wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0 (0)
> >
> > JBossFuse:karaf@root> packages:imports 304
> > wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0
> (306):
> > org.jboss.fuse.training.jar; version=0.0.0
> >
> > Bundle 304 = Spring XML Bundle
> >
> > 2) Remove bundle 306 exposing the package :  org.jboss.fuse.training.jar
> >
> > JBossFuse:karaf@root> uninstall 306
> > JBossFuse:karaf@root> packages:imports 304
> > wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0
> (306):
> > org.jboss.fuse.training.jar; version=0.0.0
> >
> > 3) Run refresh on bundle importing this package
> > JBossFuse:karaf@root> refresh 304
> > JBossFuse:karaf@root> packages:imports 304
> > wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0
> (306):
> > org.jboss.fuse.training.jar; version=0.0.0
> >
> >
> > Regards,
> >
> >
> >
> > On Tue, Sep 24, 2013 at 8:51 PM, David Bosschaert <
> > david.bosschaert@gmail.com> wrote:
> >
> >> One more thing. Restarting a bundle doesn't re-resolve it. It keeps
> >> the wirings as they were created during the resolve phase.
> >> You have to refresh it to get that behaviour. If your bundle A depends
> >> on bundle B and you uninstall bundle B, you can restart A.
> >> But when you refresh bundle A you'll notice that it won't resolve any
> >> more and at that point you can't start it any more either...
> >>
> >> On 24 September 2013 19:35, David Bosschaert <
> david.bosschaert@gmail.com>
> >> wrote:
> >> > Yes, I'm pretty sure Blueprint doesn't replace the OSGi classloaders.
> >> > However OSGi classloaders support the concept of Bundle Revisions [1].
> >> > As long as existing bundles refer to classes from a Bundle, even if
> >> > that bundle is updated or uninstalled a Bundle Revision is kept around
> >> > for it until the last reference is gone.
> >> >
> >> > Cheers,
> >> >
> >> > David
> >> >
> >> > [1]
> >>
> http://www.osgi.org/javadoc/r5/core/org/osgi/framework/wiring/BundleRevision.html
> >> >
> >> > On 24 September 2013 19:32, Johan Edstrom <seijoed@gmail.com> wrote:
> >> >> In the blueprint case I think and for this case it probably is
> cleanup -
> >> >> ie like commons-logging in Tomcat then, you keep refs to something.
> >> >>
> >> >>
> >> >>
> >> >> On Sep 24, 2013, at 12:29 PM, Charles Moulliard <ch007m@gmail.com>
> >> wrote:
> >> >>
> >> >>> And Blueprint too .... as i have done a test and behavior is the
> same
> >> >>> Personally I would prefer that we improve that. Otherwise what
will
> be
> >> >>> here the benefit to promote OSGI ?
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Sep 24, 2013 at 6:44 PM, Johan Edstrom <seijoed@gmail.com>
> >> wrote:
> >> >>>
> >> >>>> Spring dm replaces the classloaders for the bundles.
> >> >>>>
> >> >>>> Sent from my pressure cooker.
> >> >>>>
> >> >>>> On Sep 23, 2013, at 23:04, Charles Moulliard <ch007m@gmail.com>
> >> wrote:
> >> >>>>
> >> >>>>> Hi,
> >> >>>>>
> >> >>>>> Is there a reason why when we deploy  2 bundles where Bundle
A =
> >> Spring
> >> >>>> DM
> >> >>>>> project = Spring XML File + Bean initialized using Class
exposed
> by
> >> >>>> Bundle
> >> >>>>> B that when we remove Bundle B, the Bundle A (after osgi;restart)
> >> still
> >> >>>>> contain Class from Bundle B ? Does it work like that with
Aries
> >> >>>> Blueprint ?
> >> >>>>>
> >> >>>>> Scenario
> >> >>>>>
> >> >>>>> 1) Package a bundle B containing a class
>  com.mycompany.HelloWorld &
> >> >>>>> exporting this package
> >> >>>>> 2) Package a Spring XML file creating a bean
> >> (com.mycompany.HelloWorld)
> >> >>>> as
> >> >>>>> a Bundle A
> >> >>>>> 3) Deploy Bundle A, B
> >> >>>>> 4) Start them and verify in the log that by example init
method of
> >> >>>>> HelloWorld has been called
> >> >>>>> 5) Stop Bundle B, remove it
> >> >>>>> 6) Restart Bundle A = Spring project. No error occurs !
> >> >>>>>
> >> >>>>> Regards,
> >> >>>>>
> >> >>>>> --
> >> >>>>> Charles Moulliard
> >> >>>>> Apache Committer / Architect @RedHat
> >> >>>>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Charles Moulliard
> >> >>> Apache Committer / Architect @RedHat
> >> >>> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
> >> >>
> >>
> >
> >
> >
> > --
> > Charles Moulliard
> > Apache Committer / Architect @RedHat
> > Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>



-- 
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message