I could have missed something but--
No more non-String getter/setter methods exist in AMXConfig MBeans.
Recent changes to resolve GUI issues had converted most of these;
rather than leave AMX in an inconsistent state I converted the
remainder to String. The typical case was:
boolean getFoo();
void setFoo( boolean val );
This now reads as:
String getFoo();
void setFoo( String foo );
In a sense this applies to any @Configured as well, where all values
are 'String'.
In general, anything using AMX to read configuration cannot assume
that any value is a literal; any value could be a ${...} template, and
should use com.sun.appserv.management.helper.TemplateResolverHelper to
deal with this.
A BETTER SOLUTION
We can revert this decision if the group can agree on the right
approach. There are multiple problems today:
1. At the config level eg @Configured, we seem to support only
'String' (eg getters/setters at least seem to be always declared as
'String'). If this level were to support other types, then these
could be reflected at the AMX layer more easily. One problem with that
approach would be API tracking whereby the underlying object changes
from, say, 'String' to 'Integer' (or vice versa) -- this does not lead
to a stable API.
2. It should be well documented which values can be templatized. An
annotation comes to mind eg:
@Attribute(template=true)
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc