[jboss-jira] [JBoss JIRA] (WFLY-2946) Improve 'cd' behavior in batch mode

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992405#comment-12992405 ] 

Brian Stansberry commented on WFLY-2946:
----------------------------------------

I think that's reasonable. The only alternative I can think of is hacks like analyzing the batch for add ops and guessing that those mean the 'cd' would be valid. And that would have tons of holes. This could be more useful in general too, e.g. outside a batch.

I think the name of the argument is important, and limiting it to cd at first is a good idea. Those two points are a bit contradictory, because a name that's good for the 'cd' command only may be poor if we later expand the use.

Would simply "--no-validation" work, or are there cases (besides cd) where we need to do some validation no matter what?

I could see this even being useful for low-level operations, basically turning off the jboss-cli.xml "validate-operation-requests" setting for one op.

> Improve 'cd' behavior in batch mode
> -----------------------------------
>
>                 Key: WFLY-2946
>                 URL: https://issues.jboss.org/browse/WFLY-2946
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>
> See discussion at https://community.jboss.org/message/858108#858108 for background.
> The problem is the 'cd' behavior discussed in my comment. A 'cd' in batch mode seems to have triggered the CLI validating the location (or some other op against the address), which fails since the previous batch step that created the location hasn't executed.
> Would it be better to simply accept the address in batch mode, or somehow be a bit smarter?



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)