On Jan 28, 2008, at 8:52 PM, Bill Shannon wrote:
> 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"?
As Lloyd hinted, there is a difference between views and AMX. At the
core of the config-api, there is a mapping between xml attributes and
set/get accessor methods. If an attribute is always an int and does
not have to be "translated", it can be declared as an int. Now the
core config-api is an interface which we implement today with a single
class called ConfigBean that uses streaming xml APIs to read the
domain.xml. We have also identified that these APIs will need to be
implemented by pure Java Beans that will give an opportunity to
embedding applications to programmatically set configuration data
before starting glassfish with that configuration (no domain.xml
whatsoever is such a case).
So the main issue is that we want to read/save an attribute as a
String and access it as an int which will be difficult to do with a
single interface implementation like we wanted to have (config objects
are also config MBeans reducing the memory footprint, complexity,
registration, etc...).
We should potentially have an AMX view that would aggregate access to
the raw and translated data using a well defined pattern that can be
generated from the config-api interfaces. That could be used to
implement what Lloyd suggested above.
now if I look at
https://glassfish.dev.java.net/nonav/javaee5/amx/javadoc/com/sun/appserv/management/config/HTTPListenerConfig.html
I can see the getPort() returning a String (the raw value), how do you
get to the translated one ?
>
>
> Wouldn't it be simpler if there were just get/setRawAttribute
> methods that
> took an attribute name?
I feel that if we go that route, it might be simpler at the config-api/
amx level but we are going to find a lot of code in GF that will test
wether it needs to get the raw or translated attribute and call the
appropriate method. We could avoid most of these if () then else code
if we procure a view of the model and let the users use the same API
to access the raw or translated view. Also it makes it very difficult
to change the nature of an attribute from translatable to non
translatable or vice versa without changing all the code that uses
that attributes.
>
>
> I'd rather not make an incompatible change to the AMX API and turn
> every
> attribute into an untyped string.
>
ok so I would like to know how many of these APIs would be broken
because I didn't find any int getPort() in the AMX javadocs I looked
at, it seemed AMX was always giving me the raw value as a string.
Lloyd, where should I look ?
>
> 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?
good question...
also how many times does it really need that feature ? Are we
scratching our heads for two screens with specific needs ? or is it
ubiquitous ?I would rather not hack around a complicated scheme if we
can resolve it by special casing two admin screens model. I don't
think that the runtime has a real interest in the raw values, until it
needs to modify the configuration that is.
>
>
> 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.
Again with such a proposal, all the code in glassfish will have to go
to a special place to translate an attribute into a real value. If we
decide that a new attribute that was not translatable should now
become translatable we will have to change ALL the code using that
attribute from :
String foo = config.getFoo();
to
String foo = MBeanHelp.pleaseTranslate(config.getFoo());
with the view mechanism of intercepting attribute, you don't have to
change any code, the interception does the magic.
As a conclusion I would like to understand :
- how many incompatibilities would we see in AMX config interfaces ?
- how much code really needs access to both translated and raw
attributes values concurrently ?
Jerome
>
>
>> 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.