]
Jeff Mesnil commented on WFLY-10200:
------------------------------------
This RFE would break existing behaviour.
Destinations deployed by -jms.xml file are bound to JNDI and could be used by remote
applications.
If we only WARN when the destinations are not deployed, any remote applications that
expect to look up these resources would fail.
{quote}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.{quote}
This is indeed an useful use case. The presence of the messaging-activemq subsystem is
required for any JMS applications that uses the Java EE annotations to define JMS
resources or using injected JMSContext.
So if the application is using another JMS broker (through a resource adapter), the
messaging-activemq subsystem must be installed so that the annotations can be processed
and the JMS resources deployed as expected.
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.