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.bosscha...@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 <ch0...@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.bosscha...@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.bosscha...@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 <seij...@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 <ch0...@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 <seij...@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 <ch0...@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
