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

[<jue...@we...>]

First of all - great work, James :-) In the long run, do you intend to =
move the generic parts over to the Spring codebase, or will those remain =
part of the ActiveMQ project too? It's not immediately obvious to me =
which classes depend on the actual ActiveMQ message broker and which =
just reside there but are generic in nature... (I've just looked at the =
sample configuration yet.)
=20
Eugene, regarding integrating the WorkManager into the server lifecycle: =
If the WorkManager implements Spring's DisposableBean interface or has a =
declaratively specified destroy method, it will receive a proper =
shutdown callback - when the Spring application context gets closed (for =
example, when the web application gets shut down).
=20
Effectively, the WorkManager is similar to a Quartz Scheduler: It fires =
up with the Spring context, manages a couple of threads for asynchronous =
processing there, and closed down with the Spring context again. I don't =
see any more conflict with the J2EE server's resource management here =
than in the case of Quartz...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Eugene Kuleshov
Gesendet: Mi 27.10.2004 20:20
An: spr...@li...
Cc: de...@ac...
Betreff: Re: [Springframework-developer] Re: [activemq-dev] Re: message =
driven POJOs, a lightweight JCA container available



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



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer