[
https://issues.jboss.org/browse/WFLY-3493?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-3493:
----------------------------------------
[~jmesnil] This is due to how OperationContextImpl.ServiceRemovalVerificationHandler
works. The OC tracks what services are removed via the OC removeService API, and in the
JMSQueueRemove case that is just the JMSQueueService. The
ServiceRemovalVerificationHandler then reports a failure and triggers rollback if one of
those services shows up in the containerStateChangeReport.getMissingServices() map.
But the service that is missing is not the service that is removed, it is a JNDI binding
one:
15:16:04,467 INFO [org.jboss.as.controller] (management-handler-thread - 5) JBAS014774:
Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jboss.naming.context.java.queue.demo (missing) dependents: [service
jboss.naming.context.java.module.luckywinner.luckywinner.env."org.jboss.as.demos.luckywinner.webapp.LuckyWinnerServlet".queue]
So the JNDI binding is being removed, but the significance of that is unknown to the
management layer.
Messaging subsystem allows you to remove a destination even though it
has an attached client
--------------------------------------------------------------------------------------------
Key: WFLY-3493
URL:
https://issues.jboss.org/browse/WFLY-3493
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JMS
Affects Versions: 8.1.0.Final
Environment: WildFly 8.1 Final
Reporter: Tom Ross
Assignee: Jeff Mesnil
Currently jboss-cli allows a queue to be removed even though there is a MDB attached to
it. The command
{noformat}
/subsystem=messaging/hornetq-server=default/jms-queue=testQueue:remove()
{noformat}
will remove the queue without a warning. This is not desirable since a warning should be
given or a reload should be force. It may also break the dependency injection.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)