admin@glassfish.java.net

Re: More ConfigBean and CLI mismatch

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 27 Aug 2010 17:56:19 -0700

Jason, I think you were going to provide examples, but I never saw the
followup. Did I miss it?

Bill Shannon wrote on 08/10/10 08:38 PM:
> Can you fill in some details?
>
> I gathered from the issues you references that there's some mismatch
> between the CLI parameters for creating (?) virtual servers and thread
> pools vs. the config API for those elements after they're created?
> What exactly is the mismatch?
>
>
> Jason Lee wrote on 08/10/2010 04:28 PM:
>> 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? :)
>>
>