[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by timfox
"adrian(a)jboss.org" wrote :
|
| There is actually nothing in the spec about this behaviour.
| The XA stuff is massively underspecified in the JMS spec.
| And of course it is optional whether a JMS impl supports XA.
|
| The JBossMQ behaviour is to assume that an XASession behaves like
| AUTO_ACKNOWLEDGE when the XASession is not enlisted in a JTA transaction.
| (Some JMS implements throw an exception in this case).
|
|
We are having some issues with TCK where it seems the TCK actually tests this situation - the behaviour it expects is the same as the JBossMQ gives :)
anonymous wrote :
| There is one exception to this. When the XASession is being used as part of
| a ServerSessionPool, the semantics need to be receive then enlist.
| So for this, the XASession behaves like there is a transaction, it will be told
| later what XID to use for the 2PC protocol.
What I don't quite understand is how the session knows it has been created via a session pool rather than any other way so it can have different behaviour.
I couldn't work out immediately from the JBoss MQ code how this info is passed to the session.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039207#4039207
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039207
18 years, 11 months
[Design of JBoss/Tomcat Integration] - Re: org.jboss.web.tomcat.security.RunAsListener
by anil.saldhana@jboss.com
I am seeing an issue that is a bit perplexing. I do not know how it was working before in JBoss4.
Here is the use case:
Testcase: org.jboss.test.web.test.WebIntegrationUnitTestCase
Scenarios: testUnsecureRunAsServlet, testUnsecureRunAsServletWithPrincipalName,testUnsecureRunAsServletWithPrincipalNameAndRoles
In my current pass at JBoss5, I am making use of a single threadlocal to contain the security context with push/pop mechanism.
| Servlet: RunAsServlet
|
| init()
| {
| //I have a run-as defined, I am going to call a secure ejb
| }
|
| service()
| {
| //I am going to call a secure ejb. run-as will be propagated
| }
|
In my sequence of calls, JaccContextValve which is set at the host level, establishes the security context on the thread local. After this, the SecurityAssociationValve will push the current run-as on to the established security context.
When the servlet is loaded, the init() method is preceded by an InstanceEvent("before_init") which will invoke the RunAsListener. I push the runas on to the security context. After the init method, there is an event for "after_init", which would pop the run as from the security context. So things work fine for the init() method secure ejb call.
There are issues from the service() method call in the servlet onto secure ejbs. The sequence of events are as follows for the service():
| JaccContextValve - set the security context
| SecurityAssociationValve - push run as
| load the servlet
| instanceevent:before-init - push run as
| init()
| instanceevent:after-init - pop run as
|
| At this time my thread local is devoid of any run as
|
| instanceevent:before_filter
| instanceevent:after_filter
| instanceevent:before_service
| service()
| instanceevent:after_service
|
As you can see, there is no passage of the request through the valve chain between invocation of the init() and service() methods. I think this is the right sequence.
I can solve this usecase by adding push/pop of run as in the RunAsListener for InstanceEvent(before_service) and InstanceEvent(after_service).
Thoughts/suggestions?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039113#4039113
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039113
18 years, 11 months