admin@glassfish.java.net

Default Values and _at_Param

From: Jason Lee <jason.d.lee_at_oracle.com>
Date: Tue, 18 May 2010 11:57:58 -0500

I'm currently working on getting a prototype running of the Admin
Console using the REST API, and I'm having an issue with default
values. Using AMX, when we ask the system for the default values for a
JDBC Connection Pool, for steadyPoolSize, for example, we get 8. Via
REST, we get null. I glanced at the AMX code, and it appears that it is
asking JMX for the default value (how that works, specifically, I really
don't know). The REST API returns the value of the "defaultValue"
attribute on the Param annotation, which causes problems for us, as that
value is not always specified.

Looking that the class CreateJdbcConnectionPool, we see this code:

     @Param(name="steadypoolsize", camelCaseName = "steadyPoolSize",
optional=true)
     String steadypoolsize = "8";

While defaultValue is not specified, there clearly exists a default, as
steadypoolsize is initialized to 8 when an instance of the class is created.

My question, then, is how should we handle this? Altering every Param
instance to specify a default value would work, though it would be
tedious, and, unless we then removed the initialization values on the
ivars, we wouldn't be DRY, but removing that might break other code.

Another approach might be to populate the defaultValue attribute
automatically when CommandModel.getParameters() is called. Ultimately,
that method call ends up calling CommandModelImpl.add():

     private void add(AnnotatedElement e) {
         if (e.isAnnotationPresent(Param.class)) {
             ParamModel model = new ParamModelImpl(e);
             if (!params.containsKey(model.getName())) {
                 params.put(model.getName(), model);
             }
         }
     }

It would probably be pretty trivial to check for null and populate if
necessary here, but that would require instantiating an instance of the
AdminCommand, which may involve side effects and/or performance issues
that I can't predict as this is the first I've looked at the code this
deeply. :)

We could also put this second option at the REST layer, and query a live
object every time the default values are needed, if this type of
behavior is undesirable at the CommandModel level.

Any thoughts? Other options I'm missing? For the prototype, I don't
think this is a real blocker, but we'll certainly need a solution before
we can begin the Console's AMX to REST migration in earnest.

-- 
Jason Lee
Senior Member of Technical Staff
GlassFish Administration Console
Oracle Corporation
Phone x31197/+1 405-343-1964
Blog http://blogs.steeplesoft.com