jbossmq with CallerIdentityLoginModule

[philc]

I am going to install this minimal configuration for JBoss 3.2.2RC3.
Do I need to have Tomcat JBossWeb HTTP server or do I need to have integrated Jetty 4.2.11 instead of Tomcat or does it matter at all?
Is the advice to have Jetty above actually an advice to have any Web/JBoss or should it be necessarily Jetty?
And another question. Will I be able to deploy MBeans and invoke methods on them with this type of installation? Or is JMX-Console not enough for that?

[philc]

I am trying to get jbossmq to use my EJB's Security information to create, write and read topics. I have 2 Security Domains:

1. MyEJBSecurityDomain configured with an LdapLoginModule

2. jbossmq configured with

<application-policy name="jbossmq">
 <authentication>
 <login-module code="com.brockhousecooper.tw.ejb.server.authentication.CallerIdentityLoginModule" flag="required">
 <module-option name = "managedConnectionFactoryName">jboss.jca:name=JmsXA,service=TxCM</module-option>
 </login-module>
 </authentication>
</application-policy>

I use this code to login from within an MBean and create a TopicConnection

lc = new LoginContext("client-login", handler);
lc.login();
log.info("principal before: " + SecurityAssociation.getPrincipal());
connection = conFactory.createTopicConnection();

the log prints "principal before: admin" before creating the topic, however, jbossmq's Security Interceptor reports:
[ServerSecurityInterceptor] Autenticating user null/null
and the calls GetPrincipalInfoAction.getPrincipal() and GetPrincipalInfoAction.getCredential() inside CallerIndentityLoginModule both return null.

Are my login modules badly configured or is this a bug in CallerIdentityLoginModule?

[starksm64]

Ah, now I see what you're saying. Thanks.

I suppose there'd be no good way to cluster the injected abort state without doing an mbean lookup on every call rather than injecting to a static field in the interceptor from the jmx manager, though. That's dealable with, however, since in a cluster we'll presumably know what node the problem thread is running on.