[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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-73] Problem unmarshalling duration-type fields containing whitespace Created: 15/Mar/11  Updated: 28/Jun/12

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

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

Operating System: Windows XP
Platform: All


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

 Description   

The following problem could be observed in Jaxb 2.1:

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

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

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

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

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

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

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

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

Best regards,

Hao and Florian



 Comments   
Comment by gturner [ 15/Mar/11 ]

Ooops!

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

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

e.g.

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

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

Comment by Martin Grebac [ 08/Apr/11 ]

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

Comment by gturner [ 08/Apr/11 ]

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

Comment by Martin Grebac [ 08/Apr/11 ]

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

Comment by gturner [ 08/Apr/11 ]

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

test.xsd:

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

test.xml:

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

Test.java:

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

Ant output:

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

Comment by Iaroslav Savytskyi [ 28/Jun/12 ]

Hi, Joe,

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





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

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

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

javac 1.7.0_21 Ubuntu 12.04.2



 Description   

You can try this usecase with:

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

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

This was originally reported to JAXB's bugtracker:

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

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

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

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

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

Files follow:

A.xsd

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

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

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

</xs:schema>

a.xml

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

(notice the space after 'Organization')

Java validating code

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

import javax.xml.XMLConstants;

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

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

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

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

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

try

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

catch (SAXException e)

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

}
}



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

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





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

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

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

Tags: distinct, exslt, xalanj, xsltc

 Description   

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

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

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

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



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

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





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

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

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


 Description   

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

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

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

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

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

	outWriter.flush();

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

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

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






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

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

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

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

 Description   

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

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

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



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

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

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

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

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

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

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

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





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






Generated at Sun Jul 05 13:44:49 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.