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 2011/02/03 16:29:29 UTC
[DISCUSS] ARIES-536
I've committed a patch for ARIES-536 which I'm sure some people will
disagree with.
However:
* I don't see anything in the blueprint spec that forbids such a behavior
* this isn't enabled by default
* that's how DS works so I don't think it's against OSGi best
practices or anything like that
I certainly don't want to start a flame war, but I don't want to
sneakily push that into the codebase either ;-)
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] ARIES-536
Posted by Guillaume Nodet <gn...@gmail.com>.
I've actually started a different thread about that, see
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3CAANLkTi=6=6Ch5uOJ-p_fNoc5mwMqBbbQvsHLJnDWOzKa@mail.gmail.com%3E
I thought you were mostly referring to that discussion, but I may have
misunderstood.
On Mon, Feb 7, 2011 at 20:26, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Feb 7, 2011 at 20:16, Alasdair Nottingham <no...@apache.org> wrote:
>> I'm not sure but I get the feeling there are potentially two things here:
>>
>> 1. A ready service, something which I believe has been talked about in
>> the OSGi alliance. I can see a use for something like this, but I'd
>> like to see a proposal. I think there are many complexities involved,
>> like how do you make it work and not require it to be omniscient.
>
> Yes, and I think Aries could be a good location to prototype such a
> thing. IIRC it has been removed from subsystem discussions so I guess
> the OSGi EEG is not really willing to work on that much.
>
>> 2. A smart start level service that waits for blueprint/DS type things
>> to be done at one start level before progression to the next. This
>> needs 1)
>>
>> As I said I can see value in 1, 2 is something you could probably put
>> in any management agent for OSGi, so putting it start level seems odd
>> to me.
>>
>
> Well, except that if you don't define an API for #2, the start level
> service needs to be aware of all the extenders that can be deployed.
> This knowledge on itself doesn't really scale and you may need to
> end-up dynamically importing tons of packages to actually access the
> data from those providers (what about importing different versions ?).
> Not sure how that would work.
>
>> Alasdair
>>
>> On 3 February 2011 15:43, Guillaume Nodet <gn...@gmail.com> wrote:
>>> That's exactly what it's about. Thx for casting your own lights on that.
>>>
>>> On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <fm...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
>>>>> I've committed a patch for ARIES-536 which I'm sure some people will
>>>>> disagree with.
>>>>> However:
>>>>> * I don't see anything in the blueprint spec that forbids such a behavior
>>>>> * this isn't enabled by default
>>>>> * that's how DS works so I don't think it's against OSGi best
>>>>> practices or anything like that
>>>>
>>>> IIUIC this is about whether to run blueprint support for a bundle
>>>> synchronous upon the Bundle.STARTED event or asynchronously on another
>>>> thread sometime later. Right ?
>>>>
>>>> From my experience with the Apache Felix Declarative Services
>>>> implementation: I used to start declared component asynchronously
>>>> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
>>>> fired long before all components have been handled.
>>>>
>>>> So, after some discussion with the maintainer of the Equinox
>>>> implementation (they already did synchronous processing at that time), I
>>>> switched to synchronous processing, too.
>>>>
>>>> And from what I can tell, this helped tremendously .. For example system
>>>> startup is in fact shorter (interestingly) but more importantly, DS
>>>> processing is complete once the FRAMEWORK_STARTED event is fired.
>>>>
>>>> So I would think, this would be a valuable to change (not knowing any
>>>> internals).
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> I certainly don't want to start a flame war, but I don't want to
>>>>> sneakily push that into the codebase either ;-)
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] ARIES-536
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Feb 7, 2011 at 20:16, Alasdair Nottingham <no...@apache.org> wrote:
> I'm not sure but I get the feeling there are potentially two things here:
>
> 1. A ready service, something which I believe has been talked about in
> the OSGi alliance. I can see a use for something like this, but I'd
> like to see a proposal. I think there are many complexities involved,
> like how do you make it work and not require it to be omniscient.
Yes, and I think Aries could be a good location to prototype such a
thing. IIRC it has been removed from subsystem discussions so I guess
the OSGi EEG is not really willing to work on that much.
> 2. A smart start level service that waits for blueprint/DS type things
> to be done at one start level before progression to the next. This
> needs 1)
>
> As I said I can see value in 1, 2 is something you could probably put
> in any management agent for OSGi, so putting it start level seems odd
> to me.
>
Well, except that if you don't define an API for #2, the start level
service needs to be aware of all the extenders that can be deployed.
This knowledge on itself doesn't really scale and you may need to
end-up dynamically importing tons of packages to actually access the
data from those providers (what about importing different versions ?).
Not sure how that would work.
> Alasdair
>
> On 3 February 2011 15:43, Guillaume Nodet <gn...@gmail.com> wrote:
>> That's exactly what it's about. Thx for casting your own lights on that.
>>
>> On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <fm...@gmail.com> wrote:
>>> Hi,
>>>
>>> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
>>>> I've committed a patch for ARIES-536 which I'm sure some people will
>>>> disagree with.
>>>> However:
>>>> * I don't see anything in the blueprint spec that forbids such a behavior
>>>> * this isn't enabled by default
>>>> * that's how DS works so I don't think it's against OSGi best
>>>> practices or anything like that
>>>
>>> IIUIC this is about whether to run blueprint support for a bundle
>>> synchronous upon the Bundle.STARTED event or asynchronously on another
>>> thread sometime later. Right ?
>>>
>>> From my experience with the Apache Felix Declarative Services
>>> implementation: I used to start declared component asynchronously
>>> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
>>> fired long before all components have been handled.
>>>
>>> So, after some discussion with the maintainer of the Equinox
>>> implementation (they already did synchronous processing at that time), I
>>> switched to synchronous processing, too.
>>>
>>> And from what I can tell, this helped tremendously .. For example system
>>> startup is in fact shorter (interestingly) but more importantly, DS
>>> processing is complete once the FRAMEWORK_STARTED event is fired.
>>>
>>> So I would think, this would be a valuable to change (not knowing any
>>> internals).
>>>
>>> Regards
>>> Felix
>>>
>>>> I certainly don't want to start a flame war, but I don't want to
>>>> sneakily push that into the codebase either ;-)
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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: [DISCUSS] ARIES-536
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 07.02.2011, 19:16 +0000 schrieb Alasdair Nottingham:
> I'm not sure but I get the feeling there are potentially two things here:
>
> 1. A ready service, something which I believe has been talked about in
> the OSGi alliance. I can see a use for something like this, but I'd
> like to see a proposal. I think there are many complexities involved,
> like how do you make it work and not require it to be omniscient.
Interesting, we have been discussing this in the Sling context, too.
I am not really convinced about the ability to implement such a thing.
> 2. A smart start level service that waits for blueprint/DS type things
> to be done at one start level before progression to the next. This
> needs 1)
>From the POV of DS there is no need, because DS works synchronously,
i.e. by the time the asynchronous bundle STARTED events are fired, all
components have been processed and activated (as far as possible).
As I understand Guillaume, his patch does a similar thing for blueprint.
This means, when the STARTLEVEL_CHANGED (or FRAMEWORK_STARTED) event is
fired, DS (and after ARIES-536 Blueprint) processing has completed.
This does not mean, all components are active -- there may still be
problems; that's where a "start completed" thingy would come in ...
Regard
Felix
>
> As I said I can see value in 1, 2 is something you could probably put
> in any management agent for OSGi, so putting it start level seems odd
> to me.
>
> Alasdair
>
> On 3 February 2011 15:43, Guillaume Nodet <gn...@gmail.com> wrote:
> > That's exactly what it's about. Thx for casting your own lights on that.
> >
> > On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <fm...@gmail.com> wrote:
> >> Hi,
> >>
> >> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
> >>> I've committed a patch for ARIES-536 which I'm sure some people will
> >>> disagree with.
> >>> However:
> >>> * I don't see anything in the blueprint spec that forbids such a behavior
> >>> * this isn't enabled by default
> >>> * that's how DS works so I don't think it's against OSGi best
> >>> practices or anything like that
> >>
> >> IIUIC this is about whether to run blueprint support for a bundle
> >> synchronous upon the Bundle.STARTED event or asynchronously on another
> >> thread sometime later. Right ?
> >>
> >> From my experience with the Apache Felix Declarative Services
> >> implementation: I used to start declared component asynchronously
> >> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
> >> fired long before all components have been handled.
> >>
> >> So, after some discussion with the maintainer of the Equinox
> >> implementation (they already did synchronous processing at that time), I
> >> switched to synchronous processing, too.
> >>
> >> And from what I can tell, this helped tremendously .. For example system
> >> startup is in fact shorter (interestingly) but more importantly, DS
> >> processing is complete once the FRAMEWORK_STARTED event is fired.
> >>
> >> So I would think, this would be a valuable to change (not knowing any
> >> internals).
> >>
> >> Regards
> >> Felix
> >>
> >>> I certainly don't want to start a flame war, but I don't want to
> >>> sneakily push that into the codebase either ;-)
> >>>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
Re: [DISCUSS] ARIES-536
Posted by Alasdair Nottingham <no...@apache.org>.
I'm not sure but I get the feeling there are potentially two things here:
1. A ready service, something which I believe has been talked about in
the OSGi alliance. I can see a use for something like this, but I'd
like to see a proposal. I think there are many complexities involved,
like how do you make it work and not require it to be omniscient.
2. A smart start level service that waits for blueprint/DS type things
to be done at one start level before progression to the next. This
needs 1)
As I said I can see value in 1, 2 is something you could probably put
in any management agent for OSGi, so putting it start level seems odd
to me.
Alasdair
On 3 February 2011 15:43, Guillaume Nodet <gn...@gmail.com> wrote:
> That's exactly what it's about. Thx for casting your own lights on that.
>
> On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
>>> I've committed a patch for ARIES-536 which I'm sure some people will
>>> disagree with.
>>> However:
>>> * I don't see anything in the blueprint spec that forbids such a behavior
>>> * this isn't enabled by default
>>> * that's how DS works so I don't think it's against OSGi best
>>> practices or anything like that
>>
>> IIUIC this is about whether to run blueprint support for a bundle
>> synchronous upon the Bundle.STARTED event or asynchronously on another
>> thread sometime later. Right ?
>>
>> From my experience with the Apache Felix Declarative Services
>> implementation: I used to start declared component asynchronously
>> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
>> fired long before all components have been handled.
>>
>> So, after some discussion with the maintainer of the Equinox
>> implementation (they already did synchronous processing at that time), I
>> switched to synchronous processing, too.
>>
>> And from what I can tell, this helped tremendously .. For example system
>> startup is in fact shorter (interestingly) but more importantly, DS
>> processing is complete once the FRAMEWORK_STARTED event is fired.
>>
>> So I would think, this would be a valuable to change (not knowing any
>> internals).
>>
>> Regards
>> Felix
>>
>>> I certainly don't want to start a flame war, but I don't want to
>>> sneakily push that into the codebase either ;-)
>>>
>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSS] ARIES-536
Posted by Guillaume Nodet <gn...@gmail.com>.
That's exactly what it's about. Thx for casting your own lights on that.
On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
>> I've committed a patch for ARIES-536 which I'm sure some people will
>> disagree with.
>> However:
>> * I don't see anything in the blueprint spec that forbids such a behavior
>> * this isn't enabled by default
>> * that's how DS works so I don't think it's against OSGi best
>> practices or anything like that
>
> IIUIC this is about whether to run blueprint support for a bundle
> synchronous upon the Bundle.STARTED event or asynchronously on another
> thread sometime later. Right ?
>
> From my experience with the Apache Felix Declarative Services
> implementation: I used to start declared component asynchronously
> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
> fired long before all components have been handled.
>
> So, after some discussion with the maintainer of the Equinox
> implementation (they already did synchronous processing at that time), I
> switched to synchronous processing, too.
>
> And from what I can tell, this helped tremendously .. For example system
> startup is in fact shorter (interestingly) but more importantly, DS
> processing is complete once the FRAMEWORK_STARTED event is fired.
>
> So I would think, this would be a valuable to change (not knowing any
> internals).
>
> Regards
> Felix
>
>> I certainly don't want to start a flame war, but I don't want to
>> sneakily push that into the codebase either ;-)
>>
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] ARIES-536
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
> I've committed a patch for ARIES-536 which I'm sure some people will
> disagree with.
> However:
> * I don't see anything in the blueprint spec that forbids such a behavior
> * this isn't enabled by default
> * that's how DS works so I don't think it's against OSGi best
> practices or anything like that
IIUIC this is about whether to run blueprint support for a bundle
synchronous upon the Bundle.STARTED event or asynchronously on another
thread sometime later. Right ?
>From my experience with the Apache Felix Declarative Services
implementation: I used to start declared component asynchronously
getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
fired long before all components have been handled.
So, after some discussion with the maintainer of the Equinox
implementation (they already did synchronous processing at that time), I
switched to synchronous processing, too.
And from what I can tell, this helped tremendously .. For example system
startup is in fact shorter (interestingly) but more importantly, DS
processing is complete once the FRAMEWORK_STARTED event is fired.
So I would think, this would be a valuable to change (not knowing any
internals).
Regards
Felix
> I certainly don't want to start a flame war, but I don't want to
> sneakily push that into the codebase either ;-)
>