Frascati 1.3 doesn't start on Ubuntu system, the following excetpion is throws ;
org.ow2.frascati.util.FrascatiException: Cannot load the OW2 FraSCAti composite
This problem appends only on Ubuntu system, make a try with a Mac OSX 10.6 system and there is no problem, Frascati 1.3 works well.
Cause explained by P. Merle :
We have an idea about your issue.
FraSCAti generates code from SCA component definitions. The name is computed with an hashcode itself computed on component's interfaces.
But this computation is dependent of the order of the interfaces.
As FraSCAti is defined in components and different modules (jar files), the name of the class to load is dependent of the classpath order.
So, the class is generated with a name but the jvm try to load a class with another name.
It explains why it works on some systems, but not on others (depending on the file system listing order).
We have to fix this bug but it's not possible for the frascati 1.3 release. We will fix it in the current release (1.4-SNAPSHOT).
For convenience, you can still use frascati 1.3 on a system that doesn't produce the bug or switch to the development version.
If you really need frascati 1.3 in a specific system, I can work to provide you a script fixing the right classpath to avoid the bug.
Let me know.
Thank you for reporting this bug.
Solved on 05/05/2011
With the new version of Frascati 1.4, the problem is solved.
Submited on 01/04/2011
Frascati 1.3 doesn't start on Ubuntu system, the following excetpion is throws ; org.ow2.frascati.util.FrascatiException: Cannot load the OW2 FraSCAti composite
This problem appends only on Ubuntu system, make a try with a Mac OSX 10.6 system and there is no problem, Frascati 1.3 works well.
Cause explained by P. Merle :
We have an idea about your issue. FraSCAti generates code from SCA component definitions. The name is computed with an hashcode itself computed on component's interfaces. But this computation is dependent of the order of the interfaces. As FraSCAti is defined in components and different modules (jar files), the name of the class to load is dependent of the classpath order. So, the class is generated with a name but the jvm try to load a class with another name. It explains why it works on some systems, but not on others (depending on the file system listing order).
We have to fix this bug but it's not possible for the frascati 1.3 release. We will fix it in the current release (1.4-SNAPSHOT).
For convenience, you can still use frascati 1.3 on a system that doesn't produce the bug or switch to the development version. If you really need frascati 1.3 in a specific system, I can work to provide you a script fixing the right classpath to avoid the bug. Let me know.
Thank you for reporting this bug.
Solved on 05/05/2011
With the new version of Frascati 1.4, the problem is solved.