[JAXP-76] StaX: data corruption when reading Unicode SMP characters in UTF-8 XML Created: 17/Jan/13  Updated: 09/Apr/15  Resolved: 09/Apr/15

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

Type: Bug Priority: Major
Reporter: donvip Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JRE 7u11



 Description   

The attached small XML file contains a chinese character and the first gothic character (U+10330 : http://www.unicode.org/charts/PDF/U10330.pdf)

When parsing this file using StaX, the attribute value containing the gothic character is corrupted: it contains also the chinese character from the previous attribute.

See the console output:

From XML chinese:[-16, -92, -83, -94]
Expected chinese:[-16, -92, -83, -94]
From XML gothic:[-16, -92, -83, -94, -16, -112, -116, -80]
Expected gothic:[-16, -112, -116, -80]

This issue comes from JOSM bug tracker: http://josm.openstreetmap.de/ticket/3290



 Comments   
Comment by donvip [ 17/Jan/13 ]

Sorry, how do we attach files ? If I am not allowed, they can be found here:

http://josm.openstreetmap.de/attachment/ticket/3290/gottic.osm
http://josm.openstreetmap.de/attachment/ticket/3290/Test.java

Comment by donvip [ 16/Sep/13 ]

Does anyone care about this public JIRA ?

Comment by donvip [ 29/Nov/14 ]

This bug has finally been addressed through https://bugs.openjdk.java.net/browse/JDK-8058175. Any chance to see it backported to JDK7 and JDK8?

Comment by Joe Wang [ 09/Apr/15 ]

Please note that the JAXP standalone (https://jaxp.java.net/) was retired. Please report issues to <a href="https://bugs.openjdk.java.net">the OpenJDK Bug System</a>.





[JAXP-80] Broken Localization Strings (XMLSchemaMessages_de.properties) Created: 09/Apr/15  Updated: 09/Apr/15  Resolved: 09/Apr/15

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

Type: Bug Priority: Major
Reporter: flo.javajira Assignee: super_glassfish
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Many of the localization strings in XMLSchemaMessages_de.properties are broken.

Example:
English: cvc-elt.5.2.2.2.2 = cvc-elt.5.2.2.2.2: The value ''

{1}'' of element ''{0}'' does not match the '{'value constraint'}' value ''{2}''.
German: cvc-elt.5.2.2.2.2 = cvc-elt.5.2.2.2.2: Wert "{1}

" des Elements "

{0}" stimmt nicht mit dem "{''value constraint''}"-Wert "{2}" \u00FCberein.

The problem is the '{'value constraint'}', which properly escaped the {-Char, while the German version has a double-quote ("), which doesn't escape the {, so it's interpreted as if the string has an additional parameter named ''value constraint''.

This leads to the problem that the "raw" error-messages (without replaced values) get prefixed by the "FormatFailed" string (e.g. "Beim Formatieren der folgenden Meldung ist ein interner Fehler aufgetreten: Wert "{1}" des Elements "{0}

" stimmt nicht mit dem "

{''value constraint''}

"-Wert "

{2}

" überein." by the java.text.MessageFormat.format(msg, arguments) call.



 Comments   
Comment by Joe Wang [ 09/Apr/15 ]

Moved to:
https://bugs.openjdk.java.net/browse/JDK-8077351

Note that the JAXP standalone had been retired. Please visit OpenJDK for future development.

Comment by flo.javajira [ 09/Apr/15 ]

Thanks for moving it, I wasn't sure where to put it, this seemed the "best" place, I will know better in the future.





[JAXP-70] JAXP 1.4 (commit #2679) breaks backward compatility Created: 10/Jun/11  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Critical
Reporter: cmathieu Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenJDK or Java 7



 Description   

According to the JAXP documentation, http://jaxp.java.net/1.4/JAXP-Compatibility.html#JAXP_security, is it no longer possible to use XSLT extension functions when a security manager is set. This is a major regression added by JAXP in commit #2679. This limitation does not come from Xerces and the Xerces team seems to agree that it is not a good idea.

This new and unavoidable behaviour breaks all the applications using a security manager (hello RMI) with no possible workaround. Setting a security manager does not means that the application will parse user provided XML/XSLT files. It should be up to the application to (un)set the secure mode. A method to disable the secure mode even when a security manager is set should be provided.



 Comments   
Comment by Joe Wang [ 11/Jul/11 ]

Thanks for reporting the issue.

The enforcing of JAXP security is necessary in the JDK. But we will add a way for trusted code to disable the secure mode. This will take a while to happen since it would involve API documents.

Comment by sven [ 18/Jan/12 ]

Any update on the time frame for getting this fixed? Thanks.

Comment by Joe Wang [ 18/Oct/13 ]

See https://bugs.openjdk.java.net/browse/JDK-8004476.

Comment by Joe Wang [ 17/Apr/14 ]

Refer to https://bugs.openjdk.java.net/browse/JDK-8004476, fixed in 7u60, JDK8.





[JAXP-79] NPE from marshalling an IDREF that point to a missing ID attribute value Created: 19/Mar/14  Updated: 19/Mar/14  Resolved: 19/Mar/14

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

Type: Bug Priority: Minor
Reporter: tuomas_kiviaho Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

NPE is thrown prematurely in case of an id attribute being null instead of a more appropriate validation event (Object "..." is found in an IDREF property but this object doesnt have an ID.). In order to fix this see AttributeProperty.serializeAttributes method that deals with the null correctly.

It seems that other people have had to deal this problem before (http://stackoverflow.com/questions/10705532/in-jaxb-marshalling-how-to-identify-which-child-element-caused-jaxb-marshallin). I guess that pinpointing of the cause can be quite problematic with the current behavior.

  • * * StackTrace * *

AttributeProperty<BeanT>.getIdValue(BeanT) line: 128
ClassBeanInfoImpl<BeanT>.getId(BeanT, XMLSerializer) line: 322
TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>.print(BeanT) line: 290
TransducedAccessor$IDREFTransducedAccessorImpl<BeanT,TargetT>(DefaultTransducedAccessor<T>).writeLeafElement(XMLSerializer, Name, T, String) line: 69
SingleElementLeafProperty<BeanT>.serializeBody(BeanT, XMLSerializer, Object) line: 130
ClassBeanInfoImpl<BeanT>.serializeBody(BeanT, XMLSerializer) line: 361
XMLSerializer.childAsXsiType(Object, String, JaxBeanInfo, boolean) line: 696



 Comments   
Comment by Joe Wang [ 19/Mar/14 ]

This is a JAXB issue. Please file bug in JAXB IssueTracker at https://java.net/jira/browse/JAXB/. Thanks.





[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-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-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.





[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-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-71] when XMLInputFactory IS_VALIDATING is false, DTD is still loaded Created: 24/Jun/11  Updated: 16/Mar/12  Resolved: 16/Mar/12

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

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Joe Wang
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If the IS_VALIDATING property is set to "false" in an XMLInputFactory, and then an input stream is created and an XML document with a <DOCTYPE> element is read in that references an external URL for the DTD, the DTD is loaded from the URL even though it is not needed.

The parser should skip loading the DTD if it is not needed.



 Comments   
Comment by Joe Wang [ 16/Mar/12 ]

Validating != Support DTD. Refer to http://java.net/jira/browse/SJSXP-9 and http://java.net/jira/browse/SJSXP-50, you may use the added property to skip external DTD:

xif.setProperty("http://java.sun.com/xml/stream/properties/ignore-external-dtd",Boolean.TRUE);





[JAXP-68] Infinite do-while loop in XMLDocumentScannerImpl$PrologDriver.next Created: 23/Sep/10  Updated: 07/Sep/11

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: stevehale Assignee: jaxp-issues
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 68

 Description   

It appears that the do-while loop in XMLDocumentScannerImpl$PrologDriver.next
causes an infinite loop since there are if-else conditions that do not change
the "scanner state". Similar code in XercesJ-2
XMLDocumentScannerImpl$PrologDispather.dispatch appears to have corrected the
problem.

Partial thread dump from JDK 1.6.0_15 (although current source code in JAXP
1.4.4 does not appear to have changed):
"validateClockAction-9197" daemon prio=10 tid=0x00002aab84013800 nid=0x780f
runnable [0x00000000414a6000]
java.lang.Thread.State: RUNNABLE
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
(XMLDocumentScannerImpl.java:931)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
(XMLNSDocumentScannerImpl.java:140)
at
com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next
(XMLStreamReaderImpl.java:548)
at org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke
(ReadHeadersHandler.java:44)

Source excerpt from JAXP:
do {
switch (fScannerState) {
case SCANNER_STATE_PROLOG: {
fEntityScanner.skipSpaces();
if (fEntityScanner.skipChar('<'))

{ setScannerState(SCANNER_STATE_START_OF_MARKUP); }

else if (fEntityScanner.skipChar('&'))

{ setScannerState(SCANNER_STATE_REFERENCE); }

else

{ setScannerState(SCANNER_STATE_CONTENT); }

break;
}

case SCANNER_STATE_START_OF_MARKUP: {
fMarkupDepth++;

if (fEntityScanner.skipChar('?'))

{ setScannerState(SCANNER_STATE_PI); }

else if (fEntityScanner.skipChar('!')) {
if (fEntityScanner.skipChar('-')) {
if (!fEntityScanner.skipChar('-'))

{ reportFatalError("InvalidCommentStart", null); }

setScannerState(SCANNER_STATE_COMMENT);
} else if (fEntityScanner.skipString(DOCTYPE)) {
setScannerState(SCANNER_STATE_DOCTYPE);
Entity entity =
fEntityScanner.getCurrentEntity();
if(entity instanceof Entity.ScannedEntity)

{ fStartPos=((Entity.ScannedEntity) entity).position; }

fReadingDTD=true;
if(fDTDDecl == null)
fDTDDecl = new XMLStringBuffer();
fDTDDecl.append("<!DOCTYPE");

} else

{ reportFatalError ("MarkupNotRecognizedInProlog", null); >>>>>no change in fScannerState }

} else if (XMLChar.isNameStart
(fEntityScanner.peekChar()))

{ setScannerState(SCANNER_STATE_ROOT_ELEMENT); setDriver(fContentDriver); //from now onwards this would be handled by fContentDriver,in the same next() call return fContentDriver.next(); }

else

{ reportFatalError("MarkupNotRecognizedInProlog", null); >>>>>no change in fScannerState }

break;
}
}
} while (fScannerState == SCANNER_STATE_PROLOG || fScannerState
== SCANNER_STATE_START_OF_MARKUP );



 Comments   
Comment by Joe Wang [ 23/Sep/10 ]

Can you attach the testcase along with the xml? Thanks.

Comment by Joe Wang [ 23/Sep/10 ]

Also, justify P1 priority, could you explain what programs have been blocked?
Thanks.

Comment by stevehale [ 23/Sep/10 ]

My apologies for the "P1" status, the help on Priority just says "Most
Important" and an infinite loop is pretty important. However since it
doesn't "break" in that sense, I have moved it to "P2" priority.

Unfortunately I have been unsuccessful at capturing one of the SOAP messages
that causes the infinite loop (mainly because they are in an infinite loop), I
only have a thread dump that shows 12 threads spinning at the same line of
code, but I'm still working on it.

Comment by Joe Wang [ 23/Sep/10 ]

No problem at all. I was just trying to clarify/understand the issue since
internally, similar to Apache's "blocker", we treat P1 as must-fix before any
release can go out. We also call it a stopper. So if it's P1, I would need to
explain to approvers why it's a must-fix or what type of applications have been
blocked. Thx.

Comment by Joe Wang [ 30/Nov/10 ]

Hi Steve,

You indicated that similar code in XercesJ-2
XMLDocumentScannerImpl$PrologDispather.dispatch appears to have corrected the
problem, that is, set scanner state in the two place where errors are reported. Looking at the current Xerces code, it seems to me there's no setting scanner state when reporting errors, copied from the current version:
else

{ reportFatalError("MarkupNotRecognizedInProlog", null); }

Were you looking at sth. different from this: http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/impl/XMLDocumentScannerImpl.java?revision=572055&view=co?

Comment by stevehale [ 01/Dec/10 ]

Hey Joe, thanks so much for looking into this!

While it is true that the newer "dispatch" code also doesn't set the scanner state on errors, the new code does leave the new "again" boolean variable set to false which breaks it out of the do-while loop if the input argument "complete" is also false. Here's an example at the top of the do loop:
do {
again = false;
switch (fScannerState) {
case SCANNER_STATE_PROLOG: {
fEntityScanner.skipSpaces();
if (fEntityScanner.skipChar('<'))

{ setScannerState(SCANNER_STATE_START_OF_MARKUP); again = true; }

else if (fEntityScanner.skipChar('&'))

{ setScannerState(SCANNER_STATE_REFERENCE); again = true; }

else

{ setScannerState(SCANNER_STATE_CONTENT); again = true; }

break;
}
case SCANNER_STATE_START_OF_MARKUP: {
fMarkupDepth++;
if (fEntityScanner.skipChar('!')) {
if (fEntityScanner.skipChar('-')) {
if (!fEntityScanner.skipChar('-'))

{ reportFatalError("InvalidCommentStart", null); }

setScannerState(SCANNER_STATE_COMMENT);
again = true;
}
else if (fEntityScanner.skipString("DOCTYPE"))

{ setScannerState(SCANNER_STATE_DOCTYPE); again = true; }

else

{ reportFatalError("MarkupNotRecognizedInProlog", null); >>>>>"again" is left false right here }

}
else if (isValidNameStartChar(fEntityScanner.peekChar()))

{ setScannerState(SCANNER_STATE_ROOT_ELEMENT); setDispatcher(fContentDispatcher); return true; }
else if (fEntityScanner.skipChar('?')) { setScannerState(SCANNER_STATE_PI); again = true; }
else if (isValidNameStartHighSurrogate(fEntityScanner.peekChar())) { setScannerState(SCANNER_STATE_ROOT_ELEMENT); setDispatcher(fContentDispatcher); return true; }

else

{ reportFatalError("MarkupNotRecognizedInProlog", null); >>>>>"again" is left false right here }

break;
}

...

} while (complete || again);

The do-while loop in the older JAXP code only checks the scanner state before looping back, but since the scanner state isn't changed then it looks like it might loop forever. As I said, I do not have a reproducible XML example so I cannot be sure this is where the infinite loop is occurring but the thread dump shows line 931 which is the while line in the old "next" method:

do {
switch (fScannerState) {
case SCANNER_STATE_PROLOG: {
fEntityScanner.skipSpaces();
if (fEntityScanner.skipChar('<'))

{ setScannerState(SCANNER_STATE_START_OF_MARKUP); }

else if (fEntityScanner.skipChar('&'))

{ setScannerState(SCANNER_STATE_REFERENCE); }

else

{ setScannerState(SCANNER_STATE_CONTENT); }

break;
}

case SCANNER_STATE_START_OF_MARKUP: {
fMarkupDepth++;

if (fEntityScanner.skipChar('?'))

{ setScannerState(SCANNER_STATE_PI); }

else if (fEntityScanner.skipChar('!')) {
if (fEntityScanner.skipChar('-')) {
if (!fEntityScanner.skipChar('-'))

{ reportFatalError("InvalidCommentStart", null); }

setScannerState(SCANNER_STATE_COMMENT);
} else if (fEntityScanner.skipString(DOCTYPE)) {
setScannerState(SCANNER_STATE_DOCTYPE);
Entity entity = fEntityScanner.getCurrentEntity();
if(entity instanceof Entity.ScannedEntity)

{ fStartPos=((Entity.ScannedEntity)entity).position; }

fReadingDTD=true;
if(fDTDDecl == null)
fDTDDecl = new XMLStringBuffer();
fDTDDecl.append("<!DOCTYPE");

} else

{ reportFatalError("MarkupNotRecognizedInProlog", null); }

} else if (XMLChar.isNameStart(fEntityScanner.peekChar()))

{ setScannerState(SCANNER_STATE_ROOT_ELEMENT); setDriver(fContentDriver); //from now onwards this would be handled by fContentDriver,in the same next() call return fContentDriver.next(); }

else

{ reportFatalError("MarkupNotRecognizedInProlog", null); }

break;
}
}
} while (fScannerState == SCANNER_STATE_PROLOG || fScannerState == SCANNER_STATE_START_OF_MARKUP );
>>>>>>while above is line 931, where the infinite looping thread is at according to the thread dump

Comment by Joe Wang [ 01/Dec/10 ]

I see. So what did you get when you run your test, Out Of Memory Errors or StackOverflowError? It would be nice if you could reproduce it and attach an xml instance file (without sensitive information). The reason I ask this is that the dead loop you've seen would not happen after reporting fatal error. You're using StreamReader, the StaxErrorReporter would throw exception on fatal errors.

Comment by stevehale [ 01/Dec/10 ]

I apologize for not being able to capture an example XML that would consistently reproduce an infinite loop. Unfortunately we have only seen this in a production environment with heavy load, and only very rarely (7 occurrences out of tens of thousands). It did not get an Out of Memory, StackOverflow, nor any other error or exception; the only sign of trouble is max'd CPU because a few threads go into a very tight infinite loop at line 931 (while condition). Because it is so rare, it may be a multi-threading synchronization issue which might not present itself with example XML.

If it is true that reportFatalError always throws an exception, then I agree that the problem isn't at the reportFatalError lines. So at this point I am at a loss. For the while loop to continue, fScannerState must be one of the two cases in the switch; yet I don't see how it could progress through the switch cases without changing the scanner state or reporting a fatal error.

I should have included the following line from the thread dump to confirm the java version, maybe we're looking at the wrong source code.
Full thread dump Java HotSpot(TM) 64-Bit Server VM (14.1-b02 mixed mode):

Our workaround: The JDK's StAX implementation in JAXP uses the JDK's SAX implementation classes directly which seems to have the problem. So although we upgraded Xerces to 2.10.0, we still had the problem. Finally we added the Woodstox StAX implementation jars to our WEB-INF/lib (already had Xerces 2.10.0 jars in there), and there have been no further issues. However we would prefer to use the StAX implementation provided by the JDK to remove the dependency on Woodstox.

Comment by Joe Wang [ 02/Dec/10 ]

I looked around the code and created a test, not that I could reproduce the situation you encountered under heavy load. First, it's a simple test to show that an exception would be thrown if there's a fatal error. It can be done easily by adding a prolog like this:
<!wrong document SYSTEM "ExternalDTD.dtd" [
<!ENTITY max "Substituted text">
]>

I found there is a possibility to continue the loop after fatal error, if continue-after-fatal-error, a Xerces feature, is somehow being true. Since you're using StAX, I would think it's not possible since JDK's StAX does not support such a feature. For example, if I try to set it on input factory, I would get an error: java.lang.IllegalArgumentException: Property http://apache.org/xml/features/continue-after-fatal-error is not supported

Is it possible it's being set by another thread? I don't see that possibility either since the factory has a private instance of property manager.

I can create a jaxp jar file removing the "continue-after-fatal-error" condition from StAX for you to test. Would you want me to send it to your java.net email?

Comment by stevehale [ 24/Jan/11 ]

Unfortunately I have not been able to capture a test case, and our client is now using the Woodstox StAX implementation to avoid this issue. I could not use your modified jaxp.jar even if you sent it to me. However I do not believe it is an issue with "continue-after-fatal-error", but I don't have much else to go on.

The only thing I have read recently is some mention of a possible infinite loop caused by a premature EOF since SJSXP avoids throwing exceptions after receiving an EOF (at least according to what I read). I have not persued this possibility in any way, it was just something I read, so thought it might help.

Comment by kln550 [ 14/Jul/11 ]

During load tests,we are still seeing infinite loop issue with JDK 1.6 update 26 stax implementation.Any resolutions for this issue.

Comment by stevehale [ 14/Jul/11 ]

kln550, I could never capture a test case in DEV environment so it makes sense that this only happens under load. Without a way to reproduce it, no one would look into it. Our workaround was to use Woodstox StAX imnplementation instead of that provided by the JDK within JAXP (see prior entries), although that would have been preferred. Maybe it will be researched if you can provide more details on how to reproduce it.

Comment by tbutcher [ 05/Sep/11 ]

We are seeing very similar symptoms with on a high-load live website. We are using Xerces to 2.10.0. The thread dump is similar but we are not using stax.

The problem seems to occur only under productions conditions and we have not been able to reproduce it in a test environment. We need to restart appservers occasionally when the number of looping threads is large enough to cause a significant CPU load.

We are not using 'continue-after-fatal-error'.

Comment by Joe Wang [ 07/Sep/11 ]

Thanks for the information.

Are you using Xerces 2.10 only, or have you tried with/without the Xerces jar? If it's Xerces 2.10 only, have you reported the issue to Apache?

Thanks.





[JAXP-69] Double-checked locking bug in javax.xml.parsers.FactoryFinder.find(String, String) Created: 03/Jun/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Resolved
Project: jaxp
Component/s: None
Affects Version/s: current
Fix Version/s: jaxp.next

Type: Bug Priority: Minor
Reporter: ryanhos Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javax.xml.parsers.FactoryFinder.find(String, String), revision 3037 contains a double checked locking bug.

The simple solution is to make static boolean field "firstTime" volatile and move the assignment "firstTime = false;" after the call to "cacheProps.load(ss.getFileInputStream(f));"

I did search for this bug, but can never seem to get good information out of JIRA's search feature. Please excuse me if I have submitted a duplicate.



 Comments   
Comment by Joe Wang [ 11/Jul/11 ]

Patch is now in the source repository. It will be integrated into an update release of jdk7 together with other fixes.

Thanks for your contribution!





[JAXP-16] Performance issue in com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM Created: 08/Mar/07  Updated: 07/Feb/11  Resolved: 07/Feb/11

Status: Closed
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: current

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

Operating System: All
Platform: All


Attachments: File JaxbTest2.jps    
Issuezilla Id: 16

 Description   

The constructor reads:

public SAX2DOM() throws ParserConfigurationException

{ final DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); _document = factory.newDocumentBuilder().newDocument(); _root = _document; }

but this is very slow, as DocumentBuilderFactory.newInstance() takes a
significant time to run, then newDocumentBuilder() takes even more time to run.

The whole effort is more or less wasted, because all you do is to create a empty
document, which internally just invokes new
c.s.o.a.xerces.internal.dom.DocumentImpl()

I recommend either using a cached DocumentBuilder (synchronizing it shouldn't be
a problem, or use ThreadLocal), or given that this code is in the JAXP RI, hard
code JAXP RI's own Document class.

One of the JAXB users reported that this code alone is taking up more than 60%
of the entire unmarshalling processing.



 Comments   
Comment by kohsuke [ 08/Mar/07 ]

Created an attachment (id=5)
JProfiler profiler data file contributed by the user

Comment by kohsuke [ 08/Mar/07 ]

Also see http://forums.java.net/jive/thread.jspa?messageID=206299#206299 for the
relevant forum discussion.

Comment by Joe Wang [ 07/Feb/11 ]

Resolved in the fix for 6660724 (http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=7a552d1ebeec66b51d0ec77dba8c?bug_id=6660724)





[JAXP-3] XPath expressions cannot match the default namespace Created: 16/May/05  Updated: 30/Nov/10  Resolved: 30/Nov/10

Status: Closed
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: syedfazal Assignee: ndw
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3

 Description   

XPath expressions cannot match the default namespace. This is because, while
evaluating the xpath expression in the document, the evaluate function
implementation doesn't call getNamespaceUri for default namespace prefix.

The constant defained for default namespace in XMLConstants could be used to
store as well as fetch the namespace uri for the default namespace prefix.

NOTE: Looks like this is a very well know issue in java community. Its even
been published in "Processing XML with Java" book by "Elliotte Rusty Harold".
Wondering how it has not been handled till now.



 Comments   
Comment by lindstro [ 29/Aug/06 ]

Assigning bug to Norm.

Comment by ndw [ 25/Mar/08 ]

Is your concern the following:

Given:

<foo xmlns="http://example.com/ns/"/>

the XPath expression "foo" does not select that element?

If that's the case, then this is not a bug. In an XPath expression, an element
name without a prefix is always in no-namespace, irrespective of the current
default namespace.

Comment by Joe Wang [ 30/Nov/10 ]

Closing as not a bug since there's no response to Norm's comment.





[JAXP-67] StAXEvent2SAX.handleEndElement() iterates over Namespaces as Strings Created: 27/Aug/10  Updated: 27/Aug/10

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: poutsma Assignee: jaxp-issues
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 67

 Description   

In StAXEvent2SAX.handleEndElement(), line 357, an iterator is created that iterates over the namespaces of the Stax EndElement. The namespaces are
casted to Strings, while the javadoc for EndElement clearly states that the returned iterator iterates over javax.xml.stream.events.Namespace objects. See
http://download.oracle.com/javase/6/docs/api/javax/xml/stream/events/EndElement.html#getNamespaces()

Needless to say, this results in ClassCastExceptions, for instance when used with the Woodstox Stax implementation, version 3.2.9.



 Comments   
Comment by poutsma [ 27/Aug/10 ]

Here is a little code snippet that reproduces this bug:

String xml = "<root xmlns='http://springframework.org'><child>Foo</child></root>";
XMLInputFactory inputFactory = XMLInputFactory.newInstance();
XMLEventReader eventReader = inputFactory.createXMLEventReader(new StringReader(xml));

Transformer transformer = TransformerFactory.newInstance().newTransformer();

transformer.transform(new StAXSource(eventReader), new StreamResult(System.out));

Comment by poutsma [ 27/Aug/10 ]

This bug also occurs with the Stax RI.





[JAXP-66] NullPointerException thrown by SchemaFactory.newSchema(Source[] schemas) when a source contains a system-id producing an IOException when accessed and no ErrorHandler has been set on the factory. Created: 26/Jun/10  Updated: 26/Jun/10

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: schulte2005 Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 66

 Description   

java.lang.NullPointerException
at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255)

Code producing the NullPointerException in class
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory is:

try

{ fXMLSchemaLoader.loadGrammar(xmlInputSources); }


catch (XNIException e)

{ // this should have been reported to users already. throw Util.toSAXException(e); }


catch (IOException e)

{ // this hasn't been reported, so do so now. SAXParseException se = new SAXParseException(e.getMessage(),null,e); fErrorHandler.error(se); ^^^^^^^^^^^^^ null by default throw se; // and we must throw it. }




[JAXP-63] attribute is accessible with invalid namespace Created: 18/Mar/10  Updated: 21/May/10  Resolved: 21/May/10

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: Pavel Bucek Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File SAXParserTest.java    
Issuezilla Id: 63

 Description   

attributes with defined prefix (namespace) is accessible with "empty" namespace.

for example

xml: <prefix:rootElem xmlns:prefix="something" prefix:attr="attrValue" />

code:
public void startElement(String uri, String localName, String qName,
Attributes atts) throws SAXException

{ super.startElement(uri, localName, qName, atts); String attr_WithNs = atts.getValue("something", "attr"); String attr_NoNs = atts.getValue("", "attr"); }

attr_NoNs should be null but atts.getValue returns same thing as is set in
attr_WithNs.

This is confirmed regression (introduced in JDK6_18, present in OpenJDK7).



 Comments   
Comment by Pavel Bucek [ 18/Mar/10 ]

Created an attachment (id=23)
testcase

Comment by Joe Wang [ 18/Mar/10 ]

thanks

Comment by Martin Grebac [ 16/Apr/10 ]

Hi, this is an imortant issue wrt JAXB. What is the timeframe for JDK fix? I
hope it's going to be in the next available JDK update.

Comment by Joe Wang [ 20/May/10 ]

Refer to 6949607. Fixed in jaxp 1.4 and integrated into jdk6 update 21.

Comment by Martin Grebac [ 21/May/10 ]

Perfect, thanks!





[JAXP-65] Insufficient checking of names of schema entities Created: 06/May/10  Updated: 06/May/10

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: Martin Grebac Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh
URL: https://jaxb.dev.java.net/issues/show_bug.cgi?id=713


Attachments: Zip Archive 713.zip    
Issuezilla Id: 65

 Description   

Please see https://jaxb.dev.java.net/issues/show_bug.cgi?id=713 for description.
Parser should normalize the attribute values, and it seems there are cases where
this is not being done properly.



 Comments   
Comment by Martin Grebac [ 06/May/10 ]

Created an attachment (id=24)
testcase





[JAXP-64] FATAL ERROR: 'Could not compile stylesheet' when element contains open curly brace in string literal. Created: 25/Mar/10  Updated: 25/Mar/10

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: vanaltj Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC
URL: https://bugzilla.redhat.com/show_bug.cgi?id=573619


Issuezilla Id: 64

 Description   

See URL for issue as reported in openjdk on Fedora. Reproducer and instructions
therein.

To elaborate, I've determined that only an open curly brace triggers this issue,
not closing braces. The parseAVTemplate() function in
com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java
from the source bundle for openjdk6 reports an error to the parser upon any "{"
token found while IN_EXPR, IN_EXPR_SQUOTES, or IN_EXPR_DQUOTES, so that
compilation is seen as failed later on.

Afaict, upstream xalan-j has analogous code in
org/apache/xalan/templates/AVT.java, where they loop after finding a quote
within an expression, accepting anything within quotes as literal, avoiding this
problem.






[JAXP-62] QName.equals(...) optimization Created: 17/Mar/10  Updated: 18/Mar/10  Resolved: 18/Mar/10

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Major
Reporter: dmpetersson Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 62

 Description   

public final boolean equals(Object objectToTest) {
if (objectToTest == this)

{ return true; }

if (objectToTest == null || !(objectToTest instanceof QName))

{ return false; }

QName qName = (QName) objectToTest;

return localPart.equals(qName.localPart)
&& namespaceURI.equals(qName.namespaceURI);
}



 Comments   
Comment by Joe Wang [ 17/Mar/10 ]

Refer to the original submission Issue 61.

Comment by Joe Wang [ 18/Mar/10 ]

refer to issue 61.





[JAXP-61] Perf. optimization for QName.equals(...) Created: 17/Mar/10  Updated: 18/Mar/10  Resolved: 18/Mar/10

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 61

 Description   

Current implementation of QName.equals(...) is correct but can be made faster by:
1) comparing objectToTest with this

2) changing the order of the compare of namespace and localpart. Since the
localpart of a FQ-name changes more frequently then the namespace we can gain
performance by changing this order.



 Comments   
Comment by Joe Wang [ 17/Mar/10 ]

Patch is provided in issue 62.

Comment by Joe Wang [ 18/Mar/10 ]

Patch applied to both impls in the API and Xerces package. This change is now
in JAXP 1.4 on java.net.

Thanks again for your contribution!





[JAXP-60] [PATCH] XSLTC ignores XPath predicates in xsl:key elements Created: 26/Jan/10  Updated: 11/Feb/10  Resolved: 11/Feb/10

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Task Priority: Blocker
Reporter: heschulz Assignee: Joe Wang
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://issues.apache.org/jira/browse/XALANJ-2438


Attachments: Text File PredicateInKey-JAXP-CVS.patch     Text File PredicateInKey-Sun-JRE-1_5_0_22.patch     Text File PredicateInKey-Sun-JRE-1_6_0_18.patch     Java Source File PredicateInKeyTest.java     XML File PredicateInKeyTest.xml     XML File PredicateInKeyTest.xsl    
Issuezilla Id: 60

 Description   

The Apache Xalan-J XSLT compiler (XSLTC) used in JAXP and Java runtimes ignores
XPath predicates in xsl:key elements since the class
'org.apache.xalan.xsltc.compiler.Stylesheet' was rearranged in august 2003 to
reorder the compilation of top level XSLT elements (including keys) to respect
dependencies between global XSLT variables and keys. Method 'compileTopLevel'
was changed to emit code also for key elements and not emit code calling the
method generated by 'compileBuildKeys'. For this reason the byte code for each
key element is generated twice: First time into generated method 'buildKeys'
from 'compileBuildKeys' and second time into generated method 'topLevel' from
'compileTopLevel'. Method 'buildKeys' is still necessary, because it is called
by the XSLT 'document' function, if additional input documents are loaded later.

Unfortunately the translate method of some XPath elements expected to be called
only once and they remove sub elements while their first execution. So all XPath
predicates get lost in class 'org.apache.xalan.xsltc.compiler.FilterExpr' and
'org.apache.xalan.xsltc.compiler.Step' by a remove operation on the
'_predicates' container while the execution from 'compileBuildKeys'. So
'compileTopLevel' generates wrong code for all key elements containing
predicates in their XPath expressions.

The attached patch changes the 'FilterExpr', 'ParentLocationPath' and 'Step'
class to use an index variable to determine the current predicate and to not
remove them. This patch was tested with the current CVS version of JAXP, the
current Subversion version of Xalan (last change of Xalan tree in revision
889881) and with Sun JDK 1.5.0_14, 1.5.0_15, 1.6.0_04, 1.6.0_05 and 1.6.0_18.
This bug exists also in Sun JRE 1.6 (1.6.0 up to 1.6.0_18) and JRE 1.5 (since
1.5.0_12 up to 1.5.0_22). The last Sun JRE version with correct handling of
xls:key elements is 1.5.0_11.

I submitted my patch in March 2008 to the Apache Xalan-J project and file a bug
report directly to Sun Microsystems with a hyperlink to my patch in the Apache
bug tracker. Here are these entries:

<http://issues.apache.org/jira/browse/XALANJ-2438>
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6689809>

My contribution to the Apache Xalan-J project inside the Jira bug tracker
contains a test program as JAR file to diagnose the problem and fixes in form of
JAR files to be installed into '../jre/lib/endorsed' directories of Sun JRE
installations.

The first version of my patch submitted in March 2008 caused an infinite
recursion with certain XPath expressions. The JAXP regression tests
'bug6175602/Test.java' and 'bug6537167/Test.java' failed for this reason (see
<https://jaxp-sources.dev.java.net/source/browse/jaxp-sources/jaxp-ri/src/unit-test/>).
The new version from January 2010 solve this problem. Please take a look on the
test protocols in the Apache bug tracker entry.

I started a discussion topic about this patch and the consequences to the
OpenSHORE open source project here:

<http://sourceforge.net/projects/openshore/forums/forum/223377/topic/3530816>


Helge Schulz – http://OpenSHORE.org



 Comments   
Comment by heschulz [ 26/Jan/10 ]

Created an attachment (id=17)
Patch for current CVS JAXP version

Comment by heschulz [ 26/Jan/10 ]

Created an attachment (id=18)
Patch for Sun JRE 1.5.0_22 alias 5.0u22

Comment by heschulz [ 26/Jan/10 ]

Created an attachment (id=19)
Patch for Sun JRE 1.6.0_18 alias 6.0u18

Comment by Joe Wang [ 26/Jan/10 ]

Thanks Helge. I'll look into it once I have circles. The original web
submission was marked as a P4 unfortunately. But I'll raise the priority after
fixing it in jaxp and try getting it integrated into jdk6 as early as I can.

Comment by heschulz [ 01/Feb/10 ]

Hello Joe,

thank you for your message and starting with this issue. Any progress so far?

Do you now why JDK Hello Joe,

thank you for your message and starting with this issue. Any progress so far?

Do you now why JDK bug 6689809 got the lowest priority and who has decided this?

Who can raise this priority? The issue has now 8 votes.

Will my patch be integrated in JDK 1.6.0_19 alias 6.0u19 or probably later?

Regards, Helge


Helge Schulz - http://OpenSHORE.org got the lowest priority and who has decided this?

Who can raise this priority? The issue has now 8 votes.

Will my patch be integrated in JDK 1.6.0_19 alias 6.0u19 or probably later?

Regards, Helge


Helge Schulz - http://OpenSHORE.org

Comment by Joe Wang [ 02/Feb/10 ]

Hi Helge,

Unfortunately, the JAXP-sources was locked for jaxp 1.4.3 release build and jdk
integration before this issue was filed. This patch therefore could not go into
the current release.

As you may know, we are undergoing a Sun-to-Oracle transition. I believe the
focus for the JDK would be that as well. I'll let you know once I have more
details.

Thanks,
Joe

Comment by heschulz [ 09/Feb/10 ]

Created an attachment (id=20)
JUnit test class

Comment by heschulz [ 09/Feb/10 ]

Created an attachment (id=21)
JUnit stylesheet resource file

Comment by heschulz [ 09/Feb/10 ]

Created an attachment (id=22)
JUnit input resource file

Comment by heschulz [ 09/Feb/10 ]

Hello Joe,

I have uploaded a simple JUnit test class with associated resource files. These
files contain a Glassfish conform copyright header. So you can include them into
the JAXP CVS.

I released more extensive tests in March 2008 under the Apache license 2.0. You
can download them from the Apache Xalan-J issue tracker. Because Sun
Microsystems copied Xalan-J files under exclusive Apache license 2.0 into JAXP
and every JRE/JDK (especially all files in package
'com.sun.org.apache.xalan.internal'), I think it should be no problem to include
further files with this license into JAXP CVS.

Regards, Helge

Comment by Joe Wang [ 11/Feb/10 ]

I have applied the patch to jaxp source and verified that the new patch passed
all of our regression tests. The new patch is now in JAXP 1.4 sources. 6689809
will also be updated (I'm not sure how long it would take for changes to appear
on bugs.sun.com).

Thanks again for your contribution!

Joe

Comment by heschulz [ 11/Feb/10 ]

Hello Joe,

very many thanks for applying my patch and resolving this issue.

Many greetings, Helge


Helge Schulz - http://OpenSHORE.org





[JAXP-59] SAXParser should provide a way to reset SymbolTable, to enable pooling of parsers Created: 23/Sep/09  Updated: 23/Sep/09

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kumarjayanti Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 59

 Description   

The SAAJ RI tries to Pool SAXParser instances for efficiency. But it appears
that class com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl
adds all the symbols to the Xerces SymbolTable associated with the SAXParser.

Since the SymbolTable is never reset or cleared, over time as we parse new types
of messages (or even the same message, with different namespaces used), over
time the SymbolTable will fill up.

We tried calling reset() on the parser before returning to the pool but that
does not apparently clear the SymbolTable.

I will create a Testcase that shows the problem soon.

Please see the related issue where the User has stated more details :
https://saaj.dev.java.net/issues/show_bug.cgi?id=46






[JAXP-58] XML processing instruction parsing error Created: 08/Jun/09  Updated: 11/Jun/09  Resolved: 11/Jun/09

Status: Closed
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: kats Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 58

 Description   

A piece of code that we have that used to work in Java 1.5/JAXP 1.3 is broken
in Java 1.6/JAXP 1.4. Here is a boiled-down version of the java code that
demonstrates the problem. The output from the java file should be "foo", but
comes out as "". The XML in question starts with a processing instruction and
no prolog, but I think the parser gets confused and treats it as the prolog but
throws away the data.. not really sure.

import java.io.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import com.sun.org.apache.xerces.internal.parsers.*;

class test {
public static void main( String[] args ) throws Exception

{ ByteArrayInputStream bais = new ByteArrayInputStream( "<?xmltarget foo? ><test></test>".getBytes() ); DOMParser p = new DOMParser(); p.parse( new InputSource( bais ) ); System.out.println( ( (ProcessingInstruction)p.getDocument().getFirstChild () ).getData() ); }

}



 Comments   
Comment by Joe Wang [ 10/Jun/09 ]

Tested in jdk5u11 and 18. The issue appears in jdk6 and current jaxp workspace.

Comment by Joe Wang [ 11/Jun/09 ]

Fixed in jaxp 1.4 repository. We will arrange for integration into jdk6 update
release and jdk7. Meanwhile, you may place the jaxp-ri.jar in the endorsed dir
to override existing jdks. See also http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=6849942

Comment by kats [ 11/Jun/09 ]

Excellent, thanks for the quick fix!

Comment by Joe Wang [ 11/Jun/09 ]

It's a pleasure. Hope it's helpful to your project





[JAXP-52] Identity tranformation doesn't do namespace processing by default Created: 31/Mar/08  Updated: 24/Mar/09  Resolved: 24/Mar/09

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: jitu Assignee: Joe Wang
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File Test.java     XML File test.wsdl    
Issuezilla Id: 52

 Description   

JDK6u2 (and probably in all JDK6 versions) where the identity tranformation
doesn't do namespace processing by default. In the following case:

transformer.transform(StreamSource, SAXResult)

SAXResult's ContentHandler's startElement() is invoked and its
Attributes[i].getLocalName return "" for xmlns="..." attribute in a infoset.

The same thing works fine with JDK5. Let me know if you need a test case.



 Comments   
Comment by jitu [ 01/Apr/08 ]

Created an attachment (id=15)
Java source

Comment by jitu [ 01/Apr/08 ]

Created an attachment (id=16)
infoset

Comment by jitu [ 01/Apr/08 ]

Don't know whether JDK5 is correct or JDK6. Here is the difference.

jitu@araku:/home/jk144508/public_html/224/jaxp-transformer-bug$
~/jdk1.6.0_04/bin/java Test
...

http://www.w3.org/2000/xmlns/ xmlns xmlns
...
jitu@araku:/home/jk144508/public_html/224/jaxp-transformer-bug$
~/jdk1.5.0_12/bin/java Test
...
http://www.w3.org/2000/xmlns/ xmlns
...
Comment by Joe Wang [ 23/Apr/08 ]

assigned.

Comment by Joe Wang [ 24/Mar/09 ]

The difference in the two tests you mentioned, one uses a TransformerHandler
and the other uses a transformer, is that the TransformerHandler is capable of
handling SAX events while a transformer needs to create its own XMLReader to
parse the source. The XMLReader created internally has different environmental
settings than that created in the first test. One way to get around this is to
pass an XMLReader similar to the one in the first test to the transformer by
creating a SAXSource which can take an XMLReader and InputSource. Did it work
for you?





[JAXP-53] issue with StreamSource.getSystemId() Created: 04/Jul/08  Updated: 20/Mar/09  Resolved: 20/Mar/09

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: kumarjayanti Assignee: jaxp-issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 53

 Description   

I am using JDK 5 and when i try the following code :

-----------------------------------
import java.io.File;
import javax.xml.transform.stream.StreamSource;

/**
*

  • @author kumar.jayanti
    */
    public class Main {

/**

  • @param args the command line arguments
    */
    public static void main(String[] args) { // TODO code application logic here File f = new File("E:\\FRESH\\intern\\july03.txt"); StreamSource s = new StreamSource(f); System.out.println(s.getSystemId()); }

}
-------------------------------

It prints out : file:///E:/FRESH/intern/july03.txt

However when i installed JAXP 1.4 (in jre/lib/endorsed) by downloading latest
JAXP bits from :

https://jaxp.dev.java.net/servlets/ProjectDocumentList?folderID=4585&expandFolder=4585&folderID=0

then the same propgram prints out :file:/E:/FRESH/intern/july03.txt

And this is incorrect IMO. This is causing regression in some SAAJ dev tests.



 Comments   
Comment by Joe Wang [ 20/Mar/09 ]

I would agree that the format is incorrect. However, JAXP relies upon file.toURI
() to produce the system id. Refer to
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751, since JDK team has
decided not to fix the issue, we would prefer leaving it as is and let JDK
handles file related processings. For example, to create a FileInputStream out
of the SystemId, use: FileInputStream fis = new FileInputStream(new File(new URI
(systemId))); instead of parsing it with an assumption that it would be in a
format such as "file:///c:/path".





[JAXP-56] SAXException doesn't do the exception chaining properly Created: 06/Feb/09  Updated: 26/Feb/09  Resolved: 26/Feb/09

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kohsuke Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 56

 Description   

SAXException still doesn't do the proper exception chaining, masking the root
cause of the problem.

Add the following method to SAXException:

public Throwable getCause() {
return exception;
}



 Comments   
Comment by Joe Wang [ 26/Feb/09 ]

see 6809409.

Comment by Joe Wang [ 26/Feb/09 ]

see 6809409.





[JAXP-57] XMLGregorianCalendar's method "toString()" sometimes brakes ISO date format in fractional seconds Created: 19/Feb/09  Updated: 19/Feb/09

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: genoko Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 57

 Description   

XMLGregorianCalendar is used by JAX-WS to generate values for xs:dateTime in XML
documents. Sometimes, the output is broken and contains illegal characters; here
"E-9" instead of fractional seconds.

The code of my converter routine is:
public static final XMLGregorianCalendar xmlValueOf(
java.sql.Timestamp sqlValue )
{
logger.log(
Level.FINE, "java.sql.Timestamp sqlValue=

{0}", sqlValue.toString() );
if (sqlValue == null) { return null; }
GregorianCalendar calendar = new GregorianCalendar(UTC_TZ, Locale.ROOT);
logger.log(Level.FINER, "GregorianCalendar calendar={0}

", calendar);
calendar.setTime(new Date(sqlValue.getTime()));
logger.log(Level.FINER, "GregorianCalendar calendar=

{0}", calendar);
XMLGregorianCalendar result
= datatypeFactory.newXMLGregorianCalendar(calendar);
logger.log(Level.FINER, "XMLGregorianCalendar result={0}

", result);
int sqlNanoseconds = sqlValue.getNanos();
logger.log(
Level.FINER, "java.sql.Timestamp int nanoseconds=

{0}", sqlNanoseconds );
BigDecimal nanoseconds = new BigDecimal(sqlNanoseconds);
logger.log(Level.FINER, "BigDecimal nanoseconds={0}

", nanoseconds);
BigDecimal nanosecondsFractional
= nanoseconds.divide(BILLION, 9, RoundingMode.HALF_UP);
logger.log(
Level.FINER,
"BigDecimal nanosecondsFractional=

{0}", nanosecondsFractional );
result.setFractionalSecond(nanosecondsFractional);
logger.log(Level.FINE, "XMLGregorianCalendar result={0}

", result);
return result;
}

And here is an example for broken output:

FEIN: java.sql.Timestamp sqlValue=2009-02-01 00:00:00.0
FEINER: GregorianCalendar
calendar=java.util.GregorianCalendar[time=1235046117468,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2009,MONTH=1,WEEK_OF_YEAR=8,WEEK_OF_MONTH=3,DAY_OF_MONTH=19,DAY_OF_YEAR=50,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=3,AM_PM=1,HOUR=0,HOUR_OF_DAY=12,MINUTE=21,SECOND=57,MILLISECOND=468,ZONE_OFFSET=0,DST_OFFSET=0]
FEINER: GregorianCalendar
calendar=java.util.GregorianCalendar[time=1233446400000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2009,MONTH=1,WEEK_OF_YEAR=6,WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=32,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]
FEINER: XMLGregorianCalendar result=2009-02-01T00:00:00.000Z
FEINER: java.sql.Timestamp int nanoseconds=0
FEINER: BigDecimal nanoseconds=0
FEINER: BigDecimal nanosecondsFractional=0
FEIN: XMLGregorianCalendar result=2009-02-01T00:00:00E-9Z

The XML SOAP request sent included the following broken xs:dateTime value:

<startUTC>2009-02-01T00:00:00E-9Z</startUTC>

It seems that "setFractionalSecond()" triggers the error here.

We need microseconds in our application, therefore "java.util.Date" or
"java.util.GregorianCalendar" is not useable.






[JAXP-55] javax.xml.validation.Schema is not thread safe Created: 17/Nov/08  Updated: 18/Nov/08

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: armsargis Assignee: jaxp-issues
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC
URL: http://forums.sun.com/thread.jspa?threadID=5348262&tstart=0


Issuezilla Id: 55

 Description   

According documentation:

A Schema object is thread safe and applications are encouraged to share it
across many parsers in many threads.

But I have problem when sharing schema instance, here is my code:

package com.sargis;

import org.w3c.dom.Document;
import org.xml.sax.ErrorHandler;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;

import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.Source;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Validator;
import java.io.File;
import java.io.FileFilter;
import java.io.IOException;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class XMLValidationTest {

private static final int NTHREADS = 25;
private static final ExecutorService EXEC = Executors.newCachedThreadPool();

private static final CyclicBarrier BARRIER = new CyclicBarrier(NTHREADS);

public static final String IN_FOLDER =
"/home/sargis/projects/twm/branches/ng/epayment/Vasp/dist/inout/in";
public static final String XSD_PATH =
"/home/sargis/projects/twm/branches/ng/epayment/Vasp/config/epayoth.xsd";

private static Schema schema;

public static void main(String[] args) {

SchemaFactory factory =
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Source schemaFile = new StreamSource(XSD_PATH);
try

{ schema = factory.newSchema(schemaFile); }

catch (SAXException e)

{ e.printStackTrace(); System.exit(-1); }

File incoming = new File(IN_FOLDER);
File[] files = incoming.listFiles(new FileFilter() {
public boolean accept(File file)

{ return file.isFile() && file.getName().endsWith(".xml"); }

});

for (int i = 0; i < files.length; i++)

{ EXEC.execute(new XMLValiddator(files[i], i)); }

EXEC.shutdown();
}

private static class XMLValiddator implements Runnable {

private File file;
private int index;

public XMLValiddator(File file, int index)

{ this.file = file; this.index = index; }

public void run() {

try

{ System.out.printf("Waiting for barrier: %s%n", index); BARRIER.await(); System.out.println("Validating...."); DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); DocumentBuilder builder = factory.newDocumentBuilder(); Document document = builder.parse(file); Validator validator = schema.newValidator(); validator.setErrorHandler(new ErrorHandlerImpl()); validator.validate(new DOMSource(document)); }

catch (IOException e)

{ e.printStackTrace(); } catch (SAXException e) { e.printStackTrace(); }

catch (ParserConfigurationException e)

{ e.printStackTrace(); } catch (BrokenBarrierException e) { e.printStackTrace(); }

catch (InterruptedException e)

{ e.printStackTrace(); }

}
}

private static class ErrorHandlerImpl implements ErrorHandler {

public void warning(SAXParseException exception) throws SAXException

{ System.out.printf("**Parsing Warning. Line: %s URI: %s Message: %s%n", exception.getLineNumber(), exception.getSystemId(), exception.getMessage()); }

public void error(SAXParseException exception) throws SAXException

{ String msg = String.format("**Parsing Error. Line: %s URI: %s Message: %s%n", exception.getLineNumber(), exception.getSystemId(), exception.getMessage()); System.out.println(msg); throw new SAXException(msg); }

public void fatalError(SAXParseException exception) throws SAXException

{ String msg = String.format("**Parsing Fatal Error. Line: %s URI: %s Message: %s%n", exception.getLineNumber(), exception.getSystemId(), exception.getMessage()); System.out.println(msg); throw new SAXException(msg); }

}

}

Here is my XSD:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

<xs:element name="eOtherPayment">
<xs:complexType>
<xs:sequence>
<xs:element ref="OtherPaymentSerialID"/>
<xs:element ref="CustomsCode"/>
<xs:element ref="DeclarantCode"/>
<xs:element ref="CompanyCode"/>
<xs:element ref="BankCode"/>
<xs:element ref="Transactions"/>
<xs:element ref="Payments"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="OtherPaymentSerialID">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="CustomsCode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z0-9]

{4}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="DeclarantCode">
<xs:simpleType>
<xs:restriction base="U">
<xs:minLength value="0"/>
<xs:maxLength value="17"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="CompanyCode">
<xs:simpleType>
<xs:restriction base="U">
<xs:minLength value="0"/>
<xs:maxLength value="17"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="BankCode">
<xs:simpleType>
<xs:restriction base="U">
<xs:minLength value="1"/>
<xs:maxLength value="17"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="Transactions">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="10" ref="TransactionRecord"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="TransactionRecord">
<xs:complexType>
<xs:sequence>
<xs:element name="Code">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z0-9]{1,3}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element ref="RefOffice"/>
<xs:element ref="RefYear"/>
<xs:element ref="RefSerial"/>
<xs:element ref="RefNumber"/>
<xs:element ref="TransactionReference"/>
<xs:element name="Amount" type="NMU"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="RefOffice">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z0-9]{0,4}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="RefYear">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([0-9]){0}|([0-9]){4}

"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="RefSerial">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]

{0,1}

"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="RefNumber">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([0-9])*"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="TransactionReference">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="35"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="Payments">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="10" ref="MeansOfPayment"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="MeansOfPayment">
<xs:complexType>
<xs:sequence>
<xs:element ref="Code"/>
<xs:element ref="Reference"/>
<xs:element name="Amount" type="NMU"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="Code">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z0-9]

{2}

"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="Reference">
<xs:simpleType>
<xs:restriction base="U">
<xs:minLength value="1"/>
<xs:maxLength value="17"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:simpleType name="NMU">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0"/>
<xs:fractionDigits value="2"/>
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="U">
<xs:restriction base="xs:string">
<xs:pattern value="([!-`]|[{-~])*"/>
</xs:restriction>
</xs:simpleType>

</xs:schema>

and XML template

<?xml version="1.0" encoding="UTF-8"?>

<eOtherPayment>

<OtherPaymentSerialID>b972115d-829e-43ff-aebb-c7157ef25c71</OtherPaymentSerialID>
<CustomsCode>01AP</CustomsCode>
<DeclarantCode>A9901017</DeclarantCode>
<CompanyCode>A0500823</CompanyCode>
<BankCode>221</BankCode>
<Transactions>
<TransactionRecord>
<Code>89</Code>
<RefOffice>01AP</RefOffice>
<RefYear>2008</RefYear>
<RefSerial>A</RefSerial>
<RefNumber>68</RefNumber>
<TransactionReference>KJ091</TransactionReference>
<Amount>5000</Amount>
</TransactionRecord>
<TransactionRecord>
<Code>97</Code>
<RefOffice/>
<RefYear/>
<RefSerial/>
<RefNumber/>
<TransactionReference>LL091</TransactionReference>
<Amount>68700</Amount>
</TransactionRecord>
<TransactionRecord>
<Code>98</Code>
<RefOffice/>
<RefYear/>
<RefSerial/>
<RefNumber/>
<TransactionReference>HH098</TransactionReference>
<Amount>8000</Amount>
</TransactionRecord>
<TransactionRecord>
<Code>96</Code>
<RefOffice/>
<RefYear/>
<RefSerial/>
<RefNumber/>
<TransactionReference>PO091</TransactionReference>
<Amount>7500</Amount>
</TransactionRecord>
<TransactionRecord>
<Code>92</Code>
<RefOffice/>
<RefYear/>
<RefSerial/>
<RefNumber/>
<TransactionReference>098</TransactionReference>
<Amount>14000</Amount>
</TransactionRecord>
</Transactions>
<Payments>
<MeansOfPayment>
<Code>21</Code>
<Reference>EF01</Reference>
<Amount>26800</Amount>
</MeansOfPayment>
<MeansOfPayment>
<Code>22</Code>
<Reference>G</Reference>
<Amount>15000</Amount>
</MeansOfPayment>
<MeansOfPayment>
<Code>20</Code>
<Reference>HH</Reference>
<Amount>9810</Amount>
</MeansOfPayment>
<MeansOfPayment>
<Code>20</Code>
<Reference>DEE</Reference>
<Amount>51590</Amount>
</MeansOfPayment>
</Payments>
</eOtherPayment>

just create 25 XML files in IN_FOLDER folder and run my code. Here is exception:

**Parsing Error. Line: -1 URI: null Message: cvc-complex-type.2.4.d: Invalid
content was found starting with element '

{TransactionRecord}

'. No child element
is expected at this point.

at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:410)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3153)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3076)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:2978)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2121)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:791)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.finishNode(DOMValidatorHelper.java:338)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:243)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:100)
at javax.xml.validation.Validator.validate(Validator.java:127)
at com.sargis.XMLValidationTest$XMLValiddator.run(XMLValidationTest.java:87)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
org.xml.sax.SAXException: **Parsing Error. Line: -1 URI: null Message:
cvc-complex-type.2.4.b: The content of element 'Payments' is not complete. One
of '

{MeansOfPayment}' is expected.

at com.sargis.XMLValidationTest$ErrorHandlerImpl.error(XMLValidationTest.java:115)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:410)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3147)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3076)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:2978)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2121)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:791)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.finishNode(DOMValidatorHelper.java:338)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:243)
at
com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:100)
at javax.xml.validation.Validator.validate(Validator.java:127)
at com.sargis.XMLValidationTest$XMLValiddator.run(XMLValidationTest.java:87)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
**Parsing Error. Line: -1 URI: null Message: cvc-complex-type.2.4.b: The
content of element 'Payments' is not complete. One of '{MeansOfPayment}

' is
expected.



 Comments   
Comment by armsargis [ 18/Nov/08 ]

user was not assigned





[JAXP-54] Extend or change URIResolver.resolve() method for using Templates as return type. Created: 13/Oct/08  Updated: 13/Oct/08

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: jaxp.next
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: fmunafo Assignee: jaxp-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 54

 Description   

Suppose to have those three xslt files:

  • xsl1.xslt, which includes xsl3.xslt
  • xsl2.xslt, which includes xsl3.xslt
  • xsl3.xslt

In my source code I use javax.transform.Templates (xalan impl, but it doesn't
matter) for caching purpose, for example an HashMap(xslname, Templates).

I also have a class, MyUriResolver, that implements the method resolve from the
interface uriResolver.

The method resolve() return a Source.

But what if I want to have xsl3.xslt cached as a Templates and get it from my
cache when the processor calls resolve, if resolve return a Source and not a
Templates?

In other words:

First, transforming xsl1.xslt involve a call to MyUriResolver.resolve that get
and return xsl3.xslt as a Source.
Second, transforming xsl2.xslt involve a call to MyUriResolver.resolve that
again get and return xsl3.xslt as a source.

Instead I want to get xsl3.xslt as a Templates from my cache and return it, even
if I'm inside MyUriResolver.resolve.

Filippo






[JAXP-47] Xerces - complexType with simpleContent facet violation message not helpful Created: 05/Nov/07  Updated: 20/May/08  Resolved: 20/May/08

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: rgavlin Assignee: Joe Wang
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 47

 Description   

I have a maxLength facet on a complexType with simpleContent that extends a base
complexType. Schema validation performed by the included program with the
included schemas & xml file results in the stack trace listed below. Note the
message refers to the relevant anonymous type as [type 'null'] which is not
helpful. In this case, a more helpful error message would refer to either the
complexType name itself or its base type name. Should I open a JIRA for this issue?

STACK TRACE:

org.xml.sax.SAXParseException: cvc-maxLength-valid: Value '
commentZZZZZZZZZZZZZZZZZZ
' with length = '30' is not facet-valid with respect to maxLength '20' for
type 'null'.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(Unknown Source)
at org.apache.xerces.jaxp.validation.DOMValidatorHelper.finishNode(Unknown
Source)
at org.apache.xerces.jaxp.validation.DOMValidatorHelper.validate(Unknown Source)
at org.apache.xerces.jaxp.validation.DOMValidatorHelper.validate(Unknown Source)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(Unknown Source)
at javax.xml.validation.Validator.validate(Validator.java:82)
at test.XercesTest.testValidateComplexTypeWithSimpleContent(XercesTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

TEST PROGRAM:

package test;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.Source;
import javax.xml.transform.dom.DOMSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Validator;

import junit.framework.TestCase;

import org.w3c.dom.Document;
import org.xml.sax.SAXException;

public class XercesTest extends TestCase
{

public void testValidateComplexTypeWithSimpleContent() throws IOException,
ParserConfigurationException, SAXException
{
System.setProperty(
"javax.xml.parsers.DocumentBuilderFactory",
"org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");
System.setProperty(
"javax.xml.parsers.SaxParserFactory",
"org.apache.xerces.jaxp.SaxParserFactoryImpl");
System.setProperty(
"javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema",
"org.apache.xerces.jaxp.validation.XMLSchemaFactory");

DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
dFactory.setNamespaceAware(true);

String[] xsdFileNames =
new String[]

{"substitutionWithExtensionValues.xsd", "substitutionWithExtensionValues2.xsd"}

;
List xsdSourceList = new ArrayList(xsdFileNames.length);
DocumentBuilder dBuilder = dFactory.newDocumentBuilder();
for (int i = 0; i < xsdFileNames.length; i++)

{ String xsdFileName = xsdFileNames[i]; Document document = dBuilder.parse(getClass().getResourceAsStream(xsdFileName)); DOMSource domSource = new DOMSource(document); xsdSourceList.add(domSource); }

Source[] xsdSources = (Source[]) xsdSourceList.toArray(new
DOMSource[xsdSourceList.size()]);

SchemaFactory schemaFactory =
SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdSources);

String xmlFileName = "substitutionWithExtensionValues2.xml";
Document document =
dBuilder.parse(getClass().getResourceAsStream(xmlFileName));
DOMSource domSource = new DOMSource(document);

Validator validator = schema.newValidator();
validator.validate(domSource);
}

}

SUBSTITUTIONWITHEXTENSIONVALUES.XSD

<xsd:schema
targetNamespace="http://www.example.com/substitutionEV"
xmlns="http://www.example.com/substitutionEV"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sev="http://www.example.com/substitutionEV"
elementFormDefault="qualified">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<xsd:element name="results" type="sev:ResultsType" />

<xsd:element name="result" type="sev:ResultType" />
<xsd:element name="myResult" type="sev:MyResultType"
substitutionGroup="sev:result" />

<xsd:complexType name="ResultsType">
<xsd:sequence>
<xsd:element name="id" type="sev:IdType" />
<xsd:element ref="sev:result" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="comment" type="sev:CommentType" />
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResultType">
<xsd:sequence>
<xsd:element name="id" type="sev:IdType" />
<xsd:element name="name" type="xsd:string" />
<xsd:element name="value" type="sev:ValueType" />
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="MyResultType">
<xsd:complexContent>
<xsd:extension base="sev:ResultType" />
</xsd:complexContent>
</xsd:complexType>

<xsd:simpleType name="IdType">
<xsd:restriction base="sev:AsciiStringType">
<xsd:maxLength value="32" />
<xsd:pattern value="[0-9a-fA-F]*" />
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="AsciiStringType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\p

{IsBasicLatin}

*" />
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="ValueType">
<xsd:simpleContent>
<xsd:extension base="sev:Integer32Bit" />
</xsd:simpleContent>
</xsd:complexType>

<xsd:simpleType name="Integer32Bit">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="0" />
<xsd:maxInclusive value="4290000000" />
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="CommentType">
<xsd:simpleContent>
<xsd:extension base="sev:AsciiStringType">
<xsd:attribute name="language" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="English" />
<xsd:enumeration value="French" />
<xsd:enumeration value="Spanish" />
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="MyCommentType">
<xsd:simpleContent>
<xsd:restriction base="sev:CommentType">
<xsd:minLength value="0" />
<xsd:maxLength value="40" />
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

</xsd:schema>

SUBSTITUTIONWITHEXTENSIONVALUES2.XSD

<xsd:schema
targetNamespace="http://www.example.com/substitutionEV2"
xmlns="http://www.example.com/substitutionEV2"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sev2="http://www.example.com/substitutionEV2"
xmlns:sev="http://www.example.com/substitutionEV"
elementFormDefault="qualified">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->

schemaLocation="substitutionWithExtensionValues.xsd" />

<xsd:element name="allResults" type="sev2:AllResultsType" />

<xsd:complexType name="AllResultsType">
<xsd:sequence>
<xsd:element name="id" type="sev2:Id2Type" />
<xsd:element name="results" minOccurs="0" maxOccurs="unbounded"
type="sev2:Results2Type" />
<xsd:element name="comment" type="sev2:Comment2Type" />
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="Results2Type">
<xsd:complexContent>
<xsd:extension base="sev:ResultsType" />
</xsd:complexContent>
</xsd:complexType>

<xsd:simpleType name="Id2Type">
<xsd:restriction base="sev:IdType">
<xsd:maxLength value="10" />
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="Comment2Type">
<xsd:simpleContent>
<xsd:restriction base="sev:CommentType">
<xsd:minLength value="0" />
<xsd:maxLength value="20" />
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

</xsd:schema>

SUBSTITUTIONWITHEXTENSIONVALUES2.XML

<?xml version="1.0" encoding="ASCII"?>

<sev2:id>FFFFFFFFFF</sev2:id>

<sev:id>00000000000000000000</sev:id>
<sev:result>
<sev:id>11111111111111111111</sev:id>
<sev:name>name1</sev:name>
<sev:value>1</sev:value>
</sev:result>
<sev:myResult>
<sev:id>22222222222222222222</sev:id>
<sev:name>myName2</sev:name>
<sev:value>2</sev:value>
</sev:myResult>
<sev:comment>comment0</sev:comment>
</sev2:results>

<sev:id>AAAAAAAAAAAAAAAAAAAA</sev:id>
<sev:myResult>
<sev:id>BBBBBBBBBBBBBBBBBBBB</sev:id>
<sev:name>myNameB</sev:name>
<sev:value>11</sev:value>
</sev:myResult>
<sev:comment>commentA</sev:comment>
</sev2:results>
<sev2:comment language="English">
commentZZZZZZZZZZZZZZZZZZ
</sev2:comment>
</sev2:allResults>

This issue was just patched in the Apache Xerces head. I want to make sure it
gets patched in JDK Xerces fork as well. Here is the response from the Xerces
developer:

Hi Ron,

We weren't assigning an anonymous type name to the simple type. I just
committed a fix for that. If you pickup the current code from SVN you
should get "#AnonType_Comment2Type" instead of "null" as the type name in
the error message.

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org



 Comments   
Comment by rgavlin [ 05/Nov/07 ]

The link to the Apache Xerces fix is:
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/impl/xs/traversers/XSDComplexTypeTraverser.java?r1=591458&r2=591457&pathrev=591458

Comment by Joe Wang [ 29/Apr/08 ]

Correct error message.

Comment by Joe Wang [ 29/Apr/08 ]

Hi rgavlin,

The pasted XML files have some missing elements. Could you please use add the
original files as attachments?

Thanks.

Comment by Joe Wang [ 20/May/08 ]

Waiting for the submitter to provide correct xml/xsd files for the testcase.
Lowered the priority. Given that this is an error message improvement, it's
unlikely it would be accepted for jdk update releases. However, we could
definitely integrate it into JDK7.





[JAXP-49] Support dom/current-element-node property Created: 24/Jan/08  Updated: 03/Apr/08  Resolved: 03/Apr/08

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: a_ilyin Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 49

 Description   

There is the property http://apache.org/xml/properties/dom/current-element-node
which is very useful for determining error node during validation.
com.sun.org.apache.xerces.internal.impl.Constants.java has its definition but
comparing to original Xerces impl the
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.java
getProperty method lack of support of this property.

P.S. Actually there is a big problem to deal with found error. During validation
we have little information for good error handling. F.g. during in-memory DOM
validation we can get only hardcoded "strange" error message from the
SAXParseException).

I think the best way will be to change the ErrorHandler to the specialized
validation error handler like below:

public interface ValidationErrorHandler {

public boolean handleError(ErrorInformation ei);
}

where handleError will return whether validator can continue validation and
ErrorInformation has error node, error message text.
It will be great to have access to the schema part(grammar part) responsible for
this error (f.g. using Schema Object Model).



 Comments   
Comment by Joe Wang [ 19/Mar/08 ]

Yes, looks like there was a change/fix in the Xerces. I'll look into fixing it
in jaxp 1.4.

Validation error handling, as you pointed out, has a lot of room to improve.
I'll list the second part of your report as an enhancement request.

Thanks.

Comment by Joe Wang [ 03/Apr/08 ]

Fixed in jaxp 1.4. It will be included in 1.4.3 release and openJDK development.





[JAXP-40] XPathFactory.newInstance() does not use the thread context classloader Created: 05/Jul/07  Updated: 19/Mar/08

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=28049&tstart=0


Issuezilla Id: 40

 Description   

see http://forums.java.net/jive/thread.jspa?threadID=28049&tstart=0 for
background on this.
It seems that this is fixed in jaxp 1.4.2, but whatever is shipped with the JDKs
is not, despite the fact that the bug in bugparade is closed (and therefore
cannot be voted on...).

How do we go about backporting this to the JDK?



 Comments   
Comment by Joe Wang [ 19/Mar/08 ]

Yes, the issue was fix in jaxp 1.4. It's also integrated into jdk5 update 14.
Unfortunately, this is not on the top priority list for jdk6.

To answer your question about how to go about backporting this to the JDK, I
suggest call customer support and go through the customer escalation process
for 6354969, which would rise the priority.

I'll leave this open for a while.

Thanks,
Joe





[JAXP-46] Namespace problem when using DOMSource for schema validation Created: 19/Oct/07  Updated: 11/Mar/08  Resolved: 11/Mar/08

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: jitu Assignee: Joe Wang
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive case4.zip    
Issuezilla Id: 46

 Description   

When a valid DOMSource is passed for schema validation, it doesn't find some
namespaces. Attaching a testcase for this. It works for the StreamSource but not
for DOMSource.



 Comments   
Comment by jitu [ 19/Oct/07 ]

Created an attachment (id=14)
test case

Comment by Santiago Pericas-Geertsen [ 22/Oct/07 ]

I've created a unit test from the your test case, but it ran without any exceptions. I also printed out the
DOM and noticed that it was identical to 'instance.xml'. What's the exception that you're getting? Can you
try to install the latest JAXP on your JDK to see if you can reproduce the problem?

Comment by jitu [ 22/Oct/07 ]

$ java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)

$ java ValidatorTest
ERROR: 'UndeclaredPrefix: Cannot resolve 'ns2:toyota' as a QName: the prefix
'ns2' is not declared.'
Exception in thread "main" org.xml.sax.SAXParseException: UndeclaredPrefix:
Cannot resolve 'ns2:toyota' as a QName: the prefix 'ns2' is not declared.
at
com.sun.org.apache.xerces.internal.jaxp.validation.Util.toSAXParseException(Util.java:109)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ErrorHandlerAdaptor.error(ErrorHandlerAdaptor.java:104)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:429)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3185)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.getAndCheckXsiType(XMLSchemaValidator.java:2485)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1979)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:335)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:205)
at
com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:291)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.startElement(ToXMLSAXHandler.java:646)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.startElement(ToXMLSAXHandler.java:501)
at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:138)
at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:215)
at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:215)
at
com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:121)
at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:85)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:615)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:661)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:300)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.process(ValidatorImpl.java:220)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:141)
at javax.xml.validation.Validator.validate(Validator.java:82)
at ValidatorTest.validate(ValidatorTest.java:46)
at ValidatorTest.main(ValidatorTest.java:51)
[/home/jk144508/bugs/validation/case4]

I am using latest JDK. I will try using latest JAXP.

Comment by jitu [ 22/Oct/07 ]

It works with JDK 1.6.0_03 but not with JDK 1.5.0_12
Many JAX-WS users use JDK 1.5.0

Comment by Joe Wang [ 06/Nov/07 ]

I have also created a CR to be used for jdk5 integration. Refer to 6626853.

Comment by Joe Wang [ 11/Mar/08 ]

This is fixed in Jaxp 1.4 on java.net and included in the nightly build. We
have made a request to have this patch integrated in future jdk update releases.





[JAXP-51] XPath.compile() in std impl of Java5 throws XPathExpressionException with unhelpful null message Created: 13/Feb/08  Updated: 13/Feb/08

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: kwblackwell Assignee: jaxp-issues
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


Issuezilla Id: 51

 Description   

At this moment, this defect still needs some verification and qualification as
to what versions it applies to.

I noticed this using the latest Java 5 standard implementation of XPath capability.

If you feed some garbage string to an XPath object's "compile()" method, it will
throw (as expected) an XPathExpressionException. But when you call getMessage()
on that exception, it returns null. What I would expect here is a message
identifying what went wrong during the parsing or compiling, even if it is
relatively generic.

Generally speaking, exceptions with no message are reasonable only if the class
name itself is all you need to know. In this case, anyone trying to craft an
XPath expression will need more information than just that it doesn't compile.
Where was the error? What type of error was it? What token was unexpected? Etc.






[JAXP-48] Performance Issue with Xalan Transformer Created: 18/Jan/08  Updated: 02/Feb/08  Resolved: 02/Feb/08

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: kumarjayanti Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 48

 Description   

It has been observed that when using the Transfomer to convert a StreamSource to
DOMResult, the performance of Transform gets worse as the size of the
inputstream increases.

How to Reproduce :

The issue manifests in the form of Poor performance of SAAJ for Large Payloads.
SAAJ RI depends on the Transformer.

import javax.xml.soap.*;

long start = System.currentTimeMillis();
MessageFactory mf =
MessageFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
MimeHeaders hdrs = new MimeHeaders();
hdrs.addHeader("Content-Type", "application/soap+xml");
SOAPMessage sm = mf.createMessage(hdrs, new FileInputStream(new
File("msgAttach.xml")));
SOAPBody body = sm.getSOAPBody();
long end = System.currentTimeMillis();
System.out.println("Total Time Taken=" + (end - start)/1000);

Here msgAttach.xml is basically a SOAP Envelope with a large SOAPBody

------------
Profiling has shown that 99.5% of the time is being spent on in
CharacterDataImpl.appendData()

com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.characters(char[], int,
int) is calling
com.sun.org.apache.xerces.internal.dom.CharacterDataImpl.appendData(String) and
99.5% of time is spent here.



 Comments   
Comment by Joe Wang [ 02/Feb/08 ]

Assign to me

Comment by Joe Wang [ 02/Feb/08 ]

Fixed in JAXP on java.net. Simple test on a workstation (Sun Ultra 20) shows a
transformation of the provided xml file (436kb) from StreamSource to DOMResult
which took over 13 min. before now takes only 172ms after the change.

Refer also to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6652519

This fix will be integrated into future jdk5/6 update releases, and jdk7
development release.





[JAXP-50] Add SOM interface into the javax.xml.validation.Schema Created: 24/Jan/08  Updated: 24/Jan/08

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: New Feature Priority: Major
Reporter: a_ilyin Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 50

 Description   

Please add the Schema Object Model (SOM) interface into the
javax.xml.validation.Schema.

1)The jaxp lack the access to the schema grammar.
2)There is a problems to extend the validator's capabilities using
xs:annotation/xs:appInfo xsd enhancement mechanism.

.Net has such capability. Java world has at least 2 implementation of the SOM.
com.sun.xsom (xsom.dev.java.net) and org.apache.ws.commons.schema.XmlSchema
(http://ws.apache.org/commons/XmlSchema)
But neither xsom nor XmlSchema can't be used for validation. So it will be nice
to incorporate such capability directly into the javax.xml.validation.Schema.






[JAXP-44] If multiple schemas contain same targetnamespace, only the first one is used in schema validation Created: 09/Oct/07  Updated: 19/Oct/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: jitu Assignee: jaxp-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File test.zip    
Issuezilla Id: 44

 Description   

If Schema is constructed with multiple schema files and they share the same
targetnamespace, only the first is used for schema validation. This is a serious
problem and limits web services schema validation.

Attaching a test case that exhibits this behaviour. It has two runs to exhibit
this issue.



 Comments   
Comment by jitu [ 10/Oct/07 ]

Created an attachment (id=13)
test case

Comment by Santiago Pericas-Geertsen [ 18/Oct/07 ]

According to the documentation for,

http://java.sun.com/javase/6/docs/api/javax/xml/validation/SchemaFactory.html#newSchema
(javax.xml.transform.Source[])

The use of this method is equivalent to creating a single schema with a different targetns (and no
components) where all the other schemas are imported. In this case this would be equivalent to:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="foo"
elementFormDefault="qualified">

<xsd:import schemaLocation="schema1.xsd" namespace="tns"/>
<xsd:import schemaLocation="schema2.xsd" namespace="tns"/>

</xsd:schema>

If you use this single schema, you'd get a similar error. I believe processor behavior for the case when
multiple imports of the same target namespace are present is implementation dependent. This is way
I'm not convinced there's a problem here.

Comment by jitu [ 18/Oct/07 ]

It is not about imports, it's about having two documents that have the same
targetnamespace. It just happened that my testcase is using imports. Some usecases:

  • It is possible to have multiple schema documents in the same targetnamespace.
  • A WSDL could have two <xsd:schema> elements with the same targetnamespace.

I also see your point. The javadoc says "parsers may choose to ignore all but
the first <import> for a given namespace, regardless of information provided in
schemaLocation".

Earlier Kohsuke said that this was bug. I will ask him to fill more information
in this bug.

Comment by kohsuke [ 18/Oct/07 ]

Santiago is right that the test case is semantically equivalent to the schema
that has two <xsd:import>s to the same namespace URI.

The real issue here is that the JAXP RI doesn't meet the user expectation with
this kind of <import>ing two schemas of the same namespace URI. Whereas the
expectation of people is for both schemas to be read, the JAXP RI only reads the
first one and silently skips the second one.

This behavior has been a source of confusion for many users in JAXB, too. The
failure mode is often something like "no such element declaration tns:second",
and people scratch their heads because it's clearly imported, as far as they can
tell (and when they try other tools the schema works just fine.)

Yes, we are aware that this behavior is allowed by the schema spec. But if
that's the only criteria, the same schema spec allows you to ignore every
<include> and <import> altogether, which is clearly unusable. So we need to
design the behavior by factors beyond the schema spec compliance.

I do realize this part of the JAXP RI is a real hair ball inherited from Xerces,
so the fix might not be as easy as changing a few lines here and there, but I
really think this behavior needs to be fixed.

Comment by Santiago Pericas-Geertsen [ 19/Oct/07 ]

It turns out that Xerces does support this since 2.7.0, although we don't have support for in the
SchemaFactory. Xerces supports this by setting the following property:

"http://apache.org/xml/features/honour-all-schemaLocations"

to true (it is false by default). I hope we can somehow change the SchemaFactory to support it as well.
However, I still don't think this is a bug, so I'm updating the issue accordingly.





[JAXP-45] Need to get useful/proper Error messages Created: 18/Oct/07  Updated: 19/Oct/07  Resolved: 19/Oct/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: dpatil Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 45

 Description   

While running WSpex Perf benchmarking tests where one of the include file is
missing, I get following exception from jaxp, which is not useful at all. Error
message should be useful so that users can find the real cause of the error.

> ant -Dconfig=configs/all-jaxws-tango.xml run |tee run.log
Buildfile: build.xml

run:
[java] Reading configuration file 'configs/all-jaxws-tango.xml' ...
[java] Exception in thread "main" java.lang.RuntimeException:
javax.xml.bind.UnmarshalException
[java] - with linked exception:
[java] [org.xml.sax.SAXParseException: An 'include' failed, and no
'fallback' element was found.]
[java] at com.sun.japex.ConfigFileMerger.<init>(ConfigFileMerger.java:79)
[java] at com.sun.japex.Engine.start(Engine.java:117)
[java] at com.sun.japex.Japex.run(Japex.java:155)
[java] at com.sun.japex.Japex.main(Japex.java:127)
[java] Caused by: javax.xml.bind.UnmarshalException
[java] - with linked exception:
[java] [org.xml.sax.SAXParseException: An 'include' failed, and no
'fallback' element was found.]
[java] at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:315)
[java] at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:481)



 Comments   
Comment by Santiago Pericas-Geertsen [ 19/Oct/07 ]

This issue has already been fixed. I can't easily find the related issue number or CR, but here is the
putback:

https://jaxp-sources.dev.java.net/source/browse/jaxp-sources/xml-xerces/java/src/com/sun/org/
apache/xerces/internal/xinclude/XIncludeHandler.java?r1=1.3&r2=1.4





[JAXP-37] Unrecognized target namespace containing a tilde Created: 18/May/07  Updated: 15/Oct/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: ericbuist Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 37

 Description   

JAXP 1.3, included in Sun's Java 5 implementation, cannot load a schema whose
target namespace contains a tilde character. However, JAXP 1.4 in Java 6 does.
Here is a small test case.

Schema file: smalltest.xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tst="http://www.my.test.com/~dummy/test"
targetNamespace="http://www.my.test.com/~dummy/test"
elementFormDefault="qualified">
<xsd:complexType name="SuperTest">
<xsd:sequence>
<xsd:element name="test1" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>

<xsd:attribute name="test" type="xsd:int" use="required"/>
</xsd:complexType>

<xsd:element name="test" type="tst:SuperTest"/>
</xsd:schema>

Test document: smalltest.xml
<test xmlns="http://www.my.test.com/~dummy/test" test="12">
<test1>Hello</test1>
<test1>World</test1>
</test>

Test program: TestValid.java
import java.io.File;
import java.io.IOException;

import javax.xml.XMLConstants;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.Schema;
import javax.xml.validation.SchemaFactory;
import javax.xml.validation.Validator;

import org.xml.sax.SAXException;

public class TestValid {
public static void main (String[] args) {
if (args.length != 2)

{ System.err.println ("Usage: java TestValid <xml file> <schema>"); System.exit (1); }

String xmlFile = args[0];
String schemaFile = args[1];

SchemaFactory sf = SchemaFactory.newInstance
(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema sm;
try

{ sm = sf.newSchema (new File (schemaFile)); }

catch (SAXException se)

{ System.err.println ("Could not read schema"); System.err.println (se.getLocalizedMessage ()); System.exit (1); return; }

Validator val = sm.newValidator ();
try

{ val.validate (new StreamSource (xmlFile)); }

catch (IOException ioe)

{ System.err.println ("Error reading XML file: " + ioe.getLocalizedMessage ()); System.exit (1); return; }

catch (SAXException se)

{ System.err.println ("Error when validating the document"); System.err.println (se.getLocalizedMessage ()); System.exit (1); return; }

System.out.println ("The document is valid!");
}
}

Command-line: java TestValid smalltest.xml smalltest.xsd

With Java 6, I get the The document is valid! message.
But with Java 5, I get the following error:

Could not read schema
src-resolve.4.2: Error resolving component 'tst:SuperTest'. It was detected that
'tst:SuperTest' is in namespace 'http://www.my.test.com/~dummy/test', but
components from this namespace are not referenceable from schema document
'file:///mnt/common/univ/stochas/java/contactcenters/jaxbcc/bin/smalltest.xsd'.
If this is the incorrect namespace, perhaps the prefix of 'tst:SuperTest' needs
to be changed. If this is the correct namespace, then an appropriate 'import'
tag should be added to
'file:///mnt/common/univ/stochas/java/contactcenters/jaxbcc/bin/smalltest.xsd'.

So with Java 5, the program does not create the schema object at all.



 Comments   
Comment by ndw [ 02/Oct/07 ]

Can you try replacing all the "~"s with "%7E" and see if it works?

I wonder if some API is doing that and then the two URIs are different so the
references don't match.

Comment by ericbuist [ 15/Oct/07 ]

If I replace the ~ with %7E in the Schema file smalltest.xsd and I run my
program again, with Java 6 or Java 5, I get

Error when validating the document
cvc-elt.1: Cannot find the declaration of element 'test'.

If I also replace the ~ with %7E in the instance document, I get

The document is valid!

But this is only an additional way to remove ~'s.





[JAXP-43] Exception while creating Schema object as it doesn't take care of inscope namespaces. Created: 09/Oct/07  Updated: 15/Oct/07  Resolved: 15/Oct/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: jitu Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File hello_literal.wsdl     Java Source File ValidatorTest.java    
Issuezilla Id: 43

 Description   

Schema object is created with DOMSource(from a fragment), but it doesn't
preserve inscope namespaces and throws an exception. Since the DOMSource is a
valid one, this should work. Adding sample test case that exhibits this behaviour.



 Comments   
Comment by jitu [ 09/Oct/07 ]

Created an attachment (id=11)
sample data file

Comment by jitu [ 09/Oct/07 ]

Created an attachment (id=12)
test case

Comment by Santiago Pericas-Geertsen [ 15/Oct/07 ]

A patch has been committed for this issue. The namespace support created by schema loader is now
initialized with the context of the node's ancestors. This allows a schema embedded in an another
document (such as a WSDL) to be properly loaded for validation.





[JAXP-41] SchemaFactory fails to parse a seemingly valid schema Created: 10/Jul/07  Updated: 05/Oct/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 41

 Description   

A JAXB user discovered a bug in the JAXP RI. The following code reproduces the
problem:

public static void main(String[] args) throws SAXException,
MalformedURLException

{ SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI).newSchema( new URL("http://schemas.opengis.net/csw/2.0.1/CSW-discovery.xsd")); }

This fails with the error "src-resolve: Cannot resolve the name
'ows:ServiceType' to a 'type definition' component."

If you look at the schema, it contains the import line, and this imported schema
seems to define the ServiceType type.

<xsd:import namespace="http://www.opengis.net/ows"
schemaLocation="../../ows/1.0.0/owsGetCapabilities.xsd"/>

See the JAXB issue https://jaxb.dev.java.net/issues/show_bug.cgi?id=382



 Comments   
Comment by Santiago Pericas-Geertsen [ 02/Oct/07 ]

Will take a look at this one.

Comment by Santiago Pericas-Geertsen [ 05/Oct/07 ]

I was able to reproduce the problem and found a workaround for it as well. The workaround: in CSW-
discovery.xsd move the xs:include of 'report.xsd' after the xs:import's. Apparently, the schema loader is
getting confused by the multiple imports of the same schema from different include paths (e.g. of
owsCommon.xsd).

Due to the large number of schemas and their intracte dependencies, it is very difficult to pinpoint the
problem. I wonder if the original reporter of the JAXB issue could provide a simpler test case for us to
work on.





[JAXP-34] Inconsistent exception thrown in SchemaFactory Created: 24/Apr/07  Updated: 02/Oct/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: jaxp.next
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: ndw Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 34

 Description   

I've been carrying this around for a long time in a mail folder. Time to make it
a bug report

SchemaFactory#newSchema("non existing file") throws SaxException.
Shouldn't it throw IOException, for consistency with
Validator#validateSource, for instance, and also to follow the
"principle of least suprise" ?

Thanks in advance,
Daniel Serodio



 Comments   
Comment by ndw [ 02/Oct/07 ]

We'll look at this for V.next





[JAXP-42] dysfunctional hyperlink in package org.xml.sax Created: 22/Aug/07  Updated: 02/Oct/07  Resolved: 02/Oct/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: spe_anatol Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://jaxp-sources.dev.java.net/nonav/docs/api/


Issuezilla Id: 42

 Description   

The sentence ‘See http://www.saxproject.org for more information about SAX.’
contains a hyperlink that opens in the current frame. This is a
misunderstanding because the URL belongs to an external site. The external
site should open in a new window or replace the current frameset.



 Comments   
Comment by ndw [ 02/Oct/07 ]

Fixed in CVS.





[JAXP-39] Improve error message when an uninitialized variable is used Created: 05/Jun/07  Updated: 05/Jun/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: Santiago Pericas-Geertsen Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 39

 Description   

Filing this RFE based on Peter Lenahan's suggestion. The problem he encountered is described here,

https://jaxp.dev.java.net/issues/show_bug.cgi?id=38

and here is his suggestion:

"But I wonder if a better error message scheme could somehow be generated.
XSLT is often hard to debug and without a clue to where the problem happened it
is really impossible. Just a null pointer exception message is a killer.

Perhaps my un-initialized null variables could be initialized with an internal
error message reference, so if the style sheet references one of these
un-initialized variables, an error message string could be displayed instead of
just crashing with a null pointer exception. I realized that this is a lot of
work to add code to all the functions that work on the string variables, but
XSLT is not exactly a friendly language without knowing where your problems are
occurring. It would really help a lot to know where the problems originated.

This may not be a perfect solution and perhaps the feature should also only be
available when the setAttribute("debug",new Boolean(true)) is turned on.

On the page: http://www.unicode.org/charts/PDF/UE000.pdf it defines private use
UNICODE characters.

Consider this possible feature.

if (factory.getAttribute("debug"))

{ // // When you declare a variable initialize the variable // with a special character and reference to the // filename, line number // and character offset of the declaring variable. // Clearly this would need to be checked in hundreds of places // for the special first character. // char [] hidden=new char[1]; hidden[0]=0xE000; // This is a special use UNICODE Character. String special=hidden.toString()+ filenameReference+ linenumberReference+ characterOffsetReference; }

Then when using the string if this value was set, it would tell the
internal function that it was incorrect and where the problem
originated.

My problem was in a 6000 line style sheet which made the problem a little
difficult to find and understand."






[JAXP-38] Null pointer exception with decode calling substring_beforeF Created: 01/Jun/07  Updated: 05/Jun/07  Resolved: 05/Jun/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: peter_lenahan Assignee: Santiago Pericas-Geertsen
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 38

 Description   

I have a fairly simple problem with a null pointer, that is easy to fix.
This problem is a result of a different bug in the transform, that problem
fails to set the value of a GLOBAL variable (rtf) correctly with a large style
sheets file (it works ok with a small stylesheet), I have not isolated how to
reproduce the original problem yet.
But this is still a failure that is easy to resolve.

In the file: http://fisheye5.cenqua.com/browse/jaxp-sources/xml-
xalan/java/src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
?r=1.10

jeff suttor wrote:

297 /**
298 * XSLT Standard function substring-before().
299 */
300 public static String substring_beforeF(String value, String
substring)

{ NEWPROPOSAL NEWPROPOSAL if (value == null || substring == null ) // Please add this NEWPROPOSAL return EMPTYSTRING; NEWPROPOSAL 301 final int index = value.indexOf(substring); 302 if (index >= 0) 303 return value.substring(0, index); 304 else 305 return EMPTYSTRING; 306 }

Below is my trace back. I can send you the stylesheet file if you need it, but
it is rather large and I didn't think it would help.

javax.xml.transform.TransformerException: java.lang.NullPointerException
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown
Source)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown
Source)
at ibi.search.common.MagnifyTransform.<init>(MagnifyTransform.java:25)
at ibi.search.lucene.LuceneCreateHTML.transformDOMToHTML
(LuceneCreateHTML.java:704)
at ibi.search.lucene.LuceneCreateHTML.transformToHTML
(LuceneCreateHTML.java:629)
at ibi.search.lucene.LuceneCreateHTML.<init>(LuceneCreateHTML.java:546)
at ibi.search.lucene.LuceneSearch.<init>(LuceneSearch.java:422)
at ibi.search.lucene.Lucene.doPost(Lucene.java:158)
at ibi.search.lucene.Lucene.doGet(Lucene.java:142)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at ibi.srv.util.IBIHttpServlet.service(IBIHttpServlet.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at ibi.srv.util.IBIHttpServlet.service(IBIHttpServlet.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at
com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary.substring_beforeF
(Unknown Source)
at magnify_search_39.decode()
at magnify_search_39.topLevel()
at magnify_search_39.transform()
at
com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform
(Unknown Source)



 Comments   
Comment by Santiago Pericas-Geertsen [ 01/Jun/07 ]

I don't understand the rationale for the proposal. Strings passed to that method are XSLT strings that
should never be null. If they are, this is likely to be due to a bug elsewhere or the result of calling an
external Java function that returns null. If there's another problem, we should focus on it first rather than
trying to patch it. Please do attach a stylesheet to reproduce the problem. Setting priority to P3.

Comment by peter_lenahan [ 04/Jun/07 ]

Well I managed to figure out my problem with a small style sheet.
I am not sure if this is a bug on my part for referencing something
in the wrong order. However, it did work in earlier versions.

This was run against the most recent jaxp jar files.
However it also occurs in the 1.6 version I am running.

E:\test>java -cp ".;E:\test\jaxp-api.jar;e:\test\jaxp-ri.jar;" Transformer
percent.xslt percent.xml percent.out

decode: encoded=N%2FA

ERROR: ''

java.lang.NullPointerException

The order that the variables are defined differs in the newer XSLT code.
This order it seems didn't matter in the older version.

It seems that the Global Variables with constants definitions were done
before the variables set with template definitions in older version.
Now this is not the case.

Perhaps you should close the bug report for Issue 38.

I am working with the Style Sheet from the Google Search Appliance,
It works on the Google machine's XSLT transform.

This is a run of the Transform done in Stylus Studio, it also works there.
Here is the output in Stylus Studio:
External XSLT processing started...
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #31; Column #19; decode: encoded=N%2FA
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #31; Column #19; decode: encoded=A
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #15; Column #15; value_declared_in_the_wrong_order=N/A
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #18; Column #15; FLD1=N%2FA&
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #31; Column #19; decode: encoded=FLD1=N%2FA&
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #31; Column #19; decode: encoded=A&
file:///d:/Documents%20and%20Settings/pl00291/workspace/lucene/WEB-INF/src/ibi/search/common/STY1A4.xsl;
Line #24; Column #15; Stuff=FLD1=N/A&
...done

My "/" character is correctly decoded.

<?xml version='1.0'?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:variable name="value_declared_in_the_wrong_order">
<xsl:call-template name="decode">
<xsl:with-param name="encoded" select="'N%2FA'"/>
</xsl:call-template>
</xsl:variable>

<!--
These variable are used by the decode template and are declared
after the first call to the template above.
-->
<xsl:variable name="hex" select="'0123456789ABCDEF'"/>
<xsl:variable name="ascii">
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvwxyz

{|}

~</xsl:variable>
<xsl:variable
name="latin1"> ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ</xsl:variable>

<xsl:template match="/">
<xsl:message>value_declared_in_the_wrong_order=<xsl:value-of
select="$value_declared_in_the_wrong_order"/></xsl:message>

<xsl:message><xsl:value-of select="/percent"/></xsl:message>
<xsl:variable name="stuff">
<xsl:call-template name="decode">
<xsl:with-param name="encoded" select="/percent"/>
</xsl:call-template>
</xsl:variable>
<xsl:message>Stuff=<xsl:value-of select="$stuff"/></xsl:message>

</xsl:template>

<xsl:template name="decode">
<xsl:param name="encoded"/>
<xsl:message > decode: encoded=<xsl:value-of select="$encoded"/></xsl:message>
<xsl:choose>
<xsl:when test="contains($encoded,'%')">
<xsl:value-of select="substring-before($encoded,'%')"/>
<xsl:variable name="hexpair"
select="translate(substring(substring-after($encoded,'%'),1,2),'abcdef','ABCDEF')"/>

<!-- The variable $hex referenced below is undefined in the newer
transform -->

<xsl:variable name="decimal"
select="(string-length(substring-before($hex,substring($hexpair,1,1))))*16 +
string-length(substring-before($hex,substring($hexpair,2,1)))"/>

<xsl:choose>
<xsl:when test="$decimal < 127 and $decimal > 31">
<xsl:value-of select="substring($ascii,$decimal - 31,1)"/>
</xsl:when>
<xsl:when test="$decimal > 159">
<xsl:value-of select="substring($latin1,$decimal - 159,1)"/>
</xsl:when>
<xsl:otherwise>?</xsl:otherwise>
</xsl:choose>

<xsl:call-template name="decode">
<xsl:with-param name="encoded"
select="substring(substring-after($encoded,'%'),3)"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$encoded"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>

This is my XML FILE

<?xml version="1.0"?>
<percent>FLD1=N%2FA&</percent>

Comment by Santiago Pericas-Geertsen [ 04/Jun/07 ]

Peter,

Thanks for the detailed bug report and analysis. Indeed some code has changed
in the way the processor initializes global variables (this is to allow certain
dependencies with keys). The spec says that if variable x references variable y,
the latter should be initialized first. In your stylesheet, however, this is
much difficult to determine since you're calling another template. I suspect
other processors will also fail in this case (but perhaps XSLTC fails more
abrutly than others being a compiler).

At least on the attached stylesheet, declaring all the variables before
'value_declared_in_the_wrong_order' would solve the problem, right? In any case,
it seems to me that changing the stylesheet would help your app run with
different processors. I'm closing the bug, but feel free to re-open if you feel
my analysis isn't correct.

Comment by peter_lenahan [ 05/Jun/07 ]

It is ok to close the bug, since it was my problem.

But I wonder if a better error message scheme could somehow be generated.
XSLT is often hard to debug and without a clue to where the problem happened it
is really impossible. Just a null pointer exception message is a killer.

Perhaps my un-initialized null variables could be initialized with an internal
error message reference, so if the style sheet references one of these
un-initialized variables, an error message string could be displayed instead of
just crashing with a null pointer exception. I realized that this is a lot of
work to add code to all the functions that work on the string variables, but
XSLT is not exactly a friendly language without knowing where your problems are
occurring. It would really help a lot to know where the problems originated.

This may not be a perfect solution and perhaps the feature should also only be
available when the setAttribute("debug",new Boolean(true)) is turned on.

On the page: http://www.unicode.org/charts/PDF/UE000.pdf it defines private use
UNICODE characters.

Consider this possible feature.

if (factory.getAttribute("debug"))

{ // // When you declare a variable initialize the variable // with a special character and reference to the // filename, line number // and character offset of the declaring variable. // Clearly this would need to be checked in hundreds of places // for the special first character. // char [] hidden=new char[1]; hidden[0]=0xE000; // This is a special use UNICODE Character. String special=hidden.toString()+ filenameReference+ linenumberReference+ characterOffsetReference; }

Then when using the string if this value was set, it would tell the
internal function that it was incorrect and where the problem
originated.

My problem was in a 6000 line style sheet which made the problem a little
difficult to find and understand.

Thanks,
Peter





[JAXP-18] Bug in schema validator? Created: 13/Mar/07  Updated: 01/May/07  Resolved: 01/May/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kohsuke Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File pml.xml     XML File pml_1_0.xsd    
Issuezilla Id: 18

 Description   

I'm not really sure if this is correct, but to the best of my schema knowledge,
this indeed seems to be a bug in the schema validator.

When I run this schema with this instance by using JAXP RI 1.3, I get the
following error:

cvc-type.2: The type definition cannot be abstract for element
local-portlet-entity.

Apparently the error location is at the following element in the instance. Note
that there's no @xsi:type involved here:

<local-portlet-entity id="aLocalPortlet">

This corresponds to the following local element declaration:

<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="generic-portlet-entity" type="tns:genericPortletEntity"/>
<xs:element name="local-portlet-entity" type="tns:localPortletEntity"/>
<xs:element name="remote-portlet-entity" type="tns:remotePortletEntity"/>
</xs:choice>

And the localPortletEntity complex type is not abstract:

<xs:complexType name="localPortletEntity">
<xs:complexContent>
<xs:extension base="tns:portletEntity">
<xs:sequence>
...
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

So I don't understand why the JAXP RI is reporting an error. The relevant part
of the spec is http://www.w3.org/TR/xmlschema-1/#cvc-type



 Comments   
Comment by kohsuke [ 13/Mar/07 ]

Created an attachment (id=6)
schema

Comment by kohsuke [ 13/Mar/07 ]

Created an attachment (id=7)
document

Comment by Santiago Pericas-Geertsen [ 19/Mar/07 ]

Will investigate.

Comment by Santiago Pericas-Geertsen [ 01/May/07 ]

After a quick test, I can report that this appears to be fixed in JAXP 1.4. In most cases, if this is a JAXP 1.3
only bug, we ask people to upgrade to 1.4.

Comment by kohsuke [ 01/May/07 ]

I'm fine with the resolution of this being fixed in JAXP 1.4 (which is also in
JavaSE 6.)





[JAXP-33] XSLTC has information loss in compare with Xalan Created: 18/Apr/07  Updated: 01/May/07  Resolved: 01/May/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: svanteschubert Assignee: Santiago Pericas-Geertsen
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive testdocs+xslt.zip     XML File tigertest.xsl    
Issuezilla Id: 33

 Description   

The XSL transformation from OpenOffice.org XML (the predecessor of the
OpenDocument Format) to XHTML does loose the majority of the CSS styles.

Where is the reason?



 Comments   
Comment by svanteschubert [ 18/Apr/07 ]

Created an attachment (id=9)
XHTML export transformation \xslt\export\xhtml\ooo2xhtml.xsl with \testdocs\input.fsxw and results for xsltc.xhtml and xalan.xhtml, the latter should be merely the same

Comment by svanteschubert [ 18/Apr/07 ]

Created an attachment (id=10)
XSLT test stylesheet isolating a possible namespace issue

Comment by Santiago Pericas-Geertsen [ 18/Apr/07 ]

Assigning this to me.

Comment by Santiago Pericas-Geertsen [ 01/May/07 ]

This appears to be the same as,

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

which I have failed to reproduce. I've also created a unit test for it here:

https://jaxp-sources.dev.java.net/source/browse/jaxp-sources/jaxp-ri/src/unit-test/bug6384805/?
sortby=log#dirlist

Can you please see if you can modify the unit test to show the problem. We've looked at this one a few
times and have been unable to reproduce it. I suspect that the stylesheet is not enough, you need
something in your Java code (a specific Source and Result maybe) to reproduce the problem.

Also please try the latest JAXP RI available from this site to make sure it isn't actually fixed. As I said
above, the best approach at this point would be to modify the unit test to show the problem.





[JAXP-36] TransformerHandler needs to have a mode that assists debugging Created: 25/Apr/07  Updated: 25/Apr/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 36

 Description   

When TransformerHandler gets incorrect SAX events (in my case that was wrong
Attributes object with localName="" and some duplicates), XSLTC doesn't complain
in the startElement callback, but it does so later (see the stack trace below
— the error is reported when the next characters event is sent.)

While the error is in the caller's code (in this case it's JAXB), this delay
makes it very difficult to quickly find out what's feeding the wrong data.

Ideally it should work fail-fast — the error should be reported right when the
invalid data is fed. But if for a performance reason this is undesirable as the
default behavior, please provide us a debug switch (should be a system property
as well as public static variable we can set from the debugger, where the system
property becomes the initial value of the static boolean variable), which causes
TransformerFactory to return a real TransformerHandler wrapped into this debug
TransformerHandler that fails fast.

Exception in thread "main" org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt
is made to create or change an object in a way which is incorrect with regard to
namespaces.
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.checkNamespaceWF(CoreDocumentImpl.java:2388)
at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.setName(AttrNSImpl.java:126)
at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.<init>(AttrNSImpl.java:111)
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createAttributeNS(CoreDocumentImpl.java:2012)
at
com.sun.org.apache.xerces.internal.dom.ElementImpl.setAttributeNS(ElementImpl.java:684)
at
com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:134)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:205)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.characters(ToXMLSAXHandler.java:524)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.characters(TransformerHandlerImpl.java:168)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.text(DomLoader.java:102)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.text(UnmarshallingContext.java:415)
at
com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.text(InterningXmlVisitor.java:53)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.processText(StAXStreamConnector.java:330)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleEndElement(StAXStreamConnector.java:208)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:177)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:305)
at
com.sun.xml.ws.mex.client.MetadataClient.createMetadata(MetadataClient.java:278)
at mexinterop.client.MexInteropClient.main(MexInteropClient.java:112)
Java Result: 1






[JAXP-35] Better error message Created: 25/Apr/07  Updated: 25/Apr/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 35

 Description   

When someone fails to create a right attribute, JAXP fails with error messages
like this:

Exception in thread "main" org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt
is made to create or change an object in a way which is incorrect with regard to
namespaces.
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.checkNamespaceWF(CoreDocumentImpl.java:2388)
at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.setName(AttrNSImpl.java:126)
at
com.sun.org.apache.xerces.internal.dom.AttrNSImpl.<init>(AttrNSImpl.java:111)
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createAttributeNS(CoreDocumentImpl.java:2012)
at
com.sun.org.apache.xerces.internal.dom.ElementImpl.setAttributeNS(ElementImpl.java:684)
at
com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:134)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:205)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.characters(ToXMLSAXHandler.java:524)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.characters(TransformerHandlerImpl.java:168)
at
com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.text(DomLoader.java:102)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.text(UnmarshallingContext.java:415)
at
com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.text(InterningXmlVisitor.java:53)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.processText(StAXStreamConnector.java:330)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleEndElement(StAXStreamConnector.java:208)
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:177)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:305)
at
com.sun.xml.ws.mex.client.MetadataClient.createMetadata(MetadataClient.java:278)
at mexinterop.client.MexInteropClient.main(MexInteropClient.java:112)
Java Result: 1

We really need the error message to contain more information to assist the
developer how to go about fixing the problem. For example, it could have said:

(localName="xyz", uri="foobar", qname="abc:def:ghi")

which now has enough information, that is, the qname is wrong.






[JAXP-31] XSLTC - Could not compile stylesheet Created: 17/Apr/07  Updated: 18/Apr/07  Resolved: 18/Apr/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: svanteschubert Assignee: Santiago Pericas-Geertsen
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive xslt.zip    
Issuezilla Id: 31

 Description   

Two transformation based on XSLT stylesheet (wordml/spreadsheetml import) that
are shipped StarOffice/OpenOffice.org do not compile with XSLTC of 1.5.0_11 and
1.6.0_01.
But they are working with Xalan 2.7.0.

The stacktrace is:

javax.xml.transform.TransformerConfigurationException:
Could not compile stylesheet

at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(Unknown
Source)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(Unknown
Source).



 Comments   
Comment by svanteschubert [ 17/Apr/07 ]

Created an attachment (id=8)
ZIP of two XSL transformations 1) \xslt\import\spreadsheetml\spreadsheetml2ooo.xsl and 2) \xslt\import\wordml\wordml2ooo.xsl

Comment by Santiago Pericas-Geertsen [ 18/Apr/07 ]

I have looked at the first of the two stylesheets using the latest JAXP build (1.4.1 nightly from the
downloads section). In line 5945 of spreadsheetml2ooo.xsl you have the following expression,

<xsl:value-of select="count(ss:Table/ss:Row + number($spannedRows))"/>

which is making the XSLTC typechecker unhappy. I believe your intention here is:

<xsl:value-of select="count(ss:Table/ss:Row) + number($spannedRows)"/>

There may be some automatic conversion that XSLTC isn't implementing correctly, but if you change
the expression as suggested above the stylesheet compiles and runs.

Comment by Santiago Pericas-Geertsen [ 18/Apr/07 ]

As for the other stylesheet, wordml2ooo, the compilation fails in this call,

<xsl:variable name="tmp" select="oleextracter:insertByName('oledata.mso', translate(text
(),' ','' ) )"/>

I'm not familiar with the 'oleextracter' extension element declared in this stylesheet. But, whatever it is,
isn't supported by XSLTC or part of the XSLT 1.0 spec. Shouldn't the stylesheet use element-available() for
portability?

Comment by Santiago Pericas-Geertsen [ 18/Apr/07 ]

Fixing the stylesheet will make it work with XSLTC.





[JAXP-32] XMLGregorianCalendar.toXMLFormat() Variant Created: 18/Apr/07  Updated: 18/Apr/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: mshaffer55 Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 32

 Description   

JAXB maps any of eight distinct XML Schema date/time types to
XMLGregorianCalendar. When an XMLGregorianCalendar is marshalled by JAXB, the
output format generated by the toXMLFormat() method should be that appropriate
for the original schema type. Currently this may or may not happen correctly,
depending on exactly which fields of the XMLGregorianCalendar have (not) been
populated by the application code.

This problem could be solved by creating a new version of
XMLGregorianCalendar.toXMLFormat(...) that takes as a parameter a QName
representing the target schema type for formatting the output. Populated fields
not relevant to the schema type would be ignored; missing fields required by the
schema type would cause an exception to be thrown.






[JAXP-30] none value recognition of minOccurs and maxOccurs Created: 16/Apr/07  Updated: 16/Apr/07  Resolved: 16/Apr/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: suchtdenfehler Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 30

 Description   

I have an application where xml streams needs to be validated against xsd-schemas.
Using JDK 1.5 (jdk1.5.0_07) this works well and the streams are correctly validated.

When I use Java 1.6 (build 1.6.0-b105) the minOccurs and maxOccurs seams to be
skipped from the validation process and the xml is always reported as valid.

Here is a snippet of my code:

File xmlFile = new File("occurs.xml");

SchemaFactory factory=SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = factory.newSchema(new File("occurs.xsd"));

// get a DOM factory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// configure the factory
dbf.setNamespaceAware(true);

// set schema on the factory
dbf.setSchema(schema);

DocumentBuilder documentBuilder = dbf.newDocumentBuilder();

// Check the document
try {
documentBuilder.parse(xmlFile);
System.out.println(xmlFile.getName() + " is valid.");
}
catch (SAXException ex) {
System.out.println(xmlFile.getName() + " is not valid because ");
System.out.println(ex.getMessage());
}

// And the corresponding xml and xsd.

occurs.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<persons>

<person>
<full_name>Hege Refsnes</full_name>
<child_name>Cecilie</child_name>
</person>

<person>
<full_name>Tove Refsnes</full_name>
<child_name>Hege</child_name>
<child_name>Stale</child_name>
<child_name>Jim</child_name>
<child_name>Borge</child_name>
</person>

<person>
<full_name>Stale Refsnes</full_name>
</person>

</persons>

occurs.xsd

<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

<xs:element name="persons">
<xs:complexType>
<xs:sequence>
<xs:element name="person" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="full_name" type="xs:string"/>
<xs:element name="child_name" type="xs:string" minOccurs="0"
maxOccurs="3"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>

Java 1.5 reports:
occurs.xml is not valid because
cvc-complex-type.2.4.d: Invalid content was found starting with element
'child_name'. No child element is expected at this point.

while Java 1.6 reports:
occurs.xml is valid.

I browsed the JAXP Project Page to find the differences from JAXP 1.3 is
included in J2SE 5.0 and the implementation of JAXP 1.4 is part of Java SE 6.0
but found nothing linked to my problem.



 Comments   
Comment by Santiago Pericas-Geertsen [ 16/Apr/07 ]

Some code has changed in JDK 6.0, so this may indeed be a new issue in JDK 6.0.

Comment by Santiago Pericas-Geertsen [ 16/Apr/07 ]

As demonstrated in the test case of JAXP issue 30, the constant-space algorithm for validating a

{n,m}
cannot be applied when an FSA is created to accept a content model that includes, but it is not just a{n,m}

.
In other words, the optimization introduce for a

{n,m}

was a bit too aggressive and had to be restricted.

Note that the testcase should use an ErrorHandler to receive validation errors; catching a SAXException is
not enought. This patch will be available in the JAXP 1.4.1 nightly build available from this site (see
Downloads section).





[JAXP-29] NAMESPACE_ERR error message needs more details Created: 12/Apr/07  Updated: 12/Apr/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 29

 Description   

One of the DOM error often takes the form like this:

SEVERE: NAMESPACE_ERR: An attempt is made to create or change an object in a way
which is incorrect with regard to names
paces.
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change
an object in a way which is incorrect wi
th regard to namespaces.
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.checkNamespaceWF(Unknown
Source)
at com.sun.org.apache.xerces.internal.dom.AttrNSImpl.setName(Unknown Source)
at com.sun.org.apache.xerces.internal.dom.AttrNSImpl.<init>(Unknown Source)
at
com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createAttributeNS(Unknown
Source)
at com.sun.org.apache.xerces.internal.dom.ElementImpl.setAttributeNS(Unknown Source)
at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(Unknown Source)
at
com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(Unknown
Source)
at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.characters(Unknown
Source)
at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.characters(Unknown
Source)
at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.text(DomLoader.java:102)

Especially since JDK code doesn't ship with the local variable information, it's
very important that the error message points out which rule it's violating and
other details.






[JAXP-28] Problem marshalling XMLGregorianCalender with no time values (all zero) Created: 11/Apr/07  Updated: 12/Apr/07  Resolved: 12/Apr/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: lscotte Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Sun
URL: http://forums.java.net/jive/thread.jspa?threadID=25135


Issuezilla Id: 28

 Description   

I'm having some problems with corrupted dateTime/XMLGregorianCalendar
marshalling via JAXB.

The XML I'm parsing has timestamps that look like
"2007-03-17T00:00:00.0000000-07:00".

When unmarshalled the XMLGregorianCalendar looks like: year=2007, month=03,
day=17, hour=0, minute=0, second=0, timezone=-420, this appears to be correct.

The original timestamp seems to be a valid ISO8601 format, and in fact there is
no trouble marshalling an object obtained with timestamp such as
"2007-03-26T19:13:41.2637550-07:00", i.e. something other than zeros for the
hh:mm:ss.sssssss value.

The problem, is when this XMLGregorianCalendar is marshalled back to XML the
value becomes "2007-03-17T00:00:00E-7-07:00", which is not valid and JAXB is not
then able to unmarshall back! Attempting to do so results in:

javax.xml.bind.UnmarshalException: 2007-03-17T00:00:00E-7-07:00

  • with linked exception:
    [java.lang.IllegalArgumentException: 2007-03-17T00:00:00E-7-07:00]

If, before marshalling, I simply setMillisecond(1), so that it is a non-zero
value, then it produces a valid date in the XML.



 Comments   
Comment by Santiago Pericas-Geertsen [ 12/Apr/07 ]

I believe this is a duplicate of

https://jaxp.dev.java.net/issues/show_bug.cgi?id=12

which has been fixed and is available in JAXP RI verison 1.4.1. Please see here,

https://jaxp.dev.java.net/1.4/index.html

for further details.





[JAXP-27] StAXSource NPEs on events from an XMLEventReader Created: 09/Apr/07  Updated: 10/Apr/07  Resolved: 10/Apr/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 27

 Description   

When creating a StAXSource from an XMLEventReader, StAXSource NPEs if the events
returned by the reader don't have a location. This occurs, for example, when the
events are coming from a transformation.



 Comments   
Comment by ndw [ 10/Apr/07 ]

Fixed in CVS.





[JAXP-26] "Cannot find the declaration" -> "undefined element" Created: 30/Mar/07  Updated: 30/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 26

 Description   

The cvc-elt.1 error message produced by the JAXP RI is the following:

> [java] parsing a schema...
> [java] [ERROR] cvc-elt.1: Cannot find the declaration of element 'jxb:bindings'.
> [java] line 97 of file:positionTypes.xsd
> [java] Failed to parse a schema.

The error message is formulated toward schema authors, but that is wrong.
validation errors need to be phrased to instance document authors.

So this error message should become "Undefined element 'jaxb:bindings'" or
"'jaxb:bindings' is not allowed here."

Also make sure to use the string edit distance algorithm to try to find if this
is a typo of something else.






[JAXP-25] Failing to <xs:import> should produce a warning Created: 30/Mar/07  Updated: 30/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 25

 Description   

JAXP RI's XML Schema validator silently ignores <xs:import>s that failed to
resolve for some reason — be it unreachable resource, a well-formedness error
in the referenced XML, etc.

The only failure reported is when one actually tries to refer to those components.

While I know this is still within the conformance of XML Schema spec, in
practice this makes error diagnostics hard, since people have no clue why their
seemingly valid schema reference is not taking any effect.

A warning about the failed import would be highly desirable.






[JAXP-24] jaxp 1.3 failed on well known schema Created: 28/Mar/07  Updated: 28/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 24

 Description   

JAXP 1.3 cannot produce Schema object from the well known XML schema
http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd
Try to compile and run the following class

import javax.xml.validation.*;
import javax.xml.transform.stream.*;
import javax.xml.*;

public class XmlTest3 {
public static void main(String[] args) {
try

{ SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); StreamSource schemaSrc = new StreamSource("http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd"); Schema schema = factory.newSchema(schemaSrc); System.out.println("Successfully created schema"); System.exit(0); }

catch(Exception e)

{ System.out.println("Caught exception"); e.printStackTrace(); System.exit(1); }

}
}

You will get the following exception
org.xml.sax.SAXParseException: InvalidRegex: Pattern value
'[-+]?(\d+|\d+(\.\d+)?%)' is not a valid regular expression. The reported error
was: ''-' is an invalid character range. Write '-'.'.

It seems to me that the regular expression engine used by jaxp 1.3 is more
restricted than before. jaxp 1.2 works just fine. Of course, the schema could be
corrected by changing [-+] to [\-+] and this will fix the problem. However, this
schema is such a well known schema, jaxp 1.3 and jdk1.5 sure will break a lot of
existing application. Is it possible to relax the restriction on the regular
expression?



 Comments   
Comment by Joe Wang [ 28/Mar/07 ]

Assigning to Norm





[JAXP-23] JAXP 1.3 cannot failed to validate XML against DTD Created: 27/Mar/07  Updated: 27/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 23

 Description   

JAXP 1.3 failed to parse an valid XML against a DTD. Using the following Java
class and XML document to test.

import javax.xml.parsers.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
import java.io.*;

/**

  • To test:
  • 1. Using jdk1.4.2.
  • 2. Put the six jar files of JAXP 1.2 in $jdkhome/jre/lib/endorsed directory.
  • 3. Compile and run. Parsing is a success.
  • 4. Replace the six jar files of JAXP 1.2 with the five jar files of JAXP 1.3.
  • 5. Compile and run. Parsing is a failure.
    */
    public class XmlTest {

/** The property name to specify schema language. */
public static final String JAXP_SCHEMA_LANGUAGE =
"http://java.sun.com/xml/jaxp/properties/schemaLanguage";

/** The property value for W3C schema language. */
public static final String W3C_XML_SCHEMA =
"http://www.w3.org/2001/XMLSchema";

public static void main(String[] args) {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
System.out.println("SAXParserFactory: "+factory.getClass().getName());

factory.setNamespaceAware(true);
factory.setValidating(true);

SAXParser parser = factory.newSAXParser();
FileInputStream xmlStream = new FileInputStream("ejbxml.xml");
DefaultHandler handler = new DefaultHandler() {
// override to do validation
public void error(SAXParseException e) throws SAXException

{ throw e; }

};

// If the following line is enabled, the parsing will fail. The
// xml is defined by a DTD rather than a schema. Therefore, the
// parser should not fail due to the following line. In fact, the
// failure only occurs when using JAXP 1.3 (i.e. JDK 1.5), JAXP 1.2
// works just fine.
parser.setProperty(JAXP_SCHEMA_LANGUAGE, W3C_XML_SCHEMA);

parser.parse(xmlStream, handler);

System.out.println("Successfully parsed XML");
System.exit(0);
} catch(Exception e)

{ System.out.println("Caught exception"); e.printStackTrace(); System.exit(1); }

}
}

<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
1.1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<display-name>AccountEjbJar</display-name>
<enterprise-beans>
<entity>
<display-name>AccountEjb</display-name>
<ejb-name>AccountEjb</ejb-name>
<home>j2eetrails.account.ejb.AccountHome</home>
<remote>j2eetrails.account.ejb.Account</remote>
<ejb-class>j2eetrails.account.ejb.AccountEjb</ejb-class>
<persistence-type>Bean</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<resource-ref>
<res-ref-name>jdbc/SQLServerDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</entity>
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>all</role-name>
</security-role>
<method-permission>
<role-name>all</role-name>
<method>
<ejb-name>AccountEjb</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<container-transaction>
<method>
<ejb-name>AccountEjb</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>AccountEjb</ejb-name>
<method-intf>Remote</method-intf>
<method-name>debit</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>AccountEjb</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getBalance</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>AccountEjb</ejb-name>
<method-intf>Remote</method-intf>
<method-name>credit</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>



 Comments   
Comment by Joe Wang [ 27/Mar/07 ]

Assigning to Norm





[JAXP-21] XMLGregorianCalendar Does Not Implement Serializable Created: 22/Mar/07  Updated: 27/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mshaffer55 Assignee: ndw
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 21

 Description   

The class javax.xml.datatype.XMLGregorianCalendar does not implement
java.io.Serializable. This creates a problem around JAXB classes generated from
schemas. JAXB's default binding of xs:dateTime is to XMLGregorianCalender, and a
standard global JAXB binding makes the generated classes implement Serializable,
but any such class generated from a schema type containing an element of type
xs:dateTime will in fact fail binary serialization.



 Comments   
Comment by Joe Wang [ 27/Mar/07 ]

Assigning to Norm





[JAXP-22] Poor error message during a parsing error Created: 26/Mar/07  Updated: 26/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 22

 Description   

When the JAXP RI tries to read a malformed XML like <foo a="1"b="2"/> (note no
whitespace between two attributes), it dies with an error message like this:

--------------------------
[java] 11:25:05,380 ERROR MetaData:117 - Parser error with file
"/Users/clr/jpaperf/projects/persistence_benchmark/build/classes/ package.jdo"
has cause
[java] Error parsing file
/Users/clr/jpaperf/projects/persistence_benchmark/build/classes/package.jdo :
Error reading the Meta-Data input "Element type "field" must be followed by
either attribute specifications, ">" or "/>".
[java] org.xml.sax.SAXParseException: Element type "field" must be
followed by either attribute specifications, ">" or "/>".
[java] at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236)
[java] at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:215)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:386)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError
(XMLScanner.java:1438)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:218)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693)
[java] at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
[java] at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
[java] at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
[java] at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
[java] at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
[java] at javax.xml.parsers.SAXParser.parse(SAXParser.java: 375)
[java] at javax.xml.parsers.SAXParser.parse(SAXParser.java: 176)
[java] at
org.jpox.metadata.MetaDataParser.parseMetaDataStream(MetaDataParser.java:236)
[java] at org.jpox.metadata.MetaDataParser.parseMetaDataFile
MetaDataParser.java:162)
--------------------------

The only legal characters after an element name or an attribute are whitespaces,
'/', or '>'. So the error diagnosis should be:

if(the next character is valid char to start a name)

{ error "whitespace required"; }

else

{ error "invalid character"; }

I don't think most people are familiar with what "element type" or "attribute
specifications" mean — I'm not even sure what they really mean; are they
technical terms defined in XML REC?

Besides, those terms could make the user think that the error is validation
related, which is not.






[JAXP-20] Error diagnosis is sloppy Created: 21/Mar/07  Updated: 21/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 20

 Description   

One of the common error message in the JAXP RI while loading a schema document
is this:

[WARNING] schema_reference.4: Failed to read schema document 'http:/
/www.w3.org/2006/03/addressing/ws-addr.xsd', because 1) could not find the docum
ent; 2) the document could not be read; 3) the root element of the document is n
ot <xsd:schema>.
line 2 of http://localhost:8080/jaxws-stateful/bookstore?xsd=1

This error needs to be diagnosed more accurately.

Generally speaking, a program shouldn't report "either X or Y". Figure out if it
was X or Y, and just report so.

And this error is known to occur for other reasons as well, such as when this
XSD has a DOCTYPE decl that points to a remote resource.

Finally, when the parsing failed due to a wellformedness violation, the error
should include a nested error message/exception that indicates what was the
cause of the problem.






[JAXP-2] HTML serializer puts no space between public and system doctype Created: 18/Jan/05  Updated: 19/Mar/07  Resolved: 19/Mar/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: zisch666 Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2

 Description   

The HTML serializer doesn't leave a space between the public and system
doctypes. This is a known Bug in Xalan 2.6 and should be fixed in the CVS as of
this writing. See:
<http://issues.apache.org/jira/secure/ViewIssue.jspa?key=XALANJ-1910> (Bugzilla
ID 30142) The actual fix seems to be trivial, but it's difficult to work around
the problem, when you use JAXP in Java 5.0.

This bug shows up in J2SE 5.0 (JDK 1.5.0_01). Please include the fix in the next
maintenance-release of the JDK 1.5! It's a tiny problem but very annoying!



 Comments   
Comment by lindstro [ 29/Aug/06 ]

Assigning bug to Santiago

Comment by Santiago Pericas-Geertsen [ 05/Sep/06 ]

I confirm this issue still exists in JAXP 1.3 which is part of J2SE 5.0. However, it is fixed in JAXP 1.4
downloadable from this project and also part of J2SE 6.0. We'll work with the maintenance team to get this
into an update release of J2SE 5.0.

Comment by Santiago Pericas-Geertsen [ 19/Mar/07 ]

This has been fixed in the JDK 5.0 branch of JAXP at Java.net. A request approval is being prepared to
integrate this into JDK 5.0 Update 13. I'm marking it as fixed here.





[JAXP-19] LSSerializer writes processing instruction at end of document Created: 16/Mar/07  Updated: 19/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: Windows 2000
Platform: PC


Issuezilla Id: 19

 Description   

When serializing a XML-Document using LSSerializer (DOMSerializerImpl) a leading
processing-instruction (firstChild of the Document) appears at the end of the
serialized Document.
This issue occours using jre 1.4.2 (I checked it with different releases
(1.4.2_01, 1.4.3_13 and one or two more)) and JAXP 1.4.
This issue does NOT appear with jre 1.5 or JAXP 1.3

I used Eclipse 3.2.1 for the tests and the endorsed standard override mechanism.

Here is a sample-class for evaluating:

import java.io.IOException;
import java.io.StringReader;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;

import org.w3c.dom.DOMImplementation;
import org.w3c.dom.Document;
import org.w3c.dom.ls.DOMImplementationLS;
import org.w3c.dom.ls.LSSerializer;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;

public class SerializeTest {

public SerializeTest() {
}

public static void main(String [] args)

{ SerializeTest serializeTest = new SerializeTest(); serializeTest.serializePI(); }

public void serializePI() {
//create XML as String
StringBuffer xmlString = new StringBuffer();
xmlString.append("<?xml version=\"1.0\" encoding=\"UTF-16\"?>");
xmlString.append("<?processingTarget processingData?>");
xmlString.append("<Elements>");
xmlString.append("<Element>Text1</Element>");
xmlString.append("</Elements>");
//parse XML
Document xmlDocument = null;
InputSource is = new InputSource(new StringReader(xmlString.toString()));
DocumentBuilder docBuilder = null;
try

{ docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder(); }

catch (ParserConfigurationException e)

{ e.printStackTrace(); }
try { xmlDocument = docBuilder.parse(is); } catch (SAXException e) { e.printStackTrace(); }

catch (IOException e)

{ e.printStackTrace(); }

//serialize
DOMImplementation domImpl = docBuilder.getDOMImplementation();
DOMImplementationLS domImplLS = (DOMImplementationLS) domImpl.getFeature("LS",
"3.0");
LSSerializer serializer = domImplLS.createLSSerializer();
System.out.println(serializer.writeToString(xmlDocument));
}
}

The output of the last System.out when using JAXP 1.3 is:
<?xml version="1.0" encoding="UTF-16"?>
<?processingTarget processingData?><Elements><Element>Text1</Element></Elements>

The JAXP 1.4 - output is:
<?xml version="1.0" encoding="UTF-16"?>
<Elements><Element>Text1</Element></Elements><?processingTarget processingData?>

I am interested in this functionality because I want to create a xml-stylesheet

  • processing instruction, which surely must be between the prolog and the
    root-element.

I tested this issue with different JREs and configurations.
Additionally I spent a lot of time searching for solutions but I could not find
anything on this site nor at sun.com or anywhere else, so I am quiet sure this
is a defect.



 Comments   
Comment by Santiago Pericas-Geertsen [ 19/Mar/07 ]

Accepted for further investigation.





[JAXP-17] Improve the error diagnostics with classloader related problems Created: 12/Mar/07  Updated: 12/Mar/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?messageID=207570


Issuezilla Id: 17

 Description   

See the cited URL for the actual users that hit the problem. The error happens
in the following cast:

public static XMLOutputFactory newInstance()
throws FactoryConfigurationError

{ return (XMLOutputFactory) FactoryFinder.find("javax.xml.stream.XMLOutputFactory", "com.bea.xml.stream.XMLOutputFactoryBase"); }

... because there are apparently two copies of JSR-173 APIs, so the
XMLOutputFactory that Zephyr implements and the XMLOutputFactory used here are
two different classes, hence the cast fails.

This kind of problems are fairly common in multi-classloader environment, and
most of the users would get really confused with this.

In JAXB API, we have precautions for this kind of failures and provide error
diagnostics. The code is cited below so that you can adapt a similar technique
in the JAXP API.

// this creates JAXBContext, but don't cast it just yet.
Object context = m.invoke(null, classes, properties);
if(!(context instanceof JAXBContext))

{ // the cast would fail, so generate an exception with a nice message handleClassCastException(context.getClass(), JAXBContext.class); }

return (JAXBContext)context;

private static void handleClassCastException(Class originalType, Class
targetType) throws JAXBException

{ final URL targetTypeURL = which(targetType); throw new JAXBException(Messages.format(Messages.ILLEGAL_CAST, // we don't care where the impl class is, we want to know where JAXBContext lives in the impl // class' ClassLoader originalType.getClass().getClassLoader().getResource("javax/xml/bind/JAXBContext.class").toString(), targetTypeURL.toString())); }

static URL which(Class clazz)

{ return which(clazz, clazz.getClassLoader()); }

static URL which(Class clazz, ClassLoader loader) {

String classnameAsResource = clazz.getName().replace('.', '/') + ".class";

if(loader == null)

{ loader = ClassLoader.getSystemClassLoader(); }

return loader.getResource(classnameAsResource);
}






[JAXP-15] DocumentBuilder.setEntityResolver() does not work Created: 14/Feb/07  Updated: 16/Feb/07  Resolved: 16/Feb/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: adochiei Assignee: ndw
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


Issuezilla Id: 15

 Description   

I have tested this with JAXP 1.3 and 1.4 !!

I have an XML file with <!DOCTYPE sql SYSTEM "SQL.DTD"> and when parsing this
file I want to use for parsing another DTD, so that I wrote :

...
final InputStream dtd = ...; //dtd is a NOT NULL InputStream (the desired DTD)
...
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setValidating(false); //with 'true' the result is the same
factory.setNamespaceAware(false); //I do not use it in my XML

DocumentBuilder builder = factory.newDocumentBuilder();

builder.setEntityResolver(new EntityResolver(){
public InputSource resolveEntity(String publicId, String systemId)

{ return new InputSource(dtd); }

});
document = builder.parse(is);

RESULT OBSERVED: the parsing finish execution without errors but the resulting
document does not contain all XML nodes !!!! in fact I observe that only ROOT
node (sql) is available in document. If I did not setEntityResolver on builder I
receive the error of not finding SQL.DTD; if I remove the line <!DOCTYPE sql
SYSTEM "SQL.DTD"> from XML file the parsing will be just fine and document will
contain all nodes!!

I repeat: I've tested this with 1.3 and 1.4 also and the result is the same.
When specifying an EntityResolver for
javax.xml.parsers.DocumentBuilder.DocumentBuilder the parsing finish with no
error but the result is not correct.

10x

--Florin Adochiei



 Comments   
Comment by ndw [ 14/Feb/07 ]

Can you attach a small sample XML document and your DTD, please? I use resolvers
all the time and I've never seen anything like this.

Comment by adochiei [ 14/Feb/07 ]

I forgot to tell that when I used setEntityResolver with SAX (on XMLReader) it
works fine! The problem appears only for DOM type ->
javax.xml.parsers.DocumentBuilder.DocumentBuilder
-------------------
My working XML is (sql.xml):
---------------------
<?xml version="1.0"?>
<!DOCTYPE sql SYSTEM "SQL.DTD">
<sql>
<data name="TEST_SQL_SELECT_BUFFER_CNP">
<value>
<![CDATA[
select buf.CNP, buf.INFO, buf.ORIGINAL_RESPONSE
from RCB.BUFFER buf, (select max(ID) as MAXID from RCB.BUFFER group by CNP)
results
where buf.ID = results.MAXID and buf.CB='BFG' and buf.CNP in (?,?,?)
]]>
</value>
</data>
<data name="SQL_SELECT_BUFFER">
<value>
<![CDATA[
select buf.CNP, buf.INFO, buf.ORIGINAL_RESPONSE
from RCB.BUFFER buf, (select max(ID) as MAXID from RCB.BUFFER group by CNP)
results
where buf.ID = results.MAXID and buf.CB='BFG'
]]>
</value>
</data>
</sql>
----------------------------
My working DTD is (SQL.DTD):
-----------------------------
<?xml version='1.0' encoding="utf-8"?>
<!ELEMENT sql
(data+)
>

<!ELEMENT data
(value)
>

<!ATTLIST data
name CDATA #REQUIRED
>

<!ELEMENT value
(#PCDATA)
>

-------------------
I give you the exact structure of tested XML and DTD The SQL queries inside
can be anything as long as are included in CDATA section ... I suppose.

I must say I'm using JDK 1.4.2_13 with JAXP 1.4 in lib/endorsed directory.
I'm running my application with command:
C:\j2sdk1.4.2_13\bin\java.exe -Djava.endorsed.dirs=D:\work\RCB\lib\endorsed <...>

Endorsed directory (D:\work\RCB\lib\endorsed) contains 2 jar files: jaxp-api.jar
& jaxp-ri.jar, downloaded from dev.java.net site.

10x

--Florin

Comment by ndw [ 14/Feb/07 ]

The following program works for me. Does it work for you?

/*

  • Test.java
    *
  • Created on February 14, 2007, 1:04 PM
    *
  • To change this template, choose Tools | Template Manager
  • and open the template in the editor.
    */

package javanet.jaxp15;

import java.io.FileInputStream;
import java.io.IOException;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;

import junit.framework.TestCase;
import junit.textui.TestRunner;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLFilter;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLFilterImpl;

/**
*

  • @author ndw
    */
    public class Test extends TestCase {
    FileInputStream dtd;

public static void main(String [] args)

{ TestRunner.run(Test.class); }

public Test() {
}

public void test() throws ParserConfigurationException, SAXException,
IOException {
dtd = new FileInputStream("jaxp-ri/src/unit-test/javanet/jaxp15/sql.dtd");
FileInputStream is = new
FileInputStream("jaxp-ri/src/unit-test/javanet/jaxp15/sql.xml");
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setValidating(true);
factory.setNamespaceAware(false);

DocumentBuilder builder = factory.newDocumentBuilder();

builder.setEntityResolver(new EntityResolver(){
public InputSource resolveEntity(String publicId, String systemId)

{ return new InputSource(dtd); }

});

Document document = builder.parse(is);
}
}

Comment by adochiei [ 15/Feb/07 ]

Hy !

I have tested your code. For me is the same problem ...but I found a solution
for my case. Below is the code you should test you must take a look at the
comments inside the code because the problem is that method 1 has different
results when using resolver and not using resolver.

My code:
=========
package org.test;

import java.io.FileInputStream;
import java.io.IOException;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;

import junit.framework.TestCase;
import junit.textui.TestRunner;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLFilter;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.helpers.XMLFilterImpl;

public class Test extends TestCase{
FileInputStream dtd;

public static void main(String [] args)

{ TestRunner.run(Test.class); }

public Test() {
}

public void test() throws ParserConfigurationException, SAXException,
IOException {
dtd = new FileInputStream("D:\\work\\TESTResolver\\test_files
SQL.DTD");
FileInputStream is = new
FileInputStream("D:\\work\\TESTResolver\\test_files
sql.xml");

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

//factory.setValidating(true);
factory.setNamespaceAware(false);

DocumentBuilder builder = factory.newDocumentBuilder();

builder.setEntityResolver(new EntityResolver(){
public InputSource resolveEntity(String publicId, String systemId)

{ return new InputSource(dtd); }

});

Document document = builder.parse(is);

// this method 1 does not work fine when specifying the entity resolver
above but
// it works fine when the resolver is missing from above and from
sql.xml DOCTYPE element

//(you can comment setEntityResolver from above and remove <!DOCTYPE
sql SYSTEM "SQL.DTD"> from sql.xml to make the same test as I did)

parseMethod1_i_have_used(document, "sql"); //

//I find this method 2 is always working (I think I will change the
code with this) but why the first method
//have different results when using resolver and not using resolver ????
parseMethod2_works_fine_always(document);

}

/**

  • The method I have used for parsing my document. (I know that it is not
    the best solution )
  • The number of childs for 'sql' node is 0 when using entity resolver and
    works fine when we did
  • not specified the resolver.
  • @param doc
  • @param rootNodeName
    */
    private static void parseMethod1_i_have_used(Document doc, String
    rootNodeName){
    NodeList nlist = doc.getChildNodes();
    Node node = null;
    for (int i = 0; i < nlist.getLength(); i++)
    Unknown macro: { node = nlist.item(i); if (node.getNodeName().equals(rootNodeName)){ //we find node named "sql" but the number of childs differ when using resolver (0 childs) and not using resolver (correct number of childs) System.out.println("parseMethod1 > sqlRoot Node: " + node.getNodeName() + " has " + node.getChildNodes().getLength() + " childs"); break; } }

    }

/**

  • The method I find working always (with or without entity resolver).
  • Give always the right number of 'sql' element childs.
  • @param doc
    */
    private static void parseMethod2_works_fine_always(Document doc) { Element sqlRoot = doc.getDocumentElement(); System.out.println("parseMethod2 > sqlRoot Element: " + sqlRoot.getNodeName() + " has " + sqlRoot.getChildNodes().getLength() + " childs"); }

    }
    =======
    I found that using doc.getDocumentElement() to get sql root everything works
    fine but why the first method when iterating over childs nodes is not working
    when using resolver ?

10x

--Florin

Comment by ndw [ 15/Feb/07 ]

I'm baffled. This has nothing to do with the resolver. If you remove the
resolver and change things so that the parser simply loads the DTD from the
DOCTYPE declaration, I'm seeing the same bizarre behavior.

I'm still investigating.

Comment by adochiei [ 15/Feb/07 ]

well, I thought the problem was the resolver but it looks like the problem is in
the parser when using a DTD ? .... strange behaviour!

Comment by ndw [ 15/Feb/07 ]

Ok, I found the bug. In method1, you're finding the DOCUMENT_TYPE_NODE which
really doesn't have any children. Try changing the code so that it looks for
an ELEMENT_NODE:

...
for (int i = 0; i < nlist.getLength(); i++) {
node = nlist.item;
System.out.println("==>" + node.toString() + ": " + node.getNodeType());
if (node.getNodeType() == Node.ELEMENT_NODE
&& node.getNodeName().equals(rootNodeName)) {
...
...

With that change, I get the correct results in both cases, with and without the
DTD, with and without the resolver.

I believe I can close this bug now as WORKSFORME

Do you agree?

Comment by adochiei [ 16/Feb/07 ]

100% agree with you !!! it's for the first time I've used JAXP and XML parsing
and I didn't know the following:

When using <!DOCTYPE sql SYSTEM "SQL.DTD"> you will receive a Node with the name
"sql" and type org.w3c.dom.DocumentType and another node with the same name
("sql") but with type org.w3c.dom.Document; When not using DOCTYPE in xml file
you will find a single node named "sql" of type Document.

10x for help!

--Florin

Comment by ndw [ 16/Feb/07 ]

Not a bug.





[JAXP-13] No mention in release notes that XSLT command-line functionality removed Created: 12/Jan/07  Updated: 17/Jan/07  Resolved: 17/Jan/07

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: tmnelson Assignee: Joe Wang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13

 Description   

The option for using Xalan for XSLT processing on the command line was removed
(com.sun.org.apache.xalan.internal.xslt.Process, r1.4), but this was not
mentioned in the release notes for JAXP 1.4. This is a significant
functionality change, especially considering that the JAXP 1.3 compatability
guide has an entire section describing the command-line usage. The phrase
"Xalan-interpretive is not included in the reference implementation" is, I feel,
disingenious, because users searching for "command line XSLT" (or a similarly
common expression) will not find it, as "Xalan-interpretive" is a vague reference.



 Comments   
Comment by Santiago Pericas-Geertsen [ 12/Jan/07 ]

This is a good point. The release notes ought to talk about this. The functionality has been removed since
JAXP 1.3. In fact, it isn't removed, it is just hidden (the main method was renamed to _main). Thus, it's still
possible to write a simple class with a main() method that calls Process._main(). I thought we had this
explained somewhere, but if it isn't in the release notes, we need to update them. I'm assigning this one
to Joe.

Comment by Joe Wang [ 17/Jan/07 ]

Add section: Command Line Access to XSLTC

Refer to: https://jaxp.dev.java.net/1.4/ReleaseNotes.html

Thanks.





[JAXP-14] Schema correctness check is too draconian Created: 16/Jan/07  Updated: 16/Jan/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: jaxp-issues
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14

 Description   

See http://forums.java.net/jive/thread.jspa?threadID=21147&tstart=30

It would be really nice if the JAXP RI could report some of the schema
correctness problems as warnings (or in any other means that indicate those
errors are recoverable), as opposed to hard errors.

While this does seem like a correct error report, the fact of the matter is that
Microsoft is generating this kind of schemas in their WSDL (as well as other
parties — this error is fairly common), and we can't afford not to process those.

I do realize that this is a slippery slope, but please consider making this
change if possible.






[JAXP-11] validator.validate(new DOMSource(node)) throws SAXException with jaxp 1.4 Created: 25/Aug/06  Updated: 16/Nov/06  Resolved: 16/Nov/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: brinzing Assignee: ndw
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive TestValidator.zip    
Issuezilla Id: 11

 Description   

Hi,

i just made my first steps with jre 1.6b2 and found the following problem:

validator.validate(new DOMSource(node));

always throws a SAXException ("cannot find the declaration of element ROOT")
this happens in all my programs where i try to validate a xml file with a schema
xsd file ...

but this does not happen with jre 1.5 or jre 1.4.2_12 (jaxp 1.3.2 endorsed) or
even with jre 1.6b2 (jaxp 1.3.2 endorsed)

any hints ?

Oliver

example:

xml file
--------

<?xml version="1.0" encoding="UTF-8"?>
<ROOT Typ="Contents" Version="1.0">
<LINKS>
<LINK>
<TARGET template="a.xml" Version="1">
<INFO Description="test1" Theme="b"/>
</TARGET>
</LINK>
<LINK>
<TARGET template="b.xml" Version="2">
<INFO Description="test2" Theme="b"/>
</TARGET>
</LINK>
</LINKS>
</ROOT>

schema file
-----------

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="INFO">
<xs:complexType>
<xs:attribute name="Description" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="Theme" type="xs:NMTOKEN" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="LINK">
<xs:complexType>
<xs:sequence>
<xs:element ref="TARGET"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="LINKS">
<xs:complexType>
<xs:sequence>
<xs:element ref="LINK" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ROOT">
<xs:complexType>
<xs:sequence>
<xs:element ref="LINKS"/>
</xs:sequence>
<xs:attribute name="Typ" type="xs:NMTOKEN" use="required"/>
<xs:attribute name="Version" type="xs:decimal" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="TARGET">
<xs:complexType>
<xs:sequence>
<xs:element ref="INFO"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:integer" use="required"/>
<xs:attribute name="template" type="xs:NMTOKEN" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>



 Comments   
Comment by brinzing [ 25/Aug/06 ]

Created an attachment (id=4)
test case for validator

Comment by ndw [ 29/Aug/06 ]
      • Issue 10 has been marked as a duplicate of this issue. ***
Comment by lindstro [ 29/Aug/06 ]

Assigning bug to Norm.

Comment by brinzing [ 13/Nov/06 ]

Hi,

this bug still is in Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)

can someone please have a look ?

Oliver

Comment by ndw [ 16/Nov/06 ]

After you create the DocumentBuilderFactory, turn on namespace awareness. That
works around the bug. I'm still investigating why this is necessary now but was,
apparently, the default in the past.

Comment by ndw [ 16/Nov/06 ]

On further consideration, this isn't a bug. The bug is that XML Schema
validation ever worked on a DOM built with namespace support turned off.

Namespaces support is a prerequisite from XML Schema validation.





[JAXP-12] toString method of XMLGregorianCalendar does not return a valid dateTime value Created: 23/Oct/06  Updated: 16/Nov/06  Resolved: 16/Nov/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: nalmodiel Assignee: jaxp-issues
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12

 Description   

toString method of XMLGregorianCalendar does not return a valid dateTime value.
The output contains an exponent notation in millisecond value.

The following sample will create an XMLGregorianCalendar from
2006-10-23T22:15:01.0000001+08:00, but toString will print a different and an
invalid dateTime which is 2006-10-23T22:15:01E-7+08:00

package org.gs1us.xml.test;

import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.XMLGregorianCalendar;

/**

  • @author nalmodiel
    */
    public class XMLGregorianCalendarSample {

public static void main(String[] args) {

try

{ String inputDateTime = "2006-10-23T22:15:01.0000001+08:00"; DatatypeFactory factory = DatatypeFactory.newInstance(); XMLGregorianCalendar calendar = factory.newXMLGregorianCalendar(inputDateTime); System.out.println(calendar.toString()); }

catch (Exception e)

{ e.printStackTrace(); }

}
}



 Comments   
Comment by ndw [ 23/Oct/06 ]

Added a unit test to the build. Working on it.

Comment by ndw [ 16/Nov/06 ]

The fix for this is now in the HEAD





[JAXP-9] Inconsistent exception thrown in SchemaFactory Created: 24/Aug/06  Updated: 29/Aug/06

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 9

 Description   

SchemaFactory#newSchema("non existing file") throws SaxException. Shouldn't it
throw IOException, for consistency with Validator#validateSource, for instance,
and also to follow the "principle of least suprise" ?



 Comments   
Comment by lindstro [ 29/Aug/06 ]

Assigning bug to Norm.





[JAXP-10] validator.validate(new DOMSource(node)); Created: 25/Aug/06  Updated: 29/Aug/06  Resolved: 29/Aug/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: brinzing Assignee: jaxp-issues
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10

 Description   

Hi,

i just made my first steps with jre 1.6b2 and found the following problem:

validator.validate(new DOMSource(node));

always throws a SAXException ("cannot find the declaration of element xxx")
this happens in all my programs where i try to validate a xml file with a schema
xsd file ...

this does not happen with jre 1.5 or jre 1.4.2_12 (jaxp 1.3.2 endorsed) or
even with jre 1.6b2 (jaxp 1.3.2 endorsed)

any hints ?

Oliver



 Comments   
Comment by ndw [ 29/Aug/06 ]

This is a dup of 11.

      • This issue has been marked as a duplicate of 11 ***




[JAXP-8] Resolving catalog issue Created: 30/Jan/06  Updated: 25/Aug/06  Resolved: 25/Aug/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: todorst Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 8

 Description   

The fix for issue #6326037 (unfortunately I did not manage to find this issue?!)
in com.sun.org.apache.xml.internal.resolver.helpers.FileURL causes
FileURL#makeURL to generate wrong URLs on Linux (or other OS) when 'user.dir'
system property starts with slash, e.g. FileURL.makeURL("test") and
'user.dir=/home/foo' returns "file://home/foo/test", which is incorrect and does
not reference the desired location. Diff between v1.2 and v1.3:

http://fisheye5.cenqua.com/viewrep/jaxp-sources/xml-xerces/java/src/com/sun/org/apache/xml/internal/resolver/helpers/FileURL.java?r1=1.2&r2=1.3

shows that URL schema prefix has been changed from "file://" to "file:///". This
change does not affect Windows because 'user.dir' property starts with drive
letter e.g. "c:\foo", but this is valid only on Windows. On all Linux/Unix OS
this change introduces another issue. Fortunately the fix is straightforward:

public static URL makeURL(String pathname) throws MalformedURLException {
if (pathname.startsWith("/"))

{ return new URL("file://" + pathname); }

String userdir = System.getProperty("user.dir");
userdir.replace('
', '/');

String prefix = "file://";
if (!userdir.startsWith("/"))

{ prefix += "/"; }

if (userdir.endsWith("/"))

{ return new URL(prefix + userdir + pathname); }

else

{ return new URL(prefix + userdir + "/" + pathname); }

}



 Comments   
Comment by lindstro [ 25/Aug/06 ]

Looking at FileURL.java and its logs shows that Sunitha resolved this issue on
2006/06/07, by changing the code to use the File.toURL() when constructing the URL.





[JAXP-1] Typo in error message: XPathFctory Created: 30/Oct/04  Updated: 25/Aug/06  Resolved: 25/Aug/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mhkay Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1

 Description   

Type in error message from XPathFactory (the error message is otherwise legitimate):

javax.xml.xpath.XPathFactoryConfigurationException:
No XPathFctory implementation found for the object model:
^^^^
http://java.sun.com/jaxp/xpath/dom
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:150)
at ApplyXPathJAXP.doMain(ApplyXPathJAXP.java:162)
at ApplyXPathJAXP.main(ApplyXPathJAXP.java:253)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



 Comments   
Comment by lindstro [ 25/Aug/06 ]

Doing a grep on the code does not turn up this typo, so this appears to
be fixed in jaxp 1.4.





[JAXP-6] Support format-pretty-print in LSSerializer Created: 15/Dec/05  Updated: 20/Aug/06  Resolved: 20/Aug/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: iasandcb Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File DOMSerializerImpl.java     Java Source File DOMSerializerImpl.java    
Issuezilla Id: 6

 Description   

The current JAXP 1.3 RI doesn't support "format-pretty-print" in LSSerializer.
These patches enable you to turn on the parameter on Java SE 5 and SE 6.



 Comments   
Comment by iasandcb [ 15/Dec/05 ]

Created an attachment (id=2)
Patch for Java SE 5 (JAXP 1.3 RI).

Comment by iasandcb [ 15/Dec/05 ]

Created an attachment (id=3)
Patch for Java SE 6 (JAXP 1.4 RI)

Comment by iasandcb [ 15/Dec/05 ]

I hope these patches would be applied as soon as possible.

Cheers,

Ias

Comment by jeffsuttor [ 12/Jul/06 ]

this will be fixed in Mustang b92.
thanks for submitting the fix.

see CVS for LSSerializerTest unit test.

Comment by iasandcb [ 20/Aug/06 ]

Thanks.
Are you also planning to apply this patch to JDK 5 as well?





[JAXP-7] getDOMImplementation("XML 3.0") doesn't work Created: 20/Dec/05  Updated: 10/Feb/06  Resolved: 10/Feb/06

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: iasandcb Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 7

 Description   

I tried

implementation = DOMImplementationRegistry.newInstance()
.getDOMImplementation("XML 3.0");

but got null on JDK 5.0_06 while the code above works fine on Java SE 6 Mustang.

The main reason is that org.w3c.dom.DOMImplementationSourceList is not set, so applying

-
Dorg.w3c.dom.DOMImplementationSourceList=com.sun.org.apache.xerces.internal.dom.DOMXSImplem
entationSourceImpl

solves this problem.



 Comments   
Comment by sunithareddy [ 10/Feb/06 ]

This issue has been fixed and will be available in Mustang b72.
Following is the corresponding bug for this issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6367542.





[JAXP-5] JAXP [JAXP1.3, JDK1.4] does not handle XInclude properly in SAX Created: 31/Aug/05  Updated: 28/Sep/05  Resolved: 28/Sep/05

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: vhi Assignee: jaxp-issues
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jaxp_bug.zip    
Issuezilla Id: 5

 Description   

JAXP does not handle XInclude properly, failing with the following error:

"Error attempting to parse XML file (href='Included.xml')."

First of all, the exceptions are not chained properly which leads to such an un-
understandable error. Debugging has found me the following exception for the
same condition.

"org.xml.sax.SAXParseException: Elements from
namespace 'http://www.w3.org/2001/XInclude', other than 'fallback', are not
allowed to be children of 'include' elements. However, 'include' was found."

Here are the XML files that I used to reproduce the error.

X-------------------------------------------------X
Test.xml
X-------------------------------------------------X
<dodo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="Included.xml"/>
</dodo>

X-------------------------------------------------X
Included.xml
X-------------------------------------------------X
<is>
<dead>
<include xmlns="http://www.w3.org/2001/XInclude"
href="a_dir/RecInclude.xml"/>
</dead>
</is>

X-------------------------------------------------X
a_dir/RecInclude.xml
X-------------------------------------------------X
<are>
<you>
<include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
<sandi>
<include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
</sandi>
</you>
</are>

X-------------------------------------------------X
b_dir/Rec2Include.xml
X-------------------------------------------------X
<sure/>
X-------------------------------------------------X

Due to insufficient time and non-availability of the source code for JAXP, I
could not investigate deaper into the problem.

JAXP version: jaxp 1.3 20050622
JDK: 1.4.2
Mode of parsing: SAX.

The test program is as follows:

X-------------------------------------------------X
public class SAXXInclude {

public static void main(String[] args) throws Exception {

parseSAX(new FileInputStream("Test.xml"), new DefaultHandler() {

public void endElement(String uri, String localName,
String qName)
throws SAXException

{ System.out.println("END Element: " + localName); }

public void startElement(String uri, String localName,
String qName, Attributes attributes)
throws SAXException

{ System.out.println("START Element: " + localName); }

});
}

public static SAXParser createSAXParser()
throws ParserConfigurationException, SAXException

{ SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); factory.setFeature( "http://xml.org/sax/features/external-general- entities", true); factory .setFeature( "http://xml.org/sax/features/external-parameter-entities", true); factory.setXIncludeAware(true); return factory.newSAXParser(); }

public static void parseSAX(InputStream istream, DefaultHandler h)
throws SAXException, IOException,
ParserConfigurationException

{ createSAXParser().parse(istream, h); }

public static void parseSAX(InputSource isource, DefaultHandler h)
throws SAXException, IOException,
ParserConfigurationException

{ createSAXParser().parse(isource, h); }

}
X-------------------------------------------------X



 Comments   
Comment by sunithareddy [ 01/Sep/05 ]

The given test program runs successfully under the specified
environment(JDK1.4.2 & JAXP 1.3 latest). Please check for appropriate location
of XML files.

Comment by vhi [ 02/Sep/05 ]

Created an attachment (id=1)
Contains a "run.bat" running which will reproduce the bug.

Comment by vhi [ 02/Sep/05 ]

Since I cannot reopen the bug, I am attaching a zip containing proof-of-bug.
Just execute the "run.bat". You will find the libraries used by me in the "lib"
folder.

Running the program should result in:

X----------------------------------X
org.xml.sax.SAXParseException: Elements from namespace 'http://www.w3.org/2001/X
Include', other than 'fallback', are not allowed to be children of 'include' ele
ments. However, 'include' was found.
org.xml.sax.SAXParseException: Error attempting to parse XML file (href='a_dir/R
ecInclude.xml').
org.xml.sax.SAXParseException: Error attempting to parse XML file (href='Include
d.xml').
Exception in thread "main" org.xml.sax.SAXParseException: Error attempting to pa
rse XML file (href='Included.xml').
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Un
known Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:379)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:176)
at SAXXInclude.parseSAX(SAXXInclude.java:69)
at SAXXInclude.main(SAXXInclude.java:23)
X----------------------------------X

I used:

X----------------------------------X
java version "1.4.2_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05)
Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
X----------------------------------X

I hope that this is sufficient information to reproduce the bug.

Comment by vhi [ 02/Sep/05 ]

The problem seems to be that once an xinclude is declared, no other xinclude is
allowed inside another sub-element.

Example:

<are>
<you>
<include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
<sandi>
<!-- THIS ONE --> <include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
</sandi>
</you>
</are>

I worked around this problem by exporting:
<sandi>
<include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
</sandi>

into another file, and the resulting main file was:

<are>
<you>
<include xmlns="http://www.w3.org/2001/XInclude"
href="b_dir/Rec2Include.xml"/>
<include xmlns="http://www.w3.org/2001/XInclude"
href="Sandi.xml"/>
</you>
</are>

Comment by sunithareddy [ 02/Sep/05 ]

Test.xml that is bundled with the zip file contains the following attribute for
root element: xmlns:xlink="http://www.w3.org/1999/xlink". This attribute was not
present in the earlier Test.xml, that is why it could parse successfully.Do you
use both xinlude & xlink?

Comment by vhi [ 28/Sep/05 ]

I think it is not because of XLink per-se, but ANY xmlns attribute. For
example, I could reproduce it with:

<dodo xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:junk="hahaha">

But it is necessary for me to use different namespaces.





[JAXP-4] NoSuchMethod doing getSOAPBody in jws 1.6 Created: 17/Aug/05  Updated: 18/Aug/05  Resolved: 18/Aug/05

Status: Resolved
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mweitz Assignee: jaxp-issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4

 Description   

I have downloaded both jwsdp 1.6 and 1.4. I started with v 1.6 and tested the
UddiPing sample under SAAJ. It worked fine. I modified the class to do some
parsing of the response and get a NoSuchMethod error when trying to do
getSOAPBody on the reply.

I am using this tutorial to guide my changes:
http://java.sun.com/webservices/docs/1.3/tutorial/doc/SAAJ4.html.

I am running on Windows XP sp2 with J2RE 1.4.2 and the following classpath

CLASSPATH=
C:\Sun\jwsdp-1.6/saaj/lib/saaj-api.jar;
C:\Sun\jwsdp-1.6/saaj/lib/saaj-impl.jar;
C:\Sun\jwsdp-1.6/jwsdp-shared/lib/commons-logging.jar;
C:\Sun\jwsdp-1.6/jwsdp-shared/lib/mail.jar;
C:\Sun\jwsdp-1.6/jwsdp-shared/lib/activation.jar;
C:\Sun\jwsdp-1.6/jaxp/lib/endorsed/dom.jar;
C:\Sun\jwsdp-1.6/jaxp/lib/endorsed/xercesImpl.jar;
C:\Sun\jwsdp-1.6/jaxp/lib/endorsed/sax.jar;
C:\Sun\jwsdp-1.6/jaxp/lib/endorsed/xalan.jar;

I have modified UddiPing.java by adding a getSOAPBody() call. However that
method call causes a NoSuchMethod exception at runtime.

System.out.println("\n----------- Reply Message ----------\n");
reply.writeTo(System.out);
System.out.println();

// new code here
SOAPBody replyBody = reply.getSOAPBody();

connection.close();

I get the following exception:

Exception in thread "main" java.lang.NoSuchMethodError: javax.xml.parsers.SAXPar
serFactory: method getSchema()Ljavax/xml/validation/Schema; not found
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.<init>(Unknown
Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl.newSAXPa
rser(Unknown Source)
at com.sun.xml.messaging.saaj.util.ParserPool.get(ParserPool.java:42)
at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(Envelo
peFactory.java:62)
at com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelope
FromSource(SOAPPart1_1Impl.java:39)
at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl
.java:98)
at com.sun.xml.messaging.saaj.soap.MessageImpl.getSOAPBody(MessageImpl.j
ava:768)
at UddiPing.main(UddiPing.java:81)

However, taking the same Java class and using JWSDP 1.4 the class runs
correctly but using the same jar files from the 1.4 version isntead

Is there an inconsistency between 1.4 and 1.6 JAXP that is causing this? How
am I supposed to access the SOAP elements in 1.6?

I am using the this as my uddi.properties. (The 1.6 version, works for 1.4)

URL:http://uddi.ibm.com/testregistry/inquiryapi
http.proxyHost:webcache.sfbay.sun.com
http.proxyPort:8080

Here is the full UddiPing.java class I am using.

/*

  • $Id: UddiPing.java,v 1.3.4.6 2004/04/23 15:53:50 vm147297 Exp $
  • $Revision: 1.3.4.6 $
  • $Date: 2004/04/23 15:53:50 $
    */

/*

  • Copyright 2004 Sun Microsystems, Inc. All rights reserved.
  • SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
    */

import java.io.FileInputStream;
import java.net.URL;
import java.util.Enumeration;
import java.util.Properties;
import java.util.*;

import javax.xml.soap.*;

public class UddiPing {

public static void main(String[] args) {
try {

if (args.length != 2)

{ System.err.println("Usage: UddiPing properties-file business- name"); System.exit(1); }

Properties myprops = new Properties();
myprops.load(new FileInputStream(args[0]));

Properties props = System.getProperties();

Enumeration it = myprops.propertyNames();
while (it.hasMoreElements())

{ String s = (String) it.nextElement(); props.put(s, myprops.getProperty(s)); }

// Create the connection and the message factory.
SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();
SOAPConnection connection = scf.createConnection();
MessageFactory msgFactory = MessageFactory.newInstance();

// Create a message
SOAPMessage msg = msgFactory.createMessage();

// Create an envelope in the message
SOAPEnvelope envelope = msg.getSOAPPart().getEnvelope();

// Get hold of the the body
SOAPBody body = envelope.getBody();

body.addChildElement(envelope.createName("find_service", "",
"urn:uddi-org:api_v2"))
.addAttribute(envelope.createName("generic"), "2.0")
.addAttribute(envelope.createName("maxRows"), "100")
.addChildElement(envelope.createName("name"))
.addTextNode(args[1]);

URL endpoint
= new URL(System.getProperties().getProperty("URL"));

msg.saveChanges();

System.out.println("\n----------- Request Message ----------\n");
msg.writeTo(System.out);

SOAPMessage reply = connection.call(msg, endpoint);

System.out.println("\n\nReceived reply from: "+endpoint);

System.out.println("\n----------- Reply Message ----------\n");
reply.writeTo(System.out);
System.out.println();

SOAPBody replyBody = reply.getSOAPBody();
envelope = reply.getSOAPPart().getEnvelope();

System.out.println("\n\nContent extracted from " +
"the reply message:\n");

java.util.Iterator businessListIterator =
replyBody.getChildElements(
envelope.createName("serviceList",
"", "urn:uddi-org:api_v2"));

SOAPBodyElement businessList =
(SOAPBodyElement)businessListIterator.next();

java.util.Iterator businessInfosIterator =
businessList.getChildElements(
envelope.createName("serviceInfos",
"", "urn:uddi-org:api_v2"));

SOAPElement businessInfos =
(SOAPElement)businessInfosIterator.next();

Iterator businessInfoIterator =
businessInfos.getChildElements(
envelope.createName("serviceInfo",
"", "urn:uddi-org:api_v2"));

if (! businessInfoIterator.hasNext())

{ System.out.println("No businesses found " + "matching the name '" + args[1] + "'."); }

else {
while (businessInfoIterator.hasNext()) {
SOAPElement businessInfo = (SOAPElement)
businessInfoIterator.next();
// Extract name and description from the
// businessInfo
java.util.Iterator nameIterator =
businessInfo.getChildElements(
envelope.createName("name",
"", "urn:uddi-org:api_v2"));
while (nameIterator.hasNext())

{ SOAPElement businessName = (SOAPElement)nameIterator.next(); System.out.println("Company name: " + businessName.getValue()); }

java.util.Iterator descriptionIterator =
businessInfo.getChildElements(
envelope.createName(
"description", "",
"urn:uddi-org:api_v2"));
while (descriptionIterator.hasNext())

{ SOAPElement businessDescription = (SOAPElement) descriptionIterator.next(); System.out.println("Description: " + businessDescription.getValue()); }

System.out.println("");
}
} // end if-else

connection.close();

} catch (Exception ex)

{ ex.printStackTrace(); }

}
}



 Comments   
Comment by sunithareddy [ 18/Aug/05 ]

To run your class with JRE1.4.2, you need to use endorsed mechanism, as shown below:
java -Djava.endorsed.dirs=<directory of jaxp jar files> UddiPing

JRE uses the classes which are bundled in it by default. So, it doesn't help
even if you set CLASSPATH to appropriate jars. To override the deafult jars, you
need to use endorsed way.





Generated at Thu Jul 02 23:57:28 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.