What is the best way to strip SOAP envelope of a message?

[h.wolffenbuttel]

I want to validate the contents of the SOAP message, but before i can do that i need to strip the SOAP-Envelope of the message. I have looked at the SOAPProcessor but i'm not sure it contains the functionality i'm after.

The ActionPipeline has the ability to validate my message, but only if i strip of my SOAP-Envelope, otherwise i get errors. This can be done by using JAXB (generating classes via XSD) in the first pipeline-action and:
- unmarshalling the message
- marshalling the contents of the SOAP message back to XML
- placing the contents in the default body of the JBOSS-XML message

Is there another way around this? I would think there must be an easier way to do this. Maybe by using JAXB introduction? (i dont really know how to implement that btw)

It would also be helpfull to be able to define in the action if it's a SOAP-message so you don't have to extract the real message from the SOAP-Envelope:

<actions mep="RequestResponse" inXsd="/stuf.bg.0204/bg0204.xsd" outXsd="/stuf.bg.0204/bg0204.xsd" validate="true" soap="true">

[beve]

Hi,

It would also be helpfull to be able to define in the action if it's a SOAP-message so you don't have to extract the real message from the SOAP-Envelope:

If you specify something like the following you do not need to extract the message payload to validate.

<actions mep="RequestResponse" inXsd="/stuf.bg.0204/bg0204.xsd" outXsd="/stuf.bg.0204/bg0204.xsd" validate="true">

This will validate the payload of a soap body by validating against the inXsd schema. You can try using the publish_as_webservice quickstart.

Regards,

/Daniel

[h.wolffenbuttel]

hi,

This will validate the payload of a soap body by validating against the inXsd schema. You can try using the publish_as_webservice quickstart.

The payload in the message still contains the envelope. That's why the suggested configuration doesn't work in my ESB.

I have a WSDL of the service i want to provide, but no clue how to join that with the SOAPProcessor. If my analysis is correct you need to write your own service for the SOAPProcessor to work.

Any suggestions where i can find an example for implementing a SOAPProsessor with existing WSDL? I must be missing something.

[beve]

Hi,

The payload in the message still contains the envelope. That's why the suggested configuration doesn't work in my ESB.

Yes, this is correct. In the action pipeline the payload will contain the complete SOAP Message. But this is after validation has been performed. You can try this using the quickstart I mentioned. Modify the schema and see that validation occurs.

I have a WSDL of the service i want to provide, but no clue how to join that with the SOAPProcessor.

You might want to take a look at the new SOAPProxy:
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/services/soap/src/main/java/org/jboss/soa/esb/actions/soap/proxy/SOAPProxy.java
There are a few quickstarts (webservice_proxy_*) in the main trunk that demonstrate this.

Regards,

/Daniel

[h.wolffenbuttel]

I reconfigured my actionpipeline to use the xsd for validation but i get an exception:

org.jboss.deployment.DeploymentException: Failed to create webservice artifact; - nested throwable: (org.jboss.soa.esb.ConfigurationException: File defined in inXsd attribute 'stuf.bg.0204/bg0204.xsd' not found in classpath.)
 at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.createWebserviceWars(JBoss4ESBDeployer.java:552)
 at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.init(JBoss4ESBDeployer.java:278)
 at org.jboss.deployment.MainDeployer.init(MainDeployer.java:872)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
 at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy9.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:194)
 at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 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:585)
 at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
 at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
 at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818)
 at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419)
 at sun.reflect.GeneratedMethodAccessor95.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
 at sun.rmi.transport.Transport$1.run(Transport.java:153)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
 at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
 at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.soa.esb.ConfigurationException: File defined in inXsd attribute 'stuf.bg.0204/bg0204.xsd' not found in classpath.
 at org.jboss.internal.soa.esb.webservice.ESBContractGenerator.generateWSDL(ESBContractGenerator.java:132)
 at org.jboss.internal.soa.esb.webservice.ESBContractGenerator.generateWSDL(ESBContractGenerator.java:94)
 at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.createWebserviceWars(JBoss4ESBDeployer.java:476)
 ... 89 more
Caused by: java.lang.IllegalArgumentException: null 'stream' arg in method call.
 at org.jboss.soa.esb.dom.YADOMUtil.parseStream(YADOMUtil.java:135)
 at org.jboss.soa.esb.dom.YADOMUtil.parseStream(YADOMUtil.java:114)
 at org.jboss.internal.soa.esb.webservice.ESBContractGenerator.generateWSDL(ESBContractGenerator.java:126)
 ... 91 more

I'm not sure where to put the xsd files. At the moment the files are located in my src directory. So they are also in my build directory. What am i doing wrong?

Regards,

Hans

[beve]

I'm not sure where to put the xsd files. At the moment the files are located in my src directory.

You can put them in you built .esb archive. The quickstart do this when you build them. Take a look at the publish_as_webservice quickstart to see how this is done.

Regards,

/Daniel

[h.wolffenbuttel]

I do see how it is done, except I'm using Eclipse to develop JBossESB. So deployment is not done by building with ant, it's done with a deployment on a JBoss AS 4.2 server (plugin Eclipse).

So if anyone knows what to do (configuration of Eclipse or location wise) please do tell.

Regards,

Hans

[h.wolffenbuttel]

Hi,

Still having problems with getting an xsd to work when it has an import. The problem seems to be in the WSDL generation. Lets look at (a part of) the fault here:

10:03:10,654 INFO [TomcatDeployer] deploy, ctxPath=/GESB.1.0, warUrl=.../tmp/deploy/tmp2731850310978678831GESB.1.0-exp.war/
10:03:11,058 ERROR [MainDeployer] Could not start deployment: file:/C:/Tools/ESB/Jboss 4.6/jboss-4.2.3.GA/server/messaging/tmp/esbwarfiles/GESB.1.0.esb/GESB.1.0.war
java.lang.IllegalArgumentException: Cannot resolve imported resource: file:/C:/Tools/ESB/Jboss 4.6/jboss-4.2.3.GA/server/messaging/tmp/deploy/tmp2731850310978678831GESB.1.0-exp.war/WEB-INF/wsdl/stuf.0204/stuf0204.xsd
 at org.jboss.ws.tools.wsdl.WSDLLocatorImpl.getImportInputSource(WSDLLocatorImpl.java:141)
 at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseSchema(JBossWSDLReaderImpl.java:779)
 at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseSchema(JBossWSDLReaderImpl.java:659)
 at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseTypes(JBossWSDLReaderImpl.java:620)
 at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.parseDefinitions(JBossWSDLReaderImpl.java:332)
 at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.readWSDL(JBossWSDLReaderImpl.java:2293)

The path it is looking for the xsd-import is "WEB-INF/wsdl/stuf.0204/stuf0204.xsd" but the generated path is different namely "WEB-INF\wsdl\HTTPService\stuf.0204\stuf0204.xsd". So the problem lies in the generated directory "HTTPService" which is not added to the xsd-searchpath.

Is this a bug?

Regards,

Hans

[h.wolffenbuttel]

Hi,

It seems all xsd files have to be placed in the root of the ESB, otherwise it does not work when you have imports in your xsd. This means I need to change the xsd each time a new version is released instead of just swapping xsd files.

When I implement my service as a webservice, my http-provider gets bypassed. And if I try to call my http-provider nothing happens. So the question is, how can I get the exposed service to use my http-provider and to use its properties. Like for example use the port I defined or the SSL settings.

regards,

Hans