Bill,
I think the rationale all along has been to be able to generate
distinct ports so that they do not conflict if more than one server
is running on the same machine. Presumably there are other uses as
well, but perhaps (not sure) the whole feature is just overkill.
In theory configs can be shared. So that would mean sharing a
variable for all servers in a cluster, or for a group of standalone
servers (weird).
So AFAIK, it makes sense (for ports) only to define it in a <server>,
since defining it in a (shared) config would cause the conflicts the
feature purports to prevent.
Lloyd
On Feb 1, 2008, at 7:17 PM, Bill Shannon wrote:
> Lloyd L Chambers wrote:
>> Bill,
>> Proviso: my knowledge of this area is limited. AFAIK, <domain>
>> could contain a system property HTTP_LISTENER_PORT and so could
>> <config>, and so could <server> and each could have a different
>> value. But see failure below where I tried...a bug?
>
> It looks like you've found a bug here, but it's unrelated to the
> problem at hand.
>
> What do you think the semantics are of defining a system property in
> <server> vs. defining it in <config> (assuming it worked, of course)?
>
> If the property is defined in <config>, is it only set when that
> config
> is being used? I guess that must be the intent.
>
> So, if you're going to expand the value of a system property, you
> might
> need to know the <config> element context in which the value occurs.
>
> Ok, now I see the issue.
>
> Of course, it's also possible that other system properties will
> vary from
> machine to machine, without being specified in domain.xml, so to
> properly
> resolve a system property reference you really need to do it on the
> machine that's running the config that contains the element in
> which the
> property reference occurs. Yuck. I assume we just ignore that
> aspect of
> the problem and only interpret the system property settings within the
> <config> element.
>
> (I've been thinking too much of the simple DAS case where all of this
> would be much easier.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc