[英]Possible side effects when several CommandLine instance "work" on the same instance of an annotated class?
picoCLI's @-file mechanism is almost what I need, but not exactly. picoCLI 的@-file 机制几乎是我需要的,但不完全是。 The reason is that I want to control the exact location of additional files parsed -- depending on previous option values.
原因是我想控制解析的其他文件的确切位置——取决于以前的选项值。
Example: When called with the options srcfolder=/a/b optionfile=of.txt
, my program should see the additional options read from /a/b/of.txt
, but when called with srcfolder=../c optionfile=of.txt
, it should see those from ../c/of.txt
.示例:当使用选项
srcfolder=/a/b optionfile=of.txt
,我的程序应该看到从/a/b/of.txt
读取的附加选项,但是当使用srcfolder=../c optionfile=of.txt
,它应该看到来自../c/of.txt
的那些。
The @-file mechanism can't do that, because it expands ALL the option files (always relative to the current folder, if they're relative) prior to processing ANY option values. @-file 机制不能这样做,因为它会在处理任何选项值之前扩展所有选项文件(总是相对于当前文件夹,如果它们是相对的)。
So I'd like to have picoCLI...所以我想要picoCLI ......
optionfile
option,optionfile
文件, I might be able to solve this by recursively starting to parse from within the annotated setter method:我也许可以通过从带注释的 setter 方法中递归地开始解析来解决这个问题:
...
Config cfg = new Config();
CommandLine cmd = new CommandLine(cfg);
cmd.parseArgs(a);
...
public class Config {
@Option(names="srcfolder")
public void setSrcfolder(String path) {
this.srcfolder=path;
}
@Option(names="optionfile")
public void parseOptionFile(String pathAndName) {
// validate path, do some other housekeeping...
CommandLine cmd = new CommandLine(this /* same Config instance! */ );
cmd.parseArgs(new String[] { "@"+this.srcfolder + pathAndName });
}
...
This way several CommandLine
instances would call setter methods on the same Config
instance, recursively "interrupting" each other.这样,多个
CommandLine
实例将在同一个Config
实例上调用 setter 方法,从而递归地“中断”彼此。 Now comes the actual question: Is that a problem?现在是真正的问题:这是一个问题吗?
Of course my Config
class has state.当然,我的
Config
类有状态。 But do CommandLine
instances also have state that might get messed up if other CommandLine
instances also modify cfg
"in between options"?但是,如果其他
CommandLine
实例也“在选项之间”修改cfg
, CommandLine
实例是否也有可能会搞砸的状态?
Thanks for any insights!感谢您的任何见解!
Edited to add: I tried, and I'm getting an UnmatchedArgumentException
on the @-file option:编辑添加:我试过了,我在 @-file 选项上得到了
UnmatchedArgumentException
:
Exception in thread "main" picocli.CommandLine$UnmatchedArgumentException: Unmatched argument at index 0: '@/path/to/configfile'
at picocli.CommandLine$Interpreter.validateConstraints(CommandLine.java:13490)
...
So first I have to get around this: Obviously picoCLI doesn't expand the @-file option unless it's coming directly from the command line.所以首先我必须解决这个问题:显然 picoCLI 不会扩展 @-file 选项,除非它直接来自命令行。
I did get it to work: several CommandLine instance can indeed work on the same instance of an annotated class, without interfering with each other.我确实让它工作了:几个 CommandLine 实例确实可以在一个带注释的类的同一个实例上工作,而不会相互干扰。
There are some catches and I had to work around a strange picoCLI quirk, but that's not exactly part of an answer to this question, so I explain them in this other question .有一些问题,我不得不解决一个奇怪的 picoCLI 怪癖,但这不完全是这个问题的答案的一部分,所以我在另一个问题中解释了它们。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.