Re: [Springframework-developer] Re: [activemq-dev] Re: message driven POJOs, a lightweight JCA container available

[Eugene K. <eu...@md...>]

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