There would be a slightly different way of doing this. I have not
completed the APIs yet but the basic idea out be :
@Inject
HttpListener httpListener; // you get the translated view
httpListener.getPor() ---> 8080
Somewhere now you want the raw value, you do ...
HttpListener rawHttpListener = ConfigUtils.getRawView(httpListener);
rawHttpListener.getPort() ----> ${com.aas.instance.httpPort}
Another example of views is WriteableViews :
httpListener.setPort("foo.bar")
would trigger an exception but...
HttpListener writeableView = ConfigUtils.getWriteableView(httpListener);
writeableView.setPort("${com.foo.bar") // when writing, you always
write to Raw
HTH, Jerome
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
>>
>>
>>