Re: [Springframework-developer] Spring / Mule integration - step 1

[<jue...@we...>]

OK, let's open up the ApplicationEventMulticaster, which is currently =
more or less an implementation detail of AbstractApplicationContext. =
First thing I've just done is renamed ApplicationEventMulticasterImpl to =
SimpleApplicationEventMulticaster, to reflect the possibility for other =
implementations.
=20
The central question is: How to specify the ApplicationEventMulticaster =
implementation that a context should use? A typical Spring way would be =
a special bean in the context, similar to the MessageSource (and =
DispatcherServlet's special beans): A logical bean name would be =
"applicationEventMulticaster".
=20
So far, so good, so prototypically implemented :-) Works nicely, and is =
actually just a minor change that does not affect the rest of the =
framework, besides reserving the bean name =
"applicationEventMulticaster".
=20
The only remaining problem is that ApplicationEventMulticaster derives =
from ApplicationListener. On startup, the context retrieves all =
ApplicationListener beans and registers them with the multicaster. =
Unfortunately, this means that there needs to be an explicit check that =
the multicaster is not registered as a listener with itself.
=20
While the latter does work, it feels a bit unclean. However, registering =
the multicaster via a setApplicationEventMulticaster method isn't too =
convincing either, as the multicaster should not change after a refresh. =
Having it as special bean in the context just seems to be the natural =
Spring way.
=20
Of course, unless it is absolutely cristal clear how we're gonna =
approach this, the ApplicationEventMulticaster bean mechanism will not =
become part of a release. Introducing a programmatic hook to set an =
ApplicationEventMulticaster for the time being could be undesirable too =
if we consider defining a bean mechanism for 1.0.3 (or the like).
=20
Thoughts?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Mason, Ross
Gesendet: Fr 28.05.2004 15:43
An: spr...@li...; =
spr...@li...
Betreff: RE: [Springframework-developer] Spring / Mule integration - =
step 1


Hi Juergen,
=20
For events being published by Spring beans the MuleEventManager can =
simply implement the ApplicationListener interface. But in order for =
Mule to publish events to spring beans based on subscriptions, you would =
need to provide another implementation of EventMulticaster that =
published events based on listener type and subscription.   For example, =
you may have two beans listening on separate jms queues i.e. an =
orders.queue and exception.queue, you don't want your orders bean =
receiving exceptions and vice versa. =20
=20
Also, the current EventMulticaster only allows one listerner to be =
registered for each type, which means you couldn't have two beans =
listening on jms topics/queues.=20
=20
Cheers,
=20
Ross

	-----Original Message-----=20
	From: spr...@li... on behalf =
of j=FCrgen h=F6ller [werk3AT]=20
	Sent: Fri 28/05/2004 1:49 PM=20
	To: spr...@li...=20
	Cc:=20
	Subject: Re: [Springframework-developer] Spring / Mule integration - =
step 1
=09
=09

	Hi Ross,
=09
	Interesting stuff! Out of curiosity, are you using Mule yourself in a =
concrete application at Atlassian?
=09
	Regarding getting notified of events published by Spring beans: Why not =
simply make the MuleEventManager implement the ApplicationListener =
interface? It would automatically receive all ApplicationEvents then =
(like any other ApplicationListener in the context), being able to =
process them accordingly (all other listeners will ignore events that =
they don't know anyway).
=09
	So I don't really see a reason why you'd need to hook into the =
ApplicationEventMulticaster here. Please tell me if I missed your point =
:-)
=09
	Juergen
=09
=09
	________________________________
=09
	Von: spr...@li... im Auftrag =
von Mason, Ross
	Gesendet: Fr 28.05.2004 13:42
	An: spr...@li...
	Betreff: [Springframework-developer] Spring / Mule integration - step 1
=09
=09
	Hi,
	I'm writing some extensions to integrate Spring with Mule (Mule is an =
ESB - www.muleumo.org). I'm starting with an extension to Spring's =
ApplicationEvent implementation to allow beans to receive Mule events.
=09
	Mule events can be sent over transports such as jms, http, smtp, pop3, =
tcp, etc so a bean in a Spring context could implement a =
JmsEventListener, pop3EventListener, etc to receive events published in =
Mule.  Plus the observer interface could expose subscription methods to =
enable Mule to publish to different subscriptions, i.e.
=09
	public class JmsEventListener implements ApplicationEvent {
=09
	    public void setSubscription(String subscription);
=09
	    public String getSubscription();
	}
=09
	This would allow springs beans to receive Jms messages, emails, data =
over http. Mule handles the transformation of these events =
transparently.
=09
	for publishing events, the application code could publish a MuleEvent =
with an endpoint and a transport  to the applicationContext, which could =
be recieved by a MuleEventManager bean.
=09
	The problem is that I'm having trouble seeing how to change the way =
Spring manages events.  Ideally, the EventMulticaster on the =
AbstractApplicationContext would be accessible with getter and setter =
methods so that the 'MuleEventManager' bean could hook in it's own =
eventMulticaster that knows how to deal subscription events and how to =
manage MuleEvents published by Spring Beans.
=09
	I think this sort of extension would add value to Spring, would you =
guys consider exposing the EventMulticaster?
=09
	Cheers,
=09
	Ross
=09
=09
	-------------------------------------------------------
	This SF.Net email is sponsored by: Oracle 10g
	Get certified on the hottest thing ever to hit the market... Oracle =
10g.
	Take an Oracle 10g class now, and we'll give you the exam FREE.
	http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09