Problem getting graphics environment

[aevett]

Our customer is getting the following NoClassDefFoundError on Solaris 5.9 and JRE 1.4:

java.lang.NoClassDefFoundError
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Unknown Source)
       at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Unknown Source)
       at com.creamtec.ajaxswing.gui.AjaxSwingToolkit.<init>(AjaxSwingToolkit.java:150)
       at com.creamtec.ajaxswing.gui.AjaxSwingToolkit130.<init>(AjaxSwingToolkit130.java:29)
       at com.creamtec.ajaxswing.gui.AjaxSwingToolkit142.<init>(AjaxSwingToolkit142.java:21)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
       at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
       at java.lang.reflect.Constructor.newInstance(Unknown Source)
       at java.lang.Class.newInstance0(Unknown Source)
       at java.lang.Class.newInstance(Unknown Source)
       at java.awt.Toolkit$2.run(Unknown Source)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.awt.Toolkit.getDefaultToolkit(Unknown Source)
       at javax.swing.ImageIcon.<init>(Unknown Source)
       at javax.swing.ImageIcon.<init>(Unknown Source)
       at com.cleo.lexicom.LexiCom.setLookAndFeel(LexiCom.java:1360)
       at com.cleo.lexicom.LexiCom.init(LexiCom.java:448)
       ...

They originally were on JRE 1.5 and we had them downgrade to JRE 1.4 as they are unwilling to install Xvfb and our past experience has shown that JRE 1.4 does not require Xvfb.  We have had them toggle agent.usePlatformGraphicsEnvironment, but the same NoClassDefFoundError results whether this setting is on or off.

[Support Team]

Is it possible to get all log files entirely?

So that we know versions and configuration settings such as the value of java.awt.graphicsenv.

Important thing to know would be what version of JDK 1.4 are they using? AjaxSwing 2.4.0 is built again 1.4.2_13.

Is it AjaxSwing 2.4.0 Beta2?

You said they were on 1.5 - what version of AjaxSwing? Were they able to run on 1.5 without Xvfb?

If they have X running on their server they can configure the DISPLAY variable in AjaxSwing/bin/setEnv.sh and as long as the process is allowed to connect to X they wouldn't need to run Xvfb.

[aevett]

This is AjaxSwing 2.2 and JRE 1.4.2_18.  They do not have an X11 server.

I'll get the log files.

[aevett]

It appears this problem has been resolved by toggling agent.usePlatformGraphicsEnvironment.  Our customer just wasn't toggling it correctly before.

But this general problem with our customers not wanting to install Xvfb and/or having issues finding the right setting for the various graphics/fonts options is our biggest issue with AjaxSwing.  If you could please shed more light on why Xvfb became a requirement with Sun's JRE 1.5, that would be helpful.  We are trying to decide if we should just ship and install Xvfb along with our application.

[Support Team]

Short Answer:
shipping and installing Xvfb is probably the best solution for UNIX.


Long Answer:
As you know, AjaxSwing simulates graphics environment for Swing applications. Generally speaking, running Swing requires a graphics environment to be available to JVM. On Windows that environment is always available. On UNIX it is typically unavailable, either because it is not installed, or because the permissions are not given to JVMs for connection to X.

Earlier versions of AjaxSwing substituted a lot of JVM classes to emulate running graphical applications in a non-graphical environment. The problem with that is that the more internal classes were substituted (for instance FontConfiguration), the more potential failure points were created, because of the assumptions throughout JVM implementation about the consistency of internal classes (for example, classes in UNIX version of JDK would assume that graphics environment is sun.awt.X11GraphicsEnvironment and they would cast the local graphics environment to that class. Or, even worse, native calls would fail and JVM may crash entirely (you may remember those problems with WebCream).

The cleanest solution was to retain as many internal classes as possible, which is what agent.usePlatformGraphicsEnvironment and some other settings control. On UNIX this would mean that the JVM needs to be able to connect to X server. The cleanest approach is to run Xvfb because that way AjaxSwing applications do not interfere with anything else on the system. Another alternative is to set DISPLAY variable correctly and give JVM permission to connect to X, in which case Xvfb is not a requirement.

Since every platform has a slightly different JDK implementation, which also changes with every new version of JDK, it is hard to say when Xvfb is an absolute requirement and when it is not. So it is safer to always use it because we haven't had any reports of problems with it.

Is there a problem with running Xvfb, or is it just inconvenience?

Let us know if this explanation makes sense or not.

[aevett]

We're seeing more of our Unix customers having trouble with this each week.  We had started to make plans to include an Xvfb implementation in our installers, at least for Linux and maybe Solaris.  But I failed to realize that the customer would still need to have X11 installed in the OS for this to work.  Many of our customers run our software on locked down, GUI-less systems and installing X11 is not an option.

Also, it's still not clear to us why we only see a need for Xvfb when using JRE 1.5 on Unix.  When we have the customer downgrade to JRE 1.4, the need for Xvfb seems to go away.  What's the difference between JRE 1.4 and 1.5 in this area?  If it's because of different graphics classes that haven't been substituted, could you please reconsider the decision to substitute less of the JVM classes?

We plan on dropping support for JRE 1.4 in our product in our next release since the JRE itself has been desupported, so continuing to use JRE 1.4 as a fallback will no longer be an option for us.

[Support Team]

Obviously we don't want to require customers running Xvfb. This need is driven by JDK classes, not AjaxSwing classes, and the only way for us to find a work around is to test on each platform that's failing and see what exactly is the issue. There are many differences between 1.4 and 1.5 but the important ones are most likely the native methods in AWT and their implementation in shared libraries.

Would it be possible for us to SSH into customer environment and do some experiments? It's a long shot but worth asking because it may allow us to fine-tune AjaxSwing and make it run smoother.

We have added agent.usePlatformFontConfiguration parameter that allows overriding the default behavior of using platform configuration. Setting it to false (default value is true) would allow running AjaxSwing with less JDK native classes, but with the risk of inappropriate font configuration loaded for the platform.

By the way did the customer set agent.usePlatformGraphicsEnvironment to false to get it to run on JDK 1.4?

[aevett]

We have Linux and Solaris boxes in-house that we can probably make accessible.  I'll let you know next week.  Would you want to do experiments via our product or via your own test app?

So agent.usePlatformFontConfiguration is a new parameter?  When was it added?  In addition to avoiding Xvfb, the problem we have is we'd really like to be able to have known settings that always work on each platform, and if that is not possible, at least be able to indicate what setting should be changed given the error thrown.

Yes, I believe the customer referred to earlier set agent.usePlatformGraphicsEnvironment to false.

[Support Team]

agent.usePlatformFontConfiguration has been added in 2.4.0 RC, so it's only available after you download it (it has been made available for download just today).

[aevett]

We're working towards making a Linux box available to you first.  We need to know what IP address(es) you'll be coming from for access.

[Support Team]

Good news. We were able to determine what was causing the crash on some UNIX platforms, and after creating a patch for it we have AjaxSwing running everywhere without Xvfb. We are still doing testing to make sure no functionality is broken but by the way it looks right now the product should run on every version of every JDK (1.5 and 1.6 tested so far) on every platform with the same settings:-)

We'll create RC2, retest it on all available platforms, and once everything works make it available for download.

[aevett]

That's fantastic.  Thanks.