Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [glassfish-dev] [External] : Re: Any idea why on Java 11 the GlassFish Client Container might be failing to see the Client Container classloader?

Hi,

On Fri, Mar 5, 2021 at 9:28 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
This is obvious, even though not documented in 'java -help'; 'man java' says: "When you use the -jar option, the specified JAR file is the source of all user classes, and other class path settings are ignored.".

Absolutely, though in a large single line command (I used formatting here) it's sometimes easy to overlook.

 
So I guess the problem lies either in 'simple-ejb-implicit-cdiAppClient.jar's manifest file (check Class-Path entry there) or in missing app client classes in that jar. It would probably help to compare current jar with the one from some older, known to run, version.

I wonder whether the location that Java looks for when -Djava.system.class.loader is used has changed in JDK 11.

At a glance I couldn't find the exact definition of that. A quick search got me this:

"You can change the application class loader by command line option -Djava.system.class.loader. This value
specifies name of a subclass of java.lang.ClassLoader class. First the default application
loader loads the named class (and so this class has to be in CLASSPATH or -cp) and creates
an instance of it. The newly created loader is used to load application main class."


But seemingly the java command was before able to load that named class from somewhere else. Does the manifest of the target jar counts as a classpath for the "-Djava.system.class.loader" option?

Kind regards,
Arjan


Back to the top