> 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.
In the serverbeans itself, I see:
@Attribute (defaultValue="8")
@Min(value=0)
@Max(value=Integer.MAX_VALUE)
String getSteadyPoolSize();
So I guess there is not relationship defined between a CLI param and a
serverbean attribute, including for a default value...
@Param has a defaultValue attribute itself....
>
> 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,
Agree.
> 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. :)
Make sense to me...
>
> 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.
The deeper, the better imo, so unless people disagree I would not want
this in REST layer.
>
> 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.
Good investigation:-) I was thinking about these default values and the
disconnect between cli params and corresponding serverbeans attributes
recently...
Ludo