On Thu, Apr 1, 2010 at 19:53, Lin Sun <[email protected]> wrote:
> Hi,
>
> see comments in line. Lin
>
> On Thu, Apr 1, 2010 at 11:15 AM, Guillaume Nodet <[email protected]> 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()?
>
Yeah, no problems with that.
>
> >
> > 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
> themselves.
>
>
I have no problems adding a getScope() on Subsystem and getSubsystem(String
scope)
on SubsystemAdmin, but I want to make clear that the scope of a given
substem can change
over time if the subsystem is updated. It's not even guaranteed to be
unique in the whole
OSGi framework, only in a given composite.
> > 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, but that's really an implementation detail. Suffice to say that the
SubsystemAdmin will operate in the composite it is retrieved from and that
when a subsystem is created, a SubstemAdmin for this composite will be
made available.
The way we implement it is ... an implementation detail imho.
But yes, I'm thinking about registering a ServiceFactory as the
SubsystemAdmin
service so that we can retrieve the requesting bundle, hence it's
BundleContext
and/or the composite it lives in.
> >
> > 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...
>
Yes. I think it would be good to have blueprint, or any other extenders
be part of the state. But I've no idea how to do that in a generic way yet.
There's no way to even know a bundle needs to be extended !
>
> > 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.
>
Yeah, I'm still a bit worried to introduce the composite as I think in one
of the last EEG meetings,
the consensus was to hide composite rather than expose those. We'll see.
>
> 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?
>
I don't think passing an exploded url would work, because we need an input
stream
and you can't navigate through an exploded archive over http ...
Though it's not really hard to just create this stream on the fly.
If you look at felix fileinstall, it even provides a URL handler to do that.
So you could do:
admin.install("jardir:/aries/deploy/my.eba")
>
> Thanks.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
