Synopsis: When calling an executable that links to shared libraries from Java code on Tomcat, I get errors on Windows 2003 whereas the executable works great on a command prompt.
I wanted to do this in Linux, but, alas, got outvoted and have to implement it using Windows Server 2003. Here it goes,
I have a simple Java code running on Tomcat which, when it receives a "start" signal from another server has to run an external executable (written in C++, using shared library DLLs from OpenCV and ffmpeg) like so
String cmd = "c:\\workspace\\process_video.exe -video " + filename;
// Execute the command
Process proc = null;
try {
proc = rt.exec(cmd);
} catch (Exception e) {
System.out.println("VA-> Exception thrown in running the command!");
errorOut.append(e.getStackTrace().toString());
}
Now, when I run the command in process_video from a DOS command prompt, it works (doesn't matter which directory it's issued from). However, when it is run through the Tomcat->my Java code->rt.exec() chain, cmd doesn't get executed, although the exception doesn't get thrown. When I examine Windows event logs, I see an APPCHRASH event for process_video with Fault Module Name cv110.dll, which is one of the OpenCV DLLs I link from cmd.
One solution would be to stuff all the DLLs used in process_video into the tomcat\lib directory, but this hurts my programmatic sensibilities, so I want to know if there is a better way to solve this issue. What user does Tomcat use when running executables on Windows? Maybe I can give more privileges to that user? Should I add the DLL paths to Tomcat's configuration file?
Any help will be much appreciated,
Thanks!
Cuneyt
Add an entry in the PATH evironment variable that points to where your DLLs are. If this doesn't work for your app, you can try adding the entry to Tomcat's PATH. You have to modify the PATH variable of the process that will be loading the executable. Since your Java code probably shares a JVM (and hence a process) with the Tomcat executable, that will dictate which environment the PATH variable will need to be updated.
This is a Windows problem, not a Tomcat problem.
By default, Windows looks in %Path% for DLLs, which may not include the directory of the EXE file.
You can fix this by creating an empty file called process_video.exe.local in the same direcotry as the EXE ( i.e. c:\workspace )
You can also create a .manifest file, but this is a bit more complicated.
Related
I have a program where I actively ping the contents of a directory using nio.WatchService.
Anytime a new file is added there, I process some custom logic. The path to the folder is read from a properties file and has the following format:
pathvar=C:\\files\\in\\ -->works on local
pathvar=\\\\serv123\\Share\\input\\ --> works on local
Both formats run fine on win 7 local (command line and through IDE). When
executed on a win 2008 R2 server, the program executes when path variable is local - no (mapped) network paths work.
pathvar=C:\\\\files\\in\\ -->works
pathvar=\\\\serv123\\Share\\input\\ --> does not work
pathvar=N:\\Share\\input\\ --> N: mapped to serv123 does not work
Code is same as listed here:Watching a Directory for Changes in Java
I don't get any exceptions either, but UNC paths are not working. Any help is appreciated.
Edit: The way I deducted the issue was path related(in absence of any exceptions), is by playing around with the paths.
I packaged it as a jar and run it on the command window as
java -jar myjar.jar
With pathvar=C:\files\in\, the programs runs and waits
With pathvar=\\server\files\in\, it quits immediately/
I'm trying to run a simple program to test Java RMI but when I type rmiregistry 6000 into the command window I get the following message.
'rmiregistry' is not recognized as an internal or external command,
operable program or batch file.
I'm probably doing something stupid but I can't find RMI registry anywhere on the computer. Can someone tell me where to find it or how I can download it? I'm using windows 7 and java is up to date.
You are apparently using Windows. The (each) "standard" Oracle JRE installer for Windows puts everything in a subtree that you can override but defaults to **\Program Files\Java\jre<n> or Program Files (x86) for 32-bit java on 64-bit Windows, and copies a few EXEs java.exe javaw.exe javaws.exe and a few DLLs from the jre\bin subdirectory to \windows\system32 which is conventionally in your PATH because that's where lots and lots of other Windows programs are. The installer does NOT copy other programs like rmiregistry unpack200 keytool etc., so for those you need to either add the wherever\jre\bin directory to your PATH or explicitly specify the full pathname for the program. Or copy them to \windows\system32 yourself, but then you have to remember to remove or update them whenever your Java changes (which could occur automatically if you allow Java to auto-update).
The installer does also make some registry settings so you can uninstall from appwiz (like other wellbehaved Windows programs) and the Java control panel appears like other control panels and the auto-updater does its thing unless you disable it, and some settings (I'm not sure if these are registry or elsewhere) so browsers like IE and Firefox can automatically run Java applets.
I'm trying to run a sample app in Tomcat. I've installed tomcat, set up the environment variable by creating a new system variable called JAVA_HOME which is set to C:\Program Files\Java\jdk1.6.0_20. And I've created a new dir for the web app in the tomcat program directory. In the cmd prompt I navigate to the tomcat program directory and type in bin/startup.sh and I get the following error: 'bin' is not recognized as an internal or external command, operable program, or batch file.
I'm using tomcat 6.0 and I'm on a windows machine. What could the problem?
On Windows you must run the startup.bat file instead of the startup.sh file (note the extension is different).
Also, enter the bin directory before executing the bat script.
cd bin
startup.bat
Your on windows try:
bin\startup.bat
If you try typing in bin\startup.bat on a Windows machine and still get the same error, there's a possibility that Windows is not seeing the batch script where it should be. As a-horse-with-no-name already said, try installing Tomcat to a location where there are no spaces in the path. In your case, anywhere other than Program Files.
EDIT: To resolve this space issue, you can do two things: 1) Install JDK/JRE to a common location without spaces (say, C:\Java) and set it to be JAVA_HOME environment variable. 2) Install Tomcat to another location (say, C:\Tomcat) and proceed from there. Since these are all in common location, I believe you can do this as a limited account user without needing admin privileges.
Try to install Tomcat (and possibly the JDK) into a directory without spaces.
The script you ran is intended for *nix systems. Try bin\startup.bat
I'm a little confused by some of the answers. First, the error you are receiving is from Windows. Nothing to do with Tomcat. The Windows OS thinks you have entered a command, and doesn't recognize it. Files with the .bat extension are always recognized by Windows as Batch file commands....... soooo..... Navigate to the bin directory, again, under your tomcat installation. Then....
Don't append the bin in front of the command. You should do a quick look to make sure that the "startup.bat" file is here (dir *.bat). Then just type "startup.bat".
Seems like I just type "catalina.bat start" (for my tomcat catalina installation)
From Java, I'm extracting an executable into a location specified using File.createTempFile(). When I try to run my executable, my program hangs when it tries to read the first line of output.
I have discovered that if I try to run the same extracted executable from another program, it works if I specify the directory as C:\Documents and Settings\username\Local Settings\Temp\prog.exe. But if I specify the directory as C:\DOCUME~1\USERNA~1\LOCALS~1\Temp\prog.exe I get the hang.
Is there a way to unmangle the tilde filename in my program so I can specify a directory name that will work?
(And since I always like addressing the language and API design issues, is there any reason why Java File.createTempFile() and java.io.tmpdir have to evaluate to mangled filenames?)
You can use getCanonicalPath() to get the expanded path. E.g.:
try
{
File file = File.createTempFile("abc", null);
System.out.println(file.getPath());
System.out.println(file.getCanonicalPath());
}
catch (IOException e) {}
... produces ...
C:\DOCUME~1\USERNA~1\LOCALS~1\Temp\abc49634.tmp
C:\Documents and Settings\username\Local Settings\Temp\abc49634.tmp
I tested this on XP, but assume it would work similarly on other Windows operating systems.
See #raviaw's answer to your second question.
Wow, I never saw that. The fact is that the environment variable %TEMP% returns a mangled name (this is from my computer):
TEMP=C:\DOCUME~1\raviw\LOCALS~1\Temp
TMP=C:\DOCUME~1\raviw\LOCALS~1\Temp
Assuming that a newly create java VM uses the environment variable to get the temporary folder location, it is not VM's fault that the directories are coming mangled.
And even if you try to use System.getenv() to get the temporary folder, you will still have the same problem.
I would make sure that:
The problem is not caused by the fact that you have a directory called "prog.exe" (based on your question, I am assuming this);
If the file is "prog.exe", if it was not in use by any other program (an antivirus, maybe);
Checking if your computer is sane (this would be a very critical bug for any application that is not a web application and that need temporary files).
I have written a Java GUI app (using Netbeans 6.7) requiring Java 1.6. I successfully run it on my XP PC and also my Mac OSX (10.5.7).
My client is running Vista Business, and cannot run the application by double clicking the jar file. He can execute it from the command line: "javaw -jar ..." The error received is: "Cannot find the main class... Program will exit".
I've asked the client to do the following:
install the latest JRE
run JarFix
I've verified that:
JRE is installed in correct location
jar file association is correct
application works (as I have tested it on XP and Mac OSX, and the client can run it from the command line)
Any ideas on what else I can investigate? Note, Netbeans created the main jar file, and also a lib directory with a couple of other Jarfiles. I've unzipped the jarfile and examined the manifest file (which looks good). The correct main class is also within the app's jarfile.
Does the client need to be careful as to where the application is executed from in Vista?
Thanks very much.
Prembo
Does exactly the same JAR file work on other operating systems?
Is the manifest file (META-INF/MANIFEST.MF) in the JAR file correct? One catch to watch out for is that the manifest file MUST end with an empty line; if it doesn't, the last line in the manifest file will be ignored. So, for example, if the last line in your manifest file is something like this:
Main-Class: com.mypackage.MyProgram
and it is not followed by an empty line, then Java will ignore the line and it will not be able to find the main class of the program.
See Sun's Java Tutorial about deploying Java programs in JAR files for exact details about how to package your application in a JAR; it also contains the warning about the manifest file needing to end with an empty line.
Also, double-check if the right version of Java is used. Are you using the exact same version of Java as on Windows XP? Try:
java -version
to see which Java version is being used.
I'm running Vista Enterprise and have very little differences between it and other Windows versions (with regards to Java).
Here are some random ideas that may or may not work:
Have you tried: right clicking on the Jar -> Open with -> Java(TM) Platform SE Binary
Could it be permissions related? (probably not since it runs via the command line)
Have you tried it with UAC off? (UAC sandboxes java apps, and they can't write to certain locations like Program Files)
Did you make sure they have the same files as you in JAVA_HOME/lib/ext/
you could try setting environment variables:
JAVA_HOME=<your_java_home>
CLASSPATH=.
PATH=<your_java_home>\bin
Sometimes JDK needs to be installed separately,along with the net beans IDE. If you have jdk installed then you can try checking for classpath,path in the environmental variables.