On 15 February 2010 21:08, Guillaume Nodet <[email protected]> wrote: > On Mon, Feb 15, 2010 at 12:10, Mark Nuttall <[email protected]> wrote: >> Hello Guillame. >> >>> My understanding is that the state of the application is an aggregate of >> its constituents states, >>> so that the application is RESOLVED if all bundles are at least RESOLVED. >> >> Yes, that's correct. >> >>> What if a bundle has been uninstalled ? Do we force to uninstall / >> reinstall the application ? >> >> I've been expecting administrators to work at the AriesApplication level - >> defined collections of bundles. I don't want those administrators to then >> start operating on individual bundles, An application's bundles should be >> operated on collectively. > > I do agree that administrators should avoid interacting with bundles > managed by applications directly. > However, the code must cope with such case, as they will certainly > happen at some point. > Also, if a bundle is shared between two applications, you might end up > with some inconsistencies > between start / stopped states, so again, we need to deal with those. >
The state is the state of the application, not an aggregate. If you look at what the code is doing it maps the state of the application, not the state of the bundles in the application. I think this is the right thing to do, anything else gets very fuzzy. If half the bundles are RESOLVED and half ACTIVE what should the state be if it is an aggregate. The only state that is aggregate is the RESOLVED state which we never set, so if no one objects I'll remove the RESOLVED state in ARIES-162 >> >>> In order to be more consistent with OSGI bundles, we could also: >>> * keep the install on AriesApplicationManager >>> * move the uninstall on ApplicationContext >> >> When designing the current interfaces, there was a clear tension between the >> possible object- and service-oriented approaches. The current design is >> service-oriented - the ApplicationManager service both installs and >> uninstalls AriesApplications. I realise that this differs from the existing >> OSGi design, in which we have BundleContext.installBundle() and >> Bundle.uninstall(). Apart from following the same pattern, do you see any >> other advantages to such a change? >> >>> * add an update method on ApplicationContext >> >> What do you think that would mean? Currently we have the method >> >> AriesApplication resolve (AriesApplication originalApp, ResolveConstraint >> ... constraints) throws ResolverException; >> >> on AriesApplicationManager - this is a model in which AriesApplications are >> immutable: changing an AriesApplication gives you a new one. Once we start >> clustering AriesApplications - having multiple concurrent running instances >> - the idea of hot-updating individual running instances leaves us open to >> unpredictable results. Can you say a bit more about your thinking around >> update() ? Thank you! >> > > I would have thought that an update would have at the end the same effect than > uninstalling and installing the new application. Same idea as with > bundles, really. > > As for the resolve() method, I don't think I clearly understand its > purpose and given > there's no implementation to look at, i don't have much informations... > It occurs to me that there is a lack of documentation of how to use aries if you are trying to integrate it into a runtime. I'm going to start a webpage on it and I'll make sure to document the intent behind the resolve method there. I'll post again when I've got a first draft done. Alasdair > >> Regards, >> Mark >> >> On 12 February 2010 17:20, Guillaume Nodet <[email protected]> wrote: >> >>> It has been a long time since I wanted to have a closer look at the >>> application model in Aries, so I've tried to install the application >>> support bundles in Karaf and install the sample applications. >>> It doesn't really work, so I'd like to start fixing things a bit. >>> >>> The following method of AriesApplicationManager interface is supposed >>> to install the bundles for the application: >>> ApplicationContext install(AriesApplication app); >>> The counterpart for uninstalling the application is >>> void uninstall(ApplicationContext app); >>> >>> The first point is that the implementation does not actually install >>> the bundles. So i was going to fix that, but I wonder about the >>> state of the application. >>> My understanding is that the state of the application is an aggregate >>> of its constituents states, so that the application is RESOLVED if all >>> bundles are at least RESOLVED. >>> What if a bundle has been uninstalled ? Do we force to uninstall / >>> reinstall the application ? >>> In order to be more consistent with OSGI bundles, we could also: >>> * keep the install on AriesApplicationManager >>> * move the uninstall on ApplicationContext >>> * add an update method on ApplicationContext >>> >>> Thoughts ? Comments ? >>> >>> -- >>> 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]
