[JAXP-77] XSLT 2.0 / XPath 2.0 Created: 05/Jun/13  Updated: 05/Jun/13

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Now that XSLT 2.0 and XPath 2.0 are public Standards for years, with SAXON HE having an open-source, industry-proof Java-based RI, and with XSLT 3.0 on the way, JAXP should really, really finally Mandate that the minimum XSLT Level an implementation provides is not 1.0 but 2.0! People really do wait for this for years. Please, please!






[JAXP-73] Problem unmarshalling duration-type fields containing whitespace Created: 15/Mar/11  Updated: 28/Jun/12

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gturner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: Zip Archive jaxb-817.zip    
Issuezilla Id: 590

 Description   

The following problem could be observed in Jaxb 2.1:

Having an XML schema that defines the following type:
<element name="PublishedStartTime" type="dateTime" minOccurs="0"/>

and an having an XML instance document with the following entry:
<tva:PublishedStartTime>
2008-11-01T00:00:00Z
</tva:PublishedStartTime>

... i.e. with trailing and leading whitespaces, will result in an an
unmarshalled PublishedStartTime of null instead of the expected date and time.

The problem does not occur, if the entry in the XML instance document looks as
follows:

<tva:PublishedStartTime>2008-11-01T00:00:00Z</tva:PublishedStartTime>

... i.e. there are no leading and trailing whitespaces.
The Jaxb-classes generated with XJC use XMLGregorianCalendar as the data type
holding dateTime types.

The problem seems to be that the XMLGregorianCalendar / DatatypeFactory does not
support input strings with leading and trailing whitespaces as documented in
http://java.sun.com/javase/6/docs/api/javax/xml/datatype/DatatypeFactory.html#newXMLGregorianCalendar(java.lang.String).
Additionally it seems that the Jaxb2.1 runtime does not remove leading and
trailing whitespaces from dateTime entries.

We believe this is a bug, since either XMLGregorianCalendar should support
leading and trailing whitespaces, or Jaxb2.1 RI should remove leading and
trailing whitepsaces for dateTime entries. Otherwise, another JavaType than
XMLGregorianCalendar should be used as default type for xsd:dateTime types.

Best regards,

Hao and Florian



 Comments   
Comment by gturner [ 15/Mar/11 ]

Ooops!

Sorry I used the JIRA "Clone" link from bug 590. I didn't realize it would copy the initial comment. Version number, environment, etc. are wrong too.

I am using 2.1.13 and am experiencing the same effect on duration types.

e.g.

<StartTime>
2006-12-05T09:36:48.596-08:00
</StartTime>
<ExpireTime>
PT1H
</ExpireTime>

System.out.println(object.getStartTime()); // => 2006-12-05T09:36:48.596-08:00; Good! Bug 590 fixed.
System.out.println(object.getExpireTime()); // => null; Bad! Similar to bug 590.

Comment by Martin Grebac [ 08/Apr/11 ]

Thanks for filing this - would you please also attach a simple testcase?

Comment by gturner [ 08/Apr/11 ]

Hi Martin, I was going to write a testcase with the jaxb source, but it appears that jaxb-unit is not open source - http://www.java.net/node/693249 - is this still true?

Comment by Martin Grebac [ 08/Apr/11 ]

Yes, still true. You don't need to follow any guidelines/layout/whatever - anything I can execute is fine - just so that it contains the xsd/xml and the code you use.

Comment by gturner [ 08/Apr/11 ]

Attached is a testcase, a self-contained project using Ant, not JUnit or anything, may have lots of trouble running with dll-hell that is Xerces and JAXB inclusion in JRE. Here are the relevant bits:

test.xsd:

<xs:element name="document">
<xs:complexType>
<xs:sequence>
<xs:element name="duration" type="xs:duration" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>

test.xml:

<document xmlns="urn:test">
<duration>PT1H</duration>
<duration> PT1H</duration>
<duration>PT1H </duration>
<duration> PT1H </duration>
<duration>
PT1H
</duration>
</document>

Test.java:

for (Duration duration : doc.getDuration())
if (duration != null)
System.out.println("Got duration " + duration);
else
System.err.println("Got NULL duration!");

Ant output:

[java] Got duration PT1H
[java] Got NULL duration!
[java] Got NULL duration!
[java] Got NULL duration!
[java] Got NULL duration!

Comment by Iaroslav Savytskyi [ 28/Jun/12 ]

Hi, Joe,

I think this is JAXP bug. As I see from the spec for the duration type it should do "whiteSpace = collapse (fixed)".





[JAXP-78] validation fails to complain on white-space around tokens Created: 24/Jun/13  Updated: 04/Oct/13

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: m_perdikeas Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

javac 1.7.0_21 Ubuntu 12.04.2



 Description   

You can try this usecase with:

git clone https://github.com/mperdikeas/jaxp-validation-space-around-token.git && cd jaxp-validation-space-around-token && ant

The code executes and validates the a.xml instance document although, given the A.xsd grammer, it should have complained due to the extra whitespace.

This was originally reported to JAXB's bugtracker:

https://java.net/jira/browse/JAXB-964

But the engineer responsible suggested that I report it to JAXP instead.

Crux of the matter is that I have a type defined as a token in XSD and in an instance document an enumerated value appears with whitespace around it and the validation doesn't complain although it should:

From XML Schema Part 2: Datatypes Second Edition, section 3.3.2, token:

[Definition:] token represents tokenized strings. The - value space- of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces.

Files follow:

A.xsd

<xs:schema targetNamespace="foo://a"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="foo://a">

<xs:element name="type" type="Type"/>

<xs:simpleType name="Type">
<xs:restriction base="xs:token">
<xs:enumeration value="Archive"/>
<xs:enumeration value="Organisation"/>
</xs:restriction>
</xs:simpleType>

</xs:schema>

a.xml

<a:type xmlns:a="foo://a" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="foo://a A.xsd"
>Organisation </a:type>

(notice the space after 'Organization')

Java validating code

import java.io.IOException;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.InputStream;
import java.io.ByteArrayInputStream;
import java.io.File;

import javax.xml.XMLConstants;

import org.xml.sax.SAXException;
import org.xml.sax.InputSource;

import javax.xml.transform.sax.SAXSource;
import javax.xml.validation.Validator;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Schema;

import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;

import java.nio.file.Files;
import java.nio.file.Paths;
import java.nio.charset.StandardCharsets;
import java.nio.ByteBuffer;

public class FooMain {
public static void main(String args[]) throws Exception {
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema SCHEMA = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI).newSchema( new StreamSource(new File("A.xsd")));
Validator validator = SCHEMA.newValidator();
SAXSource source = new SAXSource(new InputSource(new ByteArrayInputStream(
StandardCharsets.UTF_8.decode(ByteBuffer.wrap(Files.readAllBytes(Paths.get("a.xml")))).toString().getBytes())));

try

{ validator.validate(source); System.out.println("validates"); }

catch (SAXException e)

{ System.out.println("doesn't validate"); }

}
}



 Comments   
Comment by Franta Mejta [ 04/Oct/13 ]

The value of "Organisation " is completely ok for xsd:token. See http://www.xmlplease.com/normalized.





[JAXP-72] Merge patch for XALANJ-2493 into JAXP Created: 11/Apr/12  Updated: 12/Apr/12

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: bjornbak Assignee: Joe Wang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: distinct, exslt, xalanj, xsltc

 Description   

I have run into problems that exslt.org XalanJ extension set:distinct is broken in JAXP when using XSLTC.

It has been solved in xalanj development version post to their last release 2.7.1.

The problem is documented in https://issues.apache.org/jira/browse/XALANJ-2424 and solved in https://issues.apache.org/jira/browse/XALANJ-2493

If I download XalanJ trunk version from apache subversion, build and use the compiled xalan.jar instead the problem is worked around but I'd rather JAXP worked out the box.



 Comments   
Comment by Joe Wang [ 12/Apr/12 ]

It's in the jaxp sources already. It was one of the patches during the last Xalan update. JAXP 1.4.6 will be released after 7u4 release that both will contain this change. Thanks.





[JAXP-75] XMLStreamWriterImpl does not close last empty tag in fragment Created: 24/Dec/12  Updated: 24/Dec/12

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kevinoid Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When writing an XML fragment (rather than an entire document, which would have a non-empty root element), if the last call is to writeEmptyElement, the empty element is not closed. As an example, consider the following program:

import java.io.IOException;
import java.io.OutputStreamWriter;
import javax.xml.stream.XMLOutputFactory;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;

class XMLStreamWriterFragBugDemo {
    public static void main(String[] args) throws IOException, XMLStreamException {
	OutputStreamWriter outWriter = new OutputStreamWriter(System.out);
	XMLStreamWriter xmlWriter =
	    XMLOutputFactory.newInstance().createXMLStreamWriter(outWriter);

	xmlWriter.writeEmptyElement("empty");
	xmlWriter.writeEmptyElement("empty");

	xmlWriter.flush();
	xmlWriter.close();

	outWriter.flush();

	System.out.println("");
    }
}

This should output <empty/><empty/>, but instead it outputs <empty/><empty.

The fix that I would suggest is to call closeStartTag() before fWriter.flush() in close() if fStartTagOpened is true, but that is up to you, of course.






[JAXP-74] Data corruption in SAXParser, chars outside XML passed to DefaultHandler.characters() Created: 28/Nov/12  Updated: 17/Dec/12

Status: Open
Project: jaxp
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian d'Heureuse Assignee: Joe Wang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File SaxParserError.java     XML File SaxParserError.xml    
Tags: SAXParser, Xerces

 Description   

In 2008, I have isolated and documented a serious bug in SAXParser. The bug can be easily reproduced on multiple platforms and leads to data corruption, e.g. when importing a database dump from an XML file.

http://bugs.sun.com/view_bug.do?bug_id=6716312

This bug seems to be fixed in newer Xerces versions, but JDK 7 still includes Xerces 2.7.1., which dates from 2005.



 Comments   
Comment by Joe Wang [ 17/Dec/12 ]

See JAXP release notes 1.4.4 through 1.4.6, JDK7 has been updated partially to Xerces. 2.10. Since it's not a complete update, the version number has not been changed. I wish we could have done a complete update but were constrained by resources.

As for the issue you reported, do you happen to know a particular patch in the newer Xerces that would fix your problem?

Comment by Christian d'Heureuse [ 17/Dec/12 ]

I don't know a patch. The error does not occur with any of the Apache Xerces versions I tested. But it occurs with all the JDK versions I have tested. I guess it's a problem of the JDK implementation.

I have tested with old binary Xerces JAR files from http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22xerces%22%20AND%20a%3A%22xercesImpl%22

The first Xerces version that supports XML 1.1 is 2.4.0. When I copy xercesImpl-2.4.0.jar into the lib/endorsed directory of the JRE, the error does not occur.

Also when I change the XML version at the first line of the data file from "1.1" to "1.0", the error does not occur.





Generated at Mon Apr 27 14:26:21 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.