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

Brought to you by: colins, jhoeller, johnsonr, robharrop, trevormarshall

springframework-developer

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

From: <jue...@we...> - 2004-05-28 12:50:04

Hi Ross,
=20
Interesting stuff! Out of curiosity, are you using Mule yourself in a =
concrete application at Atlassian?
=20
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).
=20
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 =
:-)
=20
Juergen
=20

________________________________

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


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.
=20
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.
=20
public class JmsEventListener implements ApplicationEvent {
=20
    public void setSubscription(String subscription);
=20
    public String getSubscription();
}
=20
This would allow springs beans to receive Jms messages, emails, data =
over http. Mule handles the transformation of these events =
transparently.
=20
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.
=20
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.
=20
I think this sort of extension would add value to Spring, would you guys =
consider exposing the EventMulticaster?
=20
Cheers,
=20
Ross

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

From: Mason, R. <ros...@vi...> - 2004-05-28 13:43:51

SGkgSnVlcmdlbiwNCiANCkZvciBldmVudHMgYmVpbmcgcHVibGlzaGVkIGJ5IFNwcmluZyBiZWFu
cyB0aGUgTXVsZUV2ZW50TWFuYWdlciBjYW4gc2ltcGx5IGltcGxlbWVudCB0aGUgQXBwbGljYXRp
b25MaXN0ZW5lciBpbnRlcmZhY2UuIEJ1dCBpbiBvcmRlciBmb3IgTXVsZSB0byBwdWJsaXNoIGV2
ZW50cyB0byBzcHJpbmcgYmVhbnMgYmFzZWQgb24gc3Vic2NyaXB0aW9ucywgeW91IHdvdWxkIG5l
ZWQgdG8gcHJvdmlkZSBhbm90aGVyIGltcGxlbWVudGF0aW9uIG9mIEV2ZW50TXVsdGljYXN0ZXIg
dGhhdCBwdWJsaXNoZWQgZXZlbnRzIGJhc2VkIG9uIGxpc3RlbmVyIHR5cGUgYW5kIHN1YnNjcmlw
dGlvbi4gICBGb3IgZXhhbXBsZSwgeW91IG1heSBoYXZlIHR3byBiZWFucyBsaXN0ZW5pbmcgb24g
c2VwYXJhdGUgam1zIHF1ZXVlcyBpLmUuIGFuIG9yZGVycy5xdWV1ZSBhbmQgZXhjZXB0aW9uLnF1
ZXVlLCB5b3UgZG9uJ3Qgd2FudCB5b3VyIG9yZGVycyBiZWFuIHJlY2VpdmluZyBleGNlcHRpb25z
IGFuZCB2aWNlIHZlcnNhLiAgDQogDQpBbHNvLCB0aGUgY3VycmVudCBFdmVudE11bHRpY2FzdGVy
IG9ubHkgYWxsb3dzIG9uZSBsaXN0ZXJuZXIgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgZWFjaCB0eXBl
LCB3aGljaCBtZWFucyB5b3UgY291bGRuJ3QgaGF2ZSB0d28gYmVhbnMgbGlzdGVuaW5nIG9uIGpt
cyB0b3BpY3MvcXVldWVzLiANCiANCkNoZWVycywNCiANClJvc3MNCg0KCS0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tIA0KCUZyb206IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlz
dHMuc291cmNlZm9yZ2UubmV0IG9uIGJlaGFsZiBvZiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRd
IA0KCVNlbnQ6IEZyaSAyOC8wNS8yMDA0IDE6NDkgUE0gDQoJVG86IHNwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglTdWJqZWN0OiBSZTogW1Nw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFNwcmluZyAvIE11bGUgaW50ZWdyYXRpb24gLSBzdGVw
IDENCgkNCgkNCg0KCUhpIFJvc3MsDQoJDQoJSW50ZXJlc3Rpbmcgc3R1ZmYhIE91dCBvZiBjdXJp
b3NpdHksIGFyZSB5b3UgdXNpbmcgTXVsZSB5b3Vyc2VsZiBpbiBhIGNvbmNyZXRlIGFwcGxpY2F0
aW9uIGF0IEF0bGFzc2lhbj8NCgkNCglSZWdhcmRpbmcgZ2V0dGluZyBub3RpZmllZCBvZiBldmVu
dHMgcHVibGlzaGVkIGJ5IFNwcmluZyBiZWFuczogV2h5IG5vdCBzaW1wbHkgbWFrZSB0aGUgTXVs
ZUV2ZW50TWFuYWdlciBpbXBsZW1lbnQgdGhlIEFwcGxpY2F0aW9uTGlzdGVuZXIgaW50ZXJmYWNl
PyBJdCB3b3VsZCBhdXRvbWF0aWNhbGx5IHJlY2VpdmUgYWxsIEFwcGxpY2F0aW9uRXZlbnRzIHRo
ZW4gKGxpa2UgYW55IG90aGVyIEFwcGxpY2F0aW9uTGlzdGVuZXIgaW4gdGhlIGNvbnRleHQpLCBi
ZWluZyBhYmxlIHRvIHByb2Nlc3MgdGhlbSBhY2NvcmRpbmdseSAoYWxsIG90aGVyIGxpc3RlbmVy
cyB3aWxsIGlnbm9yZSBldmVudHMgdGhhdCB0aGV5IGRvbid0IGtub3cgYW55d2F5KS4NCgkNCglT
byBJIGRvbid0IHJlYWxseSBzZWUgYSByZWFzb24gd2h5IHlvdSdkIG5lZWQgdG8gaG9vayBpbnRv
IHRoZSBBcHBsaWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIgaGVyZS4gUGxlYXNlIHRlbGwgbWUgaWYg
SSBtaXNzZWQgeW91ciBwb2ludCA6LSkNCgkNCglKdWVyZ2VuDQoJDQoJDQoJX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCgkNCglWb246IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIt
YWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IGltIEF1ZnRyYWcgdm9uIE1hc29uLCBSb3NzDQoJ
R2VzZW5kZXQ6IEZyIDI4LjA1LjIwMDQgMTM6NDINCglBbjogc3ByaW5nZnJhbWV3b3JrLWRldmVs
b3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglCZXRyZWZmOiBbU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3Blcl0gU3ByaW5nIC8gTXVsZSBpbnRlZ3JhdGlvbiAtIHN0ZXAgMQ0KCQ0KCQ0KCUhpLA0K
CUknbSB3cml0aW5nIHNvbWUgZXh0ZW5zaW9ucyB0byBpbnRlZ3JhdGUgU3ByaW5nIHdpdGggTXVs
ZSAoTXVsZSBpcyBhbiBFU0IgLSB3d3cubXVsZXVtby5vcmcpLiBJJ20gc3RhcnRpbmcgd2l0aCBh
biBleHRlbnNpb24gdG8gU3ByaW5nJ3MgQXBwbGljYXRpb25FdmVudCBpbXBsZW1lbnRhdGlvbiB0
byBhbGxvdyBiZWFucyB0byByZWNlaXZlIE11bGUgZXZlbnRzLg0KCQ0KCU11bGUgZXZlbnRzIGNh
biBiZSBzZW50IG92ZXIgdHJhbnNwb3J0cyBzdWNoIGFzIGptcywgaHR0cCwgc210cCwgcG9wMywg
dGNwLCBldGMgc28gYSBiZWFuIGluIGEgU3ByaW5nIGNvbnRleHQgY291bGQgaW1wbGVtZW50IGEg
Sm1zRXZlbnRMaXN0ZW5lciwgcG9wM0V2ZW50TGlzdGVuZXIsIGV0YyB0byByZWNlaXZlIGV2ZW50
cyBwdWJsaXNoZWQgaW4gTXVsZS4gIFBsdXMgdGhlIG9ic2VydmVyIGludGVyZmFjZSBjb3VsZCBl
eHBvc2Ugc3Vic2NyaXB0aW9uIG1ldGhvZHMgdG8gZW5hYmxlIE11bGUgdG8gcHVibGlzaCB0byBk
aWZmZXJlbnQgc3Vic2NyaXB0aW9ucywgaS5lLg0KCQ0KCXB1YmxpYyBjbGFzcyBKbXNFdmVudExp
c3RlbmVyIGltcGxlbWVudHMgQXBwbGljYXRpb25FdmVudCB7DQoJDQoJICAgIHB1YmxpYyB2b2lk
IHNldFN1YnNjcmlwdGlvbihTdHJpbmcgc3Vic2NyaXB0aW9uKTsNCgkNCgkgICAgcHVibGljIFN0
cmluZyBnZXRTdWJzY3JpcHRpb24oKTsNCgl9DQoJDQoJVGhpcyB3b3VsZCBhbGxvdyBzcHJpbmdz
IGJlYW5zIHRvIHJlY2VpdmUgSm1zIG1lc3NhZ2VzLCBlbWFpbHMsIGRhdGEgb3ZlciBodHRwLiBN
dWxlIGhhbmRsZXMgdGhlIHRyYW5zZm9ybWF0aW9uIG9mIHRoZXNlIGV2ZW50cyB0cmFuc3BhcmVu
dGx5Lg0KCQ0KCWZvciBwdWJsaXNoaW5nIGV2ZW50cywgdGhlIGFwcGxpY2F0aW9uIGNvZGUgY291
bGQgcHVibGlzaCBhIE11bGVFdmVudCB3aXRoIGFuIGVuZHBvaW50IGFuZCBhIHRyYW5zcG9ydCAg
dG8gdGhlIGFwcGxpY2F0aW9uQ29udGV4dCwgd2hpY2ggY291bGQgYmUgcmVjaWV2ZWQgYnkgYSBN
dWxlRXZlbnRNYW5hZ2VyIGJlYW4uDQoJDQoJVGhlIHByb2JsZW0gaXMgdGhhdCBJJ20gaGF2aW5n
IHRyb3VibGUgc2VlaW5nIGhvdyB0byBjaGFuZ2UgdGhlIHdheSBTcHJpbmcgbWFuYWdlcyBldmVu
dHMuICBJZGVhbGx5LCB0aGUgRXZlbnRNdWx0aWNhc3RlciBvbiB0aGUgQWJzdHJhY3RBcHBsaWNh
dGlvbkNvbnRleHQgd291bGQgYmUgYWNjZXNzaWJsZSB3aXRoIGdldHRlciBhbmQgc2V0dGVyIG1l
dGhvZHMgc28gdGhhdCB0aGUgJ011bGVFdmVudE1hbmFnZXInIGJlYW4gY291bGQgaG9vayBpbiBp
dCdzIG93biBldmVudE11bHRpY2FzdGVyIHRoYXQga25vd3MgaG93IHRvIGRlYWwgc3Vic2NyaXB0
aW9uIGV2ZW50cyBhbmQgaG93IHRvIG1hbmFnZSBNdWxlRXZlbnRzIHB1Ymxpc2hlZCBieSBTcHJp
bmcgQmVhbnMuDQoJDQoJSSB0aGluayB0aGlzIHNvcnQgb2YgZXh0ZW5zaW9uIHdvdWxkIGFkZCB2
YWx1ZSB0byBTcHJpbmcsIHdvdWxkIHlvdSBndXlzIGNvbnNpZGVyIGV4cG9zaW5nIHRoZSBFdmVu
dE11bHRpY2FzdGVyPw0KCQ0KCUNoZWVycywNCgkNCglSb3NzDQoJDQoJDQoJLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YuTmV0
IGVtYWlsIGlzIHNwb25zb3JlZCBieTogT3JhY2xlIDEwZw0KCUdldCBjZXJ0aWZpZWQgb24gdGhl
IGhvdHRlc3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBPcmFjbGUgMTBnLg0KCVRh
a2UgYW4gT3JhY2xlIDEwZyBjbGFzcyBub3csIGFuZCB3ZSdsbCBnaXZlIHlvdSB0aGUgZXhhbSBG
UkVFLg0KCWh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkMTQ5JmFsbG9jX2lkwoE2NiZvcD1pY2sN
CglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVs
b3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg==

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

From: <jue...@we...> - 2004-05-28 20:31:59

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

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

From: Colin S. <col...@ex...> - 2004-05-28 20:49:04

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
>

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

From: Ben A. <ben...@ac...> - 2004-05-28 23:01:42

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

I just wanted to chime in here and mention what Ross is working towards is
strategically very useful for Spring users.

By simply adding Mule (which BTW is now configurable directly from a Spring
ApplicationContext) Spring users will have the ability to receive events
from external sources (JMS, DB, HTTP etc), then transform them into native
ApplicationEvents and publish them in the ApplicationContext, and then send
ApplicationEvent replies to the ApplicationContext and have Mule send them
off to external sources. So Mule acts as an adapter between
ApplicationEvents and the external world. Mule can also be used directly to
take advantage of the growing library of Mule objects that perform message
transformation etc.

I recently added some ApplicationEvent support to Acegi Security CVS (login
success/password fail events), and am about to embark on a Swing GUI built
on top of Spring where it will be used again. It's nice for these sort of
internal-to-the-ApplicationContext usages, but if I want to publish a
CustomerOrder to a remote CustomerOrderConsumer, it will be nice when Mule
can deliver it for me.

Best regards
Ben

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

From: Colin S. <col...@ex...> - 2004-05-29 00:55:55

Ben Alex wrote:

>>I am in the thick of things at work so can't really put 
>>enough thought into this to comment much, but I would prefer 
>>to hold this until after
>>1.0.3 is out...
>>    
>>
>
>I just wanted to chime in here and mention what Ross is working towards is
>strategically very useful for Spring users.
>
>By simply adding Mule (which BTW is now configurable directly from a Spring
>ApplicationContext) Spring users will have the ability to receive events
>from external sources (JMS, DB, HTTP etc), then transform them into native
>ApplicationEvents and publish them in the ApplicationContext, and then send
>ApplicationEvent replies to the ApplicationContext and have Mule send them
>off to external sources. So Mule acts as an adapter between
>ApplicationEvents and the external world. Mule can also be used directly to
>take advantage of the growing library of Mule objects that perform message
>transformation etc.
>
>I recently added some ApplicationEvent support to Acegi Security CVS (login
>success/password fail events), and am about to embark on a Swing GUI built
>on top of Spring where it will be used again. It's nice for these sort of
>internal-to-the-ApplicationContext usages, but if I want to publish a
>CustomerOrder to a remote CustomerOrderConsumer, it will be nice when Mule
>can deliver it for me.
>
>Best regards
>  
>
Sorry, my typo. I meant to say until after _1.0.2_ is out, not 1.0.3!

I think the Mule stuff is very interesting and potentially usefull as 
well. I was just trying to make sure Juergen doesn't try to add any more 
code for 1.0.2.   :-)

Colin

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

From: Keith D. <kd...@cs...> - 2004-05-29 04:25:32

Ben,

If you would, let me know when you begin your journey developing a Swing GUI
built on top of Spring.  As the developer for Spring's in-development rich
client support (which is built directly on Swing), I'd love to be able to
combine what we've done so far and our future plans with your expertise and
the ideas you have in mind.  I could really use a sharp mind like yours to
critique and help further evolve the code base!

Right now there is already a substantial amount of functionality in our
project that should considerably jumpstart any swing application development
effort.  The codebase is actively (daily) progressing and will continue to
do so over the coming weeks/months as we work towards release candidate
form.  The mailing list is also starting to get some traffic; and I will be
checking in our first set of real samples later this weekend.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ben Alex
Sent: Friday, May 28, 2004 7:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Spring / Mule integration - step 1

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

I just wanted to chime in here and mention what Ross is working towards is
strategically very useful for Spring users.

By simply adding Mule (which BTW is now configurable directly from a Spring
ApplicationContext) Spring users will have the ability to receive events
from external sources (JMS, DB, HTTP etc), then transform them into native
ApplicationEvents and publish them in the ApplicationContext, and then send
ApplicationEvent replies to the ApplicationContext and have Mule send them
off to external sources. So Mule acts as an adapter between
ApplicationEvents and the external world. Mule can also be used directly to
take advantage of the growing library of Mule objects that perform message
transformation etc.

I recently added some ApplicationEvent support to Acegi Security CVS (login
success/password fail events), and am about to embark on a Swing GUI built
on top of Spring where it will be used again. It's nice for these sort of
internal-to-the-ApplicationContext usages, but if I want to publish a
CustomerOrder to a remote CustomerOrderConsumer, it will be nice when Mule
can deliver it for me.

Best regards
Ben



-------------------------------------------------------
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_id=3149&alloc_id=8166&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

From: Ben A. <ben...@ac...> - 2004-05-29 23:52:19

Hi Keith

> If you would, let me know when you begin your journey 
> developing a Swing GUI built on top of Spring.  As the 
> developer for Spring's in-development rich client support 
> (which is built directly on Swing), I'd love to be able to 
> combine what we've done so far and our future plans with your 
> expertise and the ideas you have in mind.

I just joined the mailing list. I'm presenting checking out the project from
CVS and look forward to participating.

Best regards
Ben

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

From: Mason, R. <ros...@vi...> - 2004-05-29 01:59:20

SGksDQoNCiBJIGNhbid0IGhlbHAgYmUgZmVlbCB0aGUgQXBwbGljYXRpb25FdmVudE11bHRpY2Fz
dGVyIGlzIG9uZSBvYmplY3Qgd2l0aCB0d28gcm9sZXMgdGhhdCBtaWdodCBiZSBiZXN0IGltcGxl
bWVudGF0ZWQgYXMgdHdvIG9iamVjdHMuIE1heWJlIHRoZSB0aGUgRXZlbnRNdWx0aWNhc3RlciBv
biB0aGUgQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQgc2hvdWxkIHJlYWxseSBiZSBhICdTaW1w
bGVFdmVudE1hbmFnZXInIGltcGxlbWVudGluZyAnU3ByaW5nRXZlbnRNYW5hZ2VyJyBhbmQgdGhl
IHRoZSBBcHBsaWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIgaXMganVzdCBhbm90aGVyIHR5cGUgb2Yg
bGlzdGVuZXIgdGhhdCBkaXNwYXRjaGVzIHRvIG90aGVyIGxpc3RlbmVycy4gICBNdWxlIGNvdWxk
IGltcGxlbWxlbWVudCBpdCdzIG93biBTcHJpbmdFdmVudE1hbmFnZXIsIHNheSBNdWxlRXZlbnRN
YW5hZ2VyLCB0aGF0IGNvdWxkIGJlIG9idGFpbmVkIGZyb20gdGhlIGNvbnRleHQuICBBcyBTcHJp
bmdFdmVudE1hbmFnZXIgZG9lc24ndCBpbXBsZW1lbnQgQXBwbGljYXRpb25FdmVudExpc3RlbmVy
IHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgbmVlZCB0byBtYWtlIHNwZWNpYWwgY2hlY2tzIHRvIG1h
a2Ugc3VyZSB0aGUgTXVsZUV2ZW50TWFuYWdlciBpc24ndCByZWdpc3RlcmVkIGFzIGEgbGlzdGVu
ZXIgdG8gaXRzZWxmLg0KDQpPYnZpb3VzbHksIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBpbiB0
aGUgbmV4dCByZWxlYXNlIDotKSBidXQgSSB0b3RhbGx5IHVuZGVyc3RhbmQgQ29saW4ncyBjb25j
ZXJucy4gIEkgdGhpbmsgdGhpcyBhcHByb2FjaCBpcyBwcmV0dHkgc29saWQgYW5kIGJhY2t3YXJk
IGNvbXBhdGlibGUgZm9yIHVzZXJzIHdobyBhcmUgdXNpbmcgdGhlIGV4aXN0aW5nIEFwcGxpY2F0
aW9uRXZlbnRNdWx0aWNhc3Rlci4NCg0KQ2hlZXJzLA0KDQpSb3NzDQoNCiANCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWlu
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgasO8cmdlbiBow7ZsbGVyIFt3ZXJr
M0FUXSANClNlbnQ6IEZyaSAyOC8wNS8yMDA0IDIxOjMxIA0KVG86IHNwcmluZ2ZyYW1ld29yay1k
ZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KQ2M6IA0KU3ViamVjdDogUmU6IFtTcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAx
DQoNCg0KT0ssIGxldCdzIG9wZW4gdXAgdGhlIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3Rlciwg
d2hpY2ggaXMgY3VycmVudGx5IG1vcmUgb3IgbGVzcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwg
b2YgQWJzdHJhY3RBcHBsaWNhdGlvbkNvbnRleHQuIEZpcnN0IHRoaW5nIEkndmUganVzdCBkb25l
IGlzIHJlbmFtZWQgQXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVySW1wbCB0byBTaW1wbGVBcHBs
aWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIsIHRvIHJlZmxlY3QgdGhlIHBvc3NpYmlsaXR5IGZvciBv
dGhlciBpbXBsZW1lbnRhdGlvbnMuDQoNClRoZSBjZW50cmFsIHF1ZXN0aW9uIGlzOiBIb3cgdG8g
c3BlY2lmeSB0aGUgQXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVyIGltcGxlbWVudGF0aW9uIHRo
YXQgYSBjb250ZXh0IHNob3VsZCB1c2U/IEEgdHlwaWNhbCBTcHJpbmcgd2F5IHdvdWxkIGJlIGEg
c3BlY2lhbCBiZWFuIGluIHRoZSBjb250ZXh0LCBzaW1pbGFyIHRvIHRoZSBNZXNzYWdlU291cmNl
IChhbmQgRGlzcGF0Y2hlclNlcnZsZXQncyBzcGVjaWFsIGJlYW5zKTogQSBsb2dpY2FsIGJlYW4g
bmFtZSB3b3VsZCBiZSAiYXBwbGljYXRpb25FdmVudE11bHRpY2FzdGVyIi4NCg0KU291bmRzIGxp
a2UgdGhlIGxvZ2ljYWwgc3ByaW5nIHdheSB0byBnbyA6LSkNCg0KU28gZmFyLCBzbyBnb29kLCBz
byBwcm90b3R5cGljYWxseSBpbXBsZW1lbnRlZCA6LSkgV29ya3MgbmljZWx5LCBhbmQgaXMgYWN0
dWFsbHkganVzdCBhIG1pbm9yIGNoYW5nZSB0aGF0IGRvZXMgbm90IGFmZmVjdCB0aGUgcmVzdCBv
ZiB0aGUgZnJhbWV3b3JrLCBiZXNpZGVzIHJlc2VydmluZyB0aGUgYmVhbiBuYW1lICJhcHBsaWNh
dGlvbkV2ZW50TXVsdGljYXN0ZXIiLg0KDQpUaGUgb25seSByZW1haW5pbmcgcHJvYmxlbSBpcyB0
aGF0IEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBkZXJpdmVzIGZyb20gQXBwbGljYXRpb25M
aXN0ZW5lci4gT24gc3RhcnR1cCwgdGhlIGNvbnRleHQgcmV0cmlldmVzIGFsbCBBcHBsaWNhdGlv
bkxpc3RlbmVyIGJlYW5zIGFuZCByZWdpc3RlcnMgdGhlbSB3aXRoIHRoZSBtdWx0aWNhc3Rlci4g
VW5mb3J0dW5hdGVseSwgdGhpcyBtZWFucyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGFuIGV4cGxp
Y2l0IGNoZWNrIHRoYXQgdGhlIG11bHRpY2FzdGVyIGlzIG5vdCByZWdpc3RlcmVkIGFzIGEgbGlz
dGVuZXIgd2l0aCBpdHNlbGYuDQoNCg0KV2hpbGUgdGhlIGxhdHRlciBkb2VzIHdvcmssIGl0IGZl
ZWxzIGEgYml0IHVuY2xlYW4uIEhvd2V2ZXIsIHJlZ2lzdGVyaW5nIHRoZSBtdWx0aWNhc3RlciB2
aWEgYSBzZXRBcHBsaWNhdGlvbkV2ZW50TXVsdGljYXN0ZXIgbWV0aG9kIGlzbid0IHRvbyBjb252
aW5jaW5nIGVpdGhlciwgYXMgdGhlIG11bHRpY2FzdGVyIHNob3VsZCBub3QgY2hhbmdlIGFmdGVy
IGEgcmVmcmVzaC4gSGF2aW5nIGl0IGFzIHNwZWNpYWwgYmVhbiBpbiB0aGUgY29udGV4dCBqdXN0
IHNlZW1zIHRvIGJlIHRoZSBuYXR1cmFsIFNwcmluZyB3YXkuDQoNCk9mIGNvdXJzZSwgdW5sZXNz
IGl0IGlzIGFic29sdXRlbHkgY3Jpc3RhbCBjbGVhciBob3cgd2UncmUgZ29ubmEgYXBwcm9hY2gg
dGhpcywgdGhlIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBiZWFuIG1lY2hhbmlzbSB3aWxs
IG5vdCBiZWNvbWUgcGFydCBvZiBhIHJlbGVhc2UuIEludHJvZHVjaW5nIGEgcHJvZ3JhbW1hdGlj
IGhvb2sgdG8gc2V0IGFuIEFwcGxpY2F0aW9uRXZlbnRNdWx0aWNhc3RlciBmb3IgdGhlIHRpbWUg
YmVpbmcgY291bGQgYmUgdW5kZXNpcmFibGUgdG9vIGlmIHdlIGNvbnNpZGVyIGRlZmluaW5nIGEg
YmVhbiBtZWNoYW5pc20gZm9yIDEuMC4zIChvciB0aGUgbGlrZSkuDQoNClRob3VnaHRzPw0KDQpK
dWVyZ2VuIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpWb246IHNwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IGltIEF1ZnRy
YWcgdm9uIE1hc29uLCBSb3NzDQpHZXNlbmRldDogRnIgMjguMDUuMjAwNCAxNTo0Mw0KQW46IHNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0OyBzcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KQmV0cmVmZjogUkU6IFtTcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAx
DQoNCg0KSGkgSnVlcmdlbiwNCg0KRm9yIGV2ZW50cyBiZWluZyBwdWJsaXNoZWQgYnkgU3ByaW5n
IGJlYW5zIHRoZSBNdWxlRXZlbnRNYW5hZ2VyIGNhbiBzaW1wbHkgaW1wbGVtZW50IHRoZSBBcHBs
aWNhdGlvbkxpc3RlbmVyIGludGVyZmFjZS4gQnV0IGluIG9yZGVyIGZvciBNdWxlIHRvIHB1Ymxp
c2ggZXZlbnRzIHRvIHNwcmluZyBiZWFucyBiYXNlZCBvbiBzdWJzY3JpcHRpb25zLCB5b3Ugd291
bGQgbmVlZCB0byBwcm92aWRlIGFub3RoZXIgaW1wbGVtZW50YXRpb24gb2YgRXZlbnRNdWx0aWNh
c3RlciB0aGF0IHB1Ymxpc2hlZCBldmVudHMgYmFzZWQgb24gbGlzdGVuZXIgdHlwZSBhbmQgc3Vi
c2NyaXB0aW9uLiAgIEZvciBleGFtcGxlLCB5b3UgbWF5IGhhdmUgdHdvIGJlYW5zIGxpc3Rlbmlu
ZyBvbiBzZXBhcmF0ZSBqbXMgcXVldWVzIGkuZS4gYW4gb3JkZXJzLnF1ZXVlIGFuZCBleGNlcHRp
b24ucXVldWUsIHlvdSBkb24ndCB3YW50IHlvdXIgb3JkZXJzIGJlYW4gcmVjZWl2aW5nIGV4Y2Vw
dGlvbnMgYW5kIHZpY2UgdmVyc2EuIA0KDQpBbHNvLCB0aGUgY3VycmVudCBFdmVudE11bHRpY2Fz
dGVyIG9ubHkgYWxsb3dzIG9uZSBsaXN0ZXJuZXIgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgZWFjaCB0
eXBlLCB3aGljaCBtZWFucyB5b3UgY291bGRuJ3QgaGF2ZSB0d28gYmVhbnMgbGlzdGVuaW5nIG9u
IGptcyB0b3BpY3MvcXVldWVzLg0KDQpDaGVlcnMsDQoNClJvc3MNCg0KICAgICAgICAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICBGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgasO8cmdlbiBow7Zs
bGVyIFt3ZXJrM0FUXQ0KICAgICAgICBTZW50OiBGcmkgMjgvMDUvMjAwNCAxOjQ5IFBNDQogICAg
ICAgIFRvOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0K
ICAgICAgICBDYzoNCiAgICAgICAgU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyXSBTcHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAxDQogICAgICAgDQogICAgICAg
DQoNCiAgICAgICAgSGkgUm9zcywNCiAgICAgICANCiAgICAgICAgSW50ZXJlc3Rpbmcgc3R1ZmYh
IE91dCBvZiBjdXJpb3NpdHksIGFyZSB5b3UgdXNpbmcgTXVsZSB5b3Vyc2VsZiBpbiBhIGNvbmNy
ZXRlIGFwcGxpY2F0aW9uIGF0IEF0bGFzc2lhbj8NCiAgICAgICANCiAgICAgICAgUmVnYXJkaW5n
IGdldHRpbmcgbm90aWZpZWQgb2YgZXZlbnRzIHB1Ymxpc2hlZCBieSBTcHJpbmcgYmVhbnM6IFdo
eSBub3Qgc2ltcGx5IG1ha2UgdGhlIE11bGVFdmVudE1hbmFnZXIgaW1wbGVtZW50IHRoZSBBcHBs
aWNhdGlvbkxpc3RlbmVyIGludGVyZmFjZT8gSXQgd291bGQgYXV0b21hdGljYWxseSByZWNlaXZl
IGFsbCBBcHBsaWNhdGlvbkV2ZW50cyB0aGVuIChsaWtlIGFueSBvdGhlciBBcHBsaWNhdGlvbkxp
c3RlbmVyIGluIHRoZSBjb250ZXh0KSwgYmVpbmcgYWJsZSB0byBwcm9jZXNzIHRoZW0gYWNjb3Jk
aW5nbHkgKGFsbCBvdGhlciBsaXN0ZW5lcnMgd2lsbCBpZ25vcmUgZXZlbnRzIHRoYXQgdGhleSBk
b24ndCBrbm93IGFueXdheSkuDQogICAgICAgDQogICAgICAgIFNvIEkgZG9uJ3QgcmVhbGx5IHNl
ZSBhIHJlYXNvbiB3aHkgeW91J2QgbmVlZCB0byBob29rIGludG8gdGhlIEFwcGxpY2F0aW9uRXZl
bnRNdWx0aWNhc3RlciBoZXJlLiBQbGVhc2UgdGVsbCBtZSBpZiBJIG1pc3NlZCB5b3VyIHBvaW50
IDotKQ0KICAgICAgIA0KICAgICAgICBKdWVyZ2VuDQogICAgICAgDQogICAgICAgDQogICAgICAg
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgDQogICAgICAgIFZvbjog
c3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgaW0g
QXVmdHJhZyB2b24gTWFzb24sIFJvc3MNCiAgICAgICAgR2VzZW5kZXQ6IEZyIDI4LjA1LjIwMDQg
MTM6NDINCiAgICAgICAgQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNl
Zm9yZ2UubmV0DQogICAgICAgIEJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBT
cHJpbmcgLyBNdWxlIGludGVncmF0aW9uIC0gc3RlcCAxDQogICAgICAgDQogICAgICAgDQogICAg
ICAgIEhpLA0KICAgICAgICBJJ20gd3JpdGluZyBzb21lIGV4dGVuc2lvbnMgdG8gaW50ZWdyYXRl
IFNwcmluZyB3aXRoIE11bGUgKE11bGUgaXMgYW4gRVNCIC0gd3d3Lm11bGV1bW8ub3JnKS4gSSdt
IHN0YXJ0aW5nIHdpdGggYW4gZXh0ZW5zaW9uIHRvIFNwcmluZydzIEFwcGxpY2F0aW9uRXZlbnQg
aW1wbGVtZW50YXRpb24gdG8gYWxsb3cgYmVhbnMgdG8gcmVjZWl2ZSBNdWxlIGV2ZW50cy4NCiAg
ICAgICANCiAgICAgICAgTXVsZSBldmVudHMgY2FuIGJlIHNlbnQgb3ZlciB0cmFuc3BvcnRzIHN1
Y2ggYXMgam1zLCBodHRwLCBzbXRwLCBwb3AzLCB0Y3AsIGV0YyBzbyBhIGJlYW4gaW4gYSBTcHJp
bmcgY29udGV4dCBjb3VsZCBpbXBsZW1lbnQgYSBKbXNFdmVudExpc3RlbmVyLCBwb3AzRXZlbnRM
aXN0ZW5lciwgZXRjIHRvIHJlY2VpdmUgZXZlbnRzIHB1Ymxpc2hlZCBpbiBNdWxlLiAgUGx1cyB0
aGUgb2JzZXJ2ZXIgaW50ZXJmYWNlIGNvdWxkIGV4cG9zZSBzdWJzY3JpcHRpb24gbWV0aG9kcyB0
byBlbmFibGUgTXVsZSB0byBwdWJsaXNoIHRvIGRpZmZlcmVudCBzdWJzY3JpcHRpb25zLCBpLmUu
DQogICAgICAgDQogICAgICAgIHB1YmxpYyBjbGFzcyBKbXNFdmVudExpc3RlbmVyIGltcGxlbWVu
dHMgQXBwbGljYXRpb25FdmVudCB7DQogICAgICAgDQogICAgICAgICAgICBwdWJsaWMgdm9pZCBz
ZXRTdWJzY3JpcHRpb24oU3RyaW5nIHN1YnNjcmlwdGlvbik7DQogICAgICAgDQogICAgICAgICAg
ICBwdWJsaWMgU3RyaW5nIGdldFN1YnNjcmlwdGlvbigpOw0KICAgICAgICB9DQogICAgICAgDQog
ICAgICAgIFRoaXMgd291bGQgYWxsb3cgc3ByaW5ncyBiZWFucyB0byByZWNlaXZlIEptcyBtZXNz
YWdlcywgZW1haWxzLCBkYXRhIG92ZXIgaHR0cC4gTXVsZSBoYW5kbGVzIHRoZSB0cmFuc2Zvcm1h
dGlvbiBvZiB0aGVzZSBldmVudHMgdHJhbnNwYXJlbnRseS4NCiAgICAgICANCiAgICAgICAgZm9y
IHB1Ymxpc2hpbmcgZXZlbnRzLCB0aGUgYXBwbGljYXRpb24gY29kZSBjb3VsZCBwdWJsaXNoIGEg
TXVsZUV2ZW50IHdpdGggYW4gZW5kcG9pbnQgYW5kIGEgdHJhbnNwb3J0ICB0byB0aGUgYXBwbGlj
YXRpb25Db250ZXh0LCB3aGljaCBjb3VsZCBiZSByZWNpZXZlZCBieSBhIE11bGVFdmVudE1hbmFn
ZXIgYmVhbi4NCiAgICAgICANCiAgICAgICAgVGhlIHByb2JsZW0gaXMgdGhhdCBJJ20gaGF2aW5n
IHRyb3VibGUgc2VlaW5nIGhvdyB0byBjaGFuZ2UgdGhlIHdheSBTcHJpbmcgbWFuYWdlcyBldmVu
dHMuICBJZGVhbGx5LCB0aGUgRXZlbnRNdWx0aWNhc3RlciBvbiB0aGUgQWJzdHJhY3RBcHBsaWNh
dGlvbkNvbnRleHQgd291bGQgYmUgYWNjZXNzaWJsZSB3aXRoIGdldHRlciBhbmQgc2V0dGVyIG1l
dGhvZHMgc28gdGhhdCB0aGUgJ011bGVFdmVudE1hbmFnZXInIGJlYW4gY291bGQgaG9vayBpbiBp
dCdzIG93biBldmVudE11bHRpY2FzdGVyIHRoYXQga25vd3MgaG93IHRvIGRlYWwgc3Vic2NyaXB0
aW9uIGV2ZW50cyBhbmQgaG93IHRvIG1hbmFnZSBNdWxlRXZlbnRzIHB1Ymxpc2hlZCBieSBTcHJp
bmcgQmVhbnMuDQogICAgICAgDQogICAgICAgIEkgdGhpbmsgdGhpcyBzb3J0IG9mIGV4dGVuc2lv
biB3b3VsZCBhZGQgdmFsdWUgdG8gU3ByaW5nLCB3b3VsZCB5b3UgZ3V5cyBjb25zaWRlciBleHBv
c2luZyB0aGUgRXZlbnRNdWx0aWNhc3Rlcj8NCiAgICAgICANCiAgICAgICAgQ2hlZXJzLA0KICAg
ICAgIA0KICAgICAgICBSb3NzDQogICAgICAgDQogICAgICAgDQogICAgICAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgVGhp
cyBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBPcmFjbGUgMTBnDQogICAgICAgIEdldCBj
ZXJ0aWZpZWQgb24gdGhlIGhvdHRlc3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBP
cmFjbGUgMTBnLg0KICAgICAgICBUYWtlIGFuIE9yYWNsZSAxMGcgY2xhc3Mgbm93LCBhbmQgd2Un
bGwgZ2l2ZSB5b3UgdGhlIGV4YW0gRlJFRS4NCiAgICAgICAgaHR0cDovL2Fkcy5vc2RuLmNvbS8/
YWRfaWQxNDkmYWxsb2NfaWTCgTY2Jm9wPWljaw0KICAgICAgICBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyIG1haWxpbmcgbGlzdA0KICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldA0KICAgICAgICBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l
dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQogICAgICAgDQoNCg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpUaGlzIFNGLk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE9yYWNsZSAxMGcNCkdldCBjZXJ0
aWZpZWQgb24gdGhlIGhvdHRlc3QgdGhpbmcgZXZlciB0byBoaXQgdGhlIG1hcmtldC4uLiBPcmFj
bGUgMTBnLg0KVGFrZSBhbiBPcmFjbGUgMTBnIGNsYXNzIG5vdywgYW5kIHdlJ2xsIGdpdmUgeW91
IHRoZSBleGFtIEZSRUUuDQpodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZDE0OSZhbGxvY19pZMKB
NjYmb3A9aWNrDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNClNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoNCg0K

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

From: Mason, R. <ros...@vi...> - 2004-05-29 02:16:09

TmljZWx5IHB1dCBCZW4gOi0pIA0KIA0KU3RyYXRlZ2ljYWxseSwgSSB0aGluayBTcHJpbmcgYW5k
IE11bGUgYXJlIGEgcG93ZXJmdWwgY29tYmluYXRpb24uICBGcm9tIGFuICdhcHBsaWNhdGlvbiB3
aXJpbmcnIHBlcnNwZWN0aXZlIFNwcmluZyBjYW4gYmUgc2VlbiBhcyBhIGZyYW1ld29yayBmb3Ig
d2lyaW5nIGJlYW5zIHdpdGhpbiBhIEpWTSBhbmQgTXVsZSBjYW4gYmUgc2VlbiBhcyBhIHdheSBv
ZiB3aXJpbmcgYmVhbnMvYXBwbGljYXRpb24gbm9kZXMgb3ZlciB0aGUgbmV0d29yay4gTXVsZSBw
cm92aWRlcyBhIHZlcnNhdGlsZSBnYXRld2F5IGZvciBTcHJpbmcgYmVhbnMgdG8gZXh0ZXJuYWwg
YXBwbGljYXRpb25zIGFuZCBoYW5kbGVzIHRoZSBjb21wbGV4aXRpZXMgb2YgY29ubmVjdGlvbnMs
IHRyYW5zZm9ybWF0aW9ucyBhbmQgcm91dGluZyB0cmFuc3BhcmVudGx5LiBQbHVzIHRoZXJlIGlz
IHZlcnkgbGl0dGxlIG92ZXJsYXAgaW4gZnVuY3Rpb25hbGl0eSBiZXR3ZWVuIHRoZSB0d28gZnJh
bWV3b3Jrcy4gDQogDQpDaGVlcnMsDQogDQpSb3NzDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLSANCglGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNv
dXJjZWZvcmdlLm5ldCBvbiBiZWhhbGYgb2YgQmVuIEFsZXggDQoJU2VudDogU2F0IDI5LzA1LzIw
MDQgMTI6MDIgQU0gDQoJVG86IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNl
Zm9yZ2UubmV0IA0KCUNjOiANCglTdWJqZWN0OiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIFNwcmluZyAvIE11bGUgaW50ZWdyYXRpb24gLSBzdGVwIDENCgkNCgkNCg0KCT4gSSBhbSBp
biB0aGUgdGhpY2sgb2YgdGhpbmdzIGF0IHdvcmsgc28gY2FuJ3QgcmVhbGx5IHB1dA0KCT4gZW5v
dWdoIHRob3VnaHQgaW50byB0aGlzIHRvIGNvbW1lbnQgbXVjaCwgYnV0IEkgd291bGQgcHJlZmVy
DQoJPiB0byBob2xkIHRoaXMgdW50aWwgYWZ0ZXINCgk+IDEuMC4zIGlzIG91dC4uLg0KCQ0KCUkg
anVzdCB3YW50ZWQgdG8gY2hpbWUgaW4gaGVyZSBhbmQgbWVudGlvbiB3aGF0IFJvc3MgaXMgd29y
a2luZyB0b3dhcmRzIGlzDQoJc3RyYXRlZ2ljYWxseSB2ZXJ5IHVzZWZ1bCBmb3IgU3ByaW5nIHVz
ZXJzLg0KCQ0KCUJ5IHNpbXBseSBhZGRpbmcgTXVsZSAod2hpY2ggQlRXIGlzIG5vdyBjb25maWd1
cmFibGUgZGlyZWN0bHkgZnJvbSBhIFNwcmluZw0KCUFwcGxpY2F0aW9uQ29udGV4dCkgU3ByaW5n
IHVzZXJzIHdpbGwgaGF2ZSB0aGUgYWJpbGl0eSB0byByZWNlaXZlIGV2ZW50cw0KCWZyb20gZXh0
ZXJuYWwgc291cmNlcyAoSk1TLCBEQiwgSFRUUCBldGMpLCB0aGVuIHRyYW5zZm9ybSB0aGVtIGlu
dG8gbmF0aXZlDQoJQXBwbGljYXRpb25FdmVudHMgYW5kIHB1Ymxpc2ggdGhlbSBpbiB0aGUgQXBw
bGljYXRpb25Db250ZXh0LCBhbmQgdGhlbiBzZW5kDQoJQXBwbGljYXRpb25FdmVudCByZXBsaWVz
IHRvIHRoZSBBcHBsaWNhdGlvbkNvbnRleHQgYW5kIGhhdmUgTXVsZSBzZW5kIHRoZW0NCglvZmYg
dG8gZXh0ZXJuYWwgc291cmNlcy4gU28gTXVsZSBhY3RzIGFzIGFuIGFkYXB0ZXIgYmV0d2Vlbg0K
CUFwcGxpY2F0aW9uRXZlbnRzIGFuZCB0aGUgZXh0ZXJuYWwgd29ybGQuIE11bGUgY2FuIGFsc28g
YmUgdXNlZCBkaXJlY3RseSB0bw0KCXRha2UgYWR2YW50YWdlIG9mIHRoZSBncm93aW5nIGxpYnJh
cnkgb2YgTXVsZSBvYmplY3RzIHRoYXQgcGVyZm9ybSBtZXNzYWdlDQoJdHJhbnNmb3JtYXRpb24g
ZXRjLg0KCQ0KCUkgcmVjZW50bHkgYWRkZWQgc29tZSBBcHBsaWNhdGlvbkV2ZW50IHN1cHBvcnQg
dG8gQWNlZ2kgU2VjdXJpdHkgQ1ZTIChsb2dpbg0KCXN1Y2Nlc3MvcGFzc3dvcmQgZmFpbCBldmVu
dHMpLCBhbmQgYW0gYWJvdXQgdG8gZW1iYXJrIG9uIGEgU3dpbmcgR1VJIGJ1aWx0DQoJb24gdG9w
IG9mIFNwcmluZyB3aGVyZSBpdCB3aWxsIGJlIHVzZWQgYWdhaW4uIEl0J3MgbmljZSBmb3IgdGhl
c2Ugc29ydCBvZg0KCWludGVybmFsLXRvLXRoZS1BcHBsaWNhdGlvbkNvbnRleHQgdXNhZ2VzLCBi
dXQgaWYgSSB3YW50IHRvIHB1Ymxpc2ggYQ0KCUN1c3RvbWVyT3JkZXIgdG8gYSByZW1vdGUgQ3Vz
dG9tZXJPcmRlckNvbnN1bWVyLCBpdCB3aWxsIGJlIG5pY2Ugd2hlbiBNdWxlDQoJY2FuIGRlbGl2
ZXIgaXQgZm9yIG1lLg0KCQ0KCUJlc3QgcmVnYXJkcw0KCUJlbg0KCQ0KCQ0KCQ0KCS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNG
Lk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE9yYWNsZSAxMGcNCglHZXQgY2VydGlmaWVkIG9u
IHRoZSBob3R0ZXN0IHRoaW5nIGV2ZXIgdG8gaGl0IHRoZSBtYXJrZXQuLi4gT3JhY2xlIDEwZy4N
CglUYWtlIGFuIE9yYWNsZSAxMGcgY2xhc3Mgbm93LCBhbmQgd2UnbGwgZ2l2ZSB5b3UgdGhlIGV4
YW0gRlJFRS4NCglodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZD0zMTQ5JmFsbG9jX2lkPTgxNjYm
b3A9Y2xpY2sNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJj
ZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoN
Cg==

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

From: Mason, R. <ros...@vi...> - 2004-05-31 23:37:02

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
>