Max,
I think this is a valid concern. Though I am not a 100% sure, one of the
reasons these classes
are not on the system classpath is to reduce the length of the classpath
which was known to
cause some issues. Currently, only the PELaunch and few other classes
are available in the system-classpath and
as such is loaded by the System CL. The rest is taken care of by the
classloading mechanism that
is documented extensively (Also read Sivakumar Thyagarajan's Blog).
Frankly, I don't see any issues with this proposal. Can you give it a
try and see if it works?
Kedar
Max Poon wrote:
> 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
>