This doesn't explain why is being called. Do you have a stack trace that shows what is calling this class?


Michael Kay

From: Rob Brown []
Sent: 30 April 2010 22:32
To: Mailing list for the SAXON XSLT and XQuery processor
Subject: Re: [saxon] Alternative to java extension functions?

I am using s9 code, but I didn't think this was the reflexive functions because I thought I saw that you have factored that out of HE at some point. I am using version of saxon.

When compiling the xpath I use the following:

        XPathCompiler xpathCompiler = new Processor(false).newXPathCompiler();
        xpathCompiler.declareNamespace("myPrefix", getJavaClassRef());
        return xpathCompiler.compile(insertMyPrefixRefs(expr)).getUnderlyingExpression();

In the insertMyPrefixRefs() method I do a simple string replace in the expression for "instance()" replacing it with "myPrefix:instance()" so it will call my static java methods.

Does that answer your question?

I do want to factor out jaxp entirely. I could do so and try to keep this code working, unless you have a better idea.


On Fri, Apr 30, 2010 at 2:18 PM, Michael Kay <> wrote:
I think the reference to shows where the
problem lies. This is the Xalan XPath engine, or the version of it built
into the Sun JDK. Saxon does not make calls on this code. So I strongly
suspect that your application is calling Saxon in one environment, and Xalan
in another, because of differences in the classpath. I would suggest loading
the Saxon XPathFactory explicitly (using new XPathFactoryImpl()) rather than
relying on the JAXP classpath search.

You haven't explained how you are implementing the extension functions - are
you using Saxon ("reflexive") extension functions, or the JAXP
FunctionResolver mechanism? Either way, there's a good chance that something
that works with Saxon isn't going to work with Xalan.


Michael Kay


       From: Rob Brown []
       Sent: 30 April 2010 19:50
       Subject: [saxon] Alternative to java extension functions?


       I'm hoping there is another design idea I can use for this problem.
I have to implement xpath functions that map to various xforms functions for
our users. My solution was to use java extension functions and do some
mapping between my own java namespace and what the users see (i.e. the users
see xforms functions but I map these before evaluation to my own java

       The main problem is that I cannot change the function signature.
This means I cannot use java extension functions that access instance
methods (which require an extra parameter) and I have to use an awful hack
that uses static methods. Basically I store an instance of my value resolver
in a synchronized static field and map static java extension functions to
this object. Ugly, but at least it worked until now.

       Now I find this is failing when I try to run the app in Amazon's
cloud environment. Somewhere inside jaxp classes as called by saxon
( I'm getting a NullPointerException. Just to be clear,
this app runs fine outside of the virtualized Amazon environment. I suspect
the root cause is how jaxp classes are being loaded because I've seen that
happen with jaxp in other VPS enviornments.

       Whatever the cause, I'm hoping that if I redesign this hack I can
clean up my code and hopefully make this bug disappear.

       Is there another design alternative to implementing xforms (or
similar) functions in xpath? I'm ok using s9 exclusively if that will help -
jaxp causes me nothing but trouble so I'm ready to toss it out the window
anyway. The function signatures (now(), index(), instance(), etc.) cannot be
changed, require object instances to resolve, and I need to evaluate them
within xpath alone (i.e. not within xslt or xquery).

       I hope there is an answer because it looks like we can't host our
application in Amazon if this doesn't get resolved.


saxon-help mailing list archived at