The AriesApplicationManager and AriesApplicationContext interfaces are intended for use by anyone wishing to create, start or stop Applications.
The AriesApplicationContextManager interface allows us to separate the common code in application-management from vendor specific implementations, which application-runtime is a lightweight proxy for - a demonstration kernel sufficient to show that application-management is working. > Or maybe we should just get rid off the AriesApplicationContextManager > completely and let folks implement the AriesApplicationManager API > directly? That would be harmful to us: we wish to consume application-management, and connect it to our runtime/kernal code via the AriesApplicationContextManager interface. > the AriesApplicationManager is missing methods for getting all > AriesApplicationContexts or finding one by name. Is it really necessary to do that via AriesApplicationManager, and not AriesApplicationManager.getApplicationContexts() ? Regards, Mark On 18 March 2010 20:37, Guillaume Nodet <[email protected]> wrote: > Agreed. > > The application looks very complicated at first glance. > We should first focus on what is necessary to manipulate applications at > runtime and make that a clean api. > For example, all the metadata information will not be needed by the users > and I'm not even sure we need to have an API for that. > On the opposite, the constants are important for users because they are the > reference for writing applications and thus should be part of the API. > > For the SPI / API split, I'm not convinced either. I can imagine multiple > implementations of the whole thing if the API becomes a standard, but not > multiple providers on the same API. So I don't think we need to use OSGi > services for that and we can hide that by repackaging things. > > 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 >
