I understand that for system level events the map structure makes a lot
of sense.
For application developers who want an internal event system I think
this is different though. There it would be nice to have pojo
structures. The restriction that the classes have to be shared would not
be so problematic in this case I think. The immutability would be an
issue though that is difficult to solve. Of course it could be "solved"
by convention to just say please do not change the objects .. for inner
application communication this might even be good enough.
Basically what I am ultimately looking for is a non intrusive way for
publish / subscribe communication inside a container as well as across
containers. This is why I also did a prototype for the EventAdmin -> jms
bridge.
Of course EventAdmin is not the only way to solve this. I am also
looking into dosgi combined with a jms transport which might have
similar capabilities. The only downside to it is that there is no fast
in container mechanism then as far as I know.
Christian
On 10/18/2012 04:59 PM, Neil Bartlett wrote:
The main issue is that all the receiving bundles will need to understand
(i.e., import) the types of the objects you put into the event. This, along
with the immutability requirement, is the main reason why EventAdmin
supports only primitive types + String.
Neil
On Thu, Oct 18, 2012 at 3:02 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
Hi all,
I really like the publish / subscribe concept of EventAdmin. It provides a
great way to decouple senders and receivers. The downside is that the
events are limited to a simple map and using anything else than simple
types for the values is discouraged.
What I am missing is a simple and ideally non intrusive way of sending
Pojos around. What I have in mind is something similar to the JEE eventing (
http://www.adam-bien.com/**roller/abien/entry/java_ee_6_**observer_with<http://www.adam-bien.com/roller/abien/entry/java_ee_6_observer_with>)
but with string topics rather than matching annoations.
So what I could imagine is something like:
public interface PojoEventAdmin <T> {
void sendEvent(String topic, T event);
void postEvent(String topic, T event);
}
public interface PojoEventHandler <T> {
void handle(String topic, T event);
}
The event handlers could register using the whiteboard pattern like for
EventAdmin. Internally the implementation could then even use the
EventAdmin to transport the objects. This is of course not fully thought
out. Especially I am not sure if the generics would cause problems.
Is there any initiative to do something like this? Perhaps even an
extension of the EventAdmin spec? I have seen the Event framework in
Eclipse 4 which seems similar but I doubt it works outside eclipse.
I would be glad about any hints.
Christian
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<users-unsubscr...@felix.apache.org>
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
