Incorrect default value #1733
Comments
|
I believe the problem is in the test. I believe the test below is clearer. The below test passes for me, clearing of command option values seems to work fine... import org.junit.Before;
import org.junit.Test;
import picocli.CommandLine;
import picocli.CommandLine.Option;
import static org.junit.Assert.*;
//@MicronautTest
public class PicocliBugTest {
// @Inject
// private ApplicationContext context;
private CommandLine cmd;
PicocliBugTest.Command userObject;
@Before
public void setUp() {
cmd = new CommandLine(PicocliBugTest.Command.class/*, new MicronautFactory(context)*/);
userObject = cmd.getCommand();
}
@Test
public void test1() {
cmd.execute("--option", "option");
assertEquals("option", userObject.option);
}
@Test
public void test2() {
cmd.execute();
assertEquals("Expected option to be reset to null", null, userObject.option);
assertNull("Expected option to be reset to null", userObject.option);
}
@CommandLine.Command(name = "command")
//@Singleton
static class Command implements Runnable {
@Option(names = "--option")
private String option;
@Override
public void run() {
System.out.printf("Option='%s'%n", option);
}
}
} |
|
Hello. Thank you for your answer! |
|
Okay that is interesting! That does sound like it may be a Micronaut issue, but I will try to find time to take a look. Can you do me a favor and post the output of running my test (after re-enabling the Micronaut logic) with system property |
|
|
Great, thank you! Meanwhile, as a workaround, can you try defining this option with |
|
Nope, this is doesn't help. |
|
The issue is related to the However, for each test, a different This test demonstrates without using Micronaut: // This test passes and prints:
// Option='option'
// Option='null'
@Test
public void testReuseBothCommandLineAndUserObject() {
Command myUserObject = new Command();
CommandLine cmdLine = new CommandLine(myUserObject);
cmdLine.execute("--option", "option");
cmdLine.execute();
assertEquals("Expected option to be reset to null", null, myUserObject.option);
assertNull("Expected option to be reset to null", myUserObject.option);
}
// This test fails and prints:
// Option='option'
// Option='option'
@Test
public void testReuseUserObjectWithDifferentCommandLine() {
Command myUserObject = new Command();
CommandLine cmdLine = new CommandLine(myUserObject);
cmdLine.execute("--option", "option"); // after this, myUserObject.option has value "option"
CommandLine cmdLine2 = new CommandLine(myUserObject); // current values of user object become the default value
cmdLine2.execute();
assertEquals("Expected option to be reset to null", null, myUserObject.option); // <-- this expectation fails
assertNull("Expected option to be reset to null", myUserObject.option);
}So, I believe this issue is an artifact of the test, not a real issue. Unless your application actually creates new |
|
@Pochatkin did this resolve the issue? |
|
@remkop There's another issue which is similar to this one but manifests itself in the picocli-shell-jline3 based interactive shell and can be seen in the picocli.shell.jline3.example.Example.java As I undestand, the CommandLine instance created in the main loop caches user objects. |
|
@valepakh oh interesting... It looks like that is a separate issue, that has to do with default values in argument groups. (I don't think it has to do with JLine, any app that reuses the CommandLine instance may encounter this.) I thought this was covered in the documentation, but you found a case that is not covered. Can you raise a separate ticket for this? |
|
Done #1768 |
The test provided shows that, under certain conditions, incorrect clearing of command option values occurs.
test2fails because aftertest1execution Picocli start providing--option optionas default value for next executions.The text was updated successfully, but these errors were encountered: