Parsing behavior FYI
starksm64 Oct 29, 2007 11:29 AMI ran into a whitespace issue with an ear that has whitespace surrounding the module path:
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"> <description>Application Archive</description> <display-name>transport_vehicles</display-name> <module> <java> transport_ejb_vehicle_client.jar </java> </module> ...
This failed to parse with:
21:40:05,543 WARN [EARStructure] Error during determineStructure: transport_vehicles.ear java.lang.RuntimeException: Error determining structure: transport_vehicles.ear at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:253) ... Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Invalid token value: transport_ejb_vehicle_client.jar at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:213) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153) at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:151) ... 58 more Caused by: org.jboss.xb.binding.JBossXBValueFormatException: Invalid token value: transport_ejb_vehicle_client.jar at org.jboss.xb.binding.SimpleTypeBindings.unmarshal(SimpleTypeBindings.java:860) at org.jboss.xb.binding.sunday.unmarshalling.CharactersHandler.unmarshal(CharactersHandler.java:114) at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtCharactersHandler.unmarshal(RtCharactersHandler.java:64) at org.jboss.xb.binding.sunday.unmarshalling.CharactersHandler.unmarshal(CharactersHandler.java:124) at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtCharactersHandler.unmarshal(RtCharactersHandler.java:64) at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:1047) at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:266) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:384) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:209) ... 60 more
Turned out the metadata-beans.xml binding for application_5.xsd schema location was incorrectly using application_5_0.xsd. Because of this the schema was being generated from the schema by the XsdBinder and somehow this was changing the behavior of the characters callback. I'm not clear where this change was happening as the ContentHandler.characters(char[] ch, int start, int length) callback value was different in the two cases.