On 8/10/10 4:28 PM, Jason Lee wrote:
> 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? :)
>
We could define a small indirection table in the REST module for now (
mapping of a few cli param names to the names we would use). I think it
will be enough for now and not extensive.... Then, we can decide if we
want to move this metadata in the cli area, but in any case it would be
used only for the rest side of the feature, not cli...
Ludo