Guillaume, I'm confused. These are very generic API that look like CompositeBundle API or RFC 152 type of stuff. Why do we need these API here when the CompositeBundle/RFC 152 API will eventually be provided by the OSGi framework? I think we need application-oriented API and I can see the implementation of these application API use the CompositeBundle/Subsystem API to do the work.
Jarek On Fri, Mar 26, 2010 at 10:27 AM, 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 >
