On Mon, Mar 29, 2010 at 22:50, Lin Sun <[email protected]> wrote: > Hi > > I have some initial comments too. > > 1. I am curious why we want to reinvent a completely new interface > here instead of extending whatever Bundle or CompositeBundle provides? >
>From the initial feedback on the EEG, it seems people prefer to hide the underneath composites. > 2. Sybsystem state: should we use all uppercase like the bundle > states, for example ACTIVE instead of Active? > Uppercase is the convention when using static final constants. For enum values, I think the usual convention is to use CamelCase, as for class names. > 3. In the context of subsystem, I think resolved state can mean the > subsystem is resolved and able to start without any Resolver > Exception/Error. I am not sure what the Subsystem.resolve() method > would do? > As answered to Alistair, I was thinking about moving all the constituents into the resolved state, but I don't really have a strong opinion on this method. I just thought it could be usefull. > > 4. SubSystem.start(), stop(), etc should throw BundleException or > perhaps SubSystemException. > They do. Just that SubsystemException is a RuntimeException. But yeah, it makes sense to add it nonetheless. > > 5. SubSystemAdmin.getSubSystems(), would that return all subsystems in > all the frameworks or the current framework? same comment for > SubSystemAdmin.install(), which bundle context does it use to install > the subsystem? > To be discussed really. If we really want to manage a tree of subsystems, I'd say it should be done per level. i.e. you only see the subsystems at your level, and you'd have to find the SubsystemAdmin in the nested framework to find inner subsystems. Though it may make things a bit more to difficult and manage. I suppose it all comes down to what we will usually see. If we think most of the users will manage nested subsystems, we need to design the api around that, so maybe using a more explicit tree. IF we think users will mostly deal with the upper level, the current one would be more suited imho. > > Thanks > > Lin > > On Fri, Mar 26, 2010 at 10:27 AM, Guillaume Nodet <[email protected]> > wrote: > > Sorry, forgot to give a pointer: > > > > > http://svn.apache.org/repos/asf/incubator/aries/trunk/subsystem/subsystem-api/src/main/java/org/apache/aries/subsystem/ > > > > On Fri, Mar 26, 2010 at 15:27, Guillaume Nodet <[email protected]> wrote: > > > >> I've just checked in a user-oriented API for subsystems (which I hope > can > >> be a superset of applications). > >> This is not the SPI part, but simply what the user needs to manipulate > >> subsystems at runtime. > >> The design has been chosen to be much more familiar to the OSGi API for > >> bundles. > >> > >> I'm planning to continue on this area when time permits, but I welcome > >> everyone to have a look and give feedback. > >> > >> On Thu, Mar 18, 2010 at 18:16, Jarek Gawor <[email protected]> wrote: > >> > >>> Hi all, > >>> > >>> I have a few questions / comments on the Aries Application API. > >>> Specifically, about AriesApplicationManager and > >>> AriesApplicationContextManager API. > >>> > >>> The application-management module provides a default implementation > >>> for the AriesApplicationManager API while the application-runtime > >>> module provides an example implementation of the > >>> AriesApplicationContextManager API. It is expected (as indicated by > >>> JavaDoc) that different server runtimes will provide their own > >>> implementations of the AriesApplicationContextManager API. > >>> > >>> So it seems to me like the AriesApplicationContextManager is more of a > >>> SPI - something that user shouldn't/wouldn't normally use. If so, the > >>> user would only interact with the AriesApplicationManager API to > >>> perform application operations. If that's true then the > >>> AriesApplicationManager is missing methods for getting all > >>> AriesApplicationContexts or finding one by name. And at the same time > >>> the AriesApplicationContextManager would probably need to be > >>> completely reworked. For example to be named > >>> AriesApplicationManagerProvider and have corresponding > >>> install/uninstall/getContexts/findContext operations. > >>> Or maybe we should just get rid off the AriesApplicationContextManager > >>> completely and let folks implement the AriesApplicationManager API > >>> directly? > >>> > >>> Btw, by 'user' I meant some code that uses these API to perform some > >>> application operations. For example, in my case, I would like to have > >>> some osgi shell commands that use these API to > >>> install/uninstall/start/stop applications. > >>> > >>> Jarek > >>> > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > >> > >> > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
