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 will share more of this soon when I can breathe again.
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