Hi,
Matthieu wrote:
> Unfortunately, I don't have the time at this point to do this for you.
> If nobody else volunteers I could give you a few pointers, the code is
> fairly self contained and there are clear interfaces to implement.
> What do you think?
Here we go (-:
I've started examining the ODE code and thinking about how to implement the
XPath 1.0 compiler and runtime based on Xalan or even the pure JAXP Xpath API.
I think I'm beginning to understand what happens currently, so I know where and
what has to be done. I'm trying now to implement some classes that can be used
as a fallback for the Jaxen based classes, if the Jaxen based classes cannot be
loaded.
But I've encountered a problem: I did not find any way to plug-in to the Xalan
XPath parsing/compilation like it is currently done by giving the
JaxenBpelHandler to the Jaxen XPathReader to resolve and check variables,
links, properties, functions and XSL sheets during BPEL compilation. I've seen
that the Saxon-based XPath 2.0 implementation uses standard JAXP Variable- and
FunctionResolvers to do this, but in my tests it seems that the Xalan compiler
does not invoke these resolvers during compilation. Or am I missing something
here?
So I'd like to ask if anybody here has an idea of how to do this with Xalan or
if there is a clean way to access the result structure of the XPath compiler,
so that it could be searched for the relevant elements. If I cannot find a way
to do this at compilation time, I would have to do it during the first
invocation of the process, I suppose, which will be probably quite awkward,
because I cannot keep the CompilationContext until runtime, because it would
introduce a dependency cycle between compiler and runtimes. Any idea on this
subject is highly appreciated.
Sorry if these questions are a bit silly, but it's my first real encounter with
XPath processing in Java (-; I somehow managed to get around this up to now...
By the way: you also wrote:
> Saxon is already optional if you rely only on XPath 1.0.
This is not quite right. There are references from the XPath10 classes to
Saxon, too: The classes
- org.apache.ode.bpel.compiler.v1.xpath10.XPath10ExpressionCompilerBPEL20
- org.apache.ode.bpel.compiler.v2.xpath10.XPath10ExpressionCompilerBPEL20
- org.apache.ode.bpel.rtrep.v1.xpath10.XPath10ExpressionRuntime
- org.apache.ode.bpel.rtrep.v2.xpath10.XPath10ExpressionRuntime
contain lines like these:
TransformerFactory trsf = new net.sf.saxon.TransformerFactoryImpl();
XslTransformHandler.getInstance().setTransformerFactory(trsf);
(in constructors or initialize methods). So, if you remove Saxon from the
classpath, XPath 1.0 will not work anymore, either (not even, if you restrict
yourself to BPEL 1.1, because the expression runtime is the same for all BPEL
versions). Maybe this has happened by accident?
Yours,
Juergen.
