<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Why not provide CLI out of the box in WildFly combined with one of scripting language, something like this ?</div><div><br></div><div><a href="https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc">https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc</a></div><div><br></div><div> </div><br><div><div>Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <<a href="mailto:tfonteyn@redhat.com">tfonteyn@redhat.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">IMHO.... you cannot use if/then in batches anyhow, e.g:<br><br>batch<br>...<br>if ...<br>...<br>then<br>...<br>fi<br>...<br>run-batch<br><br>fails. So the use of if/then was of very limited use anyhow.<br><br>Having multi-level batch would be ideal.<br>Removing auto-batch from if/then blocks would at least allow batches <br>"around" them to work properly which would be a big win anyhow.<br><br>just my £0.02 of course<br>Tom<br><br><br>On 04/09/15 06:55, Alexey Loubyansky wrote:<br><blockquote type="cite">On 09/04/2015 12:10 AM, Brian Stansberry wrote:<br><blockquote type="cite">The risk is this can break existing scripts, which we've sought to<br>avoid. A couple breakage scenarios:<br><br>1) Step 1 needs to happen in a batch with Step 2; now it won't so the<br>script breaks.<br>2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't<br>rolled back.<br><br>The first one is more likely, but the second one is a bigger concern, as<br>the user may not be aware Step 1 wasn't rolled back.<br><br>Do you have any sense of how common either of those scenarios would be?<br></blockquote>Unfortunately, no. I don't get much feedback on this except for created<br>issues that I referenced.<br>I wouldn't bring it up unless this wasn't a major version release, of<br>course.<br><br><blockquote type="cite">Below are bad ideas that I wrote down and then thought better of, but<br>I'll send them in case it sparks a thought.<br><br>I. Since there is already logic for dropping out of the batch for things<br>like cd, ls, could it be modified as follows?<br><br>a) Close any current batch and execute that batch.<br>b) Execute the cd, ls, etc<br>c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.<br><br>That seems like a better semantic for cd and ls anyway.<br></blockquote>I don't think so. The batch mode is also a composition/editing mode. cd<br>and ls are useful when writing commands/operations that should be added<br>to the batch. Imagine editing a batch and wishing to cd before entering<br>next lines. That won't be possible without explicit holback-batch, cd<br>and then batch again. That would be inconvenient.<br><br><blockquote type="cite">With that, reload and shutdown can be treated the same as cd, ls.<br></blockquote>For reload and shutdown that does seem to make sense. So, a possible<br>alternative is making them exceptions.<br><br><blockquote type="cite">Why a bad idea? Doing it as I suggest has the same two drawbacks as<br>requiring the user to declare the batch. :( Just perhaps less likely to<br>occur.<br><br>II. Is an --auto-batch=true|false param to if/else/try/catch/finally<br>possible? Why a bad idea? To solve the breakage problem it would need to<br>be 'true' by default, thus forcing users forever to declare that they<br>want the non-broken mode, *plus* they have to declare the batches.<br></blockquote>As a param to if/else/try/catch/finally this doesn't make sense to me.<br>Because then the user could simply explicitly start bodies with batch.<br>This kind of argument could make sense as a launching script argument<br>for the whole cli session, imo.<br><br>Thanks,<br>Alexey<br><br><blockquote type="cite"><br>On 9/3/15 10:42 AM, Alexey Loubyansky wrote:<br><blockquote type="cite">Hello everyone,<br><br>I've been thinking about changing how the bodies of if-else and<br>try-catch-finally are treated by the CLI.<br><br>Up until now every control flow block (i.e. between if and else, between<br>else and end-if, etc) was executed as a batch. So, when a block was<br>selected for the execution, the CLI would enter the batch mode and<br>proceed adding operations (and commands translated to operations) to it.<br>If a command can't be translated to an operation, it would be executed<br>outside the batch immediately (that's done for commands like cd, ls,<br>etc). After the last line of the body processed, the batch (if not<br>empty) is executed.<br><br>But this doesn't work when mixing operations with shutdown or reload<br>commands (they do translate to operations but they have additional logic<br>related to re-connecting). shutdown/reload will be executed outside the<br>batch and before the batch is complete.<br><br>Currently open issues for this<br><a href="https://issues.jboss.org/browse/WFCORE-876">https://issues.jboss.org/browse/WFCORE-876</a><br>https://issues.jboss.org/browse/WFCORE-533<br><br>So, I think it was a mistake to execute the bodies of control flow<br>blocks as batches. It would be better leave them as usual sequences of<br>command lines and if the user wants a batch, he/she could add batch<br>command explicitly.<br><br>I wanted to ask for opinions. Could we make this change in WildFly 10?<br><br>Thanks,<br>Alexey<br>_______________________________________________<br>wildfly-dev mailing list<br>wildfly-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/wildfly-dev<br><br></blockquote><br></blockquote>_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/wildfly-dev<br></blockquote><br>-- <br>Tom R. Fonteyne - SSME<br>Red Hat - UK<br>EMEA GSS SEG-Middleware<br><br>_______________________________________________<br>wildfly-dev mailing list<br><a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/wildfly-dev<br></blockquote></div><br></body></html>