1.4.1 release for jbossas 5.0.0.Beta4

[starksm64]

I need a release of the Branch_Stable code for jbossas 5.0.0.Beta4 early next week. The only outstanding issue requested by Tim was Upgrade to JGroups 2.5:
http://jira.jboss.org/jira/browse/JBMESSAGING-1089

jbossas is using 2.6.1.GA, so that is what would need to be tested. This does not appear to require api/config changes in jbm, so its not clear it needs to be done for jbossas 5.0.0.Beta4. If that's true I would like to postpone that issue as I don't know who has time to do this testing.

My focus is on validating that the jbm aspects, management and security store can be override by the jbossas/messaging integration code. I should be done with that this week.

[timfox]

Due to the concurrent stack in JG 2.5 and later, this can hit conditions in the code that were never possible before since we only previously had one event queue.

This means we would have to do some work (probably not much) to ensure parts of JBM code were threadsafe where before they didn't need to be.

For now we have a workaround - there is a config option on JG 2.5 and later to specify the old event queue can be used. I believe Brian has already configured JBM in AS 5 to use its own stack with this set to true.

Ideally I would like to not have to set this flag, but if you're happy this can wait until after beta4 then that's fine by me, and we can put out a release as is after you have done your aspects checks.

[dimitris]

I agree we should leave enabled the legacy settings for now, and only upgrade JBM if Scott is not happy with the integration code.

[starksm64]

The 1.4.1 release just makes it possible to override behavior that affects integration. I don't plan on doing overrides except for management issues for beta4. Down the road the security needs to be changed for some known inconsistencies with jbossmq.

[timfox]

Scott - if you give me the word when you're happy with what's there and I'll cut a 1.4.1.

Then we'll probably have to do a SP after that with potentially the JG changes, but there shouldn't be any functional / config differences so a SP should be ok.

[starksm64]

The current Branch_Stable code works for the beta4 needs.