Saxon

This is essentially a duplicate of bug #3814; comment #2 describes a workaround, and at the moment that's the best we can do.

The reason the failure occurs above a certain document size is that we only generate bytecode for code that has been executed a given number of times. Another workaround is to switch bytecode generation off completely (-opt:-c on the command line, or equivalents in the XsltCompiler class in s9api). Bytecode generation can be important for the performance of some workloads, but for others it makes very little difference.

Hi Michael,

Thanks for providing the quick info on this. Could you please confirm what's the exact value of this "document size" above which, the bytecode is generated (I believe thats for optimizing the processing of XSLT) Based on the size, we could be able to provide some workarounds for our customers.

Meanwhile, I've tried this: enterpriseConfiguration.setConfigurationProperty(Feature.GENERATE_BYTE_CODE,false); I hope this should disable the byte code genaration.

Correct me if I'm wrong here.

Regards Pranay

The trigger is only indirectly related to document size - it's based on the number of times particular expressions are executed, which will tend to increase as the document size increases, but isn't a straightforward relationship.

Switching off the bytecode generation seems a more promising approach; but there will probably be other cases where Saxon is doing dynamic loading too (as evidenced by your other bug report) so you should probably try and fix it by setting the ClassLoader for Saxon to use.

Hi Michael,

Switching off the bytecode generation seems to solve the current problem. But in general, do you have any timeline to fix the class loader problems with OSGI environment?

You can reduce down the priority of this ticket though as the immediate blocker is resolved.

-Pranay

I would imagine that using the Configuration.class.getClassLoader() workaround is going to work for Saxon's dynamic loading of its own classes, but it may not work for loading classes in a different OSGi bundle from Saxon (such as reflexive extension functions), unless the OSGi bundle that contains Saxon registers a dependency on the packages containing those extension functions.

I should stress that we have done no work on OSGi and it is technically unsupported. But I would like to help you, if only because it will help us learn about what we need to do to make Saxon work in an OSGi environment.

The first thing I need to understand is how Saxon has been bundled in this environment: what does the bundle descriptor for the bundle containing Saxon look like, and are there other things in the same bundle? What does the bundle descriptor for the calling application look like, and which Saxon packages does it declare dependencies on?

I suspect the answer to these questions is that this has all been done by Apache Camel, rather than yourselves. That means we need to start understanding what Apache Camel has done to OSGi-enable Saxon. This is a slippery slope from a support point of view: we normally make a point of not getting involved in the detail of how third parties have integrated Saxon into their environments; support is their problem not ours. At the same time, understanding what they have done may help us to understand what is possible, what its limitations are, and what changes we need to make to make it work better.

Reading around, dynamic class loading under OSGi looks like a real challenge, and there seems to be a lot of advice to avoid it wherever possible. This suggests that if and when we do support OSGi, we will have to move away from the highly-dynamic loading of reflexive extension functions (where we deduce the Java class name from the namespace URI of the function) to a model where extension function implementations are explicitly registered. This suggests that we might well have to move to something closer to "integrated extension functions". Looking more closely at your bug #4213 it seems you are already doing that, so perhaps I have misinterpreted the cause and need to investigate that separately.

Getting byte code generation to work under OSGi might be simply a case of doing further tweaking of the class loader that we use for this purpose. Other cases where we do dynamic loading might require redesign of APIs so the required classes are supplied to us as Class objects rather than as class names to be loaded.

Juan, yes, you seem to be hitting the same problem with generated byte code under Apache Camel, and the same circumventions should work: either suppress bytecode generation, or change the ClassLoader registered with the configuration so that it works under OSGi.