Hi, Lloyd.
I'm sure there are difficulties with what I'm about to say, and perhaps
its old ground that has been covered before that I'm not aware of. But
here goes anyway. (Kedar alluded to one of the difficulties already in
his reply, but I'll send this out anyway).
I would expect that some,perhaps most, AMX clients would be interested
in the substituted value for such attributes, rather than the
placeholder string itself. Continuing your example, as my AMX client
navigates to the specific HTTPListenerConfig instance of interest, the
admin infrastructure and therefore AMX would know which system property
assignment(s) applied to that particular HTTPListenerConfig and could
substitute the values for the placeholders before returning the values
to my client in response to getXXX invocations.
Would it make sense to expose something like this:
//
public boolean getEnabled();
public void setEnabled( boolean value );
public String getEnabledRaw();
public void setEnabledRaw( String value );
The setXXXRaw methods would throw data conversion exceptions if the
specified string value did not convert properly, perhaps exempting
${yyy} strings from format checking and conversion.
Pros:
An AMX client could deal with whichever approach made sense at that
point in its logic.
Strong type-checking of the argument and return values (where the type
is not already a String) would remain.
Another reason this is appealing is that AMX clients that want to deal
with the substituted value would not have to invoke some additional AMX
method to perform that substitution.
Cons:
I don't recall whether the current v2 implementation performs the
substitution automatically or not. If not, then as I described the
approach above it would be an incompatible change if getxxx methods in
v3 performed variable substitution.
In some ways it would make sense to have parallel sets of methods for
attributes whose actual underlying values are String, to allow the
client to trigger substitution or not. In such a case there would
probably not be much use for both setXXX and setXXXRaw, but then the API
would not be uniform for all attributes regardless of underlying type.
I suppose setXXX for such attributes could check for and reject attempts
to assign a value like ${yyy}, since the client should use setXXXRaw for
that.
The API would be wider, with potentially double the number of methods
for getters and setters.
Just thinking out loud a bit.
- Tim
Lloyd L Chambers wrote:
> *VARIABLES in GlassFish config*
>
> In GlassFish V2, there is a form of *variable substitution* whereby
> any Attribute can be of the form ${VAR_NAME}, with values from
> <system-properties> providing the actual value at runtime. This is
> very useful in multi-server systems, where different values can be
> substituted at runtime (eg for a port). Thus, every Attribute
> potentially is of type java.lang.String, and *any API exposing that
> Attribute must also be of type **java.lang.String* to support these
> variable substitution.
>
> *AMX APIs for config*
>
> AMX (JMX management API for managing the appserver) use data types
> which are largely java.lang.String. However, there is use of 'int',
> 'boolean', 'long' in some places. For example, HTTPListenerConfig
> includes:
>
> public boolean getEnabled();
> public void setEnabled( boolean value );
> (see
> https://glassfish.dev.java.net/nonav/javaee5/amx/javadoc/com/sun/appserv/management/config/HTTPListenerConfig.html
> )
>
> In short, the AMX API is broken should a variable be used for the
> 'enabled' Attribute. Short of using overloaded getters/setters with
> different signatures, there is no other apparent resolution to this issue.
>
> *PROPOSAL for V3*
>
> To support variables which are inherently multi-types (String or
> 'int'/'boolean'/etc), all attributes will become type
> java.lang.String in the AMX interfaces. This will be an *incompatible
> change*, and it removes compile-time type safety.
>
> Please convey any concerns or suggestions you might have.
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
> Sun Microsystems, Inc
>
>
>