aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: [DISCUSS] Subsystem API (was Re: Application API)
Date Thu, 01 Apr 2010 17:53:46 GMT

see comments in line.  Lin

On Thu, Apr 1, 2010 at 11:15 AM, Guillaume Nodet <> wrote:
> The CompositeBundle does not support update because there's no archive
> as for the bundle.  However, it does support an update(Map<String,String>)
> which updates the manifest (hence the import/export policies for services
> and
> packages).   I was thinking about leveraging that in addition to updating
> bundles,
> installing new bundles, removing old bundles, etc...
> So it would basically behave the same as a bundle, which means that when you
> update the subsystem, the symbolic name or version could change, though
> it has to be unique within the framework.
> This would mean that the symbolic name + version could change over time :-(

Ok that sounds reasonable.  How about we use Map<Long, Subsystem> as
the return type of SubsystemAdmin.getSubsystems()?

> Not sure what's your use case is.  How does the user start a bundle ?
> He has to know the id anyway, by iterating through bundles and finding
> the one he is interested in (might be using the symbolic name, or using
> the name and/or description).

Say for example, a user has installed 20 subsystems and tried to
update some of them.   The user knows each subsystem's scope well but
doesn't know the subsystem's id.

How about adding this convenient method in SubsystemAdmin - Subsystem
getSubsystem(String subsystemScope);?   With this, users can easily
retrieve the subsystem they need without iterate through the bundles

> No, i really don't think it's needed.   Even if we use a single instance of
> the SubsystemAdmin
> which is passed into the composite, detecting which composite we're in can
> be done
> by using a ServiceFactory instead.  That way, when a bundle requests the
> SubsystemAdmin,
> you know its bundle, hence it's composite (if any).
> So unless we actually want to show and manage the tree of subsystems from
> the top level
> (which i don't think is a good idea), I don't think we need those methods.
> I may be wrong, but i don't think it's technically a problem.

Just to make sure I understand you... are you suggesting to have the
SubsystemAdmin implement the ServiceFactory thus we can get hold of
the requesting bundle whenever the getService of the SubsystemAdmin
service is called?  Also, we assume the subsystem will always be
installed in the same level as the requesting bundle.

If that is the case, we don't need to pass in the bundle context of
the request bundle.
> Yeah, that's a tough problem.   Maybe we should have both somehow.
> I guess another problem is if we want to represent the state of blueprint
> bundles
> for example.  Because even if a blueprint bundle is active, it does not mean
> the blueprint container has been created successfully ...

That is an interesting thought.  we could do similar things...

> Yeah, I don't have any problem to add a getComposite() method.
> But in this case, I'm not sure if we need the getConstituents() anymore,
> because
> this mostly map to
>    getComposite().getSystemBundleContext().getBundles()

Ok I'm fine to remove the getConstituents, or keep it.

I have a question on install location/artifact of
SubsystemAdmin.install().  Can I assume the install location would be
a url location to the application that is in .eba format or exploded
eba dir?


View raw message