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.
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
