CLI batches in control flow blocks

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

CLI batches in control flow blocks

Alexey Loubyansky
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Tom Fonteyne-2
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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Alexey Loubyansky
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.

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).

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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Tom Fonteyne-2


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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Brian Stansberry
In reply to this post by Alexey Loubyansky
On 9/4/15 12:55 AM, 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.
>

Yes, it's now or not for a long time.

>> 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.
>

Thanks; that's a very good point. Yesterday, I was having a hard time
seeing the point of ls inside an if/else; now I get it. :)

>> 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.
>

I said yesterday (below) that this was a bad idea because it can still
break scripts or prevent rollback, same as your proposal. But I think in
practice this wouldn't be a real drawback, since AIUI the bugs mean any
existing script with reload/shutdown in the middle of a bunch of other
ops would be broken anyway. Right?

>> 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.
>

The drawbacks are the same though. To avoid breaking old scripts the
default behavior would have to be the old behavior, and then the people
wanting the new, correct behavior would have to jump through strange hoops.

> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Alexey Loubyansky
On 09/04/2015 04:27 PM, Brian Stansberry wrote:
> On 9/4/15 12:55 AM, Alexey Loubyansky wrote:
>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:

-- skip --

>>> 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.
>>
>
> Thanks; that's a very good point. Yesterday, I was having a hard time
> seeing the point of ls inside an if/else; now I get it. :)
>
>>> 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.
>>
>
> I said yesterday (below) that this was a bad idea because it can still
> break scripts or prevent rollback, same as your proposal. But I think in
> practice this wouldn't be a real drawback, since AIUI the bugs mean any
> existing script with reload/shutdown in the middle of a bunch of other
> ops would be broken anyway. Right?

:reload or :shutdown don't make any sense in the middle of a composite
operation. If they make sense in a batch, they should be last. Even
then, does it make sense to include them into a composite operation?

Thanks,
Alexey
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Brian Stansberry
On 9/4/15 10:44 AM, Alexey Loubyansky wrote:

> On 09/04/2015 04:27 PM, Brian Stansberry wrote:
>> On 9/4/15 12:55 AM, Alexey Loubyansky wrote:
>>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>
> -- skip --
>
>>>> 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.
>>>
>>
>> Thanks; that's a very good point. Yesterday, I was having a hard time
>> seeing the point of ls inside an if/else; now I get it. :)
>>
>>>> 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.
>>>
>>
>> I said yesterday (below) that this was a bad idea because it can still
>> break scripts or prevent rollback, same as your proposal. But I think in
>> practice this wouldn't be a real drawback, since AIUI the bugs mean any
>> existing script with reload/shutdown in the middle of a bunch of other
>> ops would be broken anyway. Right?
>
> :reload or :shutdown don't make any sense in the middle of a composite
> operation.

Agreed.

> If they make sense in a batch, they should be last. Even
> then, does it make sense to include them into a composite operation?
>

In a CLI batch, the benefit of including them last is the exclusive
write lock acquired by the previous steps is held until the reload is
initiated. If it's a separate step another change from a different
client can sneak in between.

In a non-CLI composite there's also a minor advantage in that the params
to :reload/:shutdown will be validated inside the composite and if they
are invalid this will roll back the composite. But in a CLI batch the
CLI isn't going to send invalid params from its high level commands.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: CLI batches in control flow blocks

Radoslaw Rodak
In reply to this post by Tom Fonteyne-2
Why not provide CLI out of the box in WildFly  combined with one of scripting language, something like this ?


 

Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <[hidden email]>:

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

Why not provide CLI out of the box in WildFly  combined with one of scripting language, something like this ?


 

Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <[hidden email]>:

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev