Lloyd,
> 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.
Probably. But we have seen its usage in defining something like memory
parameters which might be different for different servers in a given
cluster.
One user even used it to set the classpath.
>
> In theory configs can be shared.
That's not theory. That's true in practice. All the servers in a given
cluster share a config.
Also, I think there are multiple issues that we discussed on this thread.
Getting back to original issue:
Should AMX API be changed so that methods are type-agnostic and
accept/return strings alone(specifically for attributes of an
element like http-listener)?
And we seem to converge to "Yes, we should change the API this way".
Is it fair to say that we all agree on this?
- Kedar
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>