MDB-like functionality

[drewmca]

Any word on when the framework will support MDB-like functionality? I have a servlet application that needs to use JMS but I don't want to deal with using EjBS (also, it may need to run on Tomcat). I've been using commons-messenger for pub/sub, though I recently switched to Spring for pub and was wondering when sub functionality would be available.

Thanks,

Drew

[pmorelli]

Interested as well. Maybe just a timeframe?

I'd like to mimic mdb's as much as possible, as consumers. One to swap my message handling in and out of app servers, and two, because it's so simple, from the developer standpoint, at least...

--pete

[skroah]

The previous sandbox code had more sub functionality if you need it now and don't have time to develop it yourself. In general Spring JndiObjectFactoryBean made JMS easy enough the rest is just wrappers and callbacks. I do believe the new JMS stuff is taking a better long term approach.

[jstrachan]

FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

I"ll ping this forum when there's anything to look at

[pmorelli]

sounds great! can't wait to test it out.

Wasn't there a plan to add JCA to spring? I only mention it to try to save you some work...

--pete

[jstrachan]

Thanks Pete.

Yes I think there was discussion of adding JCA support in a similar way to JTA / JMS / JDBC.

The JCA support I meantioned above is for server side JCA - i.e. maintaining JCA pools of Managed Connections and Resource Adapters and handling the pools of beans, threads, transactions and so forth - rather than being JCA client side (using a JCA connection to send a JMS message for example).

But yes, the aim is to reuse as much code as possible

[wgunadi]

FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

I"ll ping this forum when there's anything to look at

Question for James on this:
I was able to incorporate the code in Activemq's source distribution (org.codehaus.activemq.tool.ConsumerTool) as a bean in a Spring application hosted in Tomcat and get a similar behavior as an MDB. I still have to start the Broker separately, but I'm planning to automate that too (when Tomcat is started).

So why won't this solution be sufficient?
Why do we need JCA code from Geronimo?

BTW, I'm asking for education, not as a challenge

[jstrachan]

FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

I"ll ping this forum when there's anything to look at

Question for James on this:
I was able to incorporate the code in Activemq's source distribution (org.codehaus.activemq.tool.ConsumerTool) as a bean in a Spring application hosted in Tomcat and get a similar behavior as an MDB. I still have to start the Broker separately, but I'm planning to automate that too (when Tomcat is started).

So why won't this solution be sufficient?
Why do we need JCA code from Geronimo?

BTW, I'm asking for education, not as a challenge

Your solution is totally sufficient for the simple case - creating a single consumer for a destination and registering a MessageListener.

Where it breaks down is handling more complex issues like

* pooling of MessageListener instances so that multiple messages can be processed in parallel (e.g. if you want to process messages on a queue, you might wanna process them in parallel, using 1 MessageListener per thread or something)

* automatic handling of transactions & security and all the other J2EE things - e.g. using MDBs you can let the MDB container automatically take care of JMS or XA transactions for you

For the simple case where transactions are not required, you can just create N consumers for a given queue and you've a reasonable solution using pure JMS. Ultimately though, I wanted a simple POJO & dependency injection based alternative to MDBs which supported both consuming & sending of messages.

So really its just a matter of implementing a little container for managing the MDBs and dispatching the messages - which is really what the JCA container does in J2EE anyways - so I was wondering about just reusing that code, but putting a simple Spring dependency injection facade on top so its very simple & easy to use for a developer - particularly one used to Spring - and we solve the problem without having to write too much duplicate code.

[sjivan]

FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

Is there some sample code available for this?

Thanks,
Sanjiv

[jstrachan]

FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

Is there some sample code available for this?

Thanks,
Sanjiv

Yes - see the example code described on this page...

http://activemq.codehaus.org/JCA+Container