Hi,
I am sorry I have not had the time to do anything on the jca1.5
integration. I have not even had time to read the new spec. From what
you say I would however draw the following conclusions:

1. The jca 1.5 have defined a new contract superceding chapter 8 in the
   JMS spec, which means that each JMS provider will have to roll its
   own JMS JCC provider adapter.

2. This only affecs asynchronous use, i.e only JMSContainerInvoker.

3. We would therefore perhaps want a jms.JCAContainerInvoker wich works
   agains the new JCA.

4. On the other hand we have been propagating for a year and a half now
   that chapter 8 in the JMS spec give us all we need, and we have
   integrated JBossMQ, SonicMQ and SwiftMQ through the chapter 8 api.

5. Adding a native RA to JBossMQ would entail recreating the Conumer
   stuff in the new RA.

6. My advice would actually be this: write a jca2chapter8 converter.

To do this you would thake the stuff from StdServerSession,
StdServerSessionPool and JMSContainerInvoker and integrate into the RA.
The RA would continue to work against a ProviderAdapter and chapter 8,
but would also be able to work with the new JCA.

Look for example in StdServerSession - there you can split the TX logic
and do your callback. 

The old way is that the appserver provides the thread pool
(StdServerSessionPool), the JMS provider gets a (Std)ServerSession from
the appserverpool, stuff its on session in it and let the appserver do
its work. Seems to be verry similar.

Hope this helps somewhat.

//Peter

On 30 Aug, David Jencks wrote:
> I started looking at modifying jbossmq and/or the jmsra adapter to work
> with the j2ee connector architecture 1.5 facilities.  I am definitely not a
> jms expert so a lot of what I say may not make sense.
> 
> Here's what the new spec provides that I think is relevant:
> 
> thread pooling through the WorkManager interface.  You submit Work
> instances to be done in other threads.  The app server controls the thread
> pooling.
> 
> message inflow through the MessageEndpoint interfaces.  In particular, I
> think we should use Option B which involves the jms system calling, on a
> MessageEndpoint supplied from the app server,
> 
> beforeDelivery([the onMessage method]); //this starts the jta tx and
> informs the adapter via an XAResource the adapter supplied earlier.
> 
> onMessage(message); //actual message delivery to MessageListener
> 
> afterDelivery(); //ends the tx, again the adapter is informed via the
> XAResource.
> 
> --------
> 
> I keep getting lost looking at the jms code.  My impression so far is that
> although the jca 1 jmsra adapter appears to work ok without modifying
> jbossmq, using the contracts mentioned above will require additional code
> in jbossmq itself, namely an additional way of delivering messages within a
> transaction.
> 
> Does this make sense?  Do any of the jbossmq experts want to work on this?
> 
> There are very simple examples of using the work and message endpoint
> interfaces in the testsuite in .../jca/inflow.
> 
> I haven't written the deployment portion of the connector 1.5 support yet: 
> I'm hoping for a real adapter example that can be used to test it. 
> However, I think for now everything needed can be set up without a deployer
> as explicit mbeans: this is what I did in the tests.
> 
> Thanks
> david jencks
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development

-- 
------------------------------------------------------------
Peter Antman    Chief Systems Architect, Business Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se  WWW: http://www.backsource.org
Email: [EMAIL PROTECTED]        
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 
------------------------------------------------------------



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to