felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: How to make event admin impl extensible?
Date Mon, 20 Aug 2007 14:34:32 GMT
On 8/20/07, Marcel Offermans <marcel.offermans@luminis.nl> wrote:
> On Aug 20, 2007, at 13:11 , Carsten Ziegeler wrote:
> > Karl Pauls wrote:
> >> On second thought, I guess I'm just unable to see the use case. Could
> >> you give an example of what you are trying to do that you need to
> >> extend the eventadmin for?
> >
> > Sure :) One idea is to add clustering possibilities which means that
> > events are send to other nodes in the cluster as well.
> Are you aware of the enterprise expert group within OSGi that is
> currently looking at issues like this (I'm not sure if this exact
> scenario is being discussed but distributed/clustered solutions in
> general are)?
> > Ok, looking at the code again, I think we could change the Activator
> > code a little bit and factor out the object creation in the start()
> > method to separate
> > method (like createEventAdminImpl(...)) - so I could easily provide my
> > own activator which extends the existing one.

Right, that would be one possibility. As Marcel points out, the
general idea is that you can just bridge events if you need to. I
created several bridge bundles (e.g., for upnp events).

Is there a specific reason why a bridge bundle wouldn't work for you?



> Still, in that case you're basically creating your own event admin
> implementation bundle. You can reuse some of the code, but have to
> repackage that outside of Felix (or add a second event admin
> implementation to Felix, but then it would have to be useful outside
> your own use case).
> Another idea might be to just have an event listener that listens to
> events that need to be sent to other nodes in the cluster. That can
> be done without changing the event admin itself. I doubt that you
> will want to send *all* events to all nodes, because a lot of events
> are framework related and simply having them sent to other nodes in a
> cluster would not make sense (for example, sending a "framework
> started" or "startlevel changed" event to another node would only
> confuse it).
> And probably there are even more possibilities :)
> Greetings, Marcel

Karl Pauls

View raw message