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

[<jas...@ma...>]

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/