Menu
▾
▴
springframework-developer
|
From: Eugene K. <eu...@md...> - 2004-10-27 16:10:49
|
James Strachan 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. regards, Eugene |
|
From: <jas...@ma...> - 2004-10-27 16:15:00
|
On 27 Oct 2004, at 17:10, Eugene Kuleshov wrote: > James Strachan 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 :) 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: <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 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: <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: 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: 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: 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: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 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: Jason C. <ja...@ze...> - 2004-10-28 14:51:59
|
Eugene Kuleshov wrote: > 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 > This is kind of like what I built... I built a JMS dispatcher for XWork which is all wired together with Spring. The components you write are just XWork Actions (just POJOs which implement the Action interface) and the rest of what happens, whether it's sending a response Message or sending 100 messages, one for each Object in a List, is handled by the framework outside the Action based on configuration. I made the Dispatcher a MessageListener and created a sub-class which is an MDB. I'm very interested in seeing how this Spring MDB replacement goes with transactional semantics, 'cause then this could be deployed in a very light container. If anyone's interested in trying this out in a "real app" let me know, for now it's just been an interesting intellectual challenge and an example to use for the WebWork book of how XWork can be used outside the web... Jason |
|
From: Eugene K. <eu...@md...> - 2004-10-28 16:54:41
|
Jason Carreira wrote: >> Are you suggesting to replace Spring with XWork? :-) > No, not at all... The project I was discussing uses Spring to wire > everything together. I was just suggesting that you can have Action > classes (really command objects) which don't have to know anything about > JMS, and could even be reused across JMS, Web, or even command line. I > like my components to be decoupled from the deployment technologies. Still can't see why XWork action wold be better then POJO's managed by Spring. In my case MDB is basically delegating all processing to given POJO's. I was thinking on doing somehow opposite thing. Use custom interceptor, which will transparently serializes all parameters and send them together with POJO name to JMS queue, which has pool of consumers (MDB's in my case) that are asynchronously executing that call on given POJO instance. :-) The only issue there is to detect in interceptor where POJO has been called from (skip interceptor if it is called from message consumer/MDB). Spring AOP documentation is saying that it is not recommended/slow to use control flow pointcuts, so other options would be to use custom pointcut or even AW or AspectJ. regards, Eugene |
|
From: <jas...@ma...> - 2004-10-28 17:01:07
|
On 28 Oct 2004, at 17:54, Eugene Kuleshov wrote: > Jason Carreira wrote: > >>> Are you suggesting to replace Spring with XWork? :-) > >> No, not at all... The project I was discussing uses Spring to wire >> everything together. I was just suggesting that you can have Action >> classes (really command objects) which don't have to know anything >> about JMS, and could even be reused across JMS, Web, or even command >> line. I like my components to be decoupled from the deployment >> technologies. > > Still can't see why XWork action wold be better then POJO's managed > by Spring. In my case MDB is basically delegating all processing to > given POJO's. > > I was thinking on doing somehow opposite thing. Use custom > interceptor, which will transparently serializes all parameters and > send them together with POJO name to JMS queue, which has pool of > consumers (MDB's in my case) that are asynchronously executing that > call on given POJO instance. :-) Unless I'm missing something, that sounds exactly like Spring JMS Remoting :). The only difference is to use pooling, we'd probably use 'message driven pojos'. James ------- http://radio.weblogs.com/0112098/ |
|
From: Eugene K. <eu...@md...> - 2004-10-28 17:06:57
|
jas...@ma... wrote: >> I was thinking on doing somehow opposite thing. Use custom >> interceptor, which will transparently serializes all parameters and >> send them together with POJO name to JMS queue, which has pool of >> consumers (MDB's in my case) that are asynchronously executing that >> call on given POJO instance. :-) > > Unless I'm missing something, that sounds exactly like Spring JMS > Remoting :). The only difference is to use pooling, we'd probably use > 'message driven pojos'. Similar, but POJO defined only once in a local Spring context and from client point of view it is not different in both cases: MyBean b = (MyBean) SpringContext.getBean( "asyncPojo"); b.someMethod(); // executed asynchronously (no return) regards, Eugene |
|
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/ |
