Fatal error when running UDDI sample
 Technote (troubleshooting)
 
Problem(Abstract)
The customer was running a UDDI Sample Application and seeing the following Fatal, Error, and Warning messages on the UDDI gui console.

Jul 12, 2006 10:19:45 AM com.ibm.ws.webservices.xml.WSErrorHandler

FATAL: fatalerror.sax.handler

Jul 12, 2006 10:19:46 AM com.ibm.ws.webservices.xml.BaseType

SEVERE: internal.error

Jul 12, 2006 10:19:46 AM
com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator

WARNING: warning.parse.file.failure
 
Cause
The Web services Engine only supports the use of the org.apache.xerces XML Parser
 
Resolving the problem
In the Web services client trace the following exceptions can be seen:
[8/1/06 11:18:25:125 PDT] 0000000a WSErrorHandle F WSWS1011E: Error: [META-INF/was-webservices.xml:2:-1] Relative URI "../was-webservices.dtd"; can not be resolved without a base URI.

[8/1/06 11:18:25:593 PDT] 0000000a BaseType E WSWS1000E: Error: org.xml.sax.SAXParseException: Relative URI "../was-webservices.dtd"; can not be resolved without a base URI.

at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376)

at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3370)

at org.apache.crimson.parser.Parser2.resolveURI(Parser2.java:2952)

at org.apache.crimson.parser.Parser2.maybeExternalID(Parser2.java:2924)

at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1309)

at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:656)

at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)

at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)

at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:185)

at com.ibm.ws.webservices.xml.ExtFactory.loadDocument(ExtFactory.java:107)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.privilegedInit(WebServicesEngineConfigurationGenerator.java:1212)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.access$500(WebServicesEngineConfigurationGenerator.java:117)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator$2.run(WebServicesEngineConfigurationGenerator.java:1143)

at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator._init(WebServicesEngineConfigurationGenerator.java:1139)

at com.ibm.ws.webservices.engine.lifecycle.LifeCycleObjectImpl.init(LifeCycleObjectImpl.java:112)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.init(WebServicesEngineConfigurationGenerator.java:1126)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.loadConfiguration(WebServicesEngineConfigurationGenerator.java:220)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.getConfigGeneratorInternal(WebServicesEngineConfigurationGenerator.java:185)

at com.ibm.ws.webservices.configuration.WebServicesEngineConfigurationGenerator.createClientDeployment(WebServicesEngineConfigurationGenerator.java:330)

at com.ibm.ws.webservices.engine.configuration.DefaultEngineConfigurationFactory.defaultBasicClientConfiguration(DefaultEngineConfigurationFactory.java:198)

at com.ibm.ws.webservices.engine.configuration.DefaultEngineConfigurationFactory.getClientEngineConfig(DefaultEngineConfigurationFactory.java:155)

at com.ibm.ws.webservices.engine.client.Service.initService(Service.java:444)

at com.ibm.ws.webservices.multiprotocol.provider.soap.ServiceProxy.initialize(ServiceProxy.java:108)

at com.ibm.ws.webservices.multiprotocol.provider.soap.ServiceProxy.(ServiceProxy.java:59)

at com.ibm.ws.webservices.multiprotocol.provider.soap.SOAPServiceProvider.makeService(SOAPServiceProvider.java:135)

at com.ibm.ws.webservices.multiprotocol.models.ModelServiceProvider.createService(ModelServiceProvider.java:176)

at com.ibm.ws.webservices.multiprotocol.utils.ServiceManager.discoverServiceForNamespace(ServiceManager.java:170)

at com.ibm.ws.webservices.multiprotocol.utils.ServiceManager.getServiceForNamespace(ServiceManager.java:103)

at com.ibm.ws.webservices.multiprotocol.AgnosticService.getGeneratedStub(AgnosticService.java:522)

at com.ibm.ws.webservices.multiprotocol.AgnosticService.doGetPort(AgnosticService.java:459)

at com.ibm.ws.webservices.multiprotocol.AgnosticService.getStub(AgnosticService.java:402)

at org.uddi.v3.wsdl.UDDI_ServiceLocator.getUDDI_Security_Port(UDDI_ServiceLocator.java:97)

at org.uddi.v3.wsdl.UDDI_ServiceLocator.getUDDI_Security_Port(UDDI_ServiceLocator.java:93)

at samples.v3client.UDDIv3ClientTModelSample.setupSecurityPort(UDDIv3ClientTModelSample.java:437)

at samples.v3client.UDDIv3ClientTModelSample.initialize(UDDIv3ClientTModelSample.java:329)

at samples.v3client.UDDIv3ClientTModelSample.main(UDDIv3ClientTModelSample.java:195)

[8/1/06 11:18:25:609 PDT] 0000000a WebServicesEn W WSWS1020E: Unable to parse file META-INF/was-webservices.xml

Here we can see the stack includes org.apache.crimson.*

  • There are a number of ways that the parser can be defined. We know that this customer's application is using the crimson parser because it is in the stack trace. Why it is using a different parser is the question.
  • Keep in mind the crimson parser could be getting picked up from some totally separate application in the customer's environment that might have caused it to be set as a default for all other applications.
  • Here is the ordered list of places the parser can be set. If no parser is set, then the xerces parser is set to the default.
  • Use the javax.xml.parsers.DocumentBuilderFactory system property.
  • Use the properties file "lib/jaxp.properties" in the JRE directory.
  • This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above.
  • Use the Services API (as detailed in the JAR file specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.DocumentBuilderFactory in JAR files available to the runtime.
  • Platform default DocumentBuilderFactory instance.
  • I would suggest checking all the above places for any mention of the crimson parser. Out of the 4 places, #2 and #3 are very probable places that it could be set. Notice that #3 actually implies that any JAR file available to the runtime may have a META-INF/services/javax.xml.parsers.DocumentBuilderFactory file which defines parser.
  • If still none of these places seem to define the crimson parser, then the customer could try to explicitly set it back to the xerces parser:

javax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

After setting the system property to use the xerces parser the problem was resolved.

 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Web Services (for example: SOAP or UDDI or WSGW or WSIF)
Operating system(s): Windows
Software version: 6.1
Software edition:
Reference #: 1245780
IBM Group: Software Group
Modified date: Jul 31, 2007