Saxon

This looks like a dynamic class loading issue, probably specific to your Mule ESB environment. It's something we ought to investigate. (This will have to involve both parties, since we have limited ability to analyze problems that are environment-specific).

You can work around issues connected with bytecode generation by setting the configuration property FeatureKeys.GENERATE_BYTE_CODE to false, but I would hope that doesn't distract from trying to find the root cause of the problem.

Thanks for the reply (and the one from O'Neil). FYI we are using Saxon-EE 9.7.0.2J and Java version 1.8.0_73.

I will try the later version of Saxon (9.7.0.3?) and if that still has the problem try the byte code generation workaround.

Assuming we do still have the issue with 9.7.0.3), do you want to get me get the simplest version of our project that fails and send it to you? Would you want us to open a ticket with Mulesoft or will you contact them?

Michael

I can confirm we still get the error when using 9.7.0.3

Michael Banks

Thanks. The next thing to establish is whether the failure occurs when running from the command line, or whether there is some dependency on the application environment. If you can run it from the command line, and it fails, then it should be fairly easy for us to replicate and resolve. If it turns out there's some complex interaction with the classloading environment, then it's going to be more difficult.

Hi Michael, We have no issues when running the transform from the command line. Our Mule application waits for a file being dropped into a folder then runs a transform on it and moves the original file to an archive folder. We have a very simple version of this and that does not seem to have the issue with over 50 files processed (I will set up a test for more just to be certain). The more complicated version with more interaction with a queue and more of our java code can get the error from a few files processed to 40 or 50. I will see if I can work with our Mule/Java guy to get a project together that demonstrates the issue.

Michael Banks

Are you caching the compiled stylesheet in memory (by reusing the JAXP Templates or s9api XsltExecutable objects)?

If not, it's possible that the failure could be a resource problem due to having too many classes loaded.

I think there are differences between Java versions as to whether loaded classes get garbage-collected - I don't immediately recall the details.

If you aren't caching the compiled stylesheets, and if introducing caching feels like too much work, then I would recommend switching off byte-code generation. If you're only using a stylesheet once, then generating byte-code for it is probably more cost than benefit, especially because of the memory considerations.

Update: We have now found a probable cause of our issue and a solution, although this may not help with any actual error with mule/Saxon.

Our project has 2 Mule applications, a domain app and the app that does the work. We use Mavern to build and deploy. We put the jar in the classpath and the licence in the resources folder (a solution that worked in a non "domain" environment). In this "domain" environment we had issues where it seemed that the project reverted from using SaxonEE to using SaxonHE (provided with Mule). Mule suggested using the "loader.override=-net.sf.saxon" option to force it to use the SaxonEE version. It was while testing in this configuration that we started getting the class not found errors stated in original post.

We believe, to put it simply, that the Saxon jar is "losing" the licence file.

The solution has been to remove the SaxonEE from the deployment and put the jar and the licence file in the Mule Server user lib folder) (AnypointStudio\plugins\org.mule.tooling.server_{server version number}\mule\lib\user

Jars in this folder will load before any others so will always be used. We have tested this and seem to have no more problems.

I hope this helps clear things up. If you want any further information please let us know.

Mike

OK, thanks for letting us know. Getting classpaths right in a complex environment is always tricky, and getting it wrong always causes obscure failures.

No problem. At least we won't have to deploy Saxon on all applications only per Mule ESB server. But it will mean more regression testing when changing Saxon Versions (keeps the QA guys in work I suppose).

Saxon-EE deliberately falls back to run in "HE-mode" when there is no license, unless you actually use features that won't work without a license. So it can be a good idea somewhere in your application (e.g. when instantiating a Processor or Configuration to check that a license file has been picked up. You can do this with a call on

Configuration.isLicensedFeature(Configuration.LicenseFeature.SCHEMA_VALIDATION)