Integration of different tx manager with AS (and EAP) build+

[jhalliday]

By default the app server has a JTA implementation i.e. transactions don't span multiple JVMs. There is a limited ability to do remote (client side) demarcation of transaction boundaries, but it's transport dependent. Full, interoperable distributed transactions over IIOP are available by plugging in JBossTS JTS.

Up to now the AS+JTS configuration been a second class citizen in terms of test coverage. However, it's going to be a supported part of the next enterprise platform, so I've been thinking about how to test the AS in that configuration. Some of the AS testsuite does not make sense, since there is no ORB in the default configuration. It should be possible to run those tests using the JTS code i.e. .jar files, configured for JTA mode operation (different property file). The tests for the all configuration are still valid, but there is no automatic way to build and test the server with the JTS rather than JTA.

The general form of this question is: how to make the AS build and test process support a pluggable transaction manager. Pluggability is there at the API level, and getting there with respect to the testsuite code itself. However, the automated build+test process does not reflect it. It would be great to be able to inject an arbitrary implementation of the transaction-spi through build time configuration file and have it pulled in from a repository, have the app server built with it and have the tests run using it.

That's probably going to need hooks in the build system though, since only the transaction system implementation knows e.g. what jar files need to go where, what config files need to go into each AS profile and so on. Right now that information is hardcoded into the AS build scripts and supports only JBossTS JTA. We can hardcod the JjBossTS JTS too, or look at ways to generalize the build process. That may apply to other pluggable components too e.g. pull in another WS stack or messaging bus at build time. Basically anything which is a pluggable component of the AS i.e. has an SPI defined for it.

Any thoughts from the AS team?

[adrian.brock]

The difficulty is the license isn't it?

Since it is GPL people should take an explicit decision to deploy it.

e.g. we can bundle JTS in the distribution with an installer to ask if they want it
or with JBoss5 it could be an option in the profile service configuration

I'd recommend initially that the JTS test coverage on the appserver was a
seperate project that
1) pulled in the JBossAS build
2) changed the config to use JTS
3) ran its own testsuite

This avoids any license issues for the main JBossAS distribution.

[jhalliday]

I'm not suggesting we ship the JTS with AS, although we could consider it. However, because it's supported it needs better QA than it currently has.

> 3) ran its own testsuite

My point is that the JTS replaces the JTA for customers that use it. It may have additional tests, but it needs to pass all the regular AS testsuite ones too. The AS (or at least the EAP) should not ship unless it does. If the QA is separate it will remain a second class citizen and that's a asking for support trouble.

[adrian.brock]

You can still run the JBossAS Testsuite from the other project,
it should just be a case of invoking its ant's script from your ant script
(perhaps passing different parameters - we could even "macroise" the
test targets if you need to start an ORB for all test clients).

It's a long standing issue that the testsuite is not very flexible
or even as modular as it first appears.

I guess this won't be resolved until we move to Maven?
Whenever that is. :-)

[marklittle]

"jhalliday" wrote:
I'm not suggesting we ship the JTS with AS, although we could consider it.

It was considered back in November 2005, when we decided it (and WS-TX support) should be a separate download and not part of the AS distro.