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. > 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. > 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
