On Jan 25, 2008, at 2:45 PM, Kedar Mhaswade wrote:
> 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?
>
it would be possible but you would loose the strongly typed API access
and type safety, I am not sure that's would be better although this
could be added. I feel that code requesting raw views would not care
about the translated view and the vice-versa. It would be possible to
have the 2 views (like in my example) but most likely, we could just
do something lile :
@Inject(view=Raw.class)
HttpListener httpListener;
and you get injected with the raw view, same APIs than the translated
view, same API that the writeable view. The Raw class would be
responsible for transforming the default httpListener view into a Raw
view, then you can also do things
@Inject(view=Writeable.class)
HttpListener httpListener;
@Inject(view=FunkyView.class)
and funkyview class would define a new proxy instance for the config
objects.
>
> 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.
right which is why be default you get the translated view and you have
to explicitly request the raw view if you are interested in raw
values. I think that people who need the raw view, probably don't
really care of having access to the translated value at the same time.
With this translated view injected, I want the code in GlassFish to
not have to worry about translating the raw data itself and I don't
want that translation code used everywhere.
Jerome
>
>
> 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
>>>>
>>>>
>>>>