karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Classloading question (Spring DM + Felix)
Date Tue, 24 Sep 2013 19:38:14 GMT
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

Mime
View raw message