classpath-suffix attribute in domain.xml not working in java-config

[glassfishrobot]

It appears that the classpath-suffix within domain.xml is not being included in the classpath of applications deployed within that domain.

If a deployed application attempts to load any classes from the classpath specified in classpath-suffix it fails with ClassNotFoundException.

If this is deprecated (the wiki is unclear), is there another way to append jars and directories to a domain?

FURTHER NOTES

I encountered this when attempting to install an OpenSSO agent in a GlassfishV3 domain (note: OpenSSO server is running in v2 not v3).

The error I get when loading any web page in the domain that has the classpath-suffix modified correctly is: java.lang.ClassNotFoundException: com.sun.identity.agents.filter.AmAgentFilter

even though the domain.xml contains the following modification from OpenSSO's agentadmin CLI: classpath- suffix="$

{path.separator}/Users/cosmic/development/ProjectX/opensso/j2ee_agents/appserver_v9_agent/lib/agent.jar${path.separator}

/Users/cosmic/development/ProjectX/opensso/j2ee_agents/appserverv9 agent/lib/openssoclientsdk.jar$

{path.separator}/Users/cosmic/development/ProjectX/opensso/j2ee_agents/appserver_v9_agent/locale${path.separator}

/Users/cosmic/development/ProjectX/opensso/j2ee_agent s/appserver_v9_agent/Agent_001/config"

Environment

Operating System: All Platform: Macintosh

Affected Versions

[V3]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/10967
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented cosmic said: Apologies, I should have mentioned this problem is occuring on the latest promoted build: glassfish-v3-b71.zip

[glassfishrobot]

@glassfishrobot Commented ss141213 said: classpath-suffix, classpath-prefix, system-classpath are not supported in v3. Assigning to admin team to change the domain.xml template.

[glassfishrobot]

@glassfishrobot Commented ai109478 said: re: not supporting classpath-suffix, classpath-prefix, system-classpath in v3

Did we review this in a CCC meeting? Adding Bill to the CC list.

[glassfishrobot]

@glassfishrobot Commented ai109478 said: Raising the priority to P2

[glassfishrobot]

@glassfishrobot Commented anilam said: If we are not supporting this: classpath-suffix, classpath-prefix, system-classpath

GUI will need to be changed. Currently we have pages for user to configure all of the above. Docs may need to be changed as well.

[glassfishrobot]

@glassfishrobot Commented dochez said: yes it was brought to CCC that classpath has disappeared with the use of OSGi and therefore suffix and prefix would not be honored any more.

anissa, please change the GUI accordingly.

[glassfishrobot]

@glassfishrobot Commented chaase3 said: So is anything in the JVM Settings -> Path Settings tab page still relevant? Currently the page has the following items:

Environment Classpath – Ignore checkbox selected Server Classpath – read-only field, empty System Classpath Classpath Prefix Classpath Suffix Native Library Path Prefix Native Library Path Suffix

Currently in the DFFR, the classpath-suffix, system-classpath, and env-classpath-ignored attributes are deprecated, but native-library-path- prefix and native-library-path-suffix are still supported. Server classpath is not mentioned at all.

Do the library path attributes need to remain on the page but nothing else?

[glassfishrobot]

@glassfishrobot Commented anilam said: "Currently in the DFFR, the classpath-suffix, system-classpath, and env-classpath-ignored attributes are deprecated"

Isn't deprecated different than 'un-supported' ? I thought deprecate means support but is discouraged to be used.

I am attaching a screenshot of GUI, and need input on which field to be removed from GUI. will talk to Jerome.

[glassfishrobot]

@glassfishrobot Commented anilam said: didn't realize this has been marked Resolved fixed. Reopen for GUI.

[glassfishrobot]

@glassfishrobot Commented anilam said: Created an attachment (id=3878) Java Config page

[glassfishrobot]

@glassfishrobot Commented junesm said: Changing "deprecated" to "not implemented" for classpath-suffix, classpath-prefix, and system-classpath in the DFFR.

[glassfishrobot]

@glassfishrobot Commented anilam said: I need input on what should be removed. Still waiting...

[glassfishrobot]

@glassfishrobot Commented ai109478 said: Jerome: Please explain what should be removed from GUI. We will also need to remove the domain.xml elements from the template.

[glassfishrobot]

@glassfishrobot Commented junesm said: You might want to keep these attributes in the configuration as no-ops for backward compatibility. They shouldn't appear in domain.xml though.

[glassfishrobot]

@glassfishrobot Commented bnevins said: When you guys are all done with this you can reassign it to me and I'll remove the code from Launcher that looks for all those different paths and then turns them into a final classpath/java.library.path

Or we can let sleeping dogs lie in Launcher. It won't hurt anything. The server is ignoring the passed in classpath anyways. I recommend making the Launcher changes for V3.1 and avoiding the risk.

[glassfishrobot]

@glassfishrobot Commented cosmic said: I can't find any documentation on equivalent functionality on the wiki.

Or is the answer to that question to copy jars into

/lib and resources into /lib/classes domain.xml no longer has a way to add to the classpath for all apps on the domain?

[glassfishrobot]

@glassfishrobot Commented dochez said: that's correct, you cannot set the classpath from the domain.xml anymore.

you can place jars inside glassfish/lib or glassfish/domains//lib and these jars will be automatically visible to all deployed applications.

re-assigning to byron

[glassfishrobot]

@glassfishrobot Commented chaase3 said: For the library paths, we've been saying the following:

Use the JVM Path settings page to configure the native library path. The native library path is a concatenation of the following paths:

• The server's relative path for its native shared libraries
• The standard runtime environment native library path
• The shell environment setting (LD_LIBRARY_PATH on UNIX® systems)
• Any paths that are specified on the JVM Profiler Settings page

Is any or all of this still true? If so, where do glassfish/lib and glassfish/domain_dir/lib fit in? Are they "the standard runtime environment native library path"?

Is "shared libraries" a useful term nowadays?

[glassfishrobot]

@glassfishrobot Commented anilam said: Based on email from Sahoo:

Anissa,

All classpath related entries (i.e., environment classpath, system classpath, classpath prefix & suffix) should be removed. Keep the native library related entries.

Thanks, Sahoo

I have removed the following from GUI: classpath-prefix, classpath-suffix, server-classpath system-classpath env-classpath-ignored

Attached screenshot of how it looks like now. Let me know if there is any issue with this. thanks

[glassfishrobot]

@glassfishrobot Commented anilam said: Created an attachment (id=3903) GUI screen AFTER removing the unsupported attr.

[glassfishrobot]

@glassfishrobot Commented ai109478 said: Spoke to Jerome and Abhijit about this. We agreed to do the following in GFv3 release:

GUI Changes

It is possible that people who are migrating from GFv2 will have some of the classpath fields set. In GUI, we will show environment classpath, system classpath, classpath prefix & suffix as READONLY fields. The inline help in GUI will clearly explain that these fields are not supported in GFv3. User should use glassfish/lib or glassfish/domains//lib (or glassfish/modules dir for OSGi content).

Backend Changes

We will not make any changes in domain.xml template or launcher (too risky).

Docs Changes

Docs should be updated to state that environment classpath, system classpath, classpath prefix & suffix are not supported in GFv3. We should also update our docs with GFv3 classloader hierarchy. Jerome/Sahoo are the engineering contacts for that.

Anissa: After you are done with the GUI changes, please transfer the bug to docs team. You may add "[UB]" to the "Summary".

[glassfishrobot]

@glassfishrobot Commented chaase3 said: Please don't put [UB] there till after I've finished with the GUI OLH.

I need an answer on whether the current description of how the library path is formed is correct.

Also, do you have to restart the server after changing the library path prefix or suffix?

[glassfishrobot]

@glassfishrobot Commented chaase3 said: Another question: how would you make a checkbox (Environment Classpath) read-only?

[glassfishrobot]

@glassfishrobot Commented chaase3 said: I'll attach a draft of the reference and task topics. The task topic doesn't mention the read-only fields – that's our usual practice.

Sanity check: Server Classpath is gone, right? It used to show up as empty all the time.

[glassfishrobot]

@glassfishrobot Commented chaase3 said: Created an attachment (id=3907) Reference topic for revised path settings page

[glassfishrobot]

@glassfishrobot Commented chaase3 said: Created an attachment (id=3908) Task topic for revised path settings page

[glassfishrobot]

@glassfishrobot Commented bnevins said: Created an attachment (id=3909) Source patch for Launcher changes

[glassfishrobot]

@glassfishrobot Commented bnevins said: Native path consists of the following, in this order.

1 native-library-path-prefix (domain.xml) 2 /lib 3 64-bit native lib dirs if applicable 4* java.library.path value – of the JVM that launcher is using 5 native path from the profiler element if and only if profiler is enabled 6 native-library-path-suffix (domain.xml)

• totally different on Windows vs. *NIX

The code is very easy to read if you want more details:

v3\admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\GFLauncherNativeHelper.java

[glassfishrobot]

@glassfishrobot Commented chaase3 said: Thanks! It looks as if /lib does NOT include

/domains//lib, then?

[glassfishrobot]

@glassfishrobot Commented chaase3 said: I'm a bit confused by

4* java.library.path value – of the JVM that launcher is using

Is the launcher the process that starts the server? So it sounds like "the value of the java.library.path variable for the JVM from which the Enterprise Server is started" – would that be right?

Thanks!