I am using Tomcat 5.5.23, JDK 1.5 on HP Unix. We have an application which when invoked form tomcat starts an applet. It was working fine till JDK 1.4. But now we have moved to JDK 1.5 and the applet does not start. The exception thrown is -
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
I then added JAVA_OPTS="-Djava.awt.headless=true" to catalina.sh file. But still I get the same Headless exception, but this time without the X11 Display message.
Any help would be appreciated.
Odd.. you're trying to run an applet (I assume you are talking about a subclass of java.awt.Applet) inside tomcat? Generally this won't work because there's no display on which to display the applet.
Assuming you don't want the applet to display anywhere and you just want to execute some portion of it programmatically, you may be able to get by using a virtual X server such as Xvfb or Xvnc. Once you have Xvfb or Xvnc running on your host running tomcat, you might try to set the DISPLAY inside the tomcat startup scripts to use the display of the virtual X server.
-Djava.awt.headless=false
add above in your Tomcat startup script. it will work 100%
You are maybe using something in your Java code that can not work on a headless system, such as graphics components (Swing objects, images, etc.). Some of these components, instead of being directly handled by Java, are handled by underlying platform (Windows kernel itself or X-Window server on Unix). This way the overall performance of application is boosted.
So the question now is, ok if it was working on Java 1.4, why doesn't it work on 1.5? My bet, given the peformance boost since Java 1.2 that Swing has received over time, is that Sun has moved the management of some graphic objets to OS level to increase performance. So if you can not stick to 1.4, then you should revise your code.
This good article will help you understand how to modify your application to make it headless-friendly.
Applets are going to have a hard-time running server-side. They are designed to run inside of a container, such as a web browser. The exception is getting thrown most likely because the applet is trying to draw it's GUI -- and the server is providing no support for this. I'm surprised that it worked in JDK 1.4 -- I don't know what changed between the two revisions which would have affected this.
You may also have to install the x11 libraries, or at least explicitly export the path to them.
/usr/X11R6/lib
Open $CATALINA_HOME/bin/startup.sh file with your preferred text browser
Paste this line export CATALINA_OPTS="$CATALINA_OPTS -Djava.awt.headless=false" at the beginning of the file
Save and close the file
Restart Tomcat
In spring boot with database access, when you specify asterisks: **** as username and password, it will try to prompt the user for a username and password (you read that right), and it will throw this HeadlessException if it's not a gui application.
Related
In general, browsers (I see this esp. with Safari) are kind enough to inhibit a Java applet from running if it senses that a security related update for Java exists. It seems to do this quietly... my applet just "sits-and-spins" in the browser window - never executes. Is there a way, preferably via JavaScript, to programmatically determine whether or not this condition will exist (so that, for example, applet loading can be skipped and some kind of informational message can be displayed)?
In my particular case, my applet quietly did nothing when launched with Java 1.6.0_37 (on Mac OSX 10.6, Safari 5.1.7). As soon as I updated to Java 1.6.0_43, the applet ran without incident.
The best approach is generally to poll for the existence of the applet using Javascript, and take alternate action after a specific time.
Note that the Deployment Toolkit Script is intended to ensure a valid Java version and run the applet while providing feed-back to the user, so it would be a better overall approach to deploying the applet.
I've written module that generates excel, and deployed it under Servicemix. In Windows environment everything is fine, but under Linux Servicemix unexpectedly crashes on following call:
for (short i=0;i<=3;i++) {
log.trace("AutoSize column {}", i);
worksheet.autoSizeColumn(i);
}
I'm using POI version 4.2-FINAL, FuseESB 4.2, Java 5.0. There are, however, no hs_err*.pid files. Servicemix logs ends on first autoSizeColumn call.
Did anyone met such behaviour and know, how it is caused and how to come this around?
In order to be able to calculate the column widths, POI needs to get hold of the Font in use, and ask it to size each character in turn. On all JVMs that I know of, this requires a graphical environment, because the actual work is delegated by the JVM to the underlying graphical system.
If you're on Windows, you always have a graphical system so that's fine. On Linux, if you're running on the command line on a server, you may not. (Linux as a desktop is fine though)
If you are running on a linux server without an X server running, you'll need to tell Java to run "headless". As taken from the POI AutoSize documentation
To calculate column width Sheet.autoSizeColumn uses Java2D classes that throw exception if graphical environment is not available. In case if graphical environment is not available, you must tell Java that you are running in headless mode and set the following system property:
java.awt.headless=true
Try setting that when you start your JVM, and I've a hunch it'll fix your issue (which is most likely caused by Java not finding a complete graphical environment)
We haven't tested it as it's not released yet, but since POI 5.2.3 there's a boolean system property that could help: org.apache.poi.ss.ignoreMissingFontSystem
Instructs Apache POI to ignore some errors due to missing fonts and
thus allows to perform more functionality even when no fonts are
installed. Note: Some functionality will still not be possible as it
cannot use default-values, e.g. rendering slides, drawing, ...
Hi I faced a similar problem. I didn't have any crash, but on my development environment (Windows) the autosizecolumn worked. On production environment (Unix-like) it didn't work. I put system property java.awt.headless=true but I had the problem still. I solved following this solution but I added all the Arial Family fonts. Hope it helps anyone.
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.
I have a Java program using AWT which I would like to run on a headless system. The display for the program does nothing other than display stats. When the program finishes, it exits. There is no user interaction on the display. The program creates an output file which I use in my build system.
Is there a way to get the Java program to run without an X11 display configured? Can I force Java to run the program without trying to display anything? I do not have access to the source code (it is just .jar file), so I can't make modifications to the source.
Any thoughts on how I could get this to work?
The underlying question here is how to run Java applications without an X server; providing a "fake" X server is only one option. In Java 1.4 and up, you can do the following:
java -Djava.awt.headless=true
This allows applications which use AWT to run on headless systems even without an X server.
Xvfb can do what you ask for. I've not used it myself, but here is a link to wikipedia: http://en.wikipedia.org/wiki/Xvfb
You can use a vncserver.
vncserver :1001
export DISPLAY=localhost:1001
java..
The added advantages is that you can actually view the gui
using vncserver 'just in case'
Could also run Xvnc in a low resolution and color depth.
As mentioned by Charles Duffy the traditional method is to tell Java to go headless.
Note that you can always mount the jar in Eclipse and use jad+jadclipse to see what it actually does, and perhaps even override a class if you need to by putting another class-file in "front" of it in the classpath.
A facility that might be relevant if the program uses Java2D is that newer Java versions use optimizations in the X11 server to render faster. This alone might be a reason to devote an X11 server attached to a high performance graphics card to your graphics processing.
I've used with great success in the past the PJA libraries, they don't seem to be maintained anymore, but then again, just just want to run...
I was able to get headless mode in OpenJFX with the command line arguments
-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw
We are required to add export DISPLAY=:0.0 in tomcat's startup file and batch server's startup file. This is to make java see the X11 Display libraries on Unix and run our applet. Without this export in the startup files, the applet throws a Headless Exception.
Though this explicit export makes the java applet run, it disrupts the other applications running on the server. Is there a way where I can make this export DISPLAY=:0.0 run from within java code instead of adding it to startup files? And if it is possible, would that be a good approach?
I have already tried setting the system property to -Djava.awt.headless=true , but it didn't work. As the link given above http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ also says that setting headless=true would work only for few components like Canvas, Panel but it will not work for the top level components.
So I feel the only option left for me is using export DISPLAY=:0.0. This is making my applet work when set in the startup files but causes problem for other applications running in the server. So if anybody could help me to make export DISPLAY=:0.0 work such that it doesn't interfere with other applications in the server. One way I thought was to export the display through code.
Any help would be highly appreciated.
I believe you can actually set the system property -Djava.awt.headless=true which will allow access to the graphic libraries without actually needing a display.
See http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ for more info.
From your question it seems that there is something seriously wrong with your configuration.
Tomcat should always be able to run server-side without a display.
Applets always run in browser and get the x11 environment from the browser. The applet's jar could be served by tomcat, or apache, or something else, but that's irrelevant.
If your applets communicate with the server, make sure that the server code is completely separate from your applet code (keep them in separate projects) and that it doesn't use any awt code. If it does (for image manipulation, etc.), then use -Djava.awt.headless as jdewald said.
How is this affecting other applications? How are you defining the environment variable in your start up scripts? If you're defining the variable correctly, it should only affect programs started by your start up script, i.e., Tomcat and the batch server.
Also, your original question doesn't really add up. Are you running both the server and client (Tomcat and the web browser) on the same machine?