Hmm. An easy yet tricky decision; consistency with our 1.1 API or not.
I like option 1, but mostly because it keeps the API for JMSContext
cleaner. I think it will probably help implementers reuse their XA
handling code too, but as an evil end user I'm less concerned about this!
Nick
Nicholas Wright
Senior Consultant
/C2B2 Consulting Ltd
/*The Leading Independent Middleware Experts*/
/W: www.c2b2.co.uk| T: (+44) 8450 539457| M: (+44) 7703 193351|
@c2b2consulting
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Unit 34, Malvern Hills Science Park, Geraldine
Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale,
Old Hollow, Malvern, Worcestershire
On 30/10/2012 20:04, Nigel Deakin wrote:
> I have raised the following issue:
> http://java.net/jira/browse/JMS_SPEC-105
> Provide API to allow an app server or resource adapter to obtain a
> XAResource from a JMSContext
>
> I see this issue as a bit of tidying-up - simply extending the
> optional XA interfaces to provide proper support for JMSContext - but
> I think it is something that we have to do for JMS 2.0.
>
> -----------------------------------------------------------------------------------------------
>
>
> JMS 1.1 defined an optional API to allow an application server or
> resource adapter to obtain a XAResource object corresponding to a
> Session object. This is the "chapter 8" API, which defines the
> optional interfaces XAConnectionFactory, XAConnection, XASession and
> the method XASession#getXAResource().
>
> However there is currently no equivalent API to allow an application
> server or resource adapter to obtain a XAResource object corresponding
> to a JMSContext object.
>
> This means that an application server which uses the "chapter 8" API
> to integrate with a JMS provider (rather than using a resource
> adapter) cannot support JMSContext properly. The same applies for a
> generic resource adapter which uses the "chapter 8" API to integrate
> with any JMS provider.
>
> There are two alternatives:
>
> *** Option 1
>
> This option follows the same approach as the existing "chapter 8" API
>
> * Add four new new createXAContext methods to XAConnectionFactory.
> These are similar to the four existing createContext methods on
> ConnectionFactory except that they return a XAJMSContext rather than a
> JMSContext
>
> * Define a new interface XAJMSContext. This is a subtype of JMSContext
> with one additional method, getXAResource, which returns a XAResource.
>
> *** Option 2
>
> * Simply add a new method getXAResource to the JMSContext
>
> In both cases implementation of the new interfaces and methods would
> be optional just like the rest of the existing "chapter 8" API is.
>
> It is proposed that option 1 be adopted since this is consistent with
> the existing API, but option 2 is mentioned as a possible alternative.
>
> Note that even though the chapter 8 API is optional, and JMS 2.0
> encourages the use of a the JCA API rather than the chapter 8 API for
> integration of a JMS provider and an application server, the chapter 8
> API continues to be part of JMS and is valued by some vendors. If we
> did not implement this change then we would effectively be breaking
> this API by making it unusable with JMSContext objects.
>
> -----------------------------------------------------------------------------------------------
>
>
> As always, please give your comments, questions or suggestions.
>
> Clebert was very quick off the mark and added a comment to the JIRA
> issue asking about transaction recovery. Can you (Clebert) please
> explain the issue in more detail (perhaps in an email)? As you said,
> that is probably not a JMS issue, but if we need to submit an issue to
> some other spec I'd like to help. There are, for example, maintenance
> releases of the JTA and JCA specs going on currently.
>
> Nigel
>
>
>