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.

        mgr.add(createComponent()
                .setImplementation(MyFrameworkListener.class)
                .setCallbacks(new Object(){ // create callback object
                    public void start(Component c){
BundleContext bc = c.getDependencyManager().getBundleContext(); bc.addFrameworkListener((FrameworkListener) c.getService());
                    }
                    public void stop(Component c){
BundleContext bc = c.getDependencyManager().getBundleContext();
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 <[email protected]> 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 ([email protected]) 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: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Reply via email to