[
https://issues.jboss.org/browse/WFLY-10200?page=com.atlassian.jira.plugin...
]
Jeff Mesnil commented on WFLY-10200:
------------------------------------
I'm leaving it open as I think that there might be room for improvement on that
topic.
First, the -jms.xml files are considered legacy (we added them in the messaging-activemq
subsystem as it was a feature provided by the legacy messaging subsystems) but there is no
reason to use them instead of the Java EE specified XML deployment file.
However, the Java EE XML file is itself very limited, it requires that the JMS broker is
available as a resource adapter that supports Admin objects to create the JMS resources.
As this support is optional for JMS (e.g. Artemis RA does not support them), we have a
hack where we try to match a messaging-activemq pooled-connection-factory (that is backed
by Artemis) to create the resources before we delegate to IronJacamar do do that with
JCA.
The original intent of this RFE (an application that requires JMS resources should be able
to work with either an embedded broker or a remote one) is valid.
It is difficult to achieve currently as the resource tree of the messaging-activemq
subsystem was not considered for such a use case. The main flaw is that the
pooled-connection-factory (that represents to a connection to a broker) is under the
server resource *even though a pooled-connection-factory can be configured to connect to
another unrelated broker*.
With the current structure, we must have an embedded broker that is running to be able to
connect to a remote one...
I am preparing a roadmap for the messaging features related to cloud enablement and this
RFE is taken into consideration. We need to have a better separation of concerns between
messaging client and broker that is reflected in our management model.
Once this roadmap has been discussed and approved, I'll open JIRA issues corresponding
to the different RFEs (and update this one) to cover all these new use cases.
WARN on presence of -jmx.xml file if embedded broker is not present,
instead of doing invalid wiring
----------------------------------------------------------------------------------------------------
Key: WFLY-10200
URL:
https://issues.jboss.org/browse/WFLY-10200
Project: WildFly
Issue Type: Enhancement
Components: JMS
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Priority: Minor
This is largely a topic for discussion.
If the messaging subsystem is present but no 'server' child resource is
installed, there's a DUP that will try and create services for destinations in any
discovered xxx-jmx.xml. These will fail due to missing dependencies on broker services.
Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the
destinations configured in the -jmx.xml and they are not provided otherwise (i.e.
separately configured on an external broker) then the app will fail anyway, and the WARN
would just help explain why. But if the destinations are available, then the -jms.xml
could be regarded as just ignorable cruft left in the deployment.
For example, the app at
https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-...
could benefit from this, by being able to work when deployed 1) with an embedded broker or
2) with an external broker and just an empty subsystem-messaging-activemq.
An assumption I'm making here is a subsystem=messaging-activemq is or will be useful
even without a child 'server' resource. That's what our current openshift
images configure when we configure for an external broker.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)