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

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

On 27 Oct 2004, at 19:38, j=FCrgen h=F6ller [werk3AT] wrote:
> First of all - great work, James :-)

Thanks!

> In the long run, do you intend to move the generic parts over to the=20=

> Spring codebase, or will those remain part of the ActiveMQ project=20
> too?

For simplicity sake I was gonna leave it in ActiveMQ for now -=20
particularly as we need it for other things in the ActiveMQ project and=20=

we'll be revving it pretty quickly. I also figured it was probably=20
better not to tie it to the Spring release schedule just yet. (e.g.=20
witness what's happening to the little JMS remoting stuff :)

Plus I figured it was maybe a bit big for Spring.  To be a general=20
solution for all JMS providers, Spring users may need a JCA=20
ResourceAdapter for their JMS provider if their provider doesn't have=20
one - in which case both activemq-container.jar and activemq-ra.jar=20
will be needed (rather than just activemq-container.jar).

Also over time we're putting together a set of useful JMS POJOs for=20
doing things like bridging JMS providers, transforming messages,=20
applying rules and workflow; which again are probably outside of the=20
scope of Spring.


>  It's not immediately obvious to me which classes depend on the actual=20=

> ActiveMQ message broker and which just reside there but are generic in=20=

> nature... (I've just looked at the sample configuration yet.)

The JCA Container doesn't depend on the ActiveMQ broker at all - its=20
just the demo uses ActiveMQ's Resource Adapter.


> Eugene, regarding integrating the WorkManager into the server=20
> lifecycle: If the WorkManager implements Spring's DisposableBean=20
> interface or has a declaratively specified destroy method, it will=20
> receive a proper shutdown callback - when the Spring application=20
> context gets closed (for example, when the web application gets shut=20=

> down).

Agreed. I think Eugene's concern was shutting down the container while=20=

the WorkManager was processing a message.


> Effectively, the WorkManager is similar to a Quartz Scheduler: It=20
> fires up with the Spring context, manages a couple of threads for=20
> asynchronous processing there, and closed down with the Spring context=20=

> again. I don't see any more conflict with the J2EE server's resource=20=

> management here than in the case of Quartz...

Agreed.

James
-------
http://radio.weblogs.com/0112098/