[wildfly-dev] CLI batches in control flow blocks

[Alexey Loubyansky]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>