A historical perspective on this variable:
It should be set by the startup code reading the asenv.conf (which
is rather ignored or is erroneously handled at the moment). The idea
was that we put the "Java DB" jars in standard Java extension location
and then it would be available to the runtime. Why the server runtime
needs these jars is something that Database integration folks should
know. If my memory serves me correctly it was for the embedded Java DB
database or was used by the default JDBC resource.
When you are changing the code that makes the Java DB jars available
to the runtime, talk to Jerome/Sreeni as they had been working on
reusing the Java DB while running atop *JDK* 1.6, which bundles it.
It's a little strange that you say that bootstrap code already adds
Java DB jars and yet -Djava.ext.dirs references this variable. IMO,
either of them is needed (But I don't know about class loading of the
server enough, yet).
-Kedar
Sahoo wrote:
> I don't think com.sun.aas.derbyRoot is set anywhere, yet it is
> referenced in domain.xml as shown below:
> <jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.
>
> sun.aas.instanceRoot}/lib/ext${path.separator}${com.sun.aas.derbyRoot}/lib</jvm-options>
>
>
> Who should set this variable? Currently Derby jdbc drivers are being
> made available because of some code in bootstrap module which adds them
> to classloader hierarchy. I want to change this as it does not look
> correct to me. So, I need this to be fixed.
>
> Thanks,
> Sahoo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>