You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/08/20 11:54:46 UTC
How to make event admin impl extensible?
I would like to extend the implementation of the event admin and add
some stuff (for example by sub classing). These extensions are rather
special and therefore I don't think it makes sense to commit them to the
Felix project.
But I'm now wondering how we could allow some extension hooks for such
customizing? One possible solution would be to make the class name of
the event admin impl configurable through a property, another one would
be to provide explicit hooks for extensions.
Are there perhaps better/easier solutions?
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler schrieb:
> Karl Pauls wrote:
>> On 8/20/07, Karl Pauls <ka...@gmail.com> wrote:
>>> Hm, extending the eventadmin sounds wrong to me. Why can't you just
>>> package your own bundle based on the eventadmin? Then you can just add
>>> your own Activator... Unless I'm missing something?
> Yes, I thought about this as well - but it comes with the cost of
> duplicating the activator code - it's not that much but still not that
> nice :)
>
>> 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.
>
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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Marcel Offermans wrote:
>
> 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)?
>
Ah, no didn't know that - thanks for the info!
>> 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).
Yes, true - sending events to other nodes could be done by a general
event listener. Unfortunately we have some extra requirements which
require us to add additional information to the event on the receiving
side before the event is distributed on that node. I'm not sure what the
reason was that I have to do this inside the event admin anymore - I'm
now thinking about the whole stuff for some days and lost track a little
bit :) But I'll rethink the whole stuff once more :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Didier,
Didier Donsez wrote:
> Carsten
>
> I made (1,5 year ago) bridges between EA and MOMs to distribute events
> across networked nodes.
>
cool!
> http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/eaivybridge
> http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/easienabridge
> but the IVY use a library with a ASL2-incompatible license and the Siena
> one is not finished
> They run under Oscar and some on both Oscar and Felix !
>
Unfortunately the links above do currently not work for me.
> My lab made also a bridge between EA and a JMS MOM but I don't know what
> is its status.
>
> You may have a look on them.
>
> There is also a paper and slides (in french ;-( ) presented them at an
> OSGi Users Group France workshop
I can at least look at the images :)
> http://hal.archives-ouvertes.fr/docs/00/09/73/43/ANNEX/slides_paper-5.pdf
> http://hal.archives-ouvertes.fr/docs/00/09/73/43/PDF/paper-5.pdf
>
> Moreover, Bob Brady developed a bridge between EA and ECF for his MsC
> He had presented his work at the ECLIPSEWORLD 2006
> Bob Brady. Developing Collaborative Tools With Equinox
> and ECF, .ECLIPSEWORLD 2006, Cambridge, MA, Sept.
> 8, 2006
> /Agile methods require a high degree of collaboration throughout the
> application life cycle. However, many existing development tools are
> essentially single-user. Coming to the rescue is the Equinox OSGi
> implementation and Eclipse Communication Framework, which are gaining
> momentum as a means for providing collaboration among tools, such as
> their use in the Eclipse Corona project./
>
> /This intermediate-to-advanced class will teach you how to use the
> Equinox and ECF projects to start developing real-time collaborative
> tools. We'll start with an overview of Equinox followed by several
> hands-on examples to show you the basics of Equinox's built-in SOA, and
> how to create a bundle that coordinates service interactions. We'll then
> use practical code examples to explain how ECF can be used for
> peer-to-peer messaging and sharing project resources. Finally, we'll
> create a sample tool with real-time, collaborative views. Basic Java and
> Eclipse development experience are prerequisites./
>
> Bob (I have his email address) may send his report to you.
That would be great!
>
> With Karl, we start to discuss about a brigde between EA and JXTA since
> JXTA can broadcast messages between P2P nodes and its license is
> compatible with ASL2.
>
> I hope this help you
Yes, it does.
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Didier Donsez <di...@imag.fr>.
Carsten
I made (1,5 year ago) bridges between EA and MOMs to distribute events
across networked nodes.
http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/eaivybridge
http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/easienabridge
but the IVY use a library with a ASL2-incompatible license and the Siena
one is not finished
They run under Oscar and some on both Oscar and Felix !
My lab made also a bridge between EA and a JMS MOM but I don't know what
is its status.
You may have a look on them.
There is also a paper and slides (in french ;-( ) presented them at an
OSGi Users Group France workshop
http://hal.archives-ouvertes.fr/docs/00/09/73/43/ANNEX/slides_paper-5.pdf
http://hal.archives-ouvertes.fr/docs/00/09/73/43/PDF/paper-5.pdf
Moreover, Bob Brady developed a bridge between EA and ECF for his MsC
He had presented his work at the ECLIPSEWORLD 2006
Bob Brady. Developing Collaborative Tools With Equinox
and ECF, .ECLIPSEWORLD 2006, Cambridge, MA, Sept.
8, 2006
/Agile methods require a high degree of collaboration throughout the
application life cycle. However, many existing development tools are
essentially single-user. Coming to the rescue is the Equinox OSGi
implementation and Eclipse Communication Framework, which are gaining
momentum as a means for providing collaboration among tools, such as
their use in the Eclipse Corona project./
/This intermediate-to-advanced class will teach you how to use the
Equinox and ECF projects to start developing real-time collaborative
tools. We'll start with an overview of Equinox followed by several
hands-on examples to show you the basics of Equinox's built-in SOA, and
how to create a bundle that coordinates service interactions. We'll then
use practical code examples to explain how ECF can be used for
peer-to-peer messaging and sharing project resources. Finally, we'll
create a sample tool with real-time, collaborative views. Basic Java and
Eclipse development experience are prerequisites./
Bob (I have his email address) may send his report to you.
With Karl, we start to discuss about a brigde between EA and JXTA since
JXTA can broadcast messages between P2P nodes and its license is
compatible with ASL2.
I hope this help you
Best regards
Didier
PS: I made also bridges between EA and Event-driven Flash applications
http://www-adele.imag.fr/users/Didier.Donsez/dev/osgi/eaflashbridge
(but the flash demo app is missing and I have to add it)
Carsten Ziegeler wrote:
>Carsten Ziegeler wrote:
>
>
>>Karl Pauls wrote:
>>
>>
>>>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?
>>>
>>>
>>>
>>There was some reason..but I can't remember right now. My first idea was
>>to use just an event listener which broadcasts the events to other nodes
>>and make the whole thing transparent. But for some reason (I think it
>>was elegance of implementation....) this didn't work quiet out. I'll
>>recheck.
>>
>>
>>
>Ok, the main problem is that the event should contain some information
>about the node on which it was raised. The basic idea is that some code
>sends an event to the event admin, before further distribution the event
>admin sets a flag for this event which marks this event as been raised
>on this node.
>All local receivers will get this marked event. When the event is
>replicated to the other nodes, the event won't be marked in this way.
>This allows an event listener to tell if the event has been raised on
>the current node or a different one.
>
>Carsten
>
>
>
--
--------------------------------------------------------------
Didier DONSEZ
INRIA/SARDES project, B117
655, avenue de l'Europe, Montbonnot
38334 St Ismier Cedex, France
Tel : +33 4 76 61 52 95 Fax : +33 4 76 61 52 52
GPS : lat 45°13'4.1"N, lon 05°48'24.3"E, alt 220m
Laboratoire LIG, Equipe ADELE
Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/users/Didier.Donsez
Map: http://www-adele.imag.fr/users/Didier.Donsez/map/map.html
--------------------------------------------------------------
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Karl Pauls wrote:
>> 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?
>>
> There was some reason..but I can't remember right now. My first idea was
> to use just an event listener which broadcasts the events to other nodes
> and make the whole thing transparent. But for some reason (I think it
> was elegance of implementation....) this didn't work quiet out. I'll
> recheck.
>
Ok, the main problem is that the event should contain some information
about the node on which it was raised. The basic idea is that some code
sends an event to the event admin, before further distribution the event
admin sets a flag for this event which marks this event as been raised
on this node.
All local receivers will get this marked event. When the event is
replicated to the other nodes, the event won't be marked in this way.
This allows an event listener to tell if the event has been raised on
the current node or a different one.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote:
>
> 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?
>
There was some reason..but I can't remember right now. My first idea was
to use just an event listener which broadcasts the events to other nodes
and make the whole thing transparent. But for some reason (I think it
was elegance of implementation....) this didn't work quiet out. I'll
recheck.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Karl Pauls <ka...@gmail.com>.
On 8/20/07, Marcel Offermans <ma...@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?
regards,
Karl
> 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
karlpauls@gmail.com
Re: How to make event admin impl extensible?
Posted by Marcel Offermans <ma...@luminis.nl>.
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
Re: How to make event admin impl extensible?
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote:
> On 8/20/07, Karl Pauls <ka...@gmail.com> wrote:
>> Hm, extending the eventadmin sounds wrong to me. Why can't you just
>> package your own bundle based on the eventadmin? Then you can just add
>> your own Activator... Unless I'm missing something?
Yes, I thought about this as well - but it comes with the cost of
duplicating the activator code - it's not that much but still not that
nice :)
>
> 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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: How to make event admin impl extensible?
Posted by Karl Pauls <ka...@gmail.com>.
On 8/20/07, Karl Pauls <ka...@gmail.com> wrote:
> Hm, extending the eventadmin sounds wrong to me. Why can't you just
> package your own bundle based on the eventadmin? Then you can just add
> your own Activator... Unless I'm missing something?
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?
> regards,
>
> Karl
>
> On 8/20/07, Carsten Ziegeler <cz...@apache.org> wrote:
> > I would like to extend the implementation of the event admin and add
> > some stuff (for example by sub classing). These extensions are rather
> > special and therefore I don't think it makes sense to commit them to the
> > Felix project.
> >
> > But I'm now wondering how we could allow some extension hooks for such
> > customizing? One possible solution would be to make the class name of
> > the event admin impl configurable through a property, another one would
> > be to provide explicit hooks for extensions.
> >
> > Are there perhaps better/easier solutions?
> >
> > Thanks
> > Carsten
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Karl Pauls
karlpauls@gmail.com
Re: How to make event admin impl extensible?
Posted by Karl Pauls <ka...@gmail.com>.
Hm, extending the eventadmin sounds wrong to me. Why can't you just
package your own bundle based on the eventadmin? Then you can just add
your own Activator... Unless I'm missing something?
regards,
Karl
On 8/20/07, Carsten Ziegeler <cz...@apache.org> wrote:
> I would like to extend the implementation of the event admin and add
> some stuff (for example by sub classing). These extensions are rather
> special and therefore I don't think it makes sense to commit them to the
> Felix project.
>
> But I'm now wondering how we could allow some extension hooks for such
> customizing? One possible solution would be to make the class name of
> the event admin impl configurable through a property, another one would
> be to provide explicit hooks for extensions.
>
> Are there perhaps better/easier solutions?
>
> Thanks
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Karl Pauls
karlpauls@gmail.com