Hi Patrik,
I already implemented successfully a custom saxon extension for the xslt transformations. However, I can't get access to the cached data since although the caching class is a singleton a new (empty) instance is being created when called from xslt. Is there any way to access the existing instance?
The extensions bundle works in a different isolated class loader so indeed static variables created in a specific class loader cannot be accessed from another.
To get into more details, the main Oxygen class loader loads all the libraries in the
OXYGEN\lib" folder. Then for each framework's extensions a separate class loader is created having as parent class loader the main Oxygen class loader.
One alternative would be to communicate objects using a library which is loaded in the main Oxygen class loader. For example on the extensions bundle side you could use:
Code: Select all
javax.swing.UIManager.getDefaults().put(key, value)
to put values in a static map, then from the XSLT code see if you can access by calling Java methods those keys in the "UIManager.getDefaults()" and read the values.
It depends on what type those values are, if they are plain strings or base Java types, it should work. If they are special objects created on the extensionsbundle class loader from classes defined in the JAR libraries added to the framework, you will have the same class loader issue.
I have no write access to the binary folder of oxygen. Thus, I can't place my saxon extension library there to make it available for the schematron validation. Is there already a way to explicitly configure an extension for schematron?
We already have an issue registered in our issues list to allow a Schematron-based validation scenario module to specify a set of JAR libraries to be used for validation. I will try to increase its priority.
Another approach for us to provide a fix for this kind of situations could be this one:
The validation scenario belongs to a certain document type and when the validation is performed using it we could use internally for validation (and including internal XSLT transformations) the same class loader which is created for that specific document type/framework (the same class loader which has loaded the extensions bundle instance). So we'll also investigate this approach.
Regards,
Radu