Re: [wildfly-dev] CLI batches in control flow blocks

On 05 Sep 2015, at 11:34, Radoslaw Rodak <rodakr(a)gmx.ch&gt; wrote: Why not provide CLI out of the box in WildFly combined with one of scripting language, something like this ? https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJytho... > Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <tfonteyn(a)redhat.com&gt;: > > IMHO.... you cannot use if/then in batches anyhow, e.g: > > batch > ... > if ... > ... > then > ... > fi > ... > run-batch > > fails. So the use of if/then was of very limited use anyhow. > > Having multi-level batch would be ideal. > Removing auto-batch from if/then blocks would at least allow batches > "around" them to work properly which would be a big win anyhow. > > just my £0.02 of course > Tom > > >> On 04/09/15 06:55, Alexey Loubyansky wrote: >>> On 09/04/2015 12:10 AM, Brian Stansberry wrote: >>> The risk is this can break existing scripts, which we've sought to >>> avoid. A couple breakage scenarios: >>> >>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the >>> script breaks. >>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't >>> rolled back. >>> >>> The first one is more likely, but the second one is a bigger concern, as >>> the user may not be aware Step 1 wasn't rolled back. >>> >>> Do you have any sense of how common either of those scenarios would be? >> Unfortunately, no. I don't get much feedback on this except for created >> issues that I referenced. >> I wouldn't bring it up unless this wasn't a major version release, of >> course. >> >>> Below are bad ideas that I wrote down and then thought better of, but >>> I'll send them in case it sparks a thought. >>> >>> I. Since there is already logic for dropping out of the batch for things >>> like cd, ls, could it be modified as follows? >>> >>> a) Close any current batch and execute that batch. >>> b) Execute the cd, ls, etc >>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch. >>> >>> That seems like a better semantic for cd and ls anyway. >> I don't think so. The batch mode is also a composition/editing mode. cd >> and ls are useful when writing commands/operations that should be added >> to the batch. Imagine editing a batch and wishing to cd before entering >> next lines. That won't be possible without explicit holback-batch, cd >> and then batch again. That would be inconvenient. >> >>> With that, reload and shutdown can be treated the same as cd, ls. >> For reload and shutdown that does seem to make sense. So, a possible >> alternative is making them exceptions. >> >>> Why a bad idea? Doing it as I suggest has the same two drawbacks as >>> requiring the user to declare the batch. :( Just perhaps less likely to >>> occur. >>> >>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally >>> possible? Why a bad idea? To solve the breakage problem it would need to >>> be 'true' by default, thus forcing users forever to declare that they >>> want the non-broken mode, *plus* they have to declare the batches. >> As a param to if/else/try/catch/finally this doesn't make sense to me. >> Because then the user could simply explicitly start bodies with batch. >> This kind of argument could make sense as a launching script argument >> for the whole cli session, imo. >> >> Thanks, >> Alexey >> >>> >>>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote: >>>> Hello everyone, >>>> >>>> I've been thinking about changing how the bodies of if-else and >>>> try-catch-finally are treated by the CLI. >>>> >>>> Up until now every control flow block (i.e. between if and else, between >>>> else and end-if, etc) was executed as a batch. So, when a block was >>>> selected for the execution, the CLI would enter the batch mode and >>>> proceed adding operations (and commands translated to operations) to it. >>>> If a command can't be translated to an operation, it would be executed >>>> outside the batch immediately (that's done for commands like cd, ls, >>>> etc). After the last line of the body processed, the batch (if not >>>> empty) is executed. >>>> >>>> But this doesn't work when mixing operations with shutdown or reload >>>> commands (they do translate to operations but they have additional logic >>>> related to re-connecting). shutdown/reload will be executed outside the >>>> batch and before the batch is complete. >>>> >>>> Currently open issues for this >>>> https://issues.jboss.org/browse/WFCORE-876 >>>> https://issues.jboss.org/browse/WFCORE-533 >>>> >>>> So, I think it was a mistake to execute the bodies of control flow >>>> blocks as batches. It would be better leave them as usual sequences of >>>> command lines and if the user wants a batch, he/she could add batch >>>> command explicitly. >>>> >>>> I wanted to ask for opinions. Could we make this change in WildFly 10? >>>> >>>> Thanks, >>>> Alexey >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Tom R. Fonteyne - SSME > Red Hat - UK > EMEA GSS SEG-Middleware > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev