Hmmm. Would there be other "class" of users who won't want
GlassFish to be side-effected if you change your "system" JAVA_HOME
environment variable? Think of the GlassFish based distributions
where JDK was distributed along with the application server bits and
placed at: <install-dir>/jdk, e.g.
If you think users like you outnumber the others, please file
an RFE to make asadmin respect the environment variable first.
If that fails, it should then fall back to config/asenv one
that is configured by setup scripts.
At the heart of it is the concept of asenv.conf[.bat] that is
available in install-dir/config. Ideally, this file should be
used for locating "other" software like JDK. A particular install's
asadmin refers to its sibling config/asenv.conf[.bat], by default.
So, wouldn't changing the AS_JAVA in this file let asadmin
use the Java of your choice? (This is of course a work-around for your
case).
Also, note that there are 2 JVM's involved here -- one is client
(asadmin) VM and other is the server VM that is used by the domain
when you do "asadmin start-domain".
Kedar
Ryan Shoemaker - JavaSoft East wrote:
>
> I really don't understand why the asadmin scripts are
> hard coded to launch java from a location cached during
> installation rather than trying to use JAVA_HOME first.
> Can anyone shed some light on this?
>
> asadmin runs "$AS_JAVA/bin/java" and AS_JAVA is hard
> coded to whatever $JAVA_HOME happened to be when you ran
> "ant -f setup". If you install a new version of java and
> assume that the GF scripts are smart enough to check
> JAVA_HOME, then you will probably waste time trying to
> figure out why your code still isn't working like I did.
>
> --Ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>