aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: Application API
Date Fri, 26 Mar 2010 19:18:01 GMT
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.
2. There is a Subsystem event, but no listener, or mechanism to
register an interface
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.
4. In the Bundle API a bundle is resolved implicitly, not explicitly
is there a reason a Subsystem needs to be explicitly resolved.
5. Can a subsystem contain a subsystem? If so the getConstituants
method doesn't allow for this.
6. How do the constituents get into the subsystem.
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?


On 26 March 2010 14:27, Guillaume Nodet <> wrote:
> Sorry, forgot to give a pointer:
> On Fri, Mar 26, 2010 at 15:27, Guillaume Nodet <> 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 <> 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:
>> ------------------------
>> Open Source SOA
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Alasdair Nottingham

View raw message