Hi Kedar,
kedar wrote:
> Hmmm. Would there be other "class" of users who won't want
> GlassFish to be side-effected if you change your "system" JAVA_HOME
> environmen`t variable?
I suppose.
> Think of the GlassFish based distributions
> where JDK was distributed along with the application server bits and
> placed at: <install-dir>/jdk, e.g.
>
I wasn't aware that there were distributions of GF that co-bundled
a JRE. In that case, I would fully expect GF to use its own copy.
That's what my IDE does and it makes sense.
> 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.
>
If I had to guess, I would say that most command line tools follow
this convention, like Ant and Maven, for example.
> 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).
>
That's what I did. But my point is that I was surprised that GF
hard coded a pointer to an external dependency.
> 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".
>
Do they both use the value of AS_JAVA ?
Thanks,
--Ryan