One implication of doing this is -- to get the "raw" value of an
attribute (out of possibly many) of a config bean, I need to
get the raw view of the entire bean.
I believe providing something like:
@Inject
HttpListener ls;
//...
String v = ls.getRawAttributeValue("port");
is also useful.
(This is more generalized view of what Tim suggests, I guess).
Is that possible with your changes?
My experience is that although variable substitution is a "powerful"
feature, it is used only for sparingly as far as attributes of a bean
are concerned. So, getting the raw value would be an exception rather
than a norm.
Jerome Dochez wrote:
> 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 <mailto:lloyd.chambers_at_sun.com>
>>> Sun Microsystems, Inc
>>>
>>>
>>>
>