Project

Profile

Help

Bug #4213

net.sf.saxon.trans.XPathException: Errors were reported during stylesheet compilation

Added by Pranay Deshpande 4 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2019-05-07
Due date:
% Done:

0%

Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:

Description

Dear Colleagues,

This is Pranay from SAP Labs. We are using SaxonEE library for XSLT processing in our product and we are getting the following exception net.sf.saxon.trans.XPathException: Errors were reported during stylesheet compilation. Exception occurred during execution on the exchange: ExchangeId: ID-vsa6585629-1556884301644-7-1). Exhausted after delivery attempt: 1 caught: net.sf.saxon.trans.XPathException: Errors were reported during stylesheet compilation.

We started getting this issue in SaxonEE-9.8 version once we started using EnterpriseTransformerFactory, however, we don’t get any such exception if we don’t use EnterpriseTransformerFactory.

We are extending ExtensionFunctionDefinition class to create our own extension to set header and property (Code snippet attached). Sample XSL is also attached in the ticket. Can you please suggest if need to make any configuration changes for this extension to work with EnterpriseTransformerFactory as well?

In our stack, we have Apache Camel in our runtime, SaxonEE as XSLT processor with OSGI (Karaf and Equinox containers)

Thanks in advance. Best Regards, Pranay Deshpande SAP Labs

saxonlogs.txt (4.14 KB) stacktrace Pranay Deshpande, 2019-05-07 08:54 saxonlogs.txt
setheaderextensionDefinition.txt (2.25 KB) code snippet Pranay Deshpande, 2019-05-07 08:55 setheaderextensionDefinition.txt
xsltmapping.xsl (2.1 KB) problematic xsl Pranay Deshpande, 2019-05-07 08:55 xsltmapping.xsl

History

#1 Updated by Michael Kay 4 months ago

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.

#2 Updated by Pranay Deshpande 4 months ago

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

#3 Updated by Michael Kay 4 months ago

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.

#4 Updated by Pranay Deshpande 4 months ago

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

#5 Updated by Michael Kay 4 months ago

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.

#6 Updated by Pranay Deshpande 4 months ago

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.

#7 Updated by Michael Kay 4 months ago

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

#8 Updated by Michael Kay 3 months ago

  • Status changed from New to AwaitingInfo
  • Assignee set to Michael Kay
  • Priority changed from High to Normal

I have changed the status to "AwaitingInfo". Is the problem now resolved?

#9 Updated by Michael Kay about 2 months ago

  • Status changed from AwaitingInfo to Closed

I am closing this because there has been no new information, so I assume the problem is resolved. If this is not the case, please feel free to reopen the issue at any time.

Please register to edit this issue

Also available in: Atom PDF