In my experience, the "headless" suggestion works fine when running Tomcat6 where apps make use underlying graphics functionality and end up accidentally creating an X display. You have to make sure java gets the option before it attempts to open any displays -- which might happen well before the creation of any UI widgetry, solely for the purpose of picking up Xresources in preparation for any graphics operations you might later invoke (e.g. to get the display's dots-per-inch in order to select fonts and scaling).
To prevent that from happening, you must give the headless directive on the Java command-line: "-Djava.awt.headless=true" ? For example this is what I use to launch tomcat on fedora12, where I employ underlying Java graphics functionality for image processing: JAVA_OPTS="-server -Xms160m -Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintCompilation -XX:+PrintGCDetails -XX:+TraceClassLoading -XX:+TraceClassUnloading -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/usr/lib64" http://java.sun.com/products/java-media/2D/reference/faqs/index.html Q: I have an application that reads, writes, and processes images (but does not display them) using Java2D. When I run my application on Solaris or Linux, it complains that X11 is not available. What can I do to make my application work in this environment?A: When AWT is initialized, it expects to find an Xserver, regardless of whether it is needed for actual display. Although many image operations using the Image I/O APIs or the JAI optional package might not have any obvious need for display, they often invoke code that needs an AWT resource. For example, calling getGraphics() on a BufferedImage initializes AWT and causes these error messages seen by developers. There is no way to say that a particular API does or does not have this problem; it depends on what particular operations are being invoked, and might also depend on what the application does with the images that is not strictly related to any of the APIs cited above. There are two possible solutions. As of J2SE 1.4 (and above), the preferred solution is to use the "headless AWT toolkit". This feature allows you to use the Java2D API in a server-side application without the need for a display environment. To specify the headless environment, run your application with the following system property: -Djava.awt.headless=true Niels http://nielsmayer.com PS: of course, when Java is run headless, you might find some very wacky values for dots-per-inch, other unexpected initial values which can cause your image processing routines to work incorrectly. That might be an aspect of "doesn't work" in your situation. Ultimately, to produce correct results, one would need to get the DPI of each web-user's display and dynamically compute image scaling per connection. This is unfortunately never done, and is going to be more and more of a problem as we go from tiny portable displays to huge widescreens. Q: Why does (eg) a 10 pt font in Java applications appear to have a different size from the same font at 10pt in a native application? A: Conversion from the size in points into device pixels depends on device resolution as reported by the platform APIs. Java 2D defaults to assuming 72 dpi. Platform defaults vary. Mac OS also uses 72 dpi. Linux desktops based on GTK (Gnome) or Qt (KDE) typically default to 96 dpi and let the end-user customise what they want to use. Windows defaults to 96 dpi (VGA resolution) and also offers 120 dpi (large fonts size) and lets users further specify a custom resolution. So a couple of things can now be seen - The DPI reported by platform APIs likely has no correspondence to the true DPI of the display device - Its unlikely that Java 2D's default matches the platform default. So a typical results is that for Window's default 96 DPI that a 10 pt font in a Java application is 72/96 of the size of the native counterpart. Note that Swing's Windows and GTK L&Fs do scale fonts based on the system DPI to match the desktop. If you want to do the same in your application you can call java.awt.Toolkit.getScreenResolution() and use this to apply a simple scale to the size you specify for fonts. On Mon, Dec 14, 2009 at 9:25 AM, Albert Cardona <sapri...@gmail.com> wrote: > > There's a system property (since jdk 1.4) named java.awt.headless > > (http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless) > > that allows using AWT classes in server setting. > > In my experience, the java.awt.headless property doesn't work. > I have not tried since a late 1.5; perhaps 1.6 has it fixed. > I have only successfully used java.awt.headless property with java 1.4.2. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
