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 );
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"
Lloyd
On Jan 26, 2008, at 9:10 AM, Kedar Mhaswade wrote:
>
>
> Bill Shannon wrote:
>> Two things I don't understand about the "view" approach...
>> How does this solve the AMX problem? How does the AMX client,
>> which uses JMX underneath, control which view it sees?
>
> I don't think "views" of config beans solves the "AMX" problem.
> I think we are tending toward making changes to AMX API in an
> incompatible manner (by making methods accept/return strings alone).
>
>> How do you handle the fact that the types of the attributes are
>> different in the different views? E.g., boolean vs. String.
> A view (I guess) returns a proxy that views the config bean world in
> a (possibly) type-safe manner. To that effect, there is a raw view
> which
> is type-unsafe and there is a translated view that is type-safe.
>
> Again, this applies to lower level config and not directly related to
> publicly exposed AMX API.
>
>> ---------------------------------------------------------------------
>> 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
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc