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 < [email protected]> 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<[email protected]> > For additional commands, e-mail: [email protected] > >
