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

[Colin S. <col...@ex...>]

I am in the thick of things at work so can't really put enough thought=20
into this to comment much, but I would prefer to hold this until after=20
1.0.3 is out...


j=FCrgen h=F6ller [werk3AT] wrote:

>OK, let's open up the ApplicationEventMulticaster, which is currently mo=
re or less an implementation detail of AbstractApplicationContext. First =
thing I've just done is renamed ApplicationEventMulticasterImpl to Simple=
ApplicationEventMulticaster, to reflect the possibility for other impleme=
ntations.
>=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 Dispatche=
rServlet's special beans): A logical bean name would be "applicationEvent=
Multicaster".
>=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 framewo=
rk, besides reserving the bean name "applicationEventMulticaster".
>=20
>The only remaining problem is that ApplicationEventMulticaster derives f=
rom ApplicationListener. On startup, the context retrieves all Applicatio=
nListener beans and registers them with the multicaster. Unfortunately, t=
his means that there needs to be an explicit check that the multicaster i=
s 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 co=
nvincing either, as the multicaster should not change after a refresh. Ha=
ving it as special bean in the context just seems to be the natural Sprin=
g way.
>=20
>Of course, unless it is absolutely cristal clear how we're gonna approac=
h this, the ApplicationEventMulticaster bean mechanism will not become pa=
rt of a release. Introducing a programmatic hook to set an ApplicationEve=
ntMulticaster 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 vo=
n Mason, Ross
>Gesendet: Fr 28.05.2004 15:43
>An: spr...@li...; springframework-dev=
el...@li...
>Betreff: RE: [Springframework-developer] Spring / Mule integration - ste=
p 1
>
>
>Hi Juergen,
>=20
>For events being published by Spring beans the MuleEventManager can simp=
ly 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 ver=
sa. =20
>=20
>Also, the current EventMulticaster only allows one listerner to be regis=
tered 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 o=
f 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 - st=
ep 1
>=09
>=09
>
>	Hi Ross,
>=09
>	Interesting stuff! Out of curiosity, are you using Mule yourself in a c=
oncrete application at Atlassian?
>=09
>	Regarding getting notified of events published by Spring beans: Why not=
 simply make the MuleEventManager implement the ApplicationListener inter=
face? It would automatically receive all ApplicationEvents then (like any=
 other ApplicationListener in the context), being able to process them ac=
cordingly (all other listeners will ignore events that they don't know an=
yway).
>=09
>	So I don't really see a reason why you'd need to hook into the Applicat=
ionEventMulticaster here. Please tell me if I missed your point :-)
>=09
>	Juergen
>=09
>=09
>	________________________________
>=09
>	Von: spr...@li... im Auftrag v=
on 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 E=
SB - www.muleumo.org). I'm starting with an extension to Spring's Applica=
tionEvent 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 o=
bserver interface could expose subscription methods to enable Mule to pub=
lish 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 ov=
er http. Mule handles the transformation of these events transparently.
>=09
>	for publishing events, the application code could publish a MuleEvent w=
ith an endpoint and a transport  to the applicationContext, which could b=
e recieved by a MuleEventManager bean.
>=09
>	The problem is that I'm having trouble seeing how to change the way Spr=
ing manages events.  Ideally, the EventMulticaster on the AbstractApplica=
tionContext would be accessible with getter and setter methods so that th=
e 'MuleEventManager' bean could hook in it's own eventMulticaster that kn=
ows how to deal subscription events and how to manage MuleEvents publishe=
d by Spring Beans.
>=09
>	I think this sort of extension would add value to Spring, would you guy=
s consider exposing the EventMulticaster?
>=09
>	Cheers,
>=09
>	Ross
>=09
>