parent of CTCustomXmlBlock

[Richard]

Hi,

I wonder why a root CTCustomXmlBlock has another CTCustomXmlBlock as its parent?!

I've written a traversal utility, which looks for all CTCustomXmlBlocks in my document, but I want to store only those, which are root elements. Therefor I want to check which CTCustomXmlBlock has no CTCustomXmlBlock as its parent...
Is there another possibility to check if a CTCustomXmlBlock is a root xml element?

Richard

[jason]

Hi Richard

I wonder why a root CTCustomXmlBlock has another CTCustomXmlBlock as its parent?!

I think you have hit a bug in JAXB - i've pasted below the text of a post of mine to the JAXB mailing list users@jaxb.dev.java.net on Wed, Sep 29, 2010 with subject JAXBElement: afterUnmarshal callback parent incorrect

afaik it is not logged as a bug with Oracle or JAXB yet though

cheers .. Jason

If finding that if an XML element unmarshalls as a JAXBElement, then
in the afterUnmarshal callback for the relevant class, the parent
passed in is wrong.

The parent should be, well, the parent. Instead, it is a JAXBElement
(which wraps a copy of the child). The result is that you can't climb
the tree from anything wrapped in a JAXBElement.

I did log this with Oracle a week ago, but haven't heard anything back.

Thoughts (apart from providing a test case)?

.. Jason




---------- Forwarded message ----------
From: IncidentDaemon@sun.com <IncidentDaemon@sun.com>
Date: Tue, Sep 21, 2010 at 3:13 PM
Subject: Your Report (Review ID: 1874905) - JAXB 2.x afterUnmarshal
callback parent incorrect
To: jason@plutext.org



---------------------------------------------------------------


Date Created: Mon Sep 20 23:13:14 MDT 2010
Type: bug
Customer Name: Jason Harrop
Customer Email: jason@plutext.org
SDN ID:
status: Waiting
Category: jaxb-xsd
Subcategory: runtime
Company: Plutext
release: 1.0.4
hardware: x64
OSversion: windows_7
priority: 4
Synopsis: JAXB 2.x afterUnmarshal callback parent incorrect
Description:
FULL PRODUCT VERSION :
JAXB 2.x

ADDITIONAL OS VERSION INFORMATION :
All os

EXTRA RELEVANT SYSTEM CONFIGURATION :
irrelevant

A DESCRIPTION OF THE PROBLEM :
If an element unmarshalls as a JAXBElement, then in the afterUnmarshal
callback, the parent passed in is wrong.

The parent should be the parent. Instead, it is a JAXBElement which
looks like the child.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Unmarshall something which results in a JAXBElement, and look at its
parent by implementing the afterUnmarshall callback..

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected the parent value to match the parent XML node.
ACTUAL -
The parent value matched the child.

REPRODUCIBILITY :
This bug can be reproduced always.
workaround:
comments: (company - Plutext , email - jason@plutext.org)

[Richard]

Although I haven't found any advice in the mailing lists or the bug tracking system, that the jaxb bug was fixed since the version used by the jdk, I've tried to use version 2.2.3u1 with docx4j in the latest svn version.

Thereby I've noticed, that both do not work together. If I try to get a reference to a documents body docx4j provides only null.

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

WordprocessingMLPackage wmlPckg = WordprocessingMLPackage.load(new File("test.docx"));
Body bodyObj = wmlPckg.getMainDocumentPart().getJaxbElement().getBody();
// bodyObj == null
 

Parsed in 0.015 seconds, using GeSHi 1.0.8.4

I believe "getJaxbElement()" causes the error.

Have you ever tried using the "native" JAXB package? Can you try to reproduce the error and maybe fix this issue (if it is an docx4j problem)?

Richard

[jason]

Sure, I've tried some of the 2.1.x reference implementations, not 2.2.x

I can't put my hands on exact version numbers right now, but most 2.1.x versions work well.

Let's start two new threads listing those which work and those which don't; one thread for 2.1.x and another for 2.2.x (even those 2.1.x and 2.2.x are supposed to be very similar iirc).

I think there are problems with the version included in the OpenJDK - I don't know off hand whether this corresponds to 2.1.x or 2.2.x

[Richard]

If somebody also has this problem - here is the way i fixed it. I do not know if it is the best solution, but it worked for me.

I have written a small class, which traverses the document and reapplies all parents to its children.

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

public class WmlPackageFixer extends CallbackImpl {

        public WmlPackageFixer(WordprocessingMLPackage wmlPackage) {
                walkJAXBElements(wmlPackage.getMainDocumentPart().getJaxbElement().getBody());
        }

        @Override
        public void walkJAXBElements(Object parent) {
                List<?> children = getChildren(parent);

                if (children != null) {
                        for (Object child: children) {
                                child = XmlUtils.unwrap(child);

                                // fix for JAXB Bug
                                ((Child) child).setParent(parent);

                                this.apply(child);

                                if (this.shouldTraverse(child)) {
                                        walkJAXBElements(child);
                                }
                        }
                }
        }

        @Override
        public List<Object> apply(Object element) {
                return null;
        }

        @Override
        public boolean shouldTraverse(Object o) {
                return true;
        }

        @Override
        public List<Object> getChildren(Object o) {
                return TraversalUtil.getChildrenImpl(o);
        }
}
 

Parsed in 0.016 seconds, using GeSHi 1.0.8.4

Cheers

[logicmonitor]

Is this issue fixed, I tried to use Richard's method, but I found that it cost too much memory. So I hope this issue is fixed.

[jason]

You have resurrected a really old thread here.

This shouldn't be a problem anymore. See https://github.com/plutext/docx4j/blob/ ... l.java#L77

But if you still encounter this issue in current docx4j (ie v3.3.1), please feel free to start a new thread, and please include a test case.