jta/jts jar/config file change

[jhalliday]

The jta and jts builds of the transaction service have historically existed separately. Each has its own .jar files (jbossjta[-*].jar and jbossjts[-*].jar) and config file (jbossjta-properties.xml and jbossjts-properties.xml) respectively. Internal metadata in the jar references the config file name, so the jts jar is not actually a superset of the jta one, although the .class files it contains are.

This is all well and good for the standalone customers, who tend to download only one or the other distribution.

With the introduction of the jts to AS 5.x it has become apparent that the situation is less than ideal, particularly now that the AS layout has a shared lib directory for all servers. Upgrading some servers to jts whist keeping the others running jta (not all of them have the orb needed for jts) is unduly complex. Very weird things can happen when the jts and jta jar files are both present on the classpath.

I'd like to (hopefully) simplify matters by changing both versions to use jbossts-properties.xml as the config file. Of course the actual contents of the file will still differ according to the version you want to run, but at least the jts jar files will become a strict superset of the jta ones. That means we can put the jts jar files in the AS' shared lib directory and individual server configurations can select between the jts and jta just by editing the jbossts-properties.xml and transaction-jboss-beans.xml.

This increases the footprint of the AS lib directory fractionally (jts is larger than jta), but decreases the overall app server bundle size as the jta jar files are no longer needed. More importantly, it reduces the number of ways users can potentially screw things up.

It's slightly unintuitive that even those users wanting only the jta will need a jts jar file in the path, but I don't think its worth renaming the jar files or splitting the jts into a jta+jts pair rather than a single jar -the potential space saving is only around 300k.

Unless I hear any objections I'll make this config change for JBossTS 4.6

[marklittle]

This gets my vote!

[jhalliday]

This update will probably go into TS trunk tomorrow, from which time integrating with JBossAS will be a bit hairy until the TS 4.6.0.CR is out and JBossAS is updated for the new integration process. Think twice about 'svn update' for the next week or so if you need to integrate with the AS.

[shelly.mcgowan]

With the JTS integration into JBoss AS, the org.omg.CosTransactions classes provided in jbossjts-jacorb.jar located in the common/lib directory are also provided in jacorb.jar found in the server/${conf}/lib directory. The files in jbossjts-jacorb.jar are more recent but are showing serialversionUID mismatches while running one of the integration tests. How can the duplicate distribution of these classes provided by the separate projects be eliminated when integrated with JBossAS? A question for the IIOP project team as well but thought I'd start here as the JTS specification defines the use of CORBA OTS to ensure an interoperable implementation so makes sense to distribute with JTS too.

[marklittle]

The OTS classes in JacORB are wrong. The only ones we support are the ones that we generate from our own idl in the JBossTS source. We've never modified the jacorb jars to remove their copies but we do tell people to put our OTS in their classpath first.

[sguilhen]

Is JBossTS IDL any different from the OMG OTS IDL? I'm just curious about the differences between JBossTS and JacORB implementations of the OTS service. I'm also curious about what exactly is wrong with JacORB OTS classes.

As we have a patched JacORB version in the AS, we could consider fixing the OTS service as well. I'm just not sure about how much work is involved here and if it worth doing that. We might as well remove JacORB's classes, although I think this could be confusing (having part of the CORBA features supplied by a separate jar).

[marklittle]

Unix diff is your friend.

[jhalliday]

I'm inclined to make two further changes in respect of the .jar files and config files we ship. To facilitate clean embedding, I would like to:

- bundle the default config file into the .jar and change the existing search algorithm to look for it there as a last resort before giving up. This will allow the system to run without needing the etc dir (or other dir containing the config file) on the classpath, whilst being unobtrusive for existing installations.

- bundle the contents of ext/jbossts-common.jar into the jta/jts jar files directly. The splitting out of the common code made sense when it was consumed by other apps, but with JBossTS as the only user we may as well streamline things.

With those changes it should become possible to use the system just by including a single .jar on the classpath, along with any 3rd party .jars from ext depending on the functionality required.

[marklittle]

JFDI :-)