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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi J=FCrgen,

Any more thoughts on this?=20

>I can't help be feel the ApplicationEventMulticaster is one object with =
two roles that
>might be best implementated as two objects. Maybe the the =
EventMulticaster on the
>AbstractApplicationContext should really be a 'SimpleEventManager' =
implementing
>'SpringEventManager' and the the ApplicationEventMulticaster is just =
another type of
>listener that dispatches to other listeners.   Mule could implemlement =
it's own
>SpringEventManager, say MuleEventManager, that could be obtained from =
the context.  As
>SpringEventManager doesn't implement ApplicationEventListener there =
would be no need need
>to make special checks to make sure the MuleEventManager isn't =
registered as a listener to >itself.

Cheers

Ross

>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of j=FCrgen h=F6ller [werk3AT]
>Sent: Saturday, 29 May 2004 6:31 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / Mule integration -
>step 1
>
>
>OK, let's open up the ApplicationEventMulticaster, which is=20
>currently more or less an implementation detail of=20
>AbstractApplicationContext. First thing I've just done is=20
>renamed ApplicationEventMulticasterImpl to=20
>SimpleApplicationEventMulticaster, to reflect the possibility=20
>for other implementations.
>=20
>The central question is: How to specify the=20
>ApplicationEventMulticaster implementation that a context=20
>should use? A typical Spring way would be a special bean in=20
>the context, similar to the MessageSource (and=20
>DispatcherServlet's special beans): A logical bean name would=20
>be "applicationEventMulticaster".
>=20
>So far, so good, so prototypically implemented :-) Works=20
>nicely, and is actually just a minor change that does not=20
>affect the rest of the framework, besides reserving the bean=20
>name "applicationEventMulticaster".
>=20
>The only remaining problem is that ApplicationEventMulticaster=20
>derives from ApplicationListener. On startup, the context=20
>retrieves all ApplicationListener beans and registers them=20
>with the multicaster. Unfortunately, this means that there=20
>needs to be an explicit check that the multicaster is not=20
>registered as a listener with itself.
>=20
>While the latter does work, it feels a bit unclean. However,=20
>registering the multicaster via a=20
>setApplicationEventMulticaster method isn't too convincing=20
>either, as the multicaster should not change after a refresh.=20
>Having it as special bean in the context just seems to be the=20
>natural Spring way.
>=20
>Of course, unless it is absolutely cristal clear how we're=20
>gonna approach this, the ApplicationEventMulticaster bean=20
>mechanism will not become part of a release. Introducing a=20
>programmatic hook to set an ApplicationEventMulticaster for=20
>the time being could be undesirable too if we consider=20
>defining a bean mechanism for 1.0.3 (or the like).
>=20
>Thoughts?
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im=20
>Auftrag von Mason, Ross
>Gesendet: Fr 28.05.2004 15:43
>An: spr...@li...;=20
>spr...@li...
>Betreff: RE: [Springframework-developer] Spring / Mule=20
>integration - step 1
>
>
>Hi Juergen,
>=20
>For events being published by Spring beans the=20
>MuleEventManager can simply implement the ApplicationListener=20
>interface. But in order for Mule to publish events to spring=20
>beans based on subscriptions, you would need to provide=20
>another implementation of EventMulticaster that published=20
>events based on listener type and subscription.   For example,=20
>you may have two beans listening on separate jms queues i.e.=20
>an orders.queue and exception.queue, you don't want your=20
>orders bean receiving exceptions and vice versa. =20
>=20
>Also, the current EventMulticaster only allows one listerner=20
>to be registered for each type, which means you couldn't have=20
>two beans listening on jms topics/queues.=20
>=20
>Cheers,
>=20
>Ross
>
>	-----Original Message-----=20
>	From:=20
>spr...@li... on=20
>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=20
>integration - step 1
>=09
>=09
>
>	Hi Ross,
>=09
>	Interesting stuff! Out of curiosity, are you using Mule=20
>yourself in a concrete application at Atlassian?
>=09
>	Regarding getting notified of events published by=20
>Spring beans: Why not simply make the MuleEventManager=20
>implement the ApplicationListener interface? It would=20
>automatically receive all ApplicationEvents then (like any=20
>other ApplicationListener in the context), being able to=20
>process them accordingly (all other listeners will ignore=20
>events that they don't know anyway).
>=09
>	So I don't really see a reason why you'd need to hook=20
>into the ApplicationEventMulticaster here. Please tell me if I=20
>missed your point :-)
>=09
>	Juergen
>=09
>=09
>	________________________________
>=09
>	Von:=20
>spr...@li... im=20
>Auftrag von Mason, Ross
>	Gesendet: Fr 28.05.2004 13:42
>	An: spr...@li...
>	Betreff: [Springframework-developer] Spring / Mule=20
>integration - step 1
>=09
>=09
>	Hi,
>	I'm writing some extensions to integrate Spring with=20
>Mule (Mule is an ESB - www.muleumo.org). I'm starting with an=20
>extension to Spring's ApplicationEvent implementation to allow=20
>beans to receive Mule events.
>=09
>	Mule events can be sent over transports such as jms,=20
>http, smtp, pop3, tcp, etc so a bean in a Spring context could=20
>implement a JmsEventListener, pop3EventListener, etc to=20
>receive events published in Mule.  Plus the observer interface=20
>could expose subscription methods to enable Mule to publish to=20
>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,=20
>emails, data over http. Mule handles the transformation of=20
>these events transparently.
>=09
>	for publishing events, the application code could=20
>publish a MuleEvent with an endpoint and a transport  to the=20
>applicationContext, which could be recieved by a MuleEventManager bean.
>=09
>	The problem is that I'm having trouble seeing how to=20
>change the way Spring manages events.  Ideally, the=20
>EventMulticaster on the AbstractApplicationContext would be=20
>accessible with getter and setter methods so that the=20
>'MuleEventManager' bean could hook in it's own=20
>eventMulticaster that knows how to deal subscription events=20
>and how to manage MuleEvents published by Spring Beans.
>=09
>	I think this sort of extension would add value to=20
>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=20
>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...
>=09
>https://lists.sourceforge.net/lists/listinfo/spr>ingframework-developer
>=09
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market...=20
>Oracle 10g.=20
>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
>