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
