Skip to main content

Glassfish 4 admin console class loading issue when built from source

Please note these forums are being decommissioned and use the new and improved forums at
2 replies [Last post]
Joined: 2007-03-11

I seem to have some kind of class loader problem with the admin web application after building from the most recent trunk source.
The default domain starts without error. Attempting to access the admin application fails with the root cause being failure to locate com.sun.webui.jsf.faces.UIComponentELResolver.
The class in question exists within $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/extra/webui-jsf- and was compiled using the same JDK I am using to start the container.
Moving that jar to $INSTALL_ROOT/lib/install/applications/__admingui/WEB-INF/lib/ circumvents the immediate issue but introduces/exposes new ones.

Stack trace excerpt:

[2014-04-16T19:10:31.578+1000] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=114 _ThreadName=Thread-20] [timeMillis: 1397639431578] [levelValue: 1000] [[
Critical error during deployment:
Source Document: jndi:/__asadmin/WEB-INF/faces-config.xml
Cause: Unable to create a new instance of 'com.sun.webui.jsf.faces.UIComponentELResolver': javax.faces.FacesException: com.sun.webui.jsf.faces.UIComponentELResolver
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(
at com.sun.faces.config.processor.ApplicationConfigProcessor.addELResolver(
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(
at com.sun.faces.config.processor.FactoryConfigProcessor.process(
at com.sun.faces.config.ConfigManager.initialize(
at com.sun.faces.config.ConfigureListener.contextInitialized(
at org.apache.catalina.core.StandardContext.contextListenerStart(
at com.sun.enterprise.web.WebModule.contextListenerStart(
at org.apache.catalina.core.StandardContext.start(
at com.sun.enterprise.web.WebModule.start(
at org.apache.catalina.core.ContainerBase.addChildInternal(
at org.apache.catalina.core.ContainerBase.addChild(
at org.apache.catalina.core.StandardHost.addChild(
at com.sun.enterprise.web.WebContainer.loadWebModule(
at com.sun.enterprise.web.WebContainer.loadWebModule(
at com.sun.enterprise.web.WebApplication.start(
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(
Caused by: javax.faces.FacesException: com.sun.webui.jsf.faces.UIComponentELResolver
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(
... 25 more
Caused by: java.lang.ClassNotFoundException: com.sun.webui.jsf.faces.UIComponentELResolver
at org.glassfish.web.loader.WebappClassLoader.loadClass(
at org.glassfish.web.loader.WebappClassLoader.loadClass(
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(
at com.sun.faces.util.Util.loadClass(
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(
... 26 more

I am running the container distribution found at ${SOURCE_ROOT}/main/appserver/distributions/glassfish/target/ after running 'mvn clean install' from ${SOURCE_ROOT}/main.
The latest 4.0 distribution from does not exhibit this behaviour when run on the same JVM.
I have rebuilt 3 times, completely removing my local maven repo for the last 2 builds with identical results each time. I built using too - same result which shouldn't surprise as it just invokes 'mvn $@' anyway.
The only change I have made to the source was to add the following to the shell scripts in ${INSTALL_ROOT}/bin/ to allow invocation from symbolic links in /usr/local/bin:

function realpath {
local r=$1; local t=$(readlink $r)
while [ $t ]; do
r=$(cd $(dirname $r) && cd $(dirname $t) && pwd -P)/$(basename $t)
t=$(readlink $r)
echo $r
AS_INSTALL=$(dirname $(realpath "$0"))/../glassfish

The attached diff is between the downloaded and locally built distributions.

My environment:
Mac OS X 10.9.2

dwhitla@raptor:~$ java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
dwhitla@raptor:~$ mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 23:51:28+1000)
Maven home: /opt/local/share/java/maven3
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: utf-8
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"

Does anyone have any idea what is causing this?



diff.txt666.67 KB

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2007-03-11

With a bit of debugging I have found that sun-web.xml in the __admingui exploded WAR contains the following:

<class-loader delegate="true"
              :WEB-INF/extra/prototype-1.5.0.jar" />

and com.sun.enterprise.glassfish.web.WarHandler.configureLoaderAttributes() does not strip the whitespace characters when splitting the extra-class-path into path elements.
See com.sun.enterprise.glassfish.web.WarHandler:286 for details.

Consequently at line 310:

                        URL url = file.toURI().toURL();

the spaces are URL encoded as %20 before passing the string to:

which then silently fails to add the jar to the classpath.
Strangely addRepository(String) converts the string back to a URL before passing it (eventually) to URLClassPath.addURL(). I don't have the source for this class but it evidently doesn't like the trailing encoded whitespace characters, because after this call returns the classpath has not changed.

URLClassPath.addURL() should probably strip the trailing whitespace. But then so should WarHandler.configureLoaderAttributes(). I will supply a patch to the latter after I've tested it.

Joined: 2007-03-11

I didn't want this patch to be this big but there were just so many issues with this class - dead code, out of date and valueless comments, redundant initializers and pointless string conversions.

Anyway this fixed the issue for me.