Alasdair
On 3 Apr 2010, at 06:51, Guillaume Nodet <[email protected]> wrote:
On Fri, Apr 2, 2010 at 23:03, Alasdair Nottingham <[email protected]>
wrote:
So comments on the current SubsystemAdmin:
1. How about a getSubsystem(String symbolicName, Version version);
That sounds much better than getScope() and getSubsystem(scope) imho.
2. What is the scope of SubsystemAdmin? Is it framework, composite
bundle, subsystem scoped?
Imho, composite. However, the SubsystemAdmin if inherited from its
parent
composite, it needs to be able to manage the composite it has been
requested
from. I.e. if you retrieve the SubsystemAdmin using a given
BundleContext,
the returned service will manage the composite from this
BundleContext.
So a given Subsystem admin manages the current subsystem and any child
subsystems?
3. What is the cancel method for?
Given installation and updates of subsystems will possibly download
a lot of
things,
the goal of this method is to be able to cancel an ongoing operation.
We could always use Future instead or define another mechanism, but
i'd
think it's a usefull
feature.
The API currently doesn't look like any of the methods might be
asyncronous, so this is odd. Also if they are async what happens if
you have multiple running at once. Which operation is canceled? I
think this needs work.
4. uninstallForced seems ugly is it needed?
Yeah, that one is probably not needed if we ensure that uninstall
(Subsystem)
will always uninstall
work, which sounds reasonable I suppose.
Thanks
Alasdair
On 2 April 2010 21:52, Alasdair Nottingham <[email protected]> wrote:
Hi,
Some comments. I'm sure I'll have more once I've had a chance to
catch
up.
Alasdair
On 1 April 2010 00:42, Guillaume Nodet <[email protected]> wrote:
Renaming the subject of this thread.
5. Subsystem.getState(). I wonder if we should reinvent here.
Is
there any reason why we don't make the return type of int, and
just
delegate this to the compositeBundle.getState(). Also, what if
the
composite bundle and constituents have different states. Does
this
method only work when the states are consistent among these
bundles?
My original idea was also to map closely to the composite state,
so I
don't
have any problem
using an int instead of an enum, though I think the state of
composite
is
an int because a composite
*is* a bundle and enums did not exist at the time the bundle
interface
has
been created.
However, Subsystem do not inherit the Bundle or CompositeBundle
interface,
so we could decide to
use an enum (because the state is semantically an enum).
I think we should stick with an enum. If the Bundle API had had
enum's
available
when it was originally written it would have used enums. Let's not
stick in the past.
That being said, the question you raise about the constituents
state is
important. We need to choose
whether we want to represent the state of the subsystem as an
aggregate
of
the constituents state or not.
That would surely be interesting, because you would know the
real state
of
your subsystem much more
easily. The problem is i'm not sure what would happen if one
of the
bundle can't start or is manually
stopped by the user. Would this leave the subsystem in the
STARTING
state
until the start or stop
method is called ?
I do not see how it can represent the aggregate state. If we have 10
bundles in a subsystem where
half are started and half stopped what would the aggregate state be?
In fact is this even a problem? Perhaps
this is the normal state. I think that the first thing to decide is
what does it mean to start and stop a subsystem.
Once we know what that means we can decide if a relationship with
the
bundles in a subsystem makes sense.
6. Subsystem.start() or stop(), I think it should throw either
BundleException or SubsystemException.
Yeah, SubsystemException would be fine. Currently I've defined
SubsystemException as being
a RuntimeException though ...
I suspect this might be a dangerous question to ask, but why a
RuntimeException :)?
7. The return type of Subsystem.getHeaders, do we want to use
Dictionary<String, String> or Dictionary to be consistent with
Bundle.getHeaders()? when we implement this method, we can just
delegate to compositeBundle.getHeaders.
Two things here. First, I'm not sure we would want to return the
composite
headers.
First because composite headers can't be localized, and second
because
i
was thinking
about returning the headers from the subsystem manifest as it was
installed, not of the
underlying composite (which includes computed headers for
package and
service policies).
So if we return directly the composite headers, it would surely
make
more
sense to use the
same type, but if we don't, i think using Map is more natural.
OSGi is
really the only place
that uses Dictionary instead of Map ;-)
I would use Map. If Map had existed when the OSGi interfaces were
first
created
it would have been used. I think we should stick with Map.
On Mon, Mar 29, 2010 at 6:34 PM, Guillaume Nodet <[email protected]
>
wrote:
FWIW, I've slightly updated the API with some feedback here and
mostly
two
other changes:
* moved some management methods from Subsystem to SubsystemAdmin
(update
and uninstall)
* make SubsystemConstants a non instantiable class instead of an
interface
Why move away from an interface?
--
Alasdair Nottingham
[email protected]
--
Alasdair Nottingham
[email protected]
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
