Tim,
Well explained, thank you. I don't think we'd want to "double up" on
the methods. We did reject that way back when, though it's quite
viable technically.
It might be that we could add one special method, something like:
String getAttributeRaw( String attrName ); // return unprocessed raw
value
Object setAttributeRaw( String attrName, String value );
I'm not clear on the variable substitution in V2 either, I need to
check on that to verify the behavior.
Lloyd
On Jan 25, 2008, at 1:46 PM, Tim Quinn wrote:
> 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
>> Sun Microsystems, Inc
>>
>>
>>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc