Hide Forgot
Date of First Response: 2010-05-24 06:42:56 Workaround: Workaround Exists Workaround Description: Deploying using an existing WSDL instead of leaving JBossWS to generate a new WSDL can bypass this. project_key: SOA Caused by: java.lang.NullPointerException at org.jboss.ws.tools.JavaToXSD.parseSchema(JavaToXSD.java:178) at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:415) at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(WSDL11Reader.java:180) at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:129) at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
Workaround Description: Added: Deploying using an existing WSDL instead of leaving JBossWS to generate a new WSDL can bypass this. Workaround: Added: [Workaround Exists]
Link: Added: This issue incorporates JBPAPP-3172
included in EAP 5.0.1
Can we please have some information on how this was fixed for the Release Notes? Bullet-points are fine.
Release Notes: - - Added detection for '#' characters and convert to '_' in schema namespace when generating a temporary file name to write the schema to based on it's namespace.
Thanks for the info, Darran. Draft text for the Release Notes states: https://jira.jboss.org/jira/browse/SOA-1623 A null pointer exception would occur when the user deployed a JAX-WS end-point with types in the target name-space that ended with #. To fix this problem, the software has been changed so that it now detects the presence of the # character and converts it to _ in the schema name-space. It does so at the point in time at which the temporary filename to which the schema is written is generated. (This filename is based on the schema's name-space.) As a result, the exception no longer occurs.
Verified in SOA-P 5.0.2 CR3.