I have the following:
Module path: javax.enterprise.cdi.api.jar
javax.interceptor.javax.interceptor.api.jar
Upgrade module path: java.transaction.jar javax.annotation-api-1.2.jar
I'm not sure how much of that you will need.
-----Original Message-----
From: Alan Bateman
Sent: Wednesday, October 05, 2016 7:28 AM
To: Christian Beikov; jigsaw-dev@openjdk.java.net
Subject: Re: Corba and Transaction module problems with JDK9-ea+138
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
