NoSuchMethodException when binding

[roded]

Hi,
I'm using BindingHandler.applyBindings to bind content controls to XML values in custom parts.
Please note that this code predates the Docx4J class (or I would've used Docx4J.bind) and that I'm working with a locally built nigthly version of Docx4j with xalan 2.7.1.

Calling the applyBindings method results in the following failure:

2014-09-15 17:00:31,850 ERROR org.docx4j.XmlUtils: - java.lang.NoSuchMethodException: For extension function, could not find method static org.docx4j.model.datastorage.BindingTraverserXSLT.xpathGenerateRuns([ExpressionContext,] #UNKNOWN (org.docx4j.openpackaging.packages.WordprocessingMLPackage), #UNKNOWN (org.docx4j.openpackaging.parts.WordprocessingML.MainDocumentPart), #UNKNOWN (java.util.HashMap), #STRING, #NODESET, #STRING, #STRING, #BOOLEAN).

The reason seems to be the 4th parameter, i.e. the following method in BindingTraverserXSLT is not resolved by xalan:

xpathGenerateRuns(WordprocessingMLPackage pkg, JaxbXmlPart sourcePart, Map<String, CustomXmlPart> customXmlDataStorageParts, XPathsPart xPathsPart, NodeIterator sdtPrNodeIt, String sdtParent, String contentChild, boolean multiLine);

As I understand it, as the xPathsPart of my MainDocumentPart is null, XmlUtils' transform() method skips over it when setting its Transformer's parameters.
Xalan's MethodResolver() method, in turn, is passed said parameter as an empty String wrapped by a XString:

[3] = {org.apache.xpath.objects.XString@19672}""

Resulting in the method not being resolved correctly.

This is giving me some grief, and I'm not really sure if the issue is with my usage of Docx4J (same code was OK in 2.8.1) or elsewhere.
Is this the expected behavior?

Edit: also, I think I should mention that I'm binding content controls to several different custom XML parts in the document.

Cheers,
Roded

[roded]

I have spoken too soon.
The problem I was experiencing was not related to the mentioned error.
But the question still stands: is this expected behavior?
Thanks

[jason]

The method in the Docx4J facade contains the following logic:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

                        if (wmlPackage.getMainDocumentPart().getXPathsPart()!=null) {
                                openDoPEHandler = new OpenDoPEHandler(wmlPackage);
                                openDoPEHandler.preprocess();
                        }
                        BindingHandler bh = new BindingHandler(wmlPackage);

 

Parsed in 0.015 seconds, using GeSHi 1.0.8.4

In other words, the OpenDoPEHandler step is only performed if the "OpenDoPE" XPaths part is present.

If it isn't, just the basic binding (as envisaged by Microsoft) is done, in the BindingHandler step. And that works for me, as per the sample at:

https://github.com/plutext/docx4j/blob/ ... geXML.java

That's by way of background, since the issue you are having seems to be occuring in the BindingHandler step.

Please try the sample referred to above. Does it work for you?

[roded]

Hmm..
I'm not sure of the reason for my BindingHandler exception. It has since resolved itself somehow.
This is all no doubt due to some or other non-standard usage on my part. Sorry for leaving this unresolved like this.

Regarding ContentControlsMergeXML.java, the binding works perfectly (note: I suspect the Docx4J.bind call's AND should be an OR).
Though regarding the bind method:

1. I completely missed the option to not use FLAG_BIND_INSERT_XML - As such I can start using the Docx4J facade.
2. However, as RemovalHandler.xslt is OpenDoPE specific (od:*), calling Docx4J.bind with Docx4J.FLAG_BIND_REMOVE_SDT in a case such as this ("regular" SDTs) leaves the content controls in place. Is this intended? As the functionality already exists + Docx4J.class can be used separately from OpenDoPE, it would be very useful for a RemovalHandler. Quantifier which will work on all content controls, OpenDoPE or not.

Cheers,
Roded