On 01/10/2012 07:29 PM, ssilvert(a)redhat.com wrote:
On 1/10/2012 11:30 AM, Kabir Khan wrote:
> That worked for me so I pushed that change. It looks great!
>
> The one thing which is a bit strange is the ability to add a child resource. e.g. the
add operation should really by on the parent of the resource being targeted. For example,
the ee extension has the add operation in its list, which gives the op:
"/extension=org.jboss.as.ee/:add(module=sasasa)". Which is a bit pointless since
it already exists, and there is no way to add a new extension. I had similar issues when
writing the management jmx facade, see ChildAddOperationFinder and its callers.
Yea, I agree that it's a bit strange. But I'm not sure if this is a
problem that can be solved by the tool. What I have seen is that often
you need to give an address that doesn't exist yet, and append :add to
it. For instance, to add a new logger you say
/subsystem=logging/logger=foo/:add
But if you look at subsystem=logging you see that there are many kinds
of entities that might need to be created (loggers, handlers, etc.).
That makes it hard for the tool to guess what you are trying to add.
Beyond that, there is no way for the tool to know what params are
required for a new entity. :read-operation-description(name=add)
doesn't usually help in this case.
But it is supposed to. This is why it is there in the first place
(otherwise it's completely useless), if it's not working as it should,
it's a bug (a jira issue should be raised against that component).
IMO, each management handler should fully implement the add
operation,
specify the expected params, and never rely on default behavior. But
that would be a lot of work to go back and fix them all.
And not only the 'add' operation. All of the operations, attributes and
nodes must be properly described in the model.
Anyone else have comments/suggestions?
Management model description is what the tools should rely on. Lets fix
bugs, not find ways to workaround them.
Alexey