Saxon

The key error on the log is this one:

Fatal error parsing XSLT file: Cannot find a 3-argument function named Q{http://sap.com/it/}setHeader(); SystemID: classpath:mapping/xsltmapping.xsl

There are tracing options (-TJ or FeatureKeys.TRACE_EXTERNAL_FUNCTIONS) that give more diagnostics on dynamic function loading; however this is almost certainly caused by the same OSGi issue that you reported in bug #4212, and probably needs the same workaround: configure Saxon's DynamicLoader to use a ClassLoader that is compatible with your execution environment.

Hi Michael,

Based on the traces, I don't see any class loader related errors like ClassNotFoundException of NoClassDefError. Hows it concludes to the same class loading issue?

Could there be any other workaround we can try apart from setting the class loader, like setting the configurations or something? Although External java calls are allowed, we are not able to access these java functions.

-Pranay

When Saxon isn't able to load a class that is in its own JAR file, that's pretty strong evidence that it's using the wrong ClassLoader. And the fact that other users have reported that the problem can be fixed by setting the ClassLoader in the configuration confirms the diagnosis.

In the past we've hesitated about how to do OSGi support in Saxon because of the difficulty of knowing how to test it. It's a general problem that when people run in environments with non-standard class loading, they hit "integration" problems that are difficult to reproduce in a different environment, and therefore difficult to add to any test suite. We've now had three users reporting specific issues with running Saxon under Camel, so I think this gives us a way forward. In general we're very reluctant to start testing Saxon in lots of different application environments, but it looks as if Camel might give us a way of testing OSGi frameworks more generally.

Having said that, I suspect we may still need to require setting of configuration options in such an environment, but at least it will be something we test ourselves rather than relying on users to test for us.

Hi Michael,

I tried the workaround of setting class loader for Configuration Class but that didn't help.

enterpriseTransformerFactoryObj.getConfiguration().getDynamicLoader().setClassLoader(Configuration.class.getClassLoader())

Anything else that we can try?

-Pranay

I think I might have jumped to a wrong conclusion thinking that because this involved execution of extension functions and involved OSGi, it must therefore be a classLoader issue. Since your extensions are implemented as instances of ExtensionFunctionDefinition, I think we need to look at whether the extensions have been correctly registered with the Saxon Configuration.

You haven't actually shown the code that registers the ExtensionFunctionDefinition with the Configuration, and I think that's the next thing we need to look at. The two obvious possibilities are (a) that it hasn't been registered at all, and (b) that it has been registered with the wrong Configuration.

You could do your own diagnostics by calling Configuration.getIntegratedFunctionLibrary() and either inspecting the "functions" hash map in a debugger, or probing its contents using

library.isFunctionAvailable(new SymbolicName.F(new StructuredQName("", "http://sap.com/it/", "setHeader"), 3))

A problem in this area could itself be OSGi-related. It's possible, for example, that under OSGi there are two different Configuration objects when we wouldn't normally expect that.

I'm presently trying out this:

    enterpriseConfiguration.registerExtensionFunction(new SetHeaderExtensionFunction());
    enterpriseConfiguration.registerExtensionFunction(new SetExchangePropertyExtensionFunction());
    enterpriseConfiguration.getDynamicLoader().setClassLoader(Thread.currentThread().getContextClassLoader());

This should resolve the class loader problem right.

Yes, when you register an ExtensionFunctionDefinition class with the Configuration there should be no need for dynamic loading and therefore no ClassLoader issues.