WSDL11Reader.java has problems w/ included WSDL

[davesiracusa]

I'm running into an issue w/ an external web service exposed via ESB/SOAPProxy.  The returned root WSDL, includes a child WSDL (using wsdl:include) that defines the type/schema as well as other required elements.

The WSDL validates just fine in eclipse, soapui.

WSDL11Reader.java is failing while processing because it expects some those elements in the root WSDL file.

It ends up with a null pointer exception.

  public WSDLDefinitions processDefinition(Definition srcWsdl, URL wsdlLoc) throws IOException, WSDLException
   {
      log.trace("processDefinition: " + wsdlLoc);

      destWsdl = new WSDLDefinitions();
      destWsdl.setWsdlTypes(new XSModelTypes());
      destWsdl.setWsdlOneOneDefinition(srcWsdl);
      destWsdl.setWsdlNamespace(Constants.NS_WSDL11);

      processNamespaces(srcWsdl);
      processTopLevelElements(srcWsdl);
      processTypes(srcWsdl, wsdlLoc);
      processUnknownExtensibilityElements(srcWsdl, destWsdl);
      processServices(srcWsdl);

      if (getAllDefinedBindings(srcWsdl).size() != destWsdl.getBindings().length)
         processUnreachableBindings(srcWsdl);

      cleanupTemporaryFiles();

      return destWsdl;
   }

[kconner]

Can you post the stack trace?

Thanks,

     Kev

[kconner]

BTW I am assuming this is the jbossws class, but would still be interested in the stack.

Kev

[davesiracusa]

2010-06-15 06:37:16,399 40465821 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner:) Error installing to Start: name=jboss.esb.vfszip:/C:/ybd/ESB-Tools/jboss-soa-p.5.0.0/jboss-as/server/default/deploy/bpesbservices-1.0.0-SNAPSHOT.esb/ state=Create
org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:191)
at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66)
at org.jboss.soa.esb.listeners.deployers.mc.EsbDeployment.start(EsbDeployment.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:243)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:371)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:256)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
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)
Caused by: org.jboss.soa.esb.ConfigurationException: Unexpected exception while instantiating action instance
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:359)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:340)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.<init>(ActionProcessingPipeline.java:275)
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:185)
... 61 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:355)
... 64 more
Caused by: java.lang.NullPointerException
at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.getXMLInputSource(JBossXSEntityResolver.java:170)
at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.resolveEntity(JBossXSEntityResolver.java:136)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
at org.jboss.ws.tools.JavaToXSD.parseSchema(JavaToXSD.java:181)
at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:415)
at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:430)
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.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:174)
... 69 more

[davesiracusa]

*** MORE Detail ***

The developers are using JAXB WS which generates a very modular WSDL.

I brought down a local copy of the WSDL, child WSDL, and 3 XSD files.

I was able to get it to parse and process the wsdl by adding a default types element (bold below) manually.

<definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.yellow.com/ybbp/api" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" name="MetaverseApiService" targetNamespace="http://www.co.com/ybbp/api">
<import namespace="http://www.co.com/bp/model/api" location="http://localhost/metaverse1.wsdl"/>
<types>
  <xsd:schema targetNamespace="http://www.co.com/ybbp/api" elementFormDefault="qualified"/>
</types>
<binding name="MetaverseApiPortBinding" type="ns1:MetaverseApiPortType" xmlns:ns1="http://www.co.com/bp/model/api">

...

[dward]

Kev,

Yes, this is a JBossWS utility class that I leverage in SOAPProxy, as seen in Dave's stack trace:

at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:129)
at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:174)

Should we create a JBossWS jira issue and alert that team?

David

[kconner]

Should we create a JBossWS jira issue and alert that team?

Lets not be too hasty, we need to make sure it is not us first.

The stacktrace suggests that the jbossws code has picked up the child wsdl and is trying to parse the embedded schemas.

Kev

[kconner]

Dave (Siracusa), could you create a simple test case showing the problem?

We'll investigate further and see what can be done to fix this.

Thanks,

     Kev

[davesiracusa]

I've attached the wsdl++

[davesiracusa]

I created a workaround:

I created a custom action which constructs a SOAPProxy via reflection (guest-class).

Prior to SOAPProxy construction I load (guest_wsdl) the wsdl and transform it (guest-xsl).

I stored the corrected wsdl to the file system, so SOAPProxy can pick it up (wsdl).

<action name="proxy"
        class="com.company.soa.esb.bus.bpesb.actions.WrapSoapProxyAction">
               <property name="guest-class" value="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy" />
               <property name="guest-wsdl" value="http://devkopbpbs01.yb.int/metaverse/soap?wsdl" />
               <property name="guest-xsl" value="/transforms/Fixup_Metaverse_Types_WsdlTransform.xsl" />
               <property name="wsdl" value="file://../deploy/metaverse.wsdl">  
                      <http-client-property name="max-total-connections" value="100" />
                      <http-client-property name="max-connections-per-host" value="50" />
               </property>
</action>

I also created a contract publisher, in order to handle relative file path (wsdl).

@Publish(BPSOAPProxyWsdlContractPublisher.class)
public class WrapSoapProxyAction extends ActionProxy  {
...

Please let me know whether a JIRA gets created for this issue.

Best,

Dave

[dward]

Dave,

Can you please attach WrapSoapProxyAction.java and Fixup_Metaverse_Types_WsdlTransform.xsl?

Thanks,

David

[davesiracusa]

Hi David

Right now it would drag in too many files and the project is  'mavenized'.

Is it okay if I write an article?  I could then de-identify the files and put togther a quickstart compatible project.

The article would demonstrate how to wrap any out-of-box action to handle action exceptions, perform config tweaks etc.

The xsl is below, it transforms the parent wsdl to make SOA-P happy.

Best,

Dave

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

xsl:stylesheet

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsl:output method="xml" indent="yes"/>

<xsl:preserve-space elements="*"/>

<xsl:template match="wsdl:definitions">

<xsl:copy>

<xsl:copy-of select="@*"/>

<wsdl:types>

<xsd:schema targetNamespace="http://www.comapny.com/ybbp/api" elementFormDefault="qualified"/>

</wsdl:types>

<xsl:copy-of select="node()| comment()|text()"/>

</xsl:copy>

</xsl:template>

</

xsl:stylesheet>

xsl:stylesheet>

xsl:stylesheet>

[davesiracusa]

Perhaps have an option to flatten the WSDL?

This would reduce the risk of the wsdl parser having problems.

Likewise SOAPProxy wsdlTransfom wouldn't have to deal with a modular wsdl.

[dward]

Kevin Conner wrote:

Should we create a JBossWS jira issue and alert that team?

Lets not be too hasty, we need to make sure it is not us first.

It is not us.  I was able to recreate it using no JBossESB dependencies at all.  Please see README.TXT inside the attached WSDLTest.zip.

[dward]

Here's a new version of WSDLTest.zip that has a console-success.log in addition to console-error.log, showing that you have to add the <types> section to the example WSDL to not get a NPE.