Adding module causes classloading issues

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding module causes classloading issues

Michael Hall
JMX attach keeps telling me that RMI is not a accepted protocol.
I wondered if possibly this was a modular issue, I checked my main app jar…
jdeps halfpipe.jar
...
halfpipe.jar -> java.corba


which seems to say I need java.corba which I didn’t have.
If I add that with jlink I get…

java.lang.NoClassDefFoundError: javax/transaction/UserTransaction

from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.

This doesn’t appear to be included in any existing modules including corba.
java -cp halfpipe.jar us.hall.cmdline.cmds.JRTLister /modules | grep javax.transaction
   /modules/java.sql/javax/transaction
    /modules/java.sql/javax/transaction/xa
     /modules/java.sql/javax/transaction/xa/XAException.class
     /modules/java.sql/javax/transaction/xa/XAResource.class
     /modules/java.sql/javax/transaction/xa/Xid.class
   /modules/java.transaction/javax/transaction
    /modules/java.transaction/javax/transaction/InvalidTransactionException.class
    /modules/java.transaction/javax/transaction/TransactionRequiredException.class
    /modules/java.transaction/javax/transaction/TransactionRolledbackException.class

So it doesn’t seem like it should be a ‘split package’ situation, unless possibly with java.transaction, not java.corba.
I’m not sure if ‘split package’ applies module to jar anyhow?

I’m still very new to this. Is there a command that would give me the module descriptor information for java.corba?
That might give me some idea why it is interfering with my jar classloading.
Or any other suggestions as to why it might be doing this?


Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alex Buckley
On 11/27/2017 3:16 PM, Michael Hall wrote:

> JMX attach keeps telling me that RMI is not a accepted protocol.
> I wondered if possibly this was a modular issue, I checked my main app jar…
> jdeps halfpipe.jar
> ...
> halfpipe.jar -> java.corba
> …
>
> which seems to say I need java.corba which I didn’t have.
> If I add that with jlink I get…
>
> java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
>
> from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.

java --list-modules
// Will show java.corba in your jlinked image

java --describe-module java.corba
// Will show 'requires java.transaction'
// Since this is an implementation dependency, it's not listed in
https://docs.oracle.com/javase/9/docs/api/java.corba-summary.html

java --show-module-resolution -jar halfpipe.jar
// Will show java.transaction being resolved in support of java.corba

Because java.transaction is resolved, the miniature javax.transaction
package that it exports will "win", and the full-strength
javax.transaction package in jta.jar on the classpath will "lose".

The story of java.transaction is unfortunate and complicated (see
http://openjdk.java.net/jeps/8189188) but you can augment it with the
stuff in jta.jar:

java --patch-module java.transaction=jta.jar -jar halfpipe.jar
// See http://openjdk.java.net/jeps/261#Patching-module-content

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 27, 2017, at 6:40 PM, Alex Buckley <[hidden email]> wrote:
>
> On 11/27/2017 3:16 PM, Michael Hall wrote:
>> JMX attach keeps telling me that RMI is not a accepted protocol.
>> I wondered if possibly this was a modular issue, I checked my main app jar…
>> jdeps halfpipe.jar
>> ...
>> halfpipe.jar -> java.corba
>> …
>>
>> which seems to say I need java.corba which I didn’t have.
>> If I add that with jlink I get…
>>
>> java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
>>
>> from the quartz scheduler. This class should come from the included jta.jar, and usually does without the java.corba module.
>
> java --list-modules
> // Will show java.corba in your jlinked image
>
> java --describe-module java.corba
> // Will show 'requires java.transaction'
> // Since this is an implementation dependency, it's not listed in https://docs.oracle.com/javase/9/docs/api/java.corba-summary.html
>
> java --show-module-resolution -jar halfpipe.jar
> // Will show java.transaction being resolved in support of java.corba
>
Thanks for the above, searches hadn’t hit them yet.

> Because java.transaction is resolved, the miniature javax.transaction package that it exports will "win", and the full-strength javax.transaction package in jta.jar on the classpath will "lose".
>
> The story of java.transaction is unfortunate and complicated (see http://openjdk.java.net/jeps/8189188) but you can augment it with the stuff in jta.jar:
>
> java --patch-module java.transaction=jta.jar -jar halfpipe.jar
> // See http://openjdk.java.net/jeps/261#Patching-module-content <http://openjdk.java.net/jeps/261#Patching-module-content>

The application usually runs as an OS X application. So I don’t use -jar. I do have a shell script launch for testing…

#!/bin/bash

APP_ROOT=HalfPipe7.app
JAVA=${APP_ROOT}/Contents/Java
export R_HOME=/Library/Frameworks/R.framework/Resources
java --patch-module java.transaction=${JAVA}/jta.jar -XX:+CITime -Xms32M -Xmx256M -Xdock:name=HalfPipe -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe -Dapple.laf.useScreenMenuBar=true -Djava.library.path=$APP_ROOT/Contents/MacOS -Djava.security.manager -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy -Dapp.lib=$APP_ROOT/Contents/JavaApp -Dconsole=pane -cp .:..:hp_jshell.jar:${JAVA}/halfpipe.jar:${JAVA}/log4j-1.2.16.jar:${JAVA}/quartz-2.2.2.jar:${JAVA}/quartz-jobs-2.2.2.jar:${JAVA}/httpcore-4.1.jar:${JAVA}/httpclient-4.1.jar:${JAVA}/commons-logging-1.1.1.jar:${JAVA}/slf4j-api-1.7.7.jar:${JAVA}/slf4j-log4j12-1.7.7.jar:${JAVA}/antlr-2.7.7.jar:${JAVA}/AppleScriptEngine.jar:${JAVA}/Classes:${JAVA}/groovy-all-2.4.5.jar:${JAVA}/JRI.jar:${JAVA}/JRIEngine.jar:${JAVA}/JRS.jar:${JAVA}/REngine.jar:${JAVA}/RserveEngine.jar:${JAVA}/jta.jar:${JAVA}/macnio2.jar:${JAVA}/stringtemplate-3.2.1.jar:${JAVA}/weka.jar:${JAVA}/js.jar us.hall.hp.common.LoaderLaunchStub

Note—patch-module at start if I am doing that correctly, gets…
WARNING: Unknown module: java.transaction specified to --patch-module

This is the installed jvm, not the embedded application one (I could point it at that if useful), but it should have all modules included?


Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alex Buckley
On 11/27/2017 5:03 PM, Michael Hall wrote:

> The application usually runs as an OS X application. So I don’t use
> -jar. I do have a shell script launch for testing…
>
> #!/bin/bash
>
> APP_ROOT=HalfPipe7.app
> JAVA=${APP_ROOT}/Contents/Java
> export R_HOME=/Library/Frameworks/R.framework/Resources
> java --patch-module java.transaction=${JAVA}/jta.jar -XX:+CITime -Xms32M
> -Xmx256M -Xdock:name=HalfPipe
> -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe
> -Dapple.laf.useScreenMenuBar=true
> -Djava.library.path=$APP_ROOT/Contents/MacOS -Djava.security.manager
> -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy
> -Dapp.lib=$APP_ROOT/Contents/JavaApp -Dconsole=pane -cp
> .:..:hp_jshell.jar:${JAVA}/halfpipe.jar:${JAVA}/log4j-1.2.16.jar:${JAVA}/quartz-2.2.2.jar:${JAVA}/quartz-jobs-2.2.2.jar:${JAVA}/httpcore-4.1.jar:${JAVA}/httpclient-4.1.jar:${JAVA}/commons-logging-1.1.1.jar:${JAVA}/slf4j-api-1.7.7.jar:${JAVA}/slf4j-log4j12-1.7.7.jar:${JAVA}/antlr-2.7.7.jar:${JAVA}/AppleScriptEngine.jar:${JAVA}/Classes:${JAVA}/groovy-all-2.4.5.jar:${JAVA}/JRI.jar:${JAVA}/JRIEngine.jar:${JAVA}/JRS.jar:${JAVA}/REngine.jar:${JAVA}/RserveEngine.jar:${JAVA}/jta.jar:${JAVA}/macnio2.jar:${JAVA}/stringtemplate-3.2.1.jar:${JAVA}/weka.jar:${JAVA}/js.jar
> us.hall.hp.common.LoaderLaunchStub
>
> Note—patch-module at start if I am doing that correctly, gets…
> WARNING: Unknown module: java.transaction specified to --patch-module
>
> This is the installed jvm, not the embedded application one (I could
> point it at that if useful), but it should have all modules included?

You said that you jlinked an image to include java.corba, which means
the image will contain java.transaction as well. I don't know what the
quartz scheduler that you mentioned is doing when you run it on your
custom image, but evidently java.corba was being resolved at run time
because it triggered resolution of java.transaction with its miniature
javax.transaction package.

If you're running a classpath application on the JDK out of the box,
then java.corba will not even be resolved, and nor will
java.transaction. Hence the warning that patching it is fishy. You can
use --add-modules java.transaction to force its resolution.

Please note that java.corba and java.transaction are both deprecated FOR
REMOVAL. There will soon be a modular version of JTA which you can
deploy on the upgrade module path rather than via patching. See the very
end of http://openjdk.java.net/jeps/8189188.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 27, 2017, at 7:15 PM, Alex Buckley <[hidden email]> wrote:
>
> --add-modules java.transaction

Tried to simplify.

java -cp . --patch-module java.transaction=jta.jar --add-modules java.transaction ModuleForClass javax.transaction.UserTransaction
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package javax.transaction.xa in both module java.transaction and module java.sql

import javax.transaction.UserTransaction;

public class ModuleForClass {

        public static void main(String[] args) {
                try {
                        Module m = Class.forName("javax.transaction.UserTransaction").getModule();
                        System.out.println(m.getName());
                }
                catch (Throwable tossed) { tossed.printStackTrace(); }
        }
}
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall
In reply to this post by Alex Buckley

> On Nov 27, 2017, at 7:15 PM, Alex Buckley <[hidden email]> wrote:
>
> You said that you jlinked an image to include java.corba,

For that…

HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java -cp . --patch-module java.transaction=jta.jar --add-modules java.transaction ModuleForClass javax.transaction.UserTransaction
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package javax.transaction.xa in both module java.transaction and module java.sql
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall
In reply to this post by Alex Buckley

> On Nov 27, 2017, at 7:15 PM, Alex Buckley <[hidden email]> wrote:
>
> here will soon be a modular version of JTA which you can deploy on the upgrade module path rather than via patching.

Oh, and looking forward to that of course.


Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alex Buckley
In reply to this post by Michael Hall
On 11/27/2017 5:22 PM, Michael Hall wrote:

>> On Nov 27, 2017, at 7:15 PM, Alex Buckley <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> --add-modules java.transaction
>
> Tried to simplify.
>
> java -cp . --patch-module java.transaction=jta.jar --add-modules
> java.transaction ModuleForClass javax.transaction.UserTransaction
> Error occurred during initialization of boot layer
> java.lang.LayerInstantiationException: Package javax.transaction.xa in
> both module java.transaction and module java.sql

Oh yes, jta.jar includes the XA package, so force-patching that package
into java.transaction will conflict with the same package in java.sql.

If your app doesn't use JDBC, then you could prevent java.sql from being
resolved by passing the JDK modules that you DO want to be resolved to
the --limit-modules option. Being precise about your app's use of JDK
modules is a down payment on writing its module declaration.

But most likely, you need the new, XA-less JTA jar which is coming soon
from the JSR 907 Maintenance Lead.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 27, 2017, at 7:40 PM, Alex Buckley <[hidden email]> wrote:
>
> On 11/27/2017 5:22 PM, Michael Hall wrote:
>>> On Nov 27, 2017, at 7:15 PM, Alex Buckley <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>> --add-modules java.transaction
>>
>> Tried to simplify.
>>
>> java -cp . --patch-module java.transaction=jta.jar --add-modules
>> java.transaction ModuleForClass javax.transaction.UserTransaction
>> Error occurred during initialization of boot layer
>> java.lang.LayerInstantiationException: Package javax.transaction.xa in
>> both module java.transaction and module java.sql
>
> Oh yes, jta.jar includes the XA package, so force-patching that package into java.transaction will conflict with the same package in java.sql.
>
> If your app doesn't use JDBC, then you could prevent java.sql from being resolved by passing the JDK modules that you DO want to be resolved to the --limit-modules option. Being precise about your app's use of JDK modules is a down payment on writing its module declaration.
>
> But most likely, you need the new, XA-less JTA jar which is coming soon from the JSR 907 Maintenance Lead.
>
> Alex

Thanks again, for the time.

It is a little difficult for me to track these things. For now I will probably just omit java.corba and hope it isn’t really my problem with JMX attach.
I will take a closer look at jconsole to try and figure that out.

I will maybe check back on the newer JTA later.

Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alex Buckley
On 11/27/2017 5:46 PM, Michael Hall wrote:
> Thanks again, for the time.
>
> It is a little difficult for me to track these things. For now I will probably just omit java.corba and hope it isn’t really my problem with JMX attach.
> I will take a closer look at jconsole to try and figure that out.
>
> I will maybe check back on the newer JTA later.

Thank you, for investigating how your app relates to CORBA, JTA, and
Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at
least. Alan will probably be along shortly with some points I missed.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 27, 2017, at 8:00 PM, Alex Buckley <[hidden email]> wrote:
>
> I hope http://openjdk.java.net/jeps/8189188 <http://openjdk.java.net/jeps/8189188> was informative at least.

Reading it now...
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alan Bateman
In reply to this post by Alex Buckley
On 28/11/2017 02:00, Alex Buckley wrote:
>
> Thank you, for investigating how your app relates to CORBA, JTA, and
> Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at
> least. Alan will probably be along shortly with some points I missed.
One point that I didn't see mentioned in the thread so far is a detail
in the JEP 261 policy on root modules for the case that module java.se
is not observable. When java.se is not observable then all modules
(system or upgrade module path) that export an API are resolved. The
output of `java --list-modules` will answer his quickly but I'll bet the
image doesn't have java.se.

I don't know what halfpipe is but it would be interesting to paste in
the detailed output from jdeps so we can see if it really depends on
classes in java.corba. I'm also interested in the first mail about "JMX
Attach" as it's not clear what that means. Is jconsole or VisualVM in
the picture? This would require the java.management.rmi module to be
included.

As Alex mentioned, this case is crying out for the XA-less JTA that Alex
mentioned. Hopefully the JSR 907 spec lead will sort this out soon.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 28, 2017, at 2:35 AM, Alan Bateman <[hidden email]> wrote:
>
> On 28/11/2017 02:00, Alex Buckley wrote:
>>
>> Thank you, for investigating how your app relates to CORBA, JTA, and Attach. I hope http://openjdk.java.net/jeps/8189188 was informative at least. Alan will probably be along shortly with some points I missed.
> One point that I didn't see mentioned in the thread so far is a detail in the JEP 261 policy on root modules for the case that module java.se is not observable. When java.se is not observable then all modules (system or upgrade module path) that export an API are resolved. The output of `java --list-modules` will answer his quickly but I'll bet the image doesn't have java.se.
>
HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java --list-modules | grep java.se
java.security.sasl@9


> I don't know what halfpipe is

java shell application - halfpipe = platform for skateboarding tricks. Sort of a lot of different body parts put together to make a Frankenstein monster.

> but it would be interesting to paste in the detailed output from jdeps so we can see if it really depends on classes in java.corba.

It’s a little alarming jdeps might report false dependencies? I would rather spare you the full output. How about…

jdeps halfpipe.jar | grep corba
halfpipe.jar -> java.corba
   org.cmdline                                        -> javax.rmi                                          java.corba
 

> I'm also interested in the first mail about "JMX Attach" as it's not clear what that means. Is jconsole or VisualVM in the picture? This would require the java.management.rmi module to be included.

At one point I was adding JSR 223 interfaces into the application. During the OS X port days when there was no java provided javascript JSR 223 interface yet I did one for Rhino javascript that included code, based on a blog of yours actually, that allowed it to pid attach to java processes and do scripting. Sort of like the Notebook example but again before I knew of any other way to do this it also allowed attaching to any java process.
One thing I thought the application might work as would be a monitoring/automation type app. At one point I worked on a IBM mainframe product for one of those for data center automation - CA OPS/MVS. REXX based for the language I’m afraid. So a little nostalgia coding getting my app to do some things similar.
I was thinking of re-doing this code for Java 9. JMX attach now seemed to be the way to go. jconsole I believe does this successfully and I have started looking at that to see what it might be doing right that I am not. So far no matter what I do I always end up with the same rmi: url that is rejected. Even based on what jconsole seems to be doing.
I thought maybe the missing corba explains this but since that seems to conflict with the Quartz scheduler I added. Another ‘automation’ like feature.
Maybe I will put this on hold for now.

>
> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.

Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.

>
> -Alan

Thanks. I will try to remain aware of these coming related changes.

Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall
In reply to this post by Alan Bateman

> On Nov 28, 2017, at 2:35 AM, Alan Bateman <[hidden email]> wrote:
>
> One point that I didn't see mentioned in the thread so far is a detail in the JEP 261 policy on root modules for the case that module java.se <http://java.se/> is not observable. When java.se <http://java.se/> is not observable then all modules (system or upgrade module path) that export an API are resolved. The output of `java --list-modules` will answer his quickly but I'll bet the image doesn't have java.se <http://java.se/>.

I added this. It works. java.corba included and the scheduler still working.

Still looking forward to the changes of course but this seems to give something to go on.

Thanks again.

HalfPipe7.app/Contents/PlugIns/Java.runtime/Contents/Home/bin/java --list-modules
java.activation@9
java.base@9
java.compiler@9
java.corba@9
java.datatransfer@9
java.desktop@9
java.instrument@9
java.logging@9
java.management@9
java.management.rmi@9
java.naming@9
java.prefs@9
java.rmi@9
java.scripting@9
java.se@9
java.security.jgss@9
java.security.sasl@9
java.sql@9
java.sql.rowset@9
java.transaction@9
java.xml@9
java.xml.bind@9
java.xml.crypto@9
jdk.attach@9
jdk.compiler@9
jdk.internal.ed@9
jdk.internal.jvmstat@9
jdk.internal.le@9
jdk.internal.opt@9
jdk.jdi@9
jdk.jdwp.agent@9
jdk.jshell@9
jdk.unsupported@9

Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alan Bateman
In reply to this post by Michael Hall
On 28/11/2017 09:14, Michael Hall wrote:
> It’s a little alarming jdeps might report false dependencies? I would rather spare you the full output. How about…
>
> jdeps halfpipe.jar | grep corba
> halfpipe.jar -> java.corba
>     org.cmdline                                        -> javax.rmi                                          java.corba
I assume `jdeps -verbose:class` will reveal that there is some in the
org.cmdline package with a reference to javax.rmi.PortableRemoteObject.
That class isn't used much beyond RMI-IIOP and maybe something you can
drop if an alternative is possible.


> :
>
>
>> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.
>
Once there is a version of java.transaction published to Maven without
the XA package then it will be a lot simpler.

-Alan
Reply | Threaded
Open this post in threaded view
|

RE: Adding module causes classloading issues

Stephen Felts
I'm trying to get javax.transaction-api-1.3-ea.jar published to Maven Central as soon as possible.
In the meantime, you can make your own if you are blocked by starting with javax.transaction-api-1.2.jar, deleting the three classes in the javax.transaction.xa  package, and updating  META-INF/MANIFEST.MF to add Automatic-Module-Name: java.transaction

-----Original Message-----
From: Alan Bateman
Sent: Tuesday, November 28, 2017 5:49 AM
To: Michael Hall <[hidden email]>
Cc: [hidden email]
Subject: Re: Adding module causes classloading issues

On 28/11/2017 09:14, Michael Hall wrote:
> It’s a little alarming jdeps might report false dependencies? I would
> rather spare you the full output. How about…
>
> jdeps halfpipe.jar | grep corba
> halfpipe.jar -> java.corba
>     org.cmdline                                        -> javax.rmi                                          java.corba
I assume `jdeps -verbose:class` will reveal that there is some in the org.cmdline package with a reference to javax.rmi.PortableRemoteObject.
That class isn't used much beyond RMI-IIOP and maybe something you can drop if an alternative is possible.


> :
>
>
>> As Alex mentioned, this case is crying out for the XA-less JTA that Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> Also a little sorry to hear the code is crying out but again it may be best to put it on hold then.
>
Once there is a version of java.transaction published to Maven without the XA package then it will be a lot simpler.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Gunnar Morling
Hi,

There's a preview version of JBoss' instance of the JTA API JAR without the
XA classes available already:


http://search.maven.org/#artifactdetails%7Corg.jboss.spec.javax.transaction%7Cjboss-transaction-api_1.2_spec%7C2.0.0.Alpha1%7Cjar

--Gunnar


2017-11-28 13:54 GMT+01:00 Stephen Felts <[hidden email]>:

> I'm trying to get javax.transaction-api-1.3-ea.jar published to Maven
> Central as soon as possible.
> In the meantime, you can make your own if you are blocked by starting with
> javax.transaction-api-1.2.jar, deleting the three classes in the
> javax.transaction.xa  package, and updating  META-INF/MANIFEST.MF to add
> Automatic-Module-Name: java.transaction
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Tuesday, November 28, 2017 5:49 AM
> To: Michael Hall <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Adding module causes classloading issues
>
> On 28/11/2017 09:14, Michael Hall wrote:
> > It’s a little alarming jdeps might report false dependencies? I would
> > rather spare you the full output. How about…
> >
> > jdeps halfpipe.jar | grep corba
> > halfpipe.jar -> java.corba
> >     org.cmdline                                        -> javax.rmi
>                                     java.corba
> I assume `jdeps -verbose:class` will reveal that there is some in the
> org.cmdline package with a reference to javax.rmi.PortableRemoteObject.
> That class isn't used much beyond RMI-IIOP and maybe something you can
> drop if an alternative is possible.
>
>
> > :
> >
> >
> >> As Alex mentioned, this case is crying out for the XA-less JTA that
> Alex mentioned. Hopefully the JSR 907 spec lead will sort this out soon.
> > Also a little sorry to hear the code is crying out but again it may be
> best to put it on hold then.
> >
> Once there is a version of java.transaction published to Maven without the
> XA package then it will be a lot simpler.
>
> -Alan
>
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall
In reply to this post by Alan Bateman

> On Nov 28, 2017, at 4:48 AM, Alan Bateman <[hidden email]> wrote:
>
> javax.rmi.PortableRemoteObject

It does include PortableRemoteObject. At one point, it looks like about 2004, I had made the app RMI client/server.
But having trouble coming up with a second machine to test on. I think I ended up just forgetting about that.
A little strange that Eclipse seems to show that it is missing, flagging it as an error. However the project compiles just fine with it.
So maybe not a mystery that needs solving at this point. As you suggest eliminating that code might be easier.
But theres a lot of dead code in this app so it hasn’t seemed that critical.

Unless it does relate to current problems. I haven’t had a chance to test JMX again yet.
But since getting the java.corba module in the runtime with the scheduler code still running was the concern then that isn’t a concern anymore is it?
Although, I still need to go back and look at why java.se <http://java.se/> was the apparent fix.
As well as the other posts and suggested reading.

The information was very helpful,  thanks again.
Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Michael Hall

> On Nov 28, 2017, at 4:11 PM, Michael Hall <[hidden email]> wrote:
>
> Unless it does relate to current problems. I haven’t had a chance to test JMX again yet.

That does seem to work. So java.corba was a answer there if not the best.

js> jmxAttach('994')
local service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4
addr service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4
Url service:jmx:rmi://127.0.0.1/stub/rO0ABXN9AAAAAQAlamF2YXgubWFuYWdlbWVudC5yZW1vdGUucm1pLlJNSVNlcnZlcnhyABdqYXZhLmxhbmcucmVmbGVjdC5Qcm94eeEn2iDMEEPLAgABTAABaHQAJUxqYXZhL2xhbmcvcmVmbGVjdC9JbnZvY2F0aW9uSGFuZGxlcjt4cHNyAC1qYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN0SW52b2NhdGlvbkhhbmRsZXIAAAAAAAAAAgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc4AAtVbmljYXN0UmVmMgAADTE5Mi4xNjguMS4xMDcAAMN5yW1cOzyQxCai3JwsAAABYATKoHeAAQB4

Shows how I kept coming up with the same url. But now it’s not saying that rmi isn’t a valid protocol. So I can again script JMX with javascript.

Yet again. Thanks.


Reply | Threaded
Open this post in threaded view
|

Re: Adding module causes classloading issues

Alan Bateman
In reply to this post by Michael Hall


On 28/11/2017 22:11, Michael Hall wrote:
>
>> On Nov 28, 2017, at 4:48 AM, Alan Bateman <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> javax.rmi.PortableRemoteObject
>
> It does include PortableRemoteObject.
and this probably has references to classes in org.omg.CORBA and
javax.rmi.CORBA. This will explain why jdeps reports a dependency on the
java.corba module.

-Alan