In the issue tracker, there are currently two issues open (12710 and
12711) which are caused, ultimately, by a mismatch between the CLIs and
the ConfigBeans that they ultimately manipulate. In the past, we've
been able to circumvent this by using the alias attribute on @Param. In
this case, though, there's just no @Param on the CLI to augment. The
idea, then, in this case was to ADD the CLI params that matched the
missing ConfigBean attributes, which would then allow us to interrogate
the class for the data we need. The thinking was to address this issue
as simply as possible now and find a more general solution later should
the need arise.
Today, though, I ran across a related issue while working on the JMS
pages in the console. Most of the parameters on the CLI do not match
exactly (case, etc) the attributes on the ConfigBean. In at least one
case, though, our @Param.alias approach won't work, as the alias is
already used. It seems, then, that the more general solution above
needs to be found.
From the console's perspective, if we were always to query the
ConfigBean for attributes (name, type, default value, etc), things would
be pretty simple. One problem, though, is that, for those instances
where CLIs are wrapped and exposed, we have no way of getting the the
CLI command to the ConfigBean. However, assuming we found or invented a
way, we'd have the same mismatch problem above, but coming from a
different direction: we'd have a list of attributes and values based
off the ConfigBean, but there may not be CLI params to match them.
I know it's a bit late in the game for doing major surgery, but we need
to do something, though I'm not sure what. Anybody have a good
suggestion? :)
--
Jason Lee
Senior Member of Technical Staff
GlassFish Administration Console
Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com