Saxon

Legacy ID: #5151197 Legacy Poster: Michael Kay (mhkay)

When you say "at runtime", are you really distinguishing stylesheet compile time from stylesheet runtime here? I suspect you actually want your different class used at compile time as well - you just don't want it named in the source. Or perhaps I'm wrong. It would be good to have a clearer explanation of the requirement (and its motivation: why do you want to do this? Perhaps there is some better way of achieving the objectives?) In principle you can do anything you like by registering your own FunctionLibrary using Configuration.setExtensionBinder(). But I don't think I would recommend it unless you want to spend some long evenings with a debugger - it's very low-level programming.

Legacy ID: #5151217 Legacy Poster: kendall shaw (queshaw)

I think you are right that I want the different class used at stylesheet compile time too. The idea is that I want to avoid using the classes associated with some extension functions that rely on a surrounding system, for the purpose of testing. Do you think it could be a useful enhancement to have saxon use a URIresolver (or some such thing) when looking up the extension classes? Thanks. I'll see if Configuration.setExtensionBinder() looks difficult to use or not.

Legacy ID: #5151236 Legacy Poster: Michael Kay (mhkay)

>Do you think it could be a useful enhancement to have saxon use a URIresolver (or some such thing) when looking up the extension classes? As David Wheeler taught me when I was an undergraduate many years ago, every problem can be solved by adding one more level of indirection; but by doing so you always introduce another problem. Having said that, I do think it would be useful to allow some kind of indirection between the URIs used in the names of extension functions and the names of the Java classes used in their implementation. This already exists in some kind of form for the EXSLT libraries. Which makes me think: you might be able to use that mechanism. If you can find the JavaExtensionLibrary, you should be able to call declareJavaClass(uri, class) to bind a URI to a class; and I think you should be able to find the JavaExtensionLibrary using config.getExtensionBinder("java"). Give it a try, anyway.

Legacy ID: #5152330 Legacy Poster: David Lee (daldei)

If the intended use is to run within a different (test) environment, you could also implement stubs for those classes under the same package name and include the JAR file in your classpath.

Legacy ID: #5153551 Legacy Poster: kendall shaw (queshaw)

Thanks. The problem I have with that is then it makes it difficult to use those classes outside of the XSLT in the same program. But, I had to do something similar in creating method stubs anyway, for my dummy class. The technique the Mr. Kay suggested worked perfectly.: final TransformerFactory tf = TransformerFactoryImpl.newInstance(); final Configuration cfg = (Configuration) tf.getAttribute(FeatureKeys.CONFIGURATION); JavaExtensionLibrary jel = (JavaExtensionLibrary) cfg.getExtensionBinder("java"); jel.declareJavaClass(uri, DummyExtensionFunctions.class);