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

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

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/