[jboss-jira] [JBoss JIRA] (WFLY-10200) WARN on presence of -jmx.xml file if embedded broker is not present, instead of doing invalid wiring

[Jeff Mesnil (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-10200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558465#comment-13558465 ] 

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-crash-rec-eap7 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)