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
Why not provide CLI out of the box in WildFly combined with one of scripting language, something like this ?
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev