|
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 |