Lloyd L Chambers wrote:
> Correct, the "view" idea doesn't apply directly to JMX clients, either
> in-process or remote.
>
> The MBean would have to have available both APIs (which means both
> variants, distinguished by signature or method name); the "view" could
> be swapped by using a different client-side proxy.
>
> For example, exposing "Port" would require something like this in the
> MBean to be able to support both views as Attributes:
> int getPort();
> void setPort( int port ); // implicit resolving of ${...}
> String getPortRaw();
> void setPortRaw(String port);
> String resolveAttributeValue( String attrName );
Given that approach, do we really need "views"?
Wouldn't it be simpler if there were just get/setRawAttribute methods that
took an attribute name?
I'd rather not make an incompatible change to the AMX API and turn every
attribute into an untyped string.
How does the admin GUI currently deal with the need to access both the
raw and expanded value of the attribute? Is it not using AMX?
Also, does every MBean need a resolve method, or can a single resolve method
suffice for all MBeans? I didn't think there was anything about the resolution
process that depended on which attribute you were resolving.
> An alternative which turns all Attributes into *methods* (not desirable
> IMO) would be:
>
> String getPort( boolean resolveToActualValue ); // "80" or "${PORT}"
> void setPort( String newValue );
> ...
> String resolveValue( String attrName ); // "80" => "80", "${PORT}" =>
> "80"
Ya, I don't like that either.