[wildfly-dev] CLI batches in control flow blocks

Sat Sep 5 05:34:25 EDT 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150905/4c155018/attachment-0001.html 