[wildfly-dev] CLI batches in control flow blocks

Fri Sep 4 09:14:32 EDT 2015

On 04/09/15 12:51, Alexey Loubyansky wrote:
> Yes, that could be another reason. Thanks.
>
> Although, this is where it gets complicated and confusing.
>
> By multi-level, did you mean nested batches? Like nested transactions?
> If so, I don't think we'll go for that. It's just too complicated.
that's why I say "ideally" :)  But you are almost certainly right on this.
>
> Removing auto-batch from if/else and using them in a batch like you 
> described could still be confusing. The batch won't be executed until 
> all the lines preceding run-batch are added to the batch. Now we have 
> if in the middle. What if the condition depends on the operations 
> between batch and if? The evaluation of the if condition w/o executing 
> those won't be correct. And we won't be able to predict the effects of 
> the operations on the model w/o actually sending them to the 
> controller (because unless it's write-attribute, the operations may do 
> whatever).
yes, it would difficult/confusing as well.

to be fair, anyone asking me about if/then in CLI.... I usually point 
out that if they feel they need things like this, they should use a 
scripting language (or the Java API itself)

>
> So, that would be an improvement to be able to use if/else in the 
> batch but the condition should not depend on the operations preceding 
> the if.
>
> Thanks,
> Alexey
>
> On 09/04/2015 12:36 PM, Tom Fonteyne wrote:
>> 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

-- 
Tom R. Fonteyne - SSME
Red Hat - UK
EMEA GSS SEG-Middleware