aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: svn commit: r930209 [1/2] - in /incubator/aries/trunk/subsystem: ./ org.osgi.service.composite/ org.osgi.service.composite/src/ org.osgi.service.composite/src/main/ org.osgi.service.composite/src/main/java/ org.osgi.service.composite/src/main/jav
Date Tue, 06 Apr 2010 13:30:25 GMT
Please see replies in line.

On Tue, Apr 6, 2010 at 2:47 AM, Guillaume Nodet <> wrote:
>> Yeah, it's the same as the application installer.  It works with Felix
> Fileinstall
> which is used in Karaf (and Geronimo) to support file based deployments.
> This is the way i've done very basic testing (by using Karaf and creating a
> exploded
> subsystem archive in the deploy folder).

Ah I see.  I have been wondering how we can itest this stuff as I
don't see the prototype equinox that contains the impl of the RFC 138
available in maven central.

> Yes, I think so.  Feel free to go ahead.  As I said, I only committed that
> code so
> that you can have a look and start working on it if you want.

Ok great. I'll start making changes and if you don't like them, let me know :)

> Not only.  The coupling between the admin and its internal subsystems is
> quite loose.
> Actually, subsystems are not put into the internal map when installed, but
> only through those
> processed bundle notifications.  I'm not sure it's actually a good idea,
> because this means
> that a subsystem which is being installed will be made available for
> management before
> it is fully installed.   So this certainly need to be reworked in the future
> I think.

Yes I think the code is a bit confusing as when we detect bundle event
change we add the subsystem to the map or remove the subsystem off the
map.   We don't deal with the map for the install() method, but for
the uninstall() method, we remove the subsystem off the map.

I think we don't necessarily need the sync bundle listener.   We can
just process all the initial bundles then use install/uninstall/update
to manage the map, assuming we only care about the subsystems that are
installed via subsystemAdmin.  If you like that, I can try make the

> Once again, I don't consider any of this code as really working or final.
>  The only think which is working
> is the fact that you can install a subsystem and a composite will be created
> with the jars listed
> in the manifest.  It's a bit dumb and the NoOpResolver means that the only
> way to install a subsystem is
> by giving the location in the manifest:
> Manifest-Version: 1.0
> Subsystem-ManifestVersion: 1.0
> Subsystem-SymbolicName: woodstox
> Subsystem-Version: 4.0.7
> Subsystem-Content:
> stax-api;location=mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.stax-api-1.0/1.4.0,
>  stax2-api;location=mvn:org.codehaus.woodstox/stax2-api/3.0.1,
>  woodstox-core-asl;location=mvn:org.codehaus.woodstox/woodstox-core-asl/4.0.7
> It certainly don't imply that this is what should be used by end users.  I
> agree using urls inside the manifest defeats the purpose of
> the resolver, but currently we have none, so I found that quite handy.
> So the current code will be able to deploy those bundles, that's all.

Yep we need to add other ResourceResolvers going forward.   So which
framework impl jar is providing the CompositeAdmin service and
creating the composite bundle in the test?  Is your test case checked



View raw message