Saxon

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

The same question came up on the list a few days ago: see http://sourceforge.net/mailarchive/forum.php?thread_id=6635850&forum_id=1398 A summary of the answer: you're looking at some functionality that wasn't fully implemented. The extension binding mechanism was extensively restructured in 8.1 to allow integration of debuggers, and the new structure was designed to do more than meet the immediate requirements, but in the meantime, there are one or two tantalising roads that don't lead anywhere. I hope to flesh out some of the gaps in due course. Michael Kay

Legacy ID: #3028217 Legacy Poster: Eric P. Wittmann (paalin)

Thanks for the quick response. I had searched for similar topics and for some reason didn't see the one you pointed me to. My bad. I have modified Saxon 8.3 slightly to utilize the custom function library and we'll see how it goes. So far, my function library is being called, now I just need to wrap my function impl in something that is a Saxon Expression. Shouldn't be hard from what I've seen so far. Also, if it would be helpful to you I can give you a quick overview of my use case and why the current reflection support for extension functions doesn't quite work. Looking forward to future versions of the product, including possibly utilizing the debugging related features. Nice job.

Legacy ID: #3028688 Legacy Poster: Eric P. Wittmann (paalin)

FYI - I was able to accomplish what I wanted to do by simply adding the following line to the reset() method of the StaticQueryContext: functionLibraryList.addFunctionLibrary(config.getExtensionBinder()); This adds my custom function library to the list and everything else falls into place. Works great!

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

Thanks, that's good feedback. I was thinking more in terms of a user-registered ExtensionBinder replacing the standard one, rather than being used in addition. I can see advantages both ways: I'll have a think about it. Let me know what you think. Michael Kay

Legacy ID: #3030187 Legacy Poster: Eric P. Wittmann (paalin)

Ah! That explains the name of the method (setExtensionBinder), which seemed a little odd to me. But if the intent was to override the default Java Extension library, then it makes sense. I can see where THAT code would need to go as well (also in reset()) - and it also explains why the extensionBinder member variable is initialized to a new JavaExtensionLibrary. That said, I think having both of these would be great. Maybe add a new member on the Configuration for a user supplied custom function library as well as keeping the extension binder.

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

I've left it for now that setExtensionBinder replaces the standard mechanism. This can be used in several ways: you can subclass the standard JavaFunctionLibrary, or you can supply a FunctionLibrary list that includes both the standard JavaFunctionLIbrary and another function library of your own invention, in either order, etc. Michael Kay

Legacy ID: #3030890 Legacy Poster: Eric P. Wittmann (paalin)

Sounds good - I'll just need to remember to set setAllowExternalFunctions to true when the time comes. Thanks for the help, things seem to be going very smoothly with this small tweak. Eric Wittmann