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

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-10200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-10200:
------------------------------------
    Description: 
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-jms.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 -jms.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.

  was:
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.



> WARN on presence of -jms.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-jms.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 -jms.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)