I didn't understand your issue...
Did you mean "with the jbossmq this destination would have *no* security check?
How it was supposed to behave? JBM is just getting the default security from ServerPeer if no destination is provided on QueueService. What testcase is this... and I will be taking a look as I'm messing with upgrading JBM and looking at testcases on 5 now.
Yes, if there is no security config on the destination, there would be no security check.
The org.jboss.test.security.test.EJBSpecUnitTestCase.testRunAsWithRoles. The mdb's run-as identity is being seen by the jms destination, but there should be no security check.
Well... this is how it behaves now...
I will need Tim to comment on that.
Ok, I'm trying to understand the requirement here.
Currently if there is no security configuration on the destination the default security will get used.
If instead, there is no security conf on the destination and we drop security altogether, then what do we use the default security for? Does it have any purpose?
(BTW I thought JBoss MQ also fell back to default security if no security was specified - obviously not!)
If you want no security can't you just specify the default security as no security and not specify any security on the dest?
Removing the default security config has no affect because it appears that a default based on guest is installed anyway:
13:35:04,591 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueA, adding guest 13:35:04,748 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueD, adding guest 13:35:04,763 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueC, adding guest 13:36:32,591 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueC, adding guest 13:36:32,779 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueB, adding guest 13:36:34,841 WARN [SecurityMetadataStore] No SecurityMetadadata was available f or QueueB, adding guest 13:36:34,873 ERROR [RunAsWithRolesMDB] Failed to send reply javax.jms.JMSSecurityException: User: null is not authorized to write to destination QueueB at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.ja va:312) at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspe ct.java:155) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java: 119) at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_72806806276 20114891.invokeNext(SessionAdvised$send_7280680627620114891.java) at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvi sed.java) at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendR equest.java:90) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSSe rverInvocationHandler.java:143) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:771) at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalCli entInvoker.java:101) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.remoting.Client.invoke(Client.java:536)
The org.jboss.jms.server.container.SecurityAspect and aop-messaging-server.xml should be part of the integration code, not the jboss-messaging.jar. These depend on SecurityMetadataStore which in turn depends on the security spi of the server. It also depends directly on the org.w3c.dom.Element format of the security config, which makes it unmanagable by the profile service.
Deployment of aspects likewise depends on the target server environment.
This code/configuration needs to be factored out and the appropriate integration projects created for it.