I have a script file which executes the java program like:
java -Dlog.file=/path -Dappname=name -DAsyncLogger.RingBufferSize=200000 -jar /path/main.jar -f /path/testfile -day 20211108 -p /path/test.properties
-D I understand puts the key-value pair into system properties,
I am unsure what these other -f, -day, -p do.
Code:
public class Mainprogram extends PPS{
#Parameter(names={"-f", "-fileToRep1ay'}, description = "sample", required=true)
protected static String fileToReplay;
public MainProgram(Logger logger) { super(logger);}
public static void main(string[] args) throws Exception {
new MainProgram(LoggerFactory.getLogger(MainProgram.class))
.withArgs(args)
.start(new DispatcherModuIe() ,
new SessionManagerModuIe() ,
new FixHarnessModUIe(fiLeToReplay,
currentBusinessDay)) ;
When you call java, all options after the class name or -jar <jarfile> are passed as-is to the public static void main(String[] args) method. In this case, the main method of this JAR will receive the array {"-f", "/path/testfile", "-day", "20211108", "-p", "/path/test.properties"}.
What they mean and how they are interpreted is application specific, so your question cannot be answered in general.
That said, based on the context, I guess -f specifies a file (possibly input, possibly output), -day specifies a date in ISO-8601 format without dashes, and -p specifies a properties file (e.g. configuration or something like that).
And as mentioned in the comments by g00se, most professionally developed applications will provide an explanation of the options by running it with -h and/or --help.
I agree with Schokokuchen Bäcker, the options could mean anything. If it helps though, from your description, I would say:
-f - path to test file
-day - date (ISO-8859-1 format sans dashes)
-p - path to properties file
Related
I'm trying to parse my command line arguments using the apache commons CLI. It might be a bit heavy handed for the example here, but it makes sense in the context of the program I'm creating. I'm trying to read a file pattern filter, similar to what grep uses to select files to process.
My Argument looks like this:
Program --input *.*
I've written a test program to see what the parser is seeing;
public static void main(String[] args) {
Options options = new Options();
options.addOption(new Option(INPUT_FILTER_SHORT, INPUT_FILTER_LONG, true, INPUT_FILTER_DESCRIPTION));
CommandLineParser parser = new BasicParser();
CommandLine cmd = parser.parse(options, args);
System.out.println(cmd.getOptionValue(INPUT_FILTER_SHORT));
}
This prints out:
.classpath
If I change my arguments to:
Program --input test.txt
I get the output:
test.txt
I'm assuming that I have to do something to tell apache commons what * is not a special character? I can't seem to find anything about this online.
I'm experiencing this on Windows (7). I'm fairly certain it's the *.* which is causing the issue as when I swap to using patterns that don't use *, the expected pattern shows up.
Your problem isn't really to do with Commons CLI, but to do with how the shell and the Java executable together process the parameters.
To eliminate other factors, and see what's going on, use a short Java program:
public class ArgsDemo {
public static void main(String[] args) {
for(int i=0; i<args.length; i++) {
System.out.println("" + i + ": " + args[i]);
}
}
}
Play with java ArgsDemo hello world, java ArgsDemo * etc. and observe what happens.
On UNIX and Linux:
Java does no special processing of *. However, the shell does. So if you did:
$ mkdir x
$ cd x
$ touch a b
$ java -jar myjar.jar MyClass *
... then MyClass.main() would be invoked with the parameter array ["a","b"] -- because the UNIX shell expands * to files in the current directory.
You can suppress this by escaping:
$ java -jar myjar MyClass * // main() sees ["*"])
(Note that a UNIX shell wouldn't expand *.* to .classpath because this form would ignore "hidden" files starting with .)
On Windows
cmd.exe does not do UNIX-style wildcard expansion. If you supply * as a parameter to a command in Windows, the command gets a literal *. So for example, PKUNZIP *.zip passes *.zip to PKUNZIP.EXE, and it's up to that program to expand the wildcard if it wants to.
Since some release of Java 7, the Java executable for Windows does some wildcard to filename expansion of its own, before passing the parameters to your main() class.
I've not been able to find clear documentation of Java-for-Windows' wildcard expansion rules, but you should be able to control it with quoting, escaping the quotes to prevent cmd.exe interpreting them:
> java.exe -jar myjar.jar MyClass """*.*"""
(Untested as I don't have a Windows box handy, and quoting in cmd.exe is a bit of a beast - do please experiment and either edit the above or leave a comment)
I am wondering if there's a way to create a jar that includes some command line arguments in it, the arguments that are usually passed in the command line when one tries to start up the jar (these parameters are then passed on to the main function). Basically instead of starting my app with
java -jar myapp.jar "arg1" "arg2", I want to start my app with
java -jar myapp.jar
and have "arg1" and "arg2" passed to the main function.
The reason behind this is that I want to deploy this to different environments, and I want my jar to contain different parameters according to the environment it's being deployed at.
Maybe there's another way to achieve similar results ??
Cheers.
PS: Looking for a maven solution.
Edit: I'll add a complete example to make this a bit more clear:
Let's say I have 2 environments: "Production" and "Test". I want to run the jar in the same way no matter in what environment I deploy it. So I always want to run it with:
java -jar myapp.jar
But! In order for my 2 environments to run ok, I need the Production environment jar to start it's main method with an argument "prod" and I need the Test environment jar to start it's main method with an argument "test".
If I correctly understood your problem, in your main() you could define a simple logic to handle the case where you do not specify any input parameter; the logic could retrieve the desired values according to the correct platform/env.
As an example:
public class Test01
{
public static void main(String... aaa)
{
// Check input
if(aaa.length == 0) {
/* Insert logic to retrieve the value you want, depending on the platform/environment.
* A trivial example could be: */
aaa = new String[2];
aaa[0] = "First value";
aaa[1] = "Second value";
}
// Processing, e.g. print the 2 input values
System.out.println(aaa[0] + ", " + aaa[1]);
}
}
Fyi, I created a runnable jar using eclipse, and start the application by either
java -jar Test01.jar
or
java -jar Test01.jar arg1 arg2
Hope this helps!
One solution is to change main(String[] args) to get values from env var if they are not present in the passed arguments.
String user;
String password;
if(args.length < 2)
{
user = System.getenv("appUser");
password = System.getenv("appPassword");
} else {
user = args[0];
password = args[1];
}
You can also create another class with a main function that will call the real one.
public class CallerMyApp{
public void main(String[] args) {
String[] realArgs = {System.getenv("appUser"), System.getenv("appPassword")};
MyApp.main(realArgs);
}
}
Then to execute its something like
java -cp myapp.jar CallerMyApp
I am trying to find the way to run the explain command over the entire pig script in java.
I was using PigServer but it offers only to do explain over the single query (alias) not the entire script.
Is there a way to do something like:
$ pig -x local -e 'explain -script Temp1/TPC_test.pig -out explain-out9.txt'
but from my Java code?
You may use PigRunner for this purpose.
E.g:
import org.apache.pig.PigRunner;
import org.apache.pig.tools.pigstats.PigStats;
public class PigTest {
public static void main(String[] args) throws Exception {
args = new String [] {
"-x", "local",
"-e", "explain -script Temp1/TPC_test.pig -out explain-out9.txt"
};
PigStats stats = PigRunner.run(args, null);
//print plan:
//stats.getJobGraph().explain(System.out, "text", true);
}
}
I found that the following runtime dependencies are needed to avoid NoClassDefFoundError:
jackson-mapper-asl
antlr-runtime
guava
You can use org.apache.pig.PigServer to run pig scripts from Java programs:
PigServer pigServer = new PigServer(ExecType.MAPREDUCE);
pigServer.registerScript("scripts/test.pig");
Requires 'pig.properties' on classpath.
fs.default.name=hdfs://<namenode-hostname>:<port>
mapred.job.tracker=<jobtracker-hostname>:<port>
Or pass an instance of java.util.Properties to PigServer constructor.
Properties props = new Properties();
props.setProperty("fs.default.name", "hdfs://<namenode-hostname>:<port>");
props.setProperty("mapred.job.tracker", "<jobtracker-hostname>:<port>");
PigServer pigServer = new PigServer(ExecType.MAPREDUCE, props);
Hope this helps
Of course you can also use the grunt shell! (I always forget about this.)
On our site, we're using a launcher script which prepares a pig invocation command like follows:
$ pig -p param1=foo -p param2=bar script.pig
You can use explain -script in the grunt shell:
invoke pig
wrap the script call with explain
It looks like:
$ pig
grunt> explain -param param1=foo -param param2=bar script.pig
This question already has answers here:
How do I pass parameters to a jar file at the time of execution?
(5 answers)
Closed 5 years ago.
I built a runnable JAR from an Eclipse project that processes a given XML file and extracts the plain text. However, this version requires that the file be hard-coded in the code.
Is there a way to do something like this
java -jar wiki2txt enwiki-20111007-pages-articles.xml
and have the jar execute on the xml file?
I've done some looking around, and all the examples given have to do with compiling the JAR on the command line, and none deal with passing in arguments.
Why not ?
Just modify your Main-Class to receive arguments and act upon the argument.
public class wiki2txt {
public static void main(String[] args) {
String fileName = args[0];
// Use FileInputStream, BufferedReader etc here.
}
}
Specify the full path in the commandline.
java -jar wiki2txt /home/bla/enwiki-....xml
You can also set a Java property, i.e. environment variable, on the command line and easily use it anywhere in your code.
The command line would be done this way:
c:/> java -jar -Dmyvar=enwiki-20111007-pages-articles.xml wiki2txt
and the java code accesses the value like this:
String context = System.getProperty("myvar");
See this question about argument passing in Java.
You can pass program arguments on the command line and get them in your Java app like this:
public static void main(String[] args) {
String pathToXml = args[0];
....
}
Alternatively you pass a system property by changing the command line to:
java -Dpath-to-xml=enwiki-20111007-pages-articles.xml -jar wiki2txt
and your main class to:
public static void main(String[] args) {
String pathToXml = System.getProperty("path-to-xml");
....
}
When you run your application this way, the java excecutable read the MANIFEST inside your jar and find the main class you defined. In this class you have a static method called main. In this method you may use the command line arguments.
In our application, we are allowing users to open files and directories.
Java 6 provides us with...
java.awt.Desktop.getDesktop().open(file);
which works great. However, since we need to ensure Java 5 compatibility, we also implement a method of opening files by calling the start command in cmd.exe...
String command = "cmd.exe start ...";
Runtime.getRuntime().exec(command);
This is where the problem shows up. It seems that the start command can only handle 8.3 file names, which means that any non-short (8.3) file/directory names cause the start command to fail.
Is there an easy way to generate these short names? Or any other workarounds?
Try something like this
import java.io.IOException;
class StartExcel {
public static void main(String args[])
throws IOException
{
String fileName = "c:\\temp\\xls\\test2.xls";
String[] commands = {"cmd", "/c", "start", "\"DummyTitle\"",fileName};
Runtime.getRuntime().exec(commands);
}
}
It's important to pass a dummy title to the Windows start command where there is a possibility that the filename contains a space. It's a feature.
Try this: http://dolf.trieschnigg.nl/eightpointthree/eightpointthree.html
Or you could try:
Runtime.getRuntime().exec(
new String[] { System.getenv("windir") + "\\system32\\rundll32.exe",
"shell32.dll,ShellExec_RunDLL", "http://www.stackoverflow.com" });
Source: http://www.rgagnon.com/javadetails/java-0014.html