Well, this is kinda supposed to be a proposal for the RFC 152 api ;-) (hence the name subsystem). Not sure what you really mean here, but imho applications could be merged into subsystems. I don't necesseraly see the need for two apis here.
Could you elaborate a bit more on why you're sayng this api is generic and what kind of things you're expecting as an "appliction-oriented api" ? Remember this is the API part, not the SPI part, so the obr resolver stuff and the resource processing (or bundle transformations) are out of scope I think, because those are not manipulated by the user, only by the installation process. that's why i removed them from the api. On Tue, Mar 30, 2010 at 06:57, Jarek Gawor <[email protected]> wrote: > 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 > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
