You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/03/18 18:16:15 UTC
Application API
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
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Mar 19, 2010 at 18:06, Mark Nuttall <mn...@apache.org> wrote:
> 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.
>
I think that's a fair goal. The point here, is to discuss the way to
achieve that.
The problem is that this interface need to be used by users in order to
start an application.
Also, if that's really a SPI, we should cleanly separate the user interface
from the vendor interfaces.
And as I said in my other email, being able to plug in vendor specific
implementations is fine, but that does not necesseraly implies that this
has to be done using OSGi services.
>
> > 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() ?
>
What do you mean here ? Do you
mean AriesApplicationContextManager.getApplicationContexts() ?
I thought this was supposed to be an interface for vendors, not for users.
>
> Regards,
> Mark
>
> On 18 March 2010 20:37, Guillaume Nodet <gn...@gmail.com> 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 <jg...@gmail.com> 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
Re: Application API
Posted by Mark Nuttall <mn...@apache.org>.
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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
>
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jg...@gmail.com> 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
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jg...@gmail.com> 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 <gn...@gmail.com>
> 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 <jg...@gmail.com> 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
Re: Application API
Posted by Jarek Gawor <jg...@gmail.com>.
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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
>
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
Hi Lin, thx for this very good feedback. See further comments inline.
On Wed, Mar 31, 2010 at 22:39, Lin Sun <li...@gmail.com> wrote:
> Hi Guillaume,
>
> Thanks for updating the APIs. I have the following comments -
>
> 1. SubsystemAdmin.getSubsystem(id). I wonder if we can provide a
> method like getSubsystem(String scope). subsystemScope can be
> calculated using subsystem symbolic name + "_" + subsystem version,
> and it can be used to uniquely identify subsystems instead of (or in
> addition to) a long id. Whenever a subsystem gets updated, we would
> need some way to tell which of the existing sybsystem it is updating.
> To me, it is easy to tell that by the subsystem scope which can be
> simply calculated from the bundle location. Another thought is to use
> bundle location, but I don't think that is guaranteed to be unique,
> when people are using install(location, inputstream) to install the
> subsystem.
>
>
The first question that comes to my mind is about the use of the
scope/identifier.
I don't have any problem adding such an identifier to a subsystem (or
replace the
long identifier by a string), however, I'm concerned about using the
symbolic name
+ version as the identifier. The problem is that when updating the
subsystem with
a more recent version, the id would either change (which would be
problematic) or
become inconsistent (which would be bad too). In addition a user could
choose
to have the same subsystem (identified by its symbolic name) running in two
different versions. The question becomes what would happen if the user try
to
update the first one using the more up to date subsystem. For bundles, it
would
fail afaik. In addition, the id would have been mapped to the underlying
composite
id, leading to a simple way to access the composite if needed.
So i'd like to understand how you see this scope being used. If you want a
generated id,
then what about using a UUID ? If what you want is something that can
easily be undestand
and linked to the symbolicname / version, then is that really an unique
identifier ? because it
may change over time. Actually, I think it would be ok to update the
subsystem and have
the updated version have a different symbolic name.
> 2. SubsystemAdmin.getSubsystems() returns Collection<Subsystem>. I
> wonder if it is more convenient to return Map<String, Subsystem> where
> the key is the subsystem scope.
>
Right, that makes sense. I think I was trying to avoid having to build a
read-only map,
but there's no real point here. Having the map would be sufficient, and we
should then
remove the getSubsystem(long) method imho.
>
> 3. Subsystem.install(location). I think this should be install(String
> location, BundleContext bc) instead, because we would need the bundle
> context to get the CompositeAdmin service from OSGi service registry,
> assuming we would use that to install the composite. We would also
> need bundle context to install constituents.
>
> 4. similar as No. 3, Subsyste.install(location, content) should be
> install(String location, InputStream content, BundleContext bc)
>
>
Ok, so I think those two points are related to nested subsystems. My idea
was
to follow what composites do, not necessarily because we would use those,
but
because I think users will rarely have to deal with nested subsystems
directly.
Let me explain: subsystems are defined by the user and deployed. I don't
think
we should encourage users to manually install new bundles into the created
subsystem,
because i would assume those would be uninstalled as soon as the subsystem
is
updated (or do we want to actually track the changes done by the user so
that we don't
rollback manual changes?). My idea was that if the user want to add /
remove bundles
from the composite, he needs to update the subsystem. I don't think we
should forbid
such changes, just that we should not track and manage those changes.
Nested subsystems are imho the same problem. Nested subsystems would be
installed
because a subsystem references another subsystem in its key content I think.
So you
would not really want the user to manually install a subsystem inside an
existing subsystem.
Now, if what you were thinking was about installing subsystems from inside a
composite,
the problem is a bit different. My idea was that the subsystem would be
installed from inside
the composite where the SubsystemAdmin service you use comes from. So if
you have a composite
and you want to install a subsystem into it, you retrieve the SubsystemAdmin
from this composite
and simply call one of the install method. This means that either:
* the subsystem implementation has been installed directly in this
composite
* or the subsystem impl has been installed in a parent composite and the
composite service policy has been
written to allow the service goes through
>From an implementation pov, I think it's quite easy to achieve by using a
ServiceFactory and using the
bundle context from the requesting bundle.
> 5. Subsystem.getState(). I wonder if we should reinvent here. Is
> there any reason why we don't make the return type of int, and just
> delegate this to the compositeBundle.getState(). Also, what if the
> composite bundle and constituents have different states. Does this
> method only work when the states are consistent among these bundles?
>
My original idea was also to map closely to the composite state, so I don't
have any problem
using an int instead of an enum, though I think the state of composite is an
int because a composite
*is* a bundle and enums did not exist at the time the bundle interface has
been created.
However, Subsystem do not inherit the Bundle or CompositeBundle interface,
so we could decide to
use an enum (because the state is semantically an enum).
That being said, the question you raise about the constituents state is
important. We need to choose
whether we want to represent the state of the subsystem as an aggregate of
the constituents state or not.
That would surely be interesting, because you would know the real state of
your subsystem much more
easily. The problem is i'm not sure what would happen if one of the bundle
can't start or is manually
stopped by the user. Would this leave the subsystem in the STARTING state
until the start or stop
method is called ?
> 6. Subsystem.start() or stop(), I think it should throw either
> BundleException or SubsystemException.
>
Yeah, SubsystemException would be fine. Currently I've defined
SubsystemException as being
a RuntimeException though ...
>
> 7. The return type of Subsystem.getHeaders, do we want to use
> Dictionary<String, String> or Dictionary to be consistent with
> Bundle.getHeaders()? when we implement this method, we can just
> delegate to compositeBundle.getHeaders.
>
Two things here. First, I'm not sure we would want to return the composite
headers.
First because composite headers can't be localized, and second because i was
thinking
about returning the headers from the subsystem manifest as it was installed,
not of the
underlying composite (which includes computed headers for package and
service policies).
So if we return directly the composite headers, it would surely make more
sense to use the
same type, but if we don't, i think using Map is more natural. OSGi is
really the only place
that uses Dictionary instead of Map ;-)
>
> 8. I'd like the add the following methods to Subsystem.java:
>
> + void uninstall() throws SubsystemException;
> +
> + String getScope();
> +
> + void update() throws SubsystemException;
> +
> + void update(InputStream content) throws SubsystemException;
>
> I think the uninstall(), update() are needed, because the
> SubsystemAdmin.uninstall/update can just delegate the work to the
> actual subsystem. In fact, the SubsustemAdmin cannot really do the
> work, unless we make the composite bundle available out of the
> Subsystem.
>
I agree to your point from an implementation point of view.
I initially put those methods on the Subsystem, but later moved them
to the SubsystemAdmin. I did that because it leads to a cleaner separation
between the actors and the responsibilities. In my mind, the SubsystemAdmin
is responsible for managing the content of subsystems (installation / update
/ creation),
whereas the subsystem does not perform such modifications and the only
methods
available are start() and stop(). I had the exact same objection on the
application
api some time ago and Alasdair said the design was more service oriented
rather than
object oriented. And now, I think it makes more sense to do it that way.
>
> I am also attaching a patch for stuff described above. I'd love to
> help on implementing these APIs if that is ok with you.
>
Do you mind discussing the changes a bit more ?
>
> Thanks
>
> Lin
>
>
>
> On Mon, Mar 29, 2010 at 6:34 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > FWIW, I've slightly updated the API with some feedback here and mostly
> two
> > other changes:
> > * moved some management methods from Subsystem to SubsystemAdmin (update
> > and uninstall)
> > * make SubsystemConstants a non instantiable class instead of an
> interface
> >
> > On Fri, Mar 26, 2010 at 16:27, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com>
> 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 <jg...@gmail.com> 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
> >>
> >>
> >>
> >
> >
> > --
> > 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
Re: Application API
Posted by Lin Sun <li...@gmail.com>.
Hi Guillaume,
Thanks for updating the APIs. I have the following comments -
1. SubsystemAdmin.getSubsystem(id). I wonder if we can provide a
method like getSubsystem(String scope). subsystemScope can be
calculated using subsystem symbolic name + "_" + subsystem version,
and it can be used to uniquely identify subsystems instead of (or in
addition to) a long id. Whenever a subsystem gets updated, we would
need some way to tell which of the existing sybsystem it is updating.
To me, it is easy to tell that by the subsystem scope which can be
simply calculated from the bundle location. Another thought is to use
bundle location, but I don't think that is guaranteed to be unique,
when people are using install(location, inputstream) to install the
subsystem.
2. SubsystemAdmin.getSubsystems() returns Collection<Subsystem>. I
wonder if it is more convenient to return Map<String, Subsystem> where
the key is the subsystem scope.
3. Subsystem.install(location). I think this should be install(String
location, BundleContext bc) instead, because we would need the bundle
context to get the CompositeAdmin service from OSGi service registry,
assuming we would use that to install the composite. We would also
need bundle context to install constituents.
4. similar as No. 3, Subsyste.install(location, content) should be
install(String location, InputStream content, BundleContext bc)
5. Subsystem.getState(). I wonder if we should reinvent here. Is
there any reason why we don't make the return type of int, and just
delegate this to the compositeBundle.getState(). Also, what if the
composite bundle and constituents have different states. Does this
method only work when the states are consistent among these bundles?
6. Subsystem.start() or stop(), I think it should throw either
BundleException or SubsystemException.
7. The return type of Subsystem.getHeaders, do we want to use
Dictionary<String, String> or Dictionary to be consistent with
Bundle.getHeaders()? when we implement this method, we can just
delegate to compositeBundle.getHeaders.
8. I'd like the add the following methods to Subsystem.java:
+ void uninstall() throws SubsystemException;
+
+ String getScope();
+
+ void update() throws SubsystemException;
+
+ void update(InputStream content) throws SubsystemException;
I think the uninstall(), update() are needed, because the
SubsystemAdmin.uninstall/update can just delegate the work to the
actual subsystem. In fact, the SubsustemAdmin cannot really do the
work, unless we make the composite bundle available out of the
Subsystem.
I am also attaching a patch for stuff described above. I'd love to
help on implementing these APIs if that is ok with you.
Thanks
Lin
On Mon, Mar 29, 2010 at 6:34 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> FWIW, I've slightly updated the API with some feedback here and mostly two
> other changes:
> * moved some management methods from Subsystem to SubsystemAdmin (update
> and uninstall)
> * make SubsystemConstants a non instantiable class instead of an interface
>
> On Fri, Mar 26, 2010 at 16:27, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, I've slightly updated the API with some feedback here and mostly two
other changes:
* moved some management methods from Subsystem to SubsystemAdmin (update
and uninstall)
* make SubsystemConstants a non instantiable class instead of an interface
On Fri, Mar 26, 2010 at 16:27, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Mar 30, 2010 at 00:03, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
> On Mon, Mar 29, 2010 at 22:50, Lin Sun <li...@gmail.com> wrote:
>
>> Hi
>>
>> I have some initial comments too.
>>
>> 1. I am curious why we want to reinvent a completely new interface
>> here instead of extending whatever Bundle or CompositeBundle provides?
>>
>
> From the initial feedback on the EEG, it seems people prefer to hide the
> underneath composites.
>
>
>> 2. Sybsystem state: should we use all uppercase like the bundle
>> states, for example ACTIVE instead of Active?
>>
>
> Uppercase is the convention when using static final constants. For enum
> values,
> I think the usual convention is to use CamelCase, as for class names.
>
>
Forget about that, you're right. I'll change those asap.
> 3. In the context of subsystem, I think resolved state can mean the
>> subsystem is resolved and able to start without any Resolver
>> Exception/Error. I am not sure what the Subsystem.resolve() method
>> would do?
>>
>
> As answered to Alistair, I was thinking about moving all the constituents
> into
> the resolved state, but I don't really have a strong opinion on this
> method.
> I just thought it could be usefull.
>
>>
>> 4. SubSystem.start(), stop(), etc should throw BundleException or
>> perhaps SubSystemException.
>>
>
> They do. Just that SubsystemException is a RuntimeException.
> But yeah, it makes sense to add it nonetheless.
>
>
>>
>> 5. SubSystemAdmin.getSubSystems(), would that return all subsystems in
>> all the frameworks or the current framework? same comment for
>> SubSystemAdmin.install(), which bundle context does it use to install
>> the subsystem?
>>
>
> To be discussed really.
>
> If we really want to manage a tree of subsystems, I'd say it should be done
> per level.
> i.e. you only see the subsystems at your level, and you'd have to find the
> SubsystemAdmin
> in the nested framework to find inner subsystems. Though it may make
> things a bit more to
> difficult and manage.
>
> I suppose it all comes down to what we will usually see. If we think most
> of the users will
> manage nested subsystems, we need to design the api around that, so maybe
> using a more
> explicit tree. IF we think users will mostly deal with the upper level,
> the current one would be
> more suited imho.
>
>
>>
>> Thanks
>>
>> Lin
>>
>> On Fri, Mar 26, 2010 at 10:27 AM, Guillaume Nodet <gn...@gmail.com>
>> 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 <gn...@gmail.com>
>> 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 <jg...@gmail.com> 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
>> >
>>
>
>
>
> --
> 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
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 29, 2010 at 22:50, Lin Sun <li...@gmail.com> wrote:
> Hi
>
> I have some initial comments too.
>
> 1. I am curious why we want to reinvent a completely new interface
> here instead of extending whatever Bundle or CompositeBundle provides?
>
>From the initial feedback on the EEG, it seems people prefer to hide the
underneath composites.
> 2. Sybsystem state: should we use all uppercase like the bundle
> states, for example ACTIVE instead of Active?
>
Uppercase is the convention when using static final constants. For enum
values,
I think the usual convention is to use CamelCase, as for class names.
> 3. In the context of subsystem, I think resolved state can mean the
> subsystem is resolved and able to start without any Resolver
> Exception/Error. I am not sure what the Subsystem.resolve() method
> would do?
>
As answered to Alistair, I was thinking about moving all the constituents
into
the resolved state, but I don't really have a strong opinion on this method.
I just thought it could be usefull.
>
> 4. SubSystem.start(), stop(), etc should throw BundleException or
> perhaps SubSystemException.
>
They do. Just that SubsystemException is a RuntimeException.
But yeah, it makes sense to add it nonetheless.
>
> 5. SubSystemAdmin.getSubSystems(), would that return all subsystems in
> all the frameworks or the current framework? same comment for
> SubSystemAdmin.install(), which bundle context does it use to install
> the subsystem?
>
To be discussed really.
If we really want to manage a tree of subsystems, I'd say it should be done
per level.
i.e. you only see the subsystems at your level, and you'd have to find the
SubsystemAdmin
in the nested framework to find inner subsystems. Though it may make things
a bit more to
difficult and manage.
I suppose it all comes down to what we will usually see. If we think most
of the users will
manage nested subsystems, we need to design the api around that, so maybe
using a more
explicit tree. IF we think users will mostly deal with the upper level, the
current one would be
more suited imho.
>
> Thanks
>
> Lin
>
> On Fri, Mar 26, 2010 at 10:27 AM, Guillaume Nodet <gn...@gmail.com>
> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Application API
Posted by Lin Sun <li...@gmail.com>.
Hi
I have some initial comments too.
1. I am curious why we want to reinvent a completely new interface
here instead of extending whatever Bundle or CompositeBundle provides?
2. Sybsystem state: should we use all uppercase like the bundle
states, for example ACTIVE instead of Active?
3. In the context of subsystem, I think resolved state can mean the
subsystem is resolved and able to start without any Resolver
Exception/Error. I am not sure what the Subsystem.resolve() method
would do?
4. SubSystem.start(), stop(), etc should throw BundleException or
perhaps SubSystemException.
5. SubSystemAdmin.getSubSystems(), would that return all subsystems in
all the frameworks or the current framework? same comment for
SubSystemAdmin.install(), which bundle context does it use to install
the subsystem?
Thanks
Lin
On Fri, Mar 26, 2010 at 10:27 AM, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
>
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Mar 26, 2010 at 21:18, Alasdair Nottingham <no...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Application API
Posted by Alasdair Nottingham <no...@apache.org>.
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?
Alasdair
On 26 March 2010 14:27, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
not@apache.org
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> 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 <jg...@gmail.com> 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
Re: Application API
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jg...@gmail.com> 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