Lloyd L Chambers wrote:
> System properties can exist in the following elements:
> - <config>
> - <server>
> - <cluster>
> - <domain>
>
> So to resolve a system property, one cannot simply look in one global
> place; MBeans contained (directly or indirectly) under one <config> will
> resolve differently than those contained under another config.
Can you give me an example of where an attribute value will resolve
differently depending on whether it's part of (e.g.) a <server>
element vs. a <domain> element?
> Assume 'amx' is a client-side proxy to an AMX MBean--
>
> I would much rather write:
> String value = amx.resolveAttribute( "MyAttribute" );
>
> than:
> AttributeResolver resolver = <get it somewhere>;
> String target = getTheTargetSomehow( amx ); // AMX has no concept of
> 'target'
> String attrValue = amx.getAttribute( "MyAttribute" );
> String value = resolver.resolveAttribute( attrValue, target );
>
> The latter is a truly ugly procedurally-oriented kludge. And it doesn't
> wrok at all if we add decide for some reason to add system properties at
> additional intermediate scopes lower than server/cluster/config.
I don't understand. I thought system properties were global, not scoped.
Back to the original problem...
Browsing quickly through the AMX APIs, it appears that AMX only uses
String for values, always returning the unresolved value, is that correct?
How do you use AMX to get the resolved value currently (V2)?
So let me see if I understand how this "views" stuff is going to work.
I'm going to define a config object with an "int getPort()" method.
Code that asks for the "normal" view of that config object will
use that method and get back a "resolved" integer for the port number.
Code that asks for the "raw" view of that config object will get an
object of some other type that has a "String getPort" method, which
will return the unresolved String value for the port number.
Is that right?
Who defines the type for the "raw" view object? Is it generated
automatically? Is it a name derived from the original config object?
And the AMX interface will be somehow derived from this "raw" view?
Or does AMX not depend on these config objects at all, instead accessing
the data at the "mini-DOM" level?
Sorry, I still can't put all the pieces together here...