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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >>> > >>>> Spring dm replaces the classloaders for the bundles. > >>>> > >>>> Sent from my pressure cooker. > >>>> > >>>> On Sep 23, 2013, at 23:04, Charles Moulliard <[email protected]> > 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
