[
https://issues.apache.org/jira/browse/ARTEMIS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693289#comment-17693289
]
Justin Bertram commented on ARTEMIS-4180:
-----------------------------------------
Do you have any kind of sample project that demonstrates the problem? I'd like
to take a closer look. What is the final outcome of the improper wrapping? Do
you ultimately end up with exceptions or incorrect behavior? Does the
transaction manager choke? Please clarify.
I suppose that whether or not it's "wrong" to wrap a non XA connection factory
with an XA-wrapper depends on what the final result is. It's perfectly valid
(and common) for one object to implement multiple interfaces, although it's not
strictly _necessary_. The JMS specification certainly doesn't prohibit such an
implementation. The code doing the wrapping is relying on a _convention_ that
the implementation will use different classes for {{ConnectionFactory}} and
{{XAConnectionFactory}} which may be sufficient in most cases but clearly isn't
valid in all cases.
One thing that surprises me is that this same essential implementation has been
in use for over 10 years now. It seems a bit odd that this would be breaking
now given, as you note, the commonality of this use-case.
> Unable to differentiate between XA and non XA connection factories
> ------------------------------------------------------------------
>
> Key: ARTEMIS-4180
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4180
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.26.0
> Reporter: Julio J. Gomez Diaz
> Priority: Major
>
> Using the ActiveMQ Artemis library
> ([https://github.com/apache/activemq-artemis)] we've detected that the
> org/apache/activemq/artemis/jms/client/ActiveMQConnectionFactory.java
> implements also the XAConnectionFactory, and
> org/apache/activemq/artemis/jms/client/ActiveMQXAConnectionFactory extends
> this, it seems rare that definition, the NON-XA Connection Factory
> implementation should implement only the ordinary
> {{jakarta.jms.ConnectionFactory}} and the XA Connection Factory should
> implement the {{jakarta.jms.XAConnectionFactory}}, this way we can be
> distinguished without problems if the Connection Factory is XA or not. This
> solution is what we are been working so far in another JMS-enabled brokers,
> and the exception is ActiveMQ Artemis. Apache ActiveMQ (pre-Artemis) follow
> this pattern (separation of XA and non XA).
> Why is it necessary the
> org/apache/activemq/artemis/jms/client/ActiveMQConnectionFactory implements
> also the {{jakarta.jms.XAConnectionFactory}}? Can this be changed? (Separated)
> We think this would be a great improvement for the sake of implementation
> ease.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
