On Tue, Mar 30, 2010 at 00:03, Guillaume Nodet <[email protected]> wrote:
> > > 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. > > Forget about that, you're right. I'll change those asap. > 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
