[wildfly-dev] CLI batches in control flow blocks

[Heiko Braun]

full scripting support: yes
using CLI command strings for that: no

if we go for scripting then regulat DMR makes more sense IMO

Sent from my iPhone

> On 05 Sep 2015, at 11:34, Radoslaw Rodak <rodakr at gmx.ch> 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/AdvancedCLIScriptingWithGroovyRhinoJythonEtc
> 
>  
> 
>> Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <tfonteyn at redhat.com>:
>> 
>> 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
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150905/26953c89/attachment.html