ClientUserTransaction and the JTS

[jhalliday]

I'm starting to investigate AS 5 testsuite failures with the server running in JTS mode rather than with the default JTA.

First up: ClientUserTransaction is barfing because the transaction propagation context (tpc) used by the JTS contains classes from the JTS implementation that are not present on the client classpath. The RMI classloader does not have a policy to permit them to be remote loaded from the server, so deserialization fails.

Apparent options: add the jts implementation to the manifest of jbossall-client.jar; change the client classpath so it includes the jts impl jar in addition to jbossall-client.jar (not all users need the jts); change the classloader policy; change the tpc implementation.

My vote is for changing the jbossall-client.jar. Any thoughts from the AS team?

[marklittle]

How can you change the tpc implementation? It's based on the standard from the OTS so we have no room for changing that, unless you mean that we should restrict distributed transactions from running in the client? We could (have in the past) always produce a thin-tx-client jar that knows only about the OTS.idl classes and how to manipulate that in the client abstractly, i.e., without having to have access to JBossTS implementation specific classes, but it could become a management nightmare.

[jhalliday]

The tpc in question is used only internally by JBossAS, it's not the same one we use for CORBA interop. It just happens to delegate to the CORBA one because that's the least hassle implementation, but we could potentially reimplement it if we have to. That's less than ideal though.

[marklittle]

OK, I'd go with stuffing it into jbossall-client.jar then ;-)