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
On Fri, Mar 26, 2010 at 16:27, 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
