Just ran the demo on my Windows box and it started as expected. I will try running it on my Ubuntu box in the next few days.

Internally, the property interpolator for java.awt.Color is looked up via META-INF/trident-plugin.properties. One of the entries there points to org.pushingpixels.trident.swing.AWTPropertyInterpolators which has the interpolator for the java.awt.Color.

There can be a few reasons why this fails:

• Class loader not finding the trident-plugin.properties inside the trident.jar file
• Reflection failing for Class.isAssignableFrom operations

Can you run this demo locally (to see if this is specific to WebStart)?

• Download trident.jar and trident-tst.jar from http://kenai.com/projects/trident/downloads/directory/Latest_dev
• Run java -cp trident-tst.jar;trident.jar test.swing.ButtonFg

Thanks
Kirill

I cannot seem to reproduce this on my Ubuntu machine (WebStart environment). Is it possible that you have an older trident.jar in your WebStart cache? Can you clean it and relaunch the link?

Also, running the same application locally would be great to try analyzing the cause for this issue.

Thanks
Kirill

Hi Kirill,

Thanks for the quick response. I tried downloading and running the demo locally using both version of Java on my system (Sun & OpenJDK). Both versions worked fine locally:

Version Info:

Sun:
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)

OpenJDK
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK Server VM (build 14.0-b08, mixed mode)

So the problem seems to be related to running the demos as a web-start. When I try running the JNLP using the OpenJDK, I get the error message posted above. I tried cleaning the cache, but still no luck. I would try testing the webstart
using the Official Java runtime, but unfortunately, the Sun javaws has been acting funny for the past few months, and complaining about "Invalid proxy types" and such.

Here is some more information about the system in case it helps:

Ubuntu 9.04
Linux Kore 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:57:31 UTC 2009 i686 GNU/Linux

Let me know if there is anything else I can do to help debug the issue. Also, I am getting different errors when attempting to run the Substance demo using OpenJDK (I used to be able to run it fine using the Sun Java before that started having problems). If it would be helpful, I could post a bug in the Substance issues tracker with the error messages that I get with that.

Thanks for looking into it. Keep up the great work!
Keith

Update:

I fixed the issue I was having with the Sun Java, and now both Trident & Substance work using it. The problem seems to be restricted to using the OpenJDK JRE. If you think the issue is a problem in their implementation, I can repost the bug to their issue tracking system.

In case you want to try on your Ubuntu install, here are the commands that I used:

/usr/lib/jvm/java-6-openjdk/jre/bin/javaws ~/Desktop/ButtonFg.jnlp
/usr/lib/jvm/java-6-openjdk/jre/bin/java -cp trident-tst.jar:trident.jar test.swing.ButtonFg

Keith

Assigning to "core" module and lowering priority.

If this only fails on OpenJDK, it will be a lower priority at the moment. If i understand correctly, this only happens under OpenJDK in WebStart, right? That would be tricky to debug without starting to publish custom versions with debug / tracing messages.

Do you see similar errors in Substance? It uses pretty much the same class loader resource approach to discover plugins.

Thanks
Kirill

Hi Kirill,

It only occurs with OpenJDK in Webstart, that is correct. Since it is now work in the regular Java, I wouldn't worry too much about it, especially if it is not a very simple fix.
I will go ahead and post the stack trace & error messages I run into with substance + OpenJDK, just so you know

Thanks again,
Keith

Looks like this has the same underlying cause as bug 447 that you have opened on Substance [1]. I use Thread.currentThread().getContextClassLoader() to enumerate resources from the classpath jars - reported against OpenJDK at [2]. To me, it looks like this class loader only returns resources from the first jar on the class path. In case of Trident demos, the first jar is trident-tst.jar - which only has the demo classes. The library core is trident.jar - it has a descriptor class loaded dynamically in the TimelineEngine constructor with the following:

ClassLoader classLoader = Thread.currentThread()
.getContextClassLoader();
Enumeration urls = classLoader
.getResources("META-INF/trident-plugin.properties");
while (urls.hasMoreElements()) {
URL pluginUrl = (URL) urls.nextElement();
// do the parsing of the specific plugin descriptor
}

So if the class loader fails to return the URL from the second jar on the classpath, Trident will not be able to animate properties that don't have explicit property interpolator specified.

Thanks
Kirill

[1] https://substance.dev.java.net/issues/show_bug.cgi?id=447
[2] https://bugzilla.redhat.com/show_bug.cgi?id=509301