Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jue...@we...> - 2004-10-28 08:49:51
|
James, Regarding pooling of the MessageListener objects: In many cases, this = won't be necessary, as the MessageListener implementation will be = thread-safe anyway - similar to the DAO and service object case, where a = shared singleton instance is fine in 99% of the cases, so there's no = need to pool them (like Stateless Session Beans force you to). This means that in many cases, there's no need for a pool of listeners, = i.e. there's no need to specify a TargetSource as message handler - a = plain target object will do, specified as shared MessageListener bean. If there's an actual need to pool those target listeners, this could = always be achieved through a ProxyFactoryBean with a pooling = TargetSource, with the proxy implementing the MessageListener interface: = From the point of view of the ActiveMQ message dispatcher, it would = simply keep calling the shared MessageListener onMessage method, but = this time on the proxy which will delegate to one of the instances in = its backend pool. Essentially, it seems to me that the ActiveMQ container does not have to = be aware of Spring's TargetSource mechanism: Just invoking a provided = MessageListener reference should be enough, without worrying about the = backend. Of course, the above argument does not affect the pooling of JMS = Sessions in the background: That's the core of what ActiveMQ does here. = I'm just talking about the need to pool the MessageListener = implementation beans, which is probably as rare as the need to pool = DAOs. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of jas...@ma... Sent: Thursday, October 28, 2004 10:24 AM To: spr...@li... Cc: de...@ac... Subject: Re: [activemq-dev] Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available On 27 Oct 2004, at 20:11, Eugene Kuleshov wrote: > James Strachan wrote: >>> I think Eugene has a point. >>> >>> The work manager isn't the problem, it's integrating message=20 >>> delivery to mdbs without container support. This is going to be=20 >>> even more unlikely to work for CMT mdbs. >>> >>> If you want to use your spring psuedo-mdbs inside a j2ee container,=20 >>> there's still the problem of transactional message delivery. =20 >>> There's no standard way to find the TM and even if you get it I=20 >>> would investigate extensively before thinking that using it directly = >>> will give you the correct semantics. >> Agreed - though we're delegating to Spring for this issue.... > > By the way, there was a huge discussion related to CMT and Spring=20 > manged transaction and as far as I remember everybody agreed that in=20 > general it is a bad idea to mix those. BTW I think its worth saying, that in all the projects I've used JMS=20 (which is most of them over the last 5 years), I think I use XA=20 delivery less than 2% of the time. So for 98% of the time at least, I=20 tend to use regular JMS with no transactions and just use the regular=20 JMS acknowledge() or commit() mechanisms, which requires no J2EE=20 transaction manager or special container hooks whatsoever. So even if the JCA Container never supported J2EE transactions or=20 didn't support them any where near as well as a full J2EE container,=20 its still very, very useful IMHO. James ------- http://radio.weblogs.com/0112098/ ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Oliver G. <o.g...@ce...> - 2004-10-28 08:31:27
|
Hi jas...@ma... wrote: [...] > As part of the ActiveMQ project we've written a small, Spring based & > easily embedded JCA container. Its just a few classes and is easy to > use on any project, just depending on Spring and the JCA APIs. > > http://activemq.codehaus.org/JCA+Container [...] I understand that this is mainly targeted at integrating JMS. But I wonder how to combine this with a TM like JOTM? And a related question: does the JCA Container support JDBC CA Datasources, too? With other words: How does a combination of Spring + JOTM + JCA Container compare to a J2EE/EJB Server? cu, Olli --og |
|
From: <jas...@ma...> - 2004-10-28 08:24:16
|
On 27 Oct 2004, at 20:11, Eugene Kuleshov wrote: > James Strachan wrote: >>> I think Eugene has a point. >>> >>> The work manager isn't the problem, it's integrating message >>> delivery to mdbs without container support. This is going to be >>> even more unlikely to work for CMT mdbs. >>> >>> If you want to use your spring psuedo-mdbs inside a j2ee container, >>> there's still the problem of transactional message delivery. >>> There's no standard way to find the TM and even if you get it I >>> would investigate extensively before thinking that using it directly >>> will give you the correct semantics. >> Agreed - though we're delegating to Spring for this issue.... > > By the way, there was a huge discussion related to CMT and Spring > manged transaction and as far as I remember everybody agreed that in > general it is a bad idea to mix those. BTW I think its worth saying, that in all the projects I've used JMS (which is most of them over the last 5 years), I think I use XA delivery less than 2% of the time. So for 98% of the time at least, I tend to use regular JMS with no transactions and just use the regular JMS acknowledge() or commit() mechanisms, which requires no J2EE transaction manager or special container hooks whatsoever. So even if the JCA Container never supported J2EE transactions or didn't support them any where near as well as a full J2EE container, its still very, very useful IMHO. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jue...@we...> - 2004-10-28 06:47:35
|
Thanks for spotting this - fixed (also in = AbstractRemoteSlsbInvokerInterceptor)! =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Venkat Sonnathi Gesendet: Do 28.10.2004 06:57 An: spr...@li... Betreff: [Springframework-developer] NPE in = org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke:finally= Hi, I was by mistake trying to access a remote SLSB via LocalSlsb and was getting a NPE. I think a if (ejb !=3D null) in the finally clause will prevent that. Thanks, --Venkat. ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2004-10-28 06:00:58
|
On Wednesday 27 October 2004 22:38, jbetancourt wrote: > FishEye for Spring's Jira page? Just a thought. > > http://fisheye.thecortex.net/ I think it's a CVS viewer isn't it? And AFAIK, there's no non commercial license. It does look like a very nice product though - some of the codehaus servers have it on a beta test. -- Darren Davison Public Key: #DD356B0D |
|
From: Venkat S. <vso...@ho...> - 2004-10-28 04:58:12
|
Hi, I was by mistake trying to access a remote SLSB via LocalSlsb and was getting a NPE. I think a if (ejb != null) in the finally clause will prevent that. Thanks, --Venkat. |
|
From: jbetancourt <jbe...@co...> - 2004-10-28 00:17:36
|
FishEye for Spring's Jira page? Just a thought. http://fisheye.thecortex.net/ |
|
From: <al...@jt...> - 2004-10-27 22:31:01
|
<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE - =
build.135</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>10/28/2004 00:16:37</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 26 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>10/27/2004 04:38:49</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>javadoc fix</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader"> Errors/Warnings: (=
6) </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Tests: (1470) </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2"> </td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Test Error Details: (1) </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2"> Test: test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Class: org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2"> Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2"> Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
"> </td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader"> =
Modifications since last build: =
(1) </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">c=
olins</td><td class=3D"modifications-data">src/org/springframework/beans/pr=
opertyeditors/CustomDateEditor.java</td><td class=3D"modifications-data">ja=
vadoc fix</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader"> =
Deployments by this build: (8) </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html> |
|
From: Eugene K. <eu...@md...> - 2004-10-27 20:07:55
|
jas...@ma... wrote: > Another idea to reuse legacy containers would be to just write a MDB > wrapper which delegated to Spring to create the POJO. While its more > painful to configure, it would allow you to reuse the legacy MDB > infrastructure and use Spring for Dependency Injection. That is exactly what we are using for a while. MDB and SSLB's for remoting/facades/CMT and all internals is managed by Spring (pojo's, IOC, AOP, pooling...). The only uglines is that to start nested transactions we can't use Spring's TX wrappers and have to use helper SSLB's to plug in into CMT. regards, Eugene |
|
From: Stefan K. <st...@kl...> - 2004-10-27 19:43:25
|
Great work James, and thanks to Eugene for challenging him! ;-) -Stefan > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] > On Behalf Of Eugene Kuleshov > Sent: Wednesday, October 27, 2004 9:20 PM > To: spr...@li...; > de...@ac... > Subject: Re: [activemq-dev] Re: [Springframework-developer] > Re: [activemq-dev] Re: message driven POJOs, a lightweight > JCA container available > > > jas...@ma... wrote: > > Great James! Now we agreed on everything. :-) > So that is why I suggested to write up some best > practices/patterns > and publish it somewhere neat Spring/ActiveMQ. > > Also see few more comments below. > > regards, > Eugene > > >>>> I'm pretty much aware of both options and can see number of > >>>> disadvantages for solution based on Tomkat. > >>> Like what? :) > >> Besides vendor reputation and acceptance on the > entrprise market its > >> primarily cluster-related, especially in a cluster that > has stateful > >> components. > > Agreed. > >> Failover and resource management (jdbc and external jms) > also quite > >> limited there. > > Oh I don't know, I know a pretty good clustered JMS > > (http://activemq.codehaus.org/) :) > > It is a JMS cluster, but not J2EE. Isn't it? :) > > > I take your point though. > > > >>>> Also it could be not even an option in many cases. > Anyway it seems > >>>> that you have ignored the last part of my original message. > >>> > >>> Sorry I wasn't very clear before - here's another go. > >>> The WorkManager part is a non issue. It was never in any > other J2EE > >>> version and so isn't a versioning issue - you should be > able to use > >>> the WorkManager API in any J2EE container. If the > container is J2EE > >>> 1.4 it'll have one, if it doesn't the JCAContainer comes > with its own > >>> implementation anyways. > >>> So the WorkManager isn't the issue - the issue is, does the JCA > >>> version hardwired into the J2EE container work - I've a feeling > >>> previous JCA versions in J2EE 1.3 containers might not > work with the > >>> current JCAContainer as the JCAContainer is dependent on JCA 1.5. > >> That is more or less clear already. :-) > > OK :) > > >> By the way you probably could use isolating classloader to keep > >> WorkManager API away/separate from the J2EE classpath. > > Good idea. Though I think its JCA which will be the > classloading issue, > > not the WorkManager. > > Doesn't matter. Isolating classolader could probably use > its own JCA > jar and break classloading delegation chain. > > >>>> Most likely you'll have to have container-specific WorkManager > >>>> implementation that will not interfere with container life cycle. > >>> > >>> I don't follow. The JCAContainer just uses any WorkManager > >>> implementation. Either your container provides one, or > you can use > >>> the bundled one in JCAContainer. Its a fairly trivial bit > of code the > >>> WorkManager - you could even write your own using your containers > >>> ThreadPools if it doesn't yet support the WorkManager APIs. > >> > >> > >> Ok. Here is the scenario I'm talking about. Let say WorkManager > >> started some relatively long-running transactional or > nontransactional > >> process (message processing in POJO may take some time for > a variety > >> of reasons) and nearly after that thread has been started J2EE > >> container decide to go down (doesn't really matter why, > and number of > >> reasons will increase for large environment). So, now I > can't see how > >> proprietory WorkManager implementation can coordinate with the > >> container lifecycle in such case. Am I missing something? > > > > > > OK, I'm with you now - sorry for the confusion. > > > > It totally depends on the WorkManager implementation. The > Spring one > > uses Spring's container lifecycle. If you want to use the J2EE > > container's lifecycle, then use the J2EE containers > WorkManager - such > > as the one in Geronimo if you're deploying in Geronimo. > > > > Note I can imagine a version of the 'message driven pojo' container > > being developed for Geronimo which reuses Geronimo's transaction > > manager, container lifecycle, work manager and MDB > container, but just > > used Spring to create the MessageListener POJOs using > dependency injection. > > > > The same 'message driven pojo' concept should be usable > both within a > > J2EE container or outside of one. > > > > James > > ------- > > http://radio.weblogs.com/0112098/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jas...@ma...> - 2004-10-27 19:20:52
|
On 27 Oct 2004, at 20:11, Eugene Kuleshov wrote: > James Strachan wrote: > >>> I think Eugene has a point. >>> >>> The work manager isn't the problem, it's integrating message >>> delivery to mdbs without container support. This is going to be >>> even more unlikely to work for CMT mdbs. >>> >>> If you want to use your spring psuedo-mdbs inside a j2ee container, >>> there's still the problem of transactional message delivery. >>> There's no standard way to find the TM and even if you get it I >>> would investigate extensively before thinking that using it directly >>> will give you the correct semantics. >> Agreed - though we're delegating to Spring for this issue.... > > By the way, there was a huge discussion related to CMT and Spring > manged transaction and as far as I remember everybody agreed that in > general it is a bad idea to mix those. If in doubt there's always MDBs >>> For instance, in Geronimo I'm fairly sure it would not since we >>> wrap the JTA objects with more context. >>> >>> So this spring thing looks pretty cool but is unlikely to be of much >>> use in j2ee non 1.4 containers. But, why not use a j2ee 1.4 >>> container anyway?:-) >> Exactly! > > Can you guys remind me all J2EE 1.4 containers that already released > and how long ago? :-) :) >> If you're in a J2ee 1.4 container, you might was well just deploy >> MDBs. This is more for cases where you're not in a J2EE container, >> such as you're using just Tomcat + Spring and want the effect of MDBs >> coupled with the dependency injection of Spring and using Spring as >> the transaction manager (which has hooks to JTA or could plug in to >> Geronimo's TM etc). > > By the way, speaking about Tomkat + Spring, I wonder where you going > to get transaction manager. If I'm not mistaken Spring only provide > delegators, so coordination between JMS and JDBC tx resources could be > an issue. JOTM? Folks have used that successfully in Tomcat & Jetty. >> If you need the J2EE features, just use a J2EE container! > > That bring me back to 1.3 container. :-) :) > So, personally I'm ok with MDB's, maybe except the fact that you > can't really create consumers on the fly using some standard way (not > counting container-specific JMX magic). Agreed; folks could create 'message driven pojos' containers in J2EE app servers using container specific hooks, to create the POJOs using Spring. e.g. adding this to Geronimo would be pretty easy. Another idea to reuse legacy containers would be to just write a MDB wrapper which delegated to Spring to create the POJO. While its more painful to configure, it would allow you to reuse the legacy MDB infrastructure and use Spring for Dependency Injection. James ------- http://radio.weblogs.com/0112098/ |
|
From: Eugene K. <eu...@md...> - 2004-10-27 19:20:27
|
jas...@ma... wrote: Great James! Now we agreed on everything. :-) So that is why I suggested to write up some best practices/patterns and publish it somewhere neat Spring/ActiveMQ. Also see few more comments below. regards, Eugene >>>> I'm pretty much aware of both options and can see number of >>>> disadvantages for solution based on Tomkat. >>> Like what? :) >> Besides vendor reputation and acceptance on the entrprise market its >> primarily cluster-related, especially in a cluster that has stateful >> components. > Agreed. >> Failover and resource management (jdbc and external jms) also quite >> limited there. > Oh I don't know, I know a pretty good clustered JMS > (http://activemq.codehaus.org/) :) It is a JMS cluster, but not J2EE. Isn't it? :) > I take your point though. > >>>> Also it could be not even an option in many cases. Anyway it seems >>>> that you have ignored the last part of my original message. >>> >>> Sorry I wasn't very clear before - here's another go. >>> The WorkManager part is a non issue. It was never in any other J2EE >>> version and so isn't a versioning issue - you should be able to use >>> the WorkManager API in any J2EE container. If the container is J2EE >>> 1.4 it'll have one, if it doesn't the JCAContainer comes with its own >>> implementation anyways. >>> So the WorkManager isn't the issue - the issue is, does the JCA >>> version hardwired into the J2EE container work - I've a feeling >>> previous JCA versions in J2EE 1.3 containers might not work with the >>> current JCAContainer as the JCAContainer is dependent on JCA 1.5. >> That is more or less clear already. :-) > OK :) >> By the way you probably could use isolating classloader to keep >> WorkManager API away/separate from the J2EE classpath. > Good idea. Though I think its JCA which will be the classloading issue, > not the WorkManager. Doesn't matter. Isolating classolader could probably use its own JCA jar and break classloading delegation chain. >>>> Most likely you'll have to have container-specific WorkManager >>>> implementation that will not interfere with container life cycle. >>> >>> I don't follow. The JCAContainer just uses any WorkManager >>> implementation. Either your container provides one, or you can use >>> the bundled one in JCAContainer. Its a fairly trivial bit of code the >>> WorkManager - you could even write your own using your containers >>> ThreadPools if it doesn't yet support the WorkManager APIs. >> >> >> Ok. Here is the scenario I'm talking about. Let say WorkManager >> started some relatively long-running transactional or nontransactional >> process (message processing in POJO may take some time for a variety >> of reasons) and nearly after that thread has been started J2EE >> container decide to go down (doesn't really matter why, and number of >> reasons will increase for large environment). So, now I can't see how >> proprietory WorkManager implementation can coordinate with the >> container lifecycle in such case. Am I missing something? > > > OK, I'm with you now - sorry for the confusion. > > It totally depends on the WorkManager implementation. The Spring one > uses Spring's container lifecycle. If you want to use the J2EE > container's lifecycle, then use the J2EE containers WorkManager - such > as the one in Geronimo if you're deploying in Geronimo. > > Note I can imagine a version of the 'message driven pojo' container > being developed for Geronimo which reuses Geronimo's transaction > manager, container lifecycle, work manager and MDB container, but just > used Spring to create the MessageListener POJOs using dependency injection. > > The same 'message driven pojo' concept should be usable both within a > J2EE container or outside of one. > > James > ------- > http://radio.weblogs.com/0112098/ |
|
From: Eugene K. <eu...@md...> - 2004-10-27 19:11:41
|
James Strachan wrote: >> I think Eugene has a point. >> >> The work manager isn't the problem, it's integrating message delivery >> to mdbs without container support. This is going to be even more >> unlikely to work for CMT mdbs. >> >> If you want to use your spring psuedo-mdbs inside a j2ee container, >> there's still the problem of transactional message delivery. There's >> no standard way to find the TM and even if you get it I would >> investigate extensively before thinking that using it directly will >> give you the correct semantics. > > Agreed - though we're delegating to Spring for this issue.... By the way, there was a huge discussion related to CMT and Spring manged transaction and as far as I remember everybody agreed that in general it is a bad idea to mix those. >> For instance, in Geronimo I'm fairly sure it would not since we wrap >> the JTA objects with more context. >> >> So this spring thing looks pretty cool but is unlikely to be of much >> use in j2ee non 1.4 containers. But, why not use a j2ee 1.4 container >> anyway?:-) > Exactly! Can you guys remind me all J2EE 1.4 containers that already released and how long ago? :-) > If you're in a J2ee 1.4 container, you might was well just deploy MDBs. > This is more for cases where you're not in a J2EE container, such as > you're using just Tomcat + Spring and want the effect of MDBs coupled > with the dependency injection of Spring and using Spring as the > transaction manager (which has hooks to JTA or could plug in to > Geronimo's TM etc). By the way, speaking about Tomkat + Spring, I wonder where you going to get transaction manager. If I'm not mistaken Spring only provide delegators, so coordination between JMS and JDBC tx resources could be an issue. > If you need the J2EE features, just use a J2EE container! That bring me back to 1.3 container. :-) So, personally I'm ok with MDB's, maybe except the fact that you can't really create consumers on the fly using some standard way (not counting container-specific JMX magic). regards, Eugene |
|
From: <jas...@ma...> - 2004-10-27 19:08:26
|
On 27 Oct 2004, at 19:20, Eugene Kuleshov wrote: > jas...@ma... wrote: > >>> I'm pretty much aware of both options and can see number of >>> disadvantages for solution based on Tomkat. >> Like what? :) > > Besides vendor reputation and acceptance on the entrprise market its > primarily cluster-related, especially in a cluster that has stateful > components. Agreed. > Failover and resource management (jdbc and external jms) also quite > limited there. Oh I don't know, I know a pretty good clustered JMS (http://activemq.codehaus.org/) :) I take your point though. >>> Also it could be not even an option in many cases. Anyway it seems >>> that you have ignored the last part of my original message. >> Sorry I wasn't very clear before - here's another go. >> The WorkManager part is a non issue. It was never in any other J2EE >> version and so isn't a versioning issue - you should be able to use >> the WorkManager API in any J2EE container. If the container is J2EE >> 1.4 it'll have one, if it doesn't the JCAContainer comes with its own >> implementation anyways. >> So the WorkManager isn't the issue - the issue is, does the JCA >> version hardwired into the J2EE container work - I've a feeling >> previous JCA versions in J2EE 1.3 containers might not work with the >> current JCAContainer as the JCAContainer is dependent on JCA 1.5. > > That is more or less clear already. :-) OK :) > By the way you probably could use isolating classloader to keep > WorkManager API away/separate from the J2EE classpath. Good idea. Though I think its JCA which will be the classloading issue, not the WorkManager. >>> Most likely you'll have to have container-specific WorkManager >>> implementation that will not interfere with container life cycle. >> I don't follow. The JCAContainer just uses any WorkManager >> implementation. Either your container provides one, or you can use >> the bundled one in JCAContainer. Its a fairly trivial bit of code the >> WorkManager - you could even write your own using your containers >> ThreadPools if it doesn't yet support the WorkManager APIs. > > Ok. Here is the scenario I'm talking about. Let say WorkManager > started some relatively long-running transactional or nontransactional > process (message processing in POJO may take some time for a variety > of reasons) and nearly after that thread has been started J2EE > container decide to go down (doesn't really matter why, and number of > reasons will increase for large environment). So, now I can't see how > proprietory WorkManager implementation can coordinate with the > container lifecycle in such case. Am I missing something? OK, I'm with you now - sorry for the confusion. It totally depends on the WorkManager implementation. The Spring one uses Spring's container lifecycle. If you want to use the J2EE container's lifecycle, then use the J2EE containers WorkManager - such as the one in Geronimo if you're deploying in Geronimo. Note I can imagine a version of the 'message driven pojo' container being developed for Geronimo which reuses Geronimo's transaction manager, container lifecycle, work manager and MDB container, but just used Spring to create the MessageListener POJOs using dependency injection. The same 'message driven pojo' concept should be usable both within a J2EE container or outside of one. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jas...@ma...> - 2004-10-27 18:56:50
|
On 27 Oct 2004, at 19:40, j=FCrgen h=F6ller [werk3AT] wrote: > OK - thanks for the prompt response, James. I fully understand the=20 > effect of the JCAContainer; it's just that this is big enough to=20 > warrant Spring 1.2 :-) I'd prefer to publically introduce all those=20 > JMS-related new features in Spring 1.2 RC1, rather than in a 1.1.x=20 > point release. 1.2 RC1 is scheduled for early January, so isn't too=20 > far away... Sounds great with me. We can have it all nicely documented by January=20 with a few more examples. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jas...@ma...> - 2004-10-27 18:55:39
|
On 27 Oct 2004, at 19:38, j=FCrgen h=F6ller [werk3AT] wrote: > First of all - great work, James :-) Thanks! > In the long run, do you intend to move the generic parts over to the=20= > Spring codebase, or will those remain part of the ActiveMQ project=20 > too? For simplicity sake I was gonna leave it in ActiveMQ for now -=20 particularly as we need it for other things in the ActiveMQ project and=20= we'll be revving it pretty quickly. I also figured it was probably=20 better not to tie it to the Spring release schedule just yet. (e.g.=20 witness what's happening to the little JMS remoting stuff :) Plus I figured it was maybe a bit big for Spring. To be a general=20 solution for all JMS providers, Spring users may need a JCA=20 ResourceAdapter for their JMS provider if their provider doesn't have=20 one - in which case both activemq-container.jar and activemq-ra.jar=20 will be needed (rather than just activemq-container.jar). Also over time we're putting together a set of useful JMS POJOs for=20 doing things like bridging JMS providers, transforming messages,=20 applying rules and workflow; which again are probably outside of the=20 scope of Spring. > It's not immediately obvious to me which classes depend on the actual=20= > ActiveMQ message broker and which just reside there but are generic in=20= > nature... (I've just looked at the sample configuration yet.) The JCA Container doesn't depend on the ActiveMQ broker at all - its=20 just the demo uses ActiveMQ's Resource Adapter. > Eugene, regarding integrating the WorkManager into the server=20 > lifecycle: If the WorkManager implements Spring's DisposableBean=20 > interface or has a declaratively specified destroy method, it will=20 > receive a proper shutdown callback - when the Spring application=20 > context gets closed (for example, when the web application gets shut=20= > down). Agreed. I think Eugene's concern was shutting down the container while=20= the WorkManager was processing a message. > Effectively, the WorkManager is similar to a Quartz Scheduler: It=20 > fires up with the Spring context, manages a couple of threads for=20 > asynchronous processing there, and closed down with the Spring context=20= > again. I don't see any more conflict with the J2EE server's resource=20= > management here than in the case of Quartz... Agreed. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jue...@we...> - 2004-10-27 18:42:39
|
OK - thanks for the prompt response, James. I fully understand the = effect of the JCAContainer; it's just that this is big enough to warrant = Spring 1.2 :-) I'd prefer to publically introduce all those JMS-related = new features in Spring 1.2 RC1, rather than in a 1.1.x point release. = 1.2 RC1 is scheduled for early January, so isn't too far away... =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von jas...@ma... Gesendet: Mi 27.10.2004 20:29 An: spr...@li... Betreff: Re: [Springframework-developer] JMS remoting provider available On 27 Oct 2004, at 19:25, j=FCrgen h=F6ller [werk3AT] wrote: > James, > > That's cool stuff! In particular as it reuses the existing > RemoteInvocation support so nicely. However, I still vote to put it > into the sandbox for the 1.1.x timeframe. Mainly because there is no > time to polish it, and it's worth to be publically introduced in a 1.x > release. Fine with me. > Also, for the server side, we don't ship facilities to host the > MessageListener (JmsServiceExporter) yet. I see that this is in the > works :-) but we're still lacking recommendations on how to deploy JMS > remoting end-to-end. One more reason to keep it in the sandbox for the > time being. OK - but that's one of the reasons I've been trying to get the JCAContainer going, so we have an end-to-end solution for JMS. > Finally, I'd prefer jms.remoting as package rather than remoting.jms - > for a comparison, our transaction manager implementations reside in > jdbc respectively orm.hibernate etc too, rather than in the > transaction package. EJB remoting resides in the ejb package too, > despite reusing facilities from the remoting package. Ah OK. I just went with remoting.jms to be with the other remoting solutions. I'm easy either way. > So if you don't object to the sandbox and the changed package name, > I'll move it over to the sandbox into the jms.remoting directory... We > need to clarify that before the 1.1.2 release, which is scheduled to > happen this Sunday. Go for it. Lemme know what needs doing to get it back in once we're getting ready for 1.2. James ------- http://radio.weblogs.com/0112098/ ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-10-27 18:36:32
|
First of all - great work, James :-) In the long run, do you intend to = move the generic parts over to the Spring codebase, or will those remain = part of the ActiveMQ project too? It's not immediately obvious to me = which classes depend on the actual ActiveMQ message broker and which = just reside there but are generic in nature... (I've just looked at the = sample configuration yet.) =20 Eugene, regarding integrating the WorkManager into the server lifecycle: = If the WorkManager implements Spring's DisposableBean interface or has a = declaratively specified destroy method, it will receive a proper = shutdown callback - when the Spring application context gets closed (for = example, when the web application gets shut down). =20 Effectively, the WorkManager is similar to a Quartz Scheduler: It fires = up with the Spring context, manages a couple of threads for asynchronous = processing there, and closed down with the Spring context again. I don't = see any more conflict with the J2EE server's resource management here = than in the case of Quartz... =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Eugene Kuleshov Gesendet: Mi 27.10.2004 20:20 An: spr...@li... Cc: de...@ac... Betreff: Re: [Springframework-developer] Re: [activemq-dev] Re: message = driven POJOs, a lightweight JCA container available jas...@ma... wrote: >> I'm pretty much aware of both options and can see number of >> disadvantages for solution based on Tomkat. > > Like what? :) Besides vendor reputation and acceptance on the entrprise market its primarily cluster-related, especially in a cluster that has stateful components. Failover and resource management (jdbc and external jms) also quite limited there. Monitoring capabilities probably also less advanced. >> Also it could be not even an option in many cases. Anyway it seems >> that you have ignored the last part of my original message. > > Sorry I wasn't very clear before - here's another go. > > The WorkManager part is a non issue. It was never in any other J2EE > version and so isn't a versioning issue - you should be able to use = the > WorkManager API in any J2EE container. If the container is J2EE 1.4 > it'll have one, if it doesn't the JCAContainer comes with its own > implementation anyways. > > So the WorkManager isn't the issue - the issue is, does the JCA = version > hardwired into the J2EE container work - I've a feeling previous JCA > versions in J2EE 1.3 containers might not work with the current > JCAContainer as the JCAContainer is dependent on JCA 1.5. That is more or less clear already. :-) By the way you probably could use isolating classloader to keep WorkManager API away/separate from the J2EE classpath. >> Most likely you'll have to have container-specific WorkManager >> implementation that will not interfere with container life cycle. > > I don't follow. The JCAContainer just uses any WorkManager > implementation. Either your container provides one, or you can use the > bundled one in JCAContainer. Its a fairly trivial bit of code the > WorkManager - you could even write your own using your containers > ThreadPools if it doesn't yet support the WorkManager APIs. Ok. Here is the scenario I'm talking about. Let say WorkManager started some relatively long-running transactional or nontransactional process (message processing in POJO may take some time for a variety of reasons) and nearly after that thread has been started J2EE container decide to go down (doesn't really matter why, and number of reasons will increase for large environment). So, now I can't see how proprietory WorkManager implementation can coordinate with the container lifecycle in such case. Am I missing something? >> And most likely those implementations will be different even between >> Tomkat and Jetty. > > Tomcat and Jetty don't have WorkManager implementations as they are = not > JCA 1.5 containers nor are they full J2EE containers. So the > JCAContainer's WorkManager is fine for us in any Spring deployment - > unless its a pre-J2EE 1.4 container in which case the JCA versions = could > clash. Sure they don't. I'm talking about integrating your JCA container's WorkManager into J2EE/Web server lifecycle. regards, Eugene ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jas...@ma...> - 2004-10-27 18:29:44
|
On 27 Oct 2004, at 19:25, j=FCrgen h=F6ller [werk3AT] wrote: > James, > > That's cool stuff! In particular as it reuses the existing=20 > RemoteInvocation support so nicely. However, I still vote to put it=20 > into the sandbox for the 1.1.x timeframe. Mainly because there is no=20= > time to polish it, and it's worth to be publically introduced in a 1.x=20= > release. Fine with me. > Also, for the server side, we don't ship facilities to host the=20 > MessageListener (JmsServiceExporter) yet. I see that this is in the=20 > works :-) but we're still lacking recommendations on how to deploy JMS=20= > remoting end-to-end. One more reason to keep it in the sandbox for the=20= > time being. OK - but that's one of the reasons I've been trying to get the=20 JCAContainer going, so we have an end-to-end solution for JMS. > Finally, I'd prefer jms.remoting as package rather than remoting.jms -=20= > for a comparison, our transaction manager implementations reside in=20 > jdbc respectively orm.hibernate etc too, rather than in the=20 > transaction package. EJB remoting resides in the ejb package too,=20 > despite reusing facilities from the remoting package. Ah OK. I just went with remoting.jms to be with the other remoting=20 solutions. I'm easy either way. > So if you don't object to the sandbox and the changed package name,=20 > I'll move it over to the sandbox into the jms.remoting directory... We=20= > need to clarify that before the 1.1.2 release, which is scheduled to=20= > happen this Sunday. Go for it. Lemme know what needs doing to get it back in once we're getting ready=20= for 1.2. James ------- http://radio.weblogs.com/0112098/ |
|
From: <jue...@we...> - 2004-10-27 18:23:06
|
James, =20 That's cool stuff! In particular as it reuses the existing = RemoteInvocation support so nicely. However, I still vote to put it into = the sandbox for the 1.1.x timeframe. Mainly because there is no time to = polish it, and it's worth to be publically introduced in a 1.x release. =20 Also, for the server side, we don't ship facilities to host the = MessageListener (JmsServiceExporter) yet. I see that this is in the = works :-) but we're still lacking recommendations on how to deploy JMS = remoting end-to-end. One more reason to keep it in the sandbox for the = time being. =20 Finally, I'd prefer jms.remoting as package rather than remoting.jms - = for a comparison, our transaction manager implementations reside in jdbc = respectively orm.hibernate etc too, rather than in the transaction = package. EJB remoting resides in the ejb package too, despite reusing = facilities from the remoting package. =20 So if you don't object to the sandbox and the changed package name, I'll = move it over to the sandbox into the jms.remoting directory... We need = to clarify that before the 1.1.2 release, which is scheduled to happen = this Sunday. =20 Cheers, Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von jas...@ma... Gesendet: Mo 18.10.2004 12:23 An: spr...@li... Betreff: [Springframework-developer] JMS remoting provider available I've hacked together a JMS provider of the remoting layer in Spring, which works like the HTTP, JAX-RPC & Caucho implementations but which uses JMS for the underlying networking code. By using JMS we can now load balance requests for a service across multiple service endpoints; so we can easily implement a cluster of servers complete with load balancing and auto fail-over. Currently this assumes a state-less service model. We may wish to implement something a little more clever for stateful services (and how to fail-over in a cluster of stateful services), but this is a first cut which should be quite useful for clusters of stateless services - we could layer on top some kind of stateful mechanism. Some JMS providers have features like 'exclusive queues' or 'message groups' which can be used to provide stateful-like routing of messages similar to those used in EJB containers for stateful session beans. The code is pretty straightforward; just 3 classes, so I took the cheeky approach of checking it straight into the main code branch rather than leaving it spend time in the sandbox first; we can easily move it into the sandbox if need be. Where possible the makes use of the existing JmsTemplate code. To simplify the implementation code I used the QueueRequestor, but we could tidy that up later and use explicit send() / receive() instead to be able to support configurable timeouts and timeToLive values on a remote request etc. Any feedback or thoughts are most welcome James ------- http://radio.weblogs.com/0112098/ ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Eugene K. <eu...@md...> - 2004-10-27 18:20:56
|
jas...@ma... wrote: >> I'm pretty much aware of both options and can see number of >> disadvantages for solution based on Tomkat. > > Like what? :) Besides vendor reputation and acceptance on the entrprise market its primarily cluster-related, especially in a cluster that has stateful components. Failover and resource management (jdbc and external jms) also quite limited there. Monitoring capabilities probably also less advanced. >> Also it could be not even an option in many cases. Anyway it seems >> that you have ignored the last part of my original message. > > Sorry I wasn't very clear before - here's another go. > > The WorkManager part is a non issue. It was never in any other J2EE > version and so isn't a versioning issue - you should be able to use the > WorkManager API in any J2EE container. If the container is J2EE 1.4 > it'll have one, if it doesn't the JCAContainer comes with its own > implementation anyways. > > So the WorkManager isn't the issue - the issue is, does the JCA version > hardwired into the J2EE container work - I've a feeling previous JCA > versions in J2EE 1.3 containers might not work with the current > JCAContainer as the JCAContainer is dependent on JCA 1.5. That is more or less clear already. :-) By the way you probably could use isolating classloader to keep WorkManager API away/separate from the J2EE classpath. >> Most likely you'll have to have container-specific WorkManager >> implementation that will not interfere with container life cycle. > > I don't follow. The JCAContainer just uses any WorkManager > implementation. Either your container provides one, or you can use the > bundled one in JCAContainer. Its a fairly trivial bit of code the > WorkManager - you could even write your own using your containers > ThreadPools if it doesn't yet support the WorkManager APIs. Ok. Here is the scenario I'm talking about. Let say WorkManager started some relatively long-running transactional or nontransactional process (message processing in POJO may take some time for a variety of reasons) and nearly after that thread has been started J2EE container decide to go down (doesn't really matter why, and number of reasons will increase for large environment). So, now I can't see how proprietory WorkManager implementation can coordinate with the container lifecycle in such case. Am I missing something? >> And most likely those implementations will be different even between >> Tomkat and Jetty. > > Tomcat and Jetty don't have WorkManager implementations as they are not > JCA 1.5 containers nor are they full J2EE containers. So the > JCAContainer's WorkManager is fine for us in any Spring deployment - > unless its a pre-J2EE 1.4 container in which case the JCA versions could > clash. Sure they don't. I'm talking about integrating your JCA container's WorkManager into J2EE/Web server lifecycle. regards, Eugene |
|
From: Mark P. <Mar...@co...> - 2004-10-27 16:59:34
|
Hi, Great job! Going to try it out asap... - Mark > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of jas...@ma... > Sent: Wednesday, October 27, 2004 5:23 AM > To: spr...@li... > Subject: [Springframework-developer] Spring MDB / Message Driven POJOs >=20 >=20 > This has been an ongoing area of research for some time - how=20 > best to =20 > do JMS consumption from inside Spring. After scratching my=20 > head for a =20 > while over the best way to do this; I figured, JCA is the=20 > answer, since =20 > it takes care of all the thorny issues behind doing proper consumer =20 > based JMS pooling and transaction handling, which is way more=20 > complex =20 > than you might imagine. The only downside of this approach is that =20 > folks often think JCA is really complex & fat & depends on a J2EE =20 > container which is not true. >=20 > As part of the ActiveMQ project we've written a small, Spring=20 > based & =20 > easily embedded JCA container. Its just a few classes and is easy to =20 > use on any project, just depending on Spring and the JCA APIs. >=20 > http://activemq.codehaus.org/JCA+Container >=20 > So we can now have all the features of MDB such as efficient JMS =20 > pooling, hooks to work with all the major JMS providers via=20 > their JCA =20 > Resource Adapters (*), proper transaction handling and pooling of =20 > message listeners - but all from within Spring. We get the added =20 > benefit that we get to use Spring's Dependency Injection to=20 > configure =20 > the message listeners properly - plus we can easily perform=20 > the dynamic =20 > creation of new subscriptions easily at runtime, rather than=20 > having to =20 > rely on a fixed & rigid XML deployment configuration like EJB. >=20 > So now we've 'message driven pojos' in Spring! :) >=20 > To give you an idea of how simple it is, here's a sample... >=20 > http://cvs.activemq.codehaus.org/viewrep/activemq/activemq/modules/=20 > container/src/test/org/codehaus/activemq/jca/spring.xml?r=3DHEAD >=20 > There's more detailed documentation on the above page if you need it. >=20 >=20 > (*) to help work with other JMS providers which don't yet=20 > provide a JCA =20 > ResourceAdapter, which they really should if they want to integrate =20 > well with other J2EE containers, we could enhance ActiveMQ's =20 > ResourceAdapter to work with foreign JMS providers. >=20 > James > ------- > http://radio.weblogs.com/0112098/ >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE=20 > LinuxWorld Reader's Choice Award Winner for best database on=20 > Linux. http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > _______________________________________________ > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 |
|
From: <jas...@ma...> - 2004-10-27 16:38:20
|
On 27 Oct 2004, at 17:29, Eugene Kuleshov wrote: > jas...@ma... wrote: >>>>> Then because it is using WorkManager's I wonder how it fits into >>>>> exisitng J2EE container that does not support this API. I'm not >>>>> convinced that it would be a good idea if component would do its >>>>> own >>>>> thread management (it woundn't be an issue for a single-noded >>>>> Tomkat >>>>> server, but could cause serious troubles on Weblogic or WebSphere >>>>> clusters). >>>>> So, it would be a good idea to capture some good practices >>>>> where to use and where not to use this component. >>>> The WorkManager could come from a J2EE container; so the >>>> WorkManager is just a property set on the JCAContainer which >>>> could be looked up via JNDI. Plus we've a simple implementation >>>> based on the Geronimo codebase but with some of the Geronimo >>>> dependencies removed to make it easy to use in just Spring - if >>>> we were deploying inside Geronimo we could just use its inbuilt & >>>> JMX managed implementation. Or a commercial J2EE container would >>>> come with its own WorkManager implementation managed by the >>>> container. >>> I wonder if there would be any use of this container on J2EE 1.3 >>> compliant containers where is no standard WorkManager API >>> available. >> I'm not sure if it'd work with J2EE 1.3 on the classpath - we'd have >> to try that. > > >> Hopefully since much of JCA 1.5 is new packages, it might work. If >> need be you could always just ditch the old J2EE 1.3 container and >> use pure Spring or Tomcat / Jetty + Spring etc :) > > Let's not start this. :-) OK :) > I'm pretty much aware of both options and can see number of > disadvantages for solution based on Tomkat. Like what? :) > Also it could be not even an option in many cases. Anyway it seems > that you have ignored the last part of my original message. Sorry I wasn't very clear before - here's another go. The WorkManager part is a non issue. It was never in any other J2EE version and so isn't a versioning issue - you should be able to use the WorkManager API in any J2EE container. If the container is J2EE 1.4 it'll have one, if it doesn't the JCAContainer comes with its own implementation anyways. So the WorkManager isn't the issue - the issue is, does the JCA version hardwired into the J2EE container work - I've a feeling previous JCA versions in J2EE 1.3 containers might not work with the current JCAContainer as the JCAContainer is dependent on JCA 1.5. > Most likely you'll have to have container-specific WorkManager > implementation that will not interfere with container life cycle. I don't follow. The JCAContainer just uses any WorkManager implementation. Either your container provides one, or you can use the bundled one in JCAContainer. Its a fairly trivial bit of code the WorkManager - you could even write your own using your containers ThreadPools if it doesn't yet support the WorkManager APIs. > And most likely those implementations will be different even between > Tomkat and Jetty. Tomcat and Jetty don't have WorkManager implementations as they are not JCA 1.5 containers nor are they full J2EE containers. So the JCAContainer's WorkManager is fine for us in any Spring deployment - unless its a pre-J2EE 1.4 container in which case the JCA versions could clash. James ------- http://radio.weblogs.com/0112098/ |
|
From: Eugene K. <eu...@md...> - 2004-10-27 16:30:08
|
jas...@ma... wrote: >>>> Then because it is using WorkManager's I wonder how it fits into >>>> exisitng J2EE container that does not support this API. I'm not >>>> convinced that it would be a good idea if component would do its own >>>> thread management (it woundn't be an issue for a single-noded Tomkat >>>> server, but could cause serious troubles on Weblogic or WebSphere >>>> clusters). >>>> >>>> So, it would be a good idea to capture some good practices >>>> where to use and where not to use this component. >>> >>> The WorkManager could come from a J2EE container; so the >>> WorkManager is just a property set on the JCAContainer which >>> could be looked up via JNDI. Plus we've a simple implementation >>> based on the Geronimo codebase but with some of the Geronimo >>> dependencies removed to make it easy to use in just Spring - if >>> we were deploying inside Geronimo we could just use its inbuilt & >>> JMX managed implementation. Or a commercial J2EE container would >>> come with its own WorkManager implementation managed by the >>> container. >> >> I wonder if there would be any use of this container on J2EE 1.3 >> compliant containers where is no standard WorkManager API >> available. > > I'm not sure if it'd work with J2EE 1.3 on the classpath - we'd have > to try that. > > Hopefully since much of JCA 1.5 is new packages, it might work. If > need be you could always just ditch the old J2EE 1.3 container and > use pure Spring or Tomcat / Jetty + Spring etc :) Let's not start this. :-) I'm pretty much aware of both options and can see number of disadvantages for solution based on Tomkat. Also it could be not even an option in many cases. Anyway it seems that you have ignored the last part of my original message. Most likely you'll have to have container-specific WorkManager implementation that will not interfere with container life cycle. And most likely those implementations will be different even between Tomkat and Jetty. regards, Eugene |
|
From: Venkat S. <vso...@ho...> - 2004-10-27 16:28:13
|
Hi Jurgen, Thanks for your detailed reply. That will definitely help me... I will keep you posted on how it goes. Regards, --Venkat. From: jürgen höller [werk3AT] <jue...@we...> Reply-To: spr...@li... To: <spr...@li...> Subject: Re: [Springframework-developer] Hi Date: Tue, 26 Oct 2004 20:48:13 +0200 MIME-Version: 1.0 Received: from mc5-f10.hotmail.com ([65.54.252.17]) by mc5-s5.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 26 Oct 2004 11:46:38 -0700 Received: from sc8-sf-uberspam1.sourceforge.net ([66.35.250.206]) by mc5-f10.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 26 Oct 2004 11:46:37 -0700 Received: from projects.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7])by sc8-sf-uberspam1.sourceforge.net (Postfix) with ESMTPid 43BF61D3FAB; Tue, 26 Oct 2004 11:46:03 -0700 (PDT) Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net)by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30)id 1CMWKR-0005oS-SKfor spr...@li...; Tue, 26 Oct 2004 11:45:55 -0700 Received: from cm140-139.liwest.at ([81.10.140.139] helo=mail.werk3at.com)by sc8-sf-mx2.sourceforge.net with esmtp (Exim 4.41)id 1CMWKR-0000CG-B2for spr...@li...; Tue, 26 Oct 2004 11:45:55 -0700 X-Message-Info: 0jbW5ANosZJyzd/TkjWMPHBAvKTbhaxx X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Message-ID: <170...@co...> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Springframework-developer] Hi Thread-Index: AcS7iP1twEX/rnJqTDW7ROh5NvcNiwAAeBrb X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=2000010.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with /0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with -0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with '0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with .0.0 SF_CHICKENPOX_UNDERSCORE BODY: Text interparsed with _0.0 SF_CHICKENPOX_EQUAL BODY: Text interparsed with =0.7 FOR_FREE BODY: No such thing as a free lunch (1) Errors-To: spr...@li... X-BeenThere: spr...@li... X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/springframework-developer>,<mailto:spr...@li...?subject=unsubscribe> List-Id: <springframework-developer.lists.sourceforge.net> List-Post: <mailto:spr...@li...> List-Help: <mailto:spr...@li...?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/springframework-developer>,<mailto:spr...@li...?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=springframework-developer> Return-Path: spr...@li... X-OriginalArrivalTime: 26 Oct 2004 18:46:37.0772 (UTC) FILETIME=[1FDEB0C0:01C4BB8C] Hi Venkat, First of all, thanks for your kinds words on Sprign :-) Regarding ICE: You should be able to treat just it like any other of the remoting protocols that Spring supports. As a starting point, have a look at how Spring's Hessian support (for Caucho's HTTP-based Hessian protocol) is implemented. Our usual pattern for the client side is to implement the actual invocation handling in an interceptor base class (like HessianClientInterceptor) and derive a convenient FactoryBean from it (like HessianProxyFactoryBean). The interceptor basically takes the local method invocation and converts it to a corresponding remote invocation, in turn converting the remote invocation result back to a local invocation result. What's exposed to the caller is usually a plain Java (i.e. non-RMI) interface. For a comparison, you could also have a look at Spring's RMI support, although that one is more complicated: It can work with either an RMI interface or a non-RMI business interface, so has quite a bit of case handling inside. The internals of the Hessian support are significantly simpler. Of special concern is the exception handling. The current Spring remoting support usually lets all exceptions thrown by the target service through as-is, according to the business interface contract. The interesting part is how to handle remote access failure: In Spring, all such exceptions are converted to the generic org.springframework.remoting.RemoteAccessException. From the point of view of the caller, it always gets a RemoteAccessException, no matter which protocol is used underneath. So the main responsibilities of the client interceptor respectively proxy factory bean are to delegate the call to the corresponding target service, and to correctly handle exceptions thrown. The current support classes should give a good indication on how to achieve this properly. Keep us up-to-date on how things are progressing at the ICE front! Regards, Juergen ________________________________ Von: spr...@li... im Auftrag von Venkat Sonnathi Gesendet: Di 26.10.2004 20:19 An: Spr...@li... Betreff: [Springframework-developer] Hi Hi, Thanks for the cool framework. I am still new to it. I like Dependency Setter Injection for JNDI lookup for DataSource and SLSB. We are contemplating on using ICE (http://www.zeroc.com) for distribution, as it supports versioning, cross platform, location transparency (no remote vs local interfaces) and cool asynchronous programming model. Naturally every one is concerned and want the dependencies on it to be minimal. I would like to instantiate stubs to ICE remote services via Spring. What's the best way to start/look at what code? Thanks in advance, --Venkat. ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
1239 messages has been excluded from this view by a project administrator.
