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

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

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/