Some bugs and glitches in XmlBeans

[Josef Duschl <jo...@in2soft.de>]

Hi,

During my work with XmlBeans I found some bugs and glitches.
I use XmlBeans v2 from the cvs of 11-25-2004 (09:29 [GMT+1]).

1. XmlCursor trouble with attributes of type XmlString.
-------------------------------------------------------

I've got a document like this:

<DOCUMENT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="schema.xsd" ATTRIBUTE="SomeValue">
        <ELEMENT ID="ElementId">
                <NAME>Element Name</NAME>
                ...
        </ELEMENT>
</DOCUMENT>

Searching for certain elements or attributes, I walk this document with the
XmlCursor.
Upon hitting the ATTRIBUTE I call cursor.toFirstChild(), which returns true,
but shouldn't. Cursor.getObject() then returns a XmlString: the text of the
NAME element ("Element Name") (parsing options are LoadLineNumbers and
LoadTrimTextBuffer).

As a workaround I now check cursor.currentTokenType() not to be
XmlCursor.TokenType.ATTR before asking the cursor to go to the first Child.

By the way: for such Attributes there is no way of using ExtensionInterfaces
which I would like to.


2. Strange Error messages upon errors with ExtensionInterfaces's methods.
-------------------------------------------------------------------------

Compilation of Extensions using the Ant job (from Eclipse) containing Errors
like misspelled method names, wrong parameter count etc result in quite
strange errors messages like: null or 2 (an abitary number).

I figured that basicly null means that some methods are missing in the
static handler. Invoking scomp manually made the numbers turn out to result
from wrong parameter count or wrong parameter types. In one case this also
happened when I had another public static method in the Static hander which
looked similar to one of the methods defined in the interface and expected
by XmlBeans. The correct method also existed in the static handler by the
way.

That particular code needs some work imo, since there you iterate over an
Array without ensuring it's size.


3. Poor performance of of XmlObject.validate() with big, invalid data.
----------------------------------------------------------------------

Benchmarking XmlBenas with a 10Mb file of dummy data (which actually is a
multiple copy of a quite simple file)
valiadation lasts for several minutes (bevore I aborted the execution of the
code).
The reason for this is that upon copying I created truckloads of duplicate
IDs which the validatior is complaining about.

For starters a good fix for you would be if you enable specifying a maximum
number of errors via the XmlOptions.
I also haven't found a workaround for this problem yet. If you know one
please let me know.


Thanks a lot.


Josef Duschl


____________
Virus checked by G DATA AntiVirusKit
Version: AVK 15.0.1682 from 22.12.2004
Virus news: www.antiviruslab.com


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org