6:08 a.m.
On 1/29/2013 11:38 PM, Jesse Sightler wrote:
On 01/28/2013 09:48 PM, Brian Stansberry wrote:
>> - Do we have a preexisting class to convert from the ModelNode operation to
a CLI command? If not, nothing immediately jumps out at me that would make this extremely
hard, but I don't want to duplicate existing work.
>>
> Not that I'm aware of and I'd be surprised if such a thing exists in any
> reasonably complete form. The standard use case goes the other direction.
Understood... that matches what I was seeing as well. At a glance, it
doesn't seem like the code to go in the other direction would be nearly
as complex, though.
Yes, building CLI commands automatically is pretty
straightforward. The
only thing to watch out for is to make sure you escape special
characters. Here is code from CLI GUI that does that. Please let me
know if you find this list is incomplete:
public static String escapeAddressElement(String element) {
element = element.replace(":", "\\:");
element = element.replace("/", "\\/");
element = element.replace("=", "\\=");
element = element.replace(" ", "\\ ");
return element;
}
One thing that will be difficult in converting console commands is that
the console sometimes executes a command and then decides what to do for
the next command based on the output. I think that will be next to
impossible to replicate in CLI because you will have to understand the
logic and then try to build CLI script conditions based off of it.
>> 2. I don't necessarily agree with the proposed approach in the JIRA. I think
it may be easier to append this information to the status result after an operation has
completed. For example, after the user saves a property, a "Save successful"
message appears. I believe this is clickable to show details, and we could display the CLI
commands to rerun the action within that dialog.
>>
>> Is that an acceptable way to accomplish this task? Or is there some other
preferred approach to implementing this in the UI?
>>
> I'll defer to Heiko Braun on UI details. :) My only comment is this
> needs to be unobtrusive since it's extraneous to the core task users are
> trying to accomplish. What you describe sound unobtrusive.
I agree that it should be unobtrusive. At the moment, I'm trying to get
together a simple proof-of-concept for one or two panels in the console.
Once that's done, I'm hoping Heiko can provide some guidance on how it
should be done. :)
> One thing to keep in mind with this is raw DMR operations can be
> converted readily enough into CLI low-level command syntax. But CLI low
> level commands may not be the recommended approach for achieving many
> tasks. The CLI now has quite a number of high level commands (e.g.
> "deploy") that are more user friendly. I wouldn't support any attempt
to
> map console-generated operations to those high level commands, as that
> would be a likely bug nest and a maintenance nightmare.
Good, and I agree that translation to high-level operations would be
extremely difficult to get perfect.
Right now it looks like the biggest challenge may be that the CLI seems
to be more strict than DMR. For example, the operation to add a
system-property in standalone mode rejects "add" operations that contain
the "boot-time" parameter. But this is only the case from the CLI, as
the management console sends them as DMR with no issues.
I haven't yet figured out an approach for dealing with that yet, but it
may be that each operation has to be aware of these discrepancies in the
management console.
> The one exception to this is the DMR "composite" operation[1] should be
> converted to the CLI "batch" and "run-batch" high level commands,
with
> each step in the composite being a low-level command after "batch" and
> before "run-batch".
Good point, and this looks relatively straightforward to implement.
Thanks,
Jess
_______________________________________________
jboss--dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev