]
Jeff Mesnil updated AS7-5330:
-----------------------------
Fix Version/s: 7.1.3.Final (EAP)
7.2.0.Alpha1
Git Pull Request:
HornetQSecurityManagerAS7 is not restoring the original security
context when it pops its own
---------------------------------------------------------------------------------------------
Key: AS7-5330
URL:
https://issues.jboss.org/browse/AS7-5330
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.1.Final
Environment: Windows XP SP2
JDK 1.6.0_32
Eclipse Indigo for JMS Client invocation
Reporter: Ed Roberts
Assignee: Jeff Mesnil
Labels: jboss-as7, messaging, security-context
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
Attachments: JMSClient.java, messaging-susbsystem-configuration.txt,
messaging.war
I have added the HornetQ acceptor, connector and connection factory to allow JMS over
HTTP tunneling.
I tested a message send using an external JMS Client.
The following exception is thrown during the transmission
2012-08-09 10:50:07,155 ERROR
[org.apache.catalina.connector.CoyoteAdapter](http-executor-threads - 1) An exception or
error occurred in the container during the request processing:
java.lang.IllegalStateException: JBAS018053: No security context found
at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:136)
at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:130)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.as.web.security.SecurityActions.popRunAsIdentity(SecurityActions.java:130)
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:155)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:518)
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:842)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
After some debugging, I can make out that this has exposed a fault in the
HornetQSecurityManagerAS7. When it is active, it pushes the "other" security
context from my configuration into the active security context, but when done and pops its
security context, it does not restore the original, which was the jboss-web-policy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: