tags:

views:

945

answers:

5

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?

+2  A: 

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.

jdewald
+1  A: 

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.

Yoni
A: 

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.

It would help to register an account (or keep your login cookies for longer) and add this information to the question. Also you should then clarify what *applet* is run on your *server*. This sounds like either a typo or a weird architecture unless you clarify.
Olaf
A: 

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?

Jack Leow
A: 

Ok let me explain this in detail. And the server and clients are not on the same machine. The tomcat server is run on one machine, the batch server is a separate machine and there are several client machines.

Tomcat Server: I added export DISPLAY=:0.0 in tomcat's startup.sh file. This removes the X11 Display error and the Headless Exception and my code works. Since tomcat is run in a separate instance, it is not affecting other applications running out of tomcat on that machine. Hence there is no side effects here.

Batch Server: I added export DISPLAY=:0.0 in batch server's batchstart.sh file. This also removes the X11 Display error and the Headless Exception and my code works. But here batchstart.sh file is sourced for the entire batch server. So all the other applications running on batch server use the settings of this file. All other applications are able to see the X11 Display except mine, which till java 1.4 was also working without any X11 Display error. The problem started only after I moved my app to java 1.5. When I set the export DISPLAY=:0.0 in batch server's batchstart.sh file, it overrides the existing Display that is being used by other applications and hence causes problems for the other applications running.

Any help highly appreciated.

I think we are going to need more details as to how the batch server is set up to be able to help. And I really do not understand how upgrading the JVM would cause this, are you sure nothing else changed?
Jack Leow