[wildfly-dev] CLI batches in control flow blocks

[Brian Stansberry]

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?


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.

With that, reload and shutdown can be treated the same as cd, ls.

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.


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
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat