Some initial thoughts: 1. There isn't an equivalent of BundleContext which I was expecting when you said you had modelled it on the Bundle API. 2. There is a Subsystem event, but no listener, or mechanism to register an interface 3. I removed the resolved state from an application since it didn't make much sense in the context. I was wondering what a RESOLVED state means in the context of a subsystem. 4. In the Bundle API a bundle is resolved implicitly, not explicitly is there a reason a Subsystem needs to be explicitly resolved. 5. Can a subsystem contain a subsystem? If so the getConstituants method doesn't allow for this. 6. How do the constituents get into the subsystem. 7. The BundleContext.install method defines the String to be a location and doesn't say the location is a url (I don't think the OSGi spec requires the location to be a url). Wouldn't it make sense to have the location consistent?
Alasdair On 26 March 2010 14: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 > -- Alasdair Nottingham [email protected]
