felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bulu <b...@romandie.com>
Subject Re: Dependency Manager: registering FrameworkListener
Date Thu, 09 Oct 2014 11:43:13 GMT
There were two things I had in mind.
1. Has OSGi been expanded to handle it's own listeners with the 
whiteboard pattern? The original paper "Listeners considered harmful..." 
is from 2001, so maybe in these 13 years they have adopted it themselves...
My main problem here was: how should I google that (if I don't find 
anything, is it because I don't know how to google or because it's not 
there?). You clarified that point.

2. Using DM, I was wondering if there is an elegant way to add the 
listener, in particular at the place where you define the component, but 
I only came up with the following (see below) which I thought, was a bit 
of a hack. As I'm pretty new in DM, I was wondering if I had overlooked 
a clean way of doing the registration. You clarified that point as well.

                 .setCallbacks(new Object(){ // create callback object
                     public void start(Component c){
                         BundleContext bc = 
                     public void stop(Component c){
                         BundleContext bc = 
bc.removeFrameworkListener((FrameworkListener) c.getService());

                 }, "notUsed", "start", "stop", "notUsed"));

Thanks & regards Philipp

PS: I understand that writing a whiteboard handler is not the issue - 
the issue is probably that in the JavaDoc of FrameworkListener it says 
"The Framework deliversFrameworkEvent objects to a FrameworkListener in 
order (...)". Although its not specified in "what" order (order of 
registration?), using a whiteboard approach cannot guarantee this 
(AFAIU). Maybe some client code depends on the call order being the 
registration order...

On 09.10.2014 12:17, Marcel Offermans wrote:
> Let me reverse the question: what would be a newer/better way and how should that be
implemented. I mean I can see somebody writing a whiteboard style handler and donating it
to (for example) Felix. Is that what you would like, or??
> On 09 Oct 2014, at 9:02 am, Bulu <bulu@romandie.com> wrote:
>> Hello Marcel
>> Yes I already knew the standard way you describe. I just wanted to clarify whether
a newer/better method existed.
>> Thanks again for your answer.
>> Philipp
>> On 08.10.2014 11:24, Marcel Offermans wrote:
>>>  From the spec: "A FrameworkListener object is registered with the Framework
using the BundleContext.addFrameworkListener method.”
>>> So it is not whiteboard-style (it pre-dates the whiteboard pattern afaik).
>>> In DM I would do:
>>> in the init:
>>> dm.add(createComponent().setImplementation(Comp.class));
>>> and then the component:
>>> public class Comp implements FrameworkListener {
>>>    private volatile BundleContext m_context;
>>>    public void start() {
>>>      m_context.addFrameworkListener(this);
>>>    }
>>>    public void stop() {
>>>      m_context.removeFrameworkListener(this);
>>>    }
>>>    // implement the FrameworkListener methods here
>>> }
>>> of course it would also be possible to create a whiteboard style handler for
this (just like one exists to handle Servlets for HttpService)…
>>> Greetings, Marcel
>>> On 8 Oct 2014 at 10:06:01 , Bulu (bulu@romandie.com) wrote:
>>> Hello all
>>> I'm declaring a component using DM which gets created when all
>>> dependencies are met. This component should also get notified of
>>> framework events and thus implements FrameworkListener.
>>> Does the OSGi framework also use a whiteboard pattern for delivering
>>> these events, meaning I only need to publish my component as a
>>> FrameworkListener.class service and it will get called by the framework
>>> when needed?
>>> If not, is there an elegant way of registering it using DM?
>>> Thanks & regards
>>> Philipp
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message