Can't run Java enterprise application client against glassfish 7.0.6 server because VM won't create because of -Djava.endorsed.dirs

[Blavo]

Apache NetBeans version

Apache NetBeans 18

What happened

Attempted to run a very simple Java enterprise application client against a glassfish 7.0.6 server. The application deploys but won't run because the JVM can't be created. The log shows:

Djava.endorsed.dirs=/Applications/glassfish7/glassfish/lib/endorsed:/Applications/glassfish7/glassfish/modules/endorsed is not supported. Endorsed standards and standalone APIs in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

The full Netbeans output from the run command is attached.

The Java version is 17, so modularised.

The use of -Djava.endorsed.dirs appears to be introduced in the build.impl file created by Netbeans. The file is attached. There are clear references to the endorsed directory in the file but I don't pretend to understand the file's operation. The directory referenced in the final generated JVM option reported above (/Applications/glassfish7/glassfish/lib/endorsed) does not exist in the glassfish 7 installation so the build.impl can't be right for the target.

build.impl.txt
Netbeans output.txt

How to reproduce

It is not clear what the real prerequisites are to this issue. I would think that running Netbeans 18 in a Java 17 environment will be sufficient. It is the build.impl generated in the environment that appears to be the problem. There has to be a JEE server to run against but I doubt the actual target will make very much difference provided the enterprise application client deploys to the server (it has to deploy before execution of the app client can be attempted).

I suggest trying to reproduce the problem with whatever is readily to hand.

Simple source of an interface, a web application, an application client, and a non-application client are attached.

RemoteCalculatorInterface is the interface. It has no dependencies.

RemoteCalculatorBean is the (very simple) web application that is a bean on the interface.

GF7RemoteDependencyDeployReproducerNonAppClient is a non-enterprise client that can be used to prove that the web app has been correctly deployed. See the dependencies in the source.

GF7RemoteDependencyDeployReproducerAppClient is an enterprise client that can be used to reproduce the problem. See the dependencies in the source.

To reproduce the problem:

1. Compile RemoteCalculatorInterface as a class library
2. Compile RemoteCalculatorBean as a web application, with the interface above in the class path
3. Deploy the web app to the target server
4. Adjust the lookup string in GF7RemoteDependencyDeployReproducerNonAppClient based on the portable JNDI name of the deployed remote calculator bean
5. Compile GF7RemoteDependencyDeployReproducerNonAppClient with the interface and run it to show the web application is properly deployed
6. Compile GF7RemoteDependencyDeployReproducerAppClient with the interface and attempt to run it to demonstrate the problem.

Netbeans output.txt
build.impl.txt
GF7RemoteDependencyDeployReproducerAppClient.txt
GF7RemoteDependencyDeployReproducerNonAppClient.txt
RemoteCalculatorBean.txt
RemoteCalculatorInterface.txt

Did this work correctly in an earlier version?

No / Don't know

Operating System

Mac OS 12.4 (Monterey)

JDK

java version "17.0.7" 2023-04-18 LTS Java(TM) SE Runtime Environment (build 17.0.7+8-LTS-224) Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing)

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

Problem is reliably reproducible.

Are you willing to submit a pull request?

No

[asbachb]

@Blavo I assume you have registered Glassfish 7.0.6 within NetBeans? Does this also happen, when you start the server within NetBeans or only when you deploy your project?

[Blavo]

G’day, As I recall it, after I installed GF7 and restarted NB18 I was surprised not to be offered GF7 as a ’server’ option for a new Java web project. I had to add the Jakarta EE 10 API library to that project’s library list manually (from the list of available libraries). Since then my GF7 install is offered as a ’server’ option including in the new Enterprise application client that is the subject of the issue . So, in that sense, yes I ‘registered’ my GF 7.0.6 installation in NetBeans. The issue is with an enterprise application client. Attempting to run the client from within NetBeans results in a successful deploy but a failed run attempt. Being an EAC it can’t be run from within the server and isn’t run on server restart.

…

On 1 Aug 2023, at 21:49, Benjamin Asbach ***@***.***> wrote: @Blavo <https://github.com/Blavo> I assume you have registered Glassfish 7.0.6 within NetBeans? Does this also happen, when you start the server within NetBeans or only when you deploy your project? — Reply to this email directly, view it on GitHub <#6270 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKL4EN5J6LTGNMTSF57QATXTDUMZANCNFSM6AAAAAA24KGX2Q>. You are receiving this because you were mentioned.

[renatsaf]

Root cause and a fix in #9446.

The -Djava.endorsed.dirs=… argument is not generated by the project's build-impl.xml (its own endorsed.classpath.cmd.line.arg correctly uses -Xbootclasspath/p: and is empty here). It comes from the GlassFish plugin: Hk2JavaEEPlatformImpl.getToolProperty(TOOL_APP_CLIENT_RUNTIME, TOOL_PROP_JVM_OPTS) unconditionally prepends -Djava.endorsed.dirs=<root>/lib/endorsed:<root>/modules/endorsed to the app-client container JVM options. That flows into the generated build script as j2ee.appclient.tool.jvmoptions and is passed as a <jvmarg> to the run-appclient macro.

The endorsed-standards mechanism was removed in JDK 9 (JEP 220), and HotSpot deliberately aborts at startup when java.endorsed.dirs is set — which is why the client JVM never starts. GlassFish 7 requires JDK 11+ and ships no endorsed directories, so the option is both invalid and points at non-existent paths (matching your observation that the directory doesn't exist).

#9446 builds the option only from the lib/endorsed / modules/endorsed directories that actually exist and omits it entirely when neither is present, so app clients run on JDK 9+ while legacy JDK 8 servers that still ship those dirs are unaffected.