dev@glassfish.java.net

Proposal for consideration to load JavaDB classes by System ClassLoader instead of Extension ClassLoader in GlassFish

From: Max Poon <maxpoon_at_dev.java.net>
Date: Fri, 11 May 2007 08:18:27 +0800

Greetings *

Is the any specific reason why JavaDB (org.apache.derby.*) classes are
loaded via Extensions ClassLoader instead of System ClassLoader in
GlassFish, since Extensions ClassLoader seems to be used for loading
optional packages to core Java packages, mostly the javax.* classes ?

 From JDK documentation on Java Extension Mechansim :

"Optional packages are the new name for what used to be known as
/standard extensions/. The "extension mechanism" is that functionality
of the JDK and JRE that supports the use of optional packages.
  .......
A optional package is an implementation of an open, standard API
(examples of optional packages from Sun are JavaServlet
<http://java.sun.com/products/servlet>, Java3D
<http://java.sun.com/products/java-media/3D>, JavaManagement
<http://java.sun.com/products/JavaManagement/>). Most optional packages
are rooted in the javax.* namespace, although there may be exceptions."

Especially in case of deploying AspectJ applications where the AspectJ
weaver is loaded in GlassFish's System ClassLoader via the Java language
agent (-javaagent:xxx.jar), the application classes weavable with
AspectJ are limited to those which can "see" the AspectJ weaver classes
and the aspects being weaved which are typically loaded in GlassFish's
System ClassLoader. Loading database driver related (e.g. Derby)
classes via Extension ClassLoader will render weaving on those classes
not possible. This seems to be in sync with the strategy with loading
of "non-core" classes via Bootstrap or Extension ClassLoader should be
minimized.

This will also facilitate deployment of AspectJ weaving applications on
GlassFish. For example, we explicitly modified GlassFish's jvm-options
to have derby jars and classes loaded via GlassFish's System ClassLoader
to enable JDBC connection and statement execution monitoring by GlassBox
<http://glassbox.com> on GlassFish, which may be by default enabled on
other web containers like Tomcat without similar jvm-option modification
needed :

The following 3 additional jars are required to be entered and included
in the AppServer Class Path configuration

    * ${com.sun.aas.derbyRoot}/lib/derby.jar
    * ${com.sun.aas.derbyRoot}/lib/derbyclient.jar
    * ${com.sun.aas.derbyRoot}/lib/derbynet.jar

The following string is required to be deleted from -Djava.ext.dir JVM
option

    * ${path.separator}${com.sun.aas.derbyRoot}/lib

so that java.ext.dir is now

    * -Djava.ext.dirs=${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext


Appreciate any comments/advice.

Thanks
Max