Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@gmail.com designates
 74.125.82.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id
         :mime-version:x-mailer:content-transfer-encoding;
        b=byArNgz636OW+8tPuvQcSf3V5TxUHc2Mb2p4OP74qv6FjQwUS7cmiPW4NpwK984zIC
         NpTncpq4bqETtc4YrEFiBOLQStJqHefiOk2AapZtUHrvZz522CawjUwvDqdR56pTV5me
         X/7/EqNbp/VgOooGk2JJZsNWqZ6rAAI11pTEM=
Subject: Re: [DISCUSS] Api for a monitoring real bundles states when used
 with extenders
From: Felix Meschberger <fmeschbe@gmail.com>
To: dev@aries.apache.org
In-Reply-To: <AANLkTi=MMkejsE2C-3OpaTHosuxD5anx6XFYOGGBP3RJ@mail.gmail.com>
References: <AANLkTi=6=6Ch5uOJ-p_fNoc5mwMqBbbQvsHLJnDWOzKa@mail.gmail.com>
	 <1296726513.20360.2056.camel@meschbix>
	 <AANLkTinGfA4sppXQi4WrYyzAVS5adFV=947Hp8qpLV=H@mail.gmail.com>
	 <1296730129.20360.2147.camel@meschbix>
	 <AANLkTi=MMkejsE2C-3OpaTHosuxD5anx6XFYOGGBP3RJ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 03 Feb 2011 14:30:53 +0100
Message-ID: <1296739853.20360.2345.camel@meschbix>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

Thanks a lot for your clarifications !

Am Donnerstag, den 03.02.2011, 13:37 +0100 schrieb Guillaume Nodet: 
> >
> > But actually, the bundle is ready, when it's started. The services and
> > components/beans/you-name-it may not available yet at that time, though.
> >
> > How about just defining a best practice for such extenders to send an
> > EventAdmin event once they finished handling a bundle ?
> >
> 
> I think all do, but we still don't have any piece of code that grabs
> and aggregate those for a given bundle.
> Also, to compute this aggregation, you need to know before-hand what you expect.

So such an extender would still have to "register" itself somehow ?

> >>
> >> As for bundle ordering, I problem I came across is that such
> >> asynchronous extenders can't be ordered using the start level service,
> >> and that's sometimes desirable, so I'd like to be able to do that too.
> >
> > As always with bundle start ordering: It ain't gonna work. It will work
> > in a few controlled situations but in general it won't. This is why I
> > generally try to stop such bundle start order discussions right from the
> > start ;-)
> >
> > Consider for example a simple case of a bundle update: This may happen
> > at any time where you don't have any influence on ordering anything.
> >
> > Another option -- any maybe you mean this -- would be to be able to sort
> > the call order of the BundleListeners. This could be solved by
> > supporting whiteboard pattern style registrations for BundleListeners,
> > which would be called in their service ranking order. Of course this
> > only works for BundleListeners not registered with the framework
> > directly....
> 
> I am aware of the pitfalls, but I have some very specific use cases
> which aren't about making things work, but rather making things works
> nicely.
> For example consider the two following use cases:
>   * a log bundle is blueprint powered and thus started asycnhronously.
> All other bundles can actually work without this service being
> available, but when you start your framework, you'd still like the log
> bundle to be *ready* before the other ones start to capture most of
> the log events
>   * you have a bundle which will look for configurations in an
> external source (for example a jdbc database, or a file directory) and
> will feed the config admin with such data.  When you start the
> framework, you'd like to avoid having all bundles configured twice,
> you it would be better if other bundles would wait for that one to be
> ready before starting.
> I think such ordering has to be made with the StartLevel service, and
> once again, I don't want to solve bad designed bundles problems using
> the start level service, but I think the two uses cases I mentioned
> are actually valid (well, I do have those problems right now).  It
> would just be better if I could have a better control over a few
> bundles when the whole thing starts.

Ok. Thanks for enlighten my.

BTW: This is one of the reasons why I created a basically self-contained
logging support bundle in Sling, which can be started in a plain
framework and which we do at start level 1.

Regards
Felix

> 
> > Regards
> > Felix
> >
> >>
> >>
> >> >
> >> > Regards
> >> > Felix
> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
>