You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/02/12 18:20:06 UTC
[Applications] Installation and resolution of aries applications
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
Re: [Applications] Installation and resolution of aries applications
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Guillaume,
I've got some code which I'm close to checking in which hooks up Felix
fileinstall to an Aries application - so I have install working. There
were a few issues I found on the way, one of which I need to open a
JIRA against blueprint for. I'll check what I have in later and we can
discuss some more.
Cheers,
Jeremy
On 12 February 2010 17:20, Guillaume Nodet <gn...@gmail.com> 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
>
Fwd: [Applications] Installation and resolution of aries applications
Posted by Mark Nuttall <mn...@apache.org>.
This seems to have vanished - resending.
---------- Forwarded message ----------
From: Mark Nuttall <mn...@apache.org>
Date: 15 February 2010 11:10
Subject: Re: [Applications] Installation and resolution of aries
applications
To: aries-dev@incubator.apache.org
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.
> 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!
Regards,
Mark
On 12 February 2010 17:20, Guillaume Nodet <gn...@gmail.com> 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
>
Re: [Applications] Installation and resolution of aries applications
Posted by Alasdair Nottingham <no...@apache.org>.
On 15 February 2010 21:08, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Feb 15, 2010 at 12:10, Mark Nuttall <mn...@apache.org> 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 <gn...@gmail.com> 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
not@apache.org
Re: [Applications] Installation and resolution of aries applications
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Feb 15, 2010 at 12:10, Mark Nuttall <mn...@apache.org> 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.
>
>> 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...
> Regards,
> Mark
>
> On 12 February 2010 17:20, Guillaume Nodet <gn...@gmail.com> 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
Re: [Applications] Installation and resolution of aries applications
Posted by Mark Nuttall <mn...@apache.org>.
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.
> 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!
Regards,
Mark
On 12 February 2010 17:20, Guillaume Nodet <gn...@gmail.com> 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
>