Corba and Transaction module problems with JDK9-ea+138

[Alan Bateman]

On 05/10/2016 10:41, Christian Beikov wrote:

> Hello again,
>
> I am trying to run OpenEJB on JDK9 but can't get it to work. I added 
> java.corba and java.xml.bind but since java.corba has a dependency on 
> java.transaction, the JAR on the classpath containing the other 
> classes of the javax.transaction package seem "invisible". Is there a 
> way to deactivate the java.transaction module although it is required 
> for java.corba?

I assume you need the EE version of the java.transaction module. If you 
had that then you could deploy it on the upgrade module path 
(--upgrade-module-path option) to upgrade/override the Java SE version 
of java.transaction and move on.

The EE version of the java.transaction module `exports java.transaction` 
and does not contain any classes in javax.transaction.xa (because they 
have moved to the java.sql module, long story).

Sadly, there isn't an EE version of this module published anywhere yet. 
In the mean-time there are ways to get this working, it's just a bit 
complicated until there are EE versions of components that are shared 
between Java SE and Java EE.

1. Patch the JDK's java.transaction module to add the extra classes that 
Java EE defines. This means creating a directory or JAR file with the 
javax.transaction classes (not the javax.transaction.xa classes) and 
patch the module with a command like this:
    --patch-module java.transaction=/d/transaction.jar

2. Alternatively, create your the java.transaction module yourself. You 
can do this by unpacking the EE transaction.jar to a "classes" 
directory, blowing away the classes in javax/transaction/xa, and then 
compiling the module descriptor:

module java.transaction {
     requires public java.rmi;
     exports javax.transaction;
}

$ javac -d classes module-info.java
$ jar cf transaction.jar -C classes .

You can then deploy the resulting modular JAR on the upgrade module path 
with:
     -upgrade-module-path eemods (or eemods/transaction.jar if you want)

I'm assuming in both approaches that they aren't additional dependences, 
if they are then the direct dependences will need to be modules 
(automatic modules to the rescue). Let's see if you need that.

-Alan