oxygenxml vs xerces

[trillich]

hi. we're trying to use eclipse with oxygenxml just for xml/xslt/xsd editing -- no java heads here... but we're running into an error message that's well above our heads: on startup, we get this error dialog--

"""
The expected Xerces version Xerces-J 2.8.0 was not loaded due to the fact that the version XML4J 4.3.3
is added as an extension to the JVM. This can cause program malfunction. It is strongly recommended to remove the Xerces implementation located at: jar:file:/C:/Program%20Files/IBM/Java/jre/lib/xml.jar!/org/apache/xerces/impl/Version.class
"""

the interesting thing is, this was all working nicely at one point. we're having dozens of BSOD (about 50 since 1-jan-2006) and sometimes we try rolling back to a previous system state, and maybe something got partially uninstalled? this is on a thinkpad r52, as evidenced by the "IBM" part of the path; but in Window->Preferences->Java->Installed JREs we have three listed: c:\progra~1\java\jre1.5.0_06, x:\progra~1\java\jre1.5.0_07 and one we installed when at the uportal conference in june: c:\progra~1\java\jdk1.5.0_07\jre ... that is, no mention of the IBM file path at all.

yes, we're new at eclipse and hopelessly lost within java (it's all very daunting, but we're determined). we just want a nice xsl/xsd editor for now.

any pointers that the newbies can follow?

[trillich]

also might add -- we were having troubles with eclipse and xerces, so we tried a while new download of eclipse, which runs fine... until we install the oxygenxml components; then, we get the xerces error on launch.

ideas?

[george]

Hi,

That is a warning, not an error. The problem is that you use an IBM JRE to run Eclipse and that contains an old version of Xerces. Note that oXygen has as requirement a JRE from Sun. To start Eclipse with a Sun JRE just edit its command line and add

-vm path/to/your/java.exe

while you are there it will be a good idea to give also a little more memory than default to Eclipse by adding for instance

-vmargs -Xmx256m

Best Regards,
George

[trillich]

thanks for your reply!

of course, i'm confused nonetheless.

we didn't have to munge the command line back in june, and from what i can tell there's no reason for eclipse to look anywhere but in the javas we've pointed it to. but it is indeed looking at the ibm instance for some godawful reason.

i can make a desktop shortcut [windo~1, yikes] that adds command line args, sure, but what could have changed to make that necessary?

[george]

Well... I do not know how Eclipse decides what Java to use but you can check what Java it actually uses if you look in Help -> About Eclipse SDK -- Configuration Details and look at java.vendor and java.version entries.

Best Regards,
George

[fragavi]

I also have the same problem, and I don't want to change the default JRE of my eclipse product, in this case it is Rational Software Architect, because it might have an effect somewhere i don't know.

Is it possible for the oxygen plug-in to use either a different JRE or use it's own xerces library (and other libraries)? Oxygen comes with it's own set of libraries right, is it possible for it to use it? The dialog is just a warning, but it always pops-up, and i also don't want to use a different library than what oxygen is requiring.

Thanks![/quote]

[sorin_ristache]

Hello,

No, an Eclipse plugin cannot change the JRE in which the Eclipse platform runs or the order of loading the libraries in the plugin class loader. The libraries used by the plugin are loaded by the plugin class loader which is created by the Eclipse platform. This class loader uses the libraries that are installed by the plugin but the libraries from the JRE are loaded before the ones of the plugin. An Eclipse plugin cannot change that. This is why the oXygen plugin uses the Xerces library that it installs with the only exception of a JRE which comes with other version of Xerces and which is used to run the Eclipse platform.


Regards,
Sorin

[george]

The class loaders in Java are organized in a forest structure, that means each class loader can have a parent. Normally each class loader first delegates to the parent class loader for loading a class and if the parent does not find the class then it tries itself to load that class.

In Eclipse case, it creates a class loader for each plugin but all these plugin class loaders have a common parent and the common ancestor is the system class loader. So it is possible for different plugins to use different versions of the same library as they are isolated one from each other. However, in the case when a library appears in the system class loader then all the plugins will see that library due to the delegation mechanism, as all the plugin class loaders delegate first to the parent class loader and as the class will be found by the system class loader they will not try to load anymore the class from plugin jars. We have no control on the plugin class loader, that comes with Eclipse so we cannot remove its delegation mechanism to its parent class loader.

Best Regards,
George