[
https://issues.apache.org/jira/browse/ARTEMIS-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4180:
------------------------------------
Description:
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.
was:
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.
> 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)
