On Fri, Mar 26, 2010 at 21:18, Alasdair Nottingham <[email protected]> wrote:
> 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. > BundleContext is used to register services or install bundles, which we don't really need in subsystems, given they are handled by the SubsystemAdmin > 2. There is a Subsystem event, but no listener, or mechanism to > register an interface > As for other osgi specs, using a whiteboard pattern is usually a better idea than registering listeners. I.e. the osgi registry is the reigstry of listeners. > 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. > Same as composite. I'd assume that it moves all bundles into a resolved state. > 4. In the Bundle API a bundle is resolved implicitly, not explicitly > is there a reason a Subsystem needs to be explicitly resolved. > Maybe not, you're right. > 5. Can a subsystem contain a subsystem? If so the getConstituants > method doesn't allow for this. > Good question. I haven't thought about that yet. I wonder if this need to be shown explicitely or if this is an implementation detail. The question comes down to whether the user can manage those nested subsystems, or if they are managed only as part of the upper level subsystem (same as you don't really want the user managing the constituent bundles directly). I guess one could retrieve the subsystem by using SubsystemAdmin#getSubsystem(long) I was thinking that when a subsystem is mapped to a composite, their id would be equals. But maybe we need something else. > 6. How do the constituents get into the subsystem. > Not sure what you mean. The Subsystem interface is the end result of the installation. Anything during the installation would be in the SPI I assume. > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
