Jerome Dochez wrote:
> I agree and I have added the concept of views of a confit object to
> give u either the translated value or the raw property name depending
> which view you are using. By default u get the translated view of course.
I am just now seeing Jerome's response. The alternate views sound like
they address the substituted vs. raw issue nicely, so long as all
attribute values are treated as strings. Presumably AMX will need to
tap into the views and let the AMX client switch between the views.
> I will share more of this soon when I can breathe again.
I still wish there were a good way to preserve strong type-checking, but
the prevailing opinion seems to be running against that due to the
expansion of the API involved. That would also conflict with the
translated vs. raw view approach since it would not make sense to have
the strongly-typed methods with the raw view.
- Tim
>
> Jerome
>
> On Jan 25, 2008, at 12:51 PM, Kedar Mhaswade <Kedar.Mhaswade_at_Sun.COM>
> wrote:
>
>> This is not a new issue. We had this problem (!) for V2 and before
>> that too.
>>
>> I don't see any way around this. Providing both type-safe and unsafe
>> varieties makes API too complex. So, I think we have no choice but to
>> Stringify all getters/setters.
>>
>> 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
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>