So comments on the current SubsystemAdmin: 1. How about a getSubsystem(String symbolicName, Version version); 2. What is the scope of SubsystemAdmin? Is it framework, composite bundle, subsystem scoped? 3. What is the cancel method for? 4. uninstallForced seems ugly is it needed?
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]
