[JBoss Web Services Users] - Getting Classcast Exception Inconsistently on WSAddressing I
by vinothkumar
Hello all,
We are using JBOSS 4.2.3 with JBOSSWS Native 3.1.0 deployed.
We had implemented WSAddressing for Our Services as per the Steps given in the link : http://www.jboss.org/community/wiki/JBossWS-NativeUserGuide.
This WSAddressing implementation works fine without any issues if we give a single hit to the Services from the client for a given time. But if we have multiple simultaneous hits, we are getting the Classcast Exception inconsistently.
We had done the following changes in Client,
Service service = Service.create(wsdlURL, serviceName);
| port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class);
| BindingProvider bindingProvider = (BindingProvider)port1;
|
| List<Handler> customHandlerChain = new ArrayList<Handler>();
| customHandlerChain.add(new ClientHandler());
| customHandlerChain.add(new WSAddressingClientHandler());
| bindingProvider.getBinding().setHandlerChain(customHandlerChain);
The Exception that we are getting is,
javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.mobax.signage.ws.RemoveDeviceResponse cannot be cast to com.mobax.signage.ws.GetDeviceResponseResponse
| at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:404)
| at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:314)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152)
| at $Proxy103.removeDevice(Unknown Source)
| at com.mobax.mashup.webserviceconsumer.SignageServiceConsumer.removeDevices(SignageServiceConsumer.java:264)
| at com.mobax.mashup.responsebuilder.EnablerResponseParser.removeDevice(EnablerResponseParser.java:1489)
| at com.mobax.mashup.servlet.signage.RemoveDevice.processRequest(RemoveDevice.java:60)
| at com.mobax.mashup.servlet.signage.RemoveDevice.doGet(RemoveDevice.java:88)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:619)
As per Our understanding,
We are invoking the method port1.getDeviceResponse(). Before receiving the response for this request, we are invoking another method port1.removeDevice(). The Proxy seems to be waiting for the Response for the second request removeDevice(). When it receives the Response for the first request getDeviceResponse(), the proxy tries to parse this response assuming that this response belongs to the Second request, thus Resulting in Classcast Exception.
We would like to know whether anybody have Successfully implemented the WSAddressing in their Services without having any issues.
Interestingly, we had find out a WORKAROUND for this issue. The workaround is to generate the following code for every Request. i.e., before calling any Requests, if we generate the following proxy every time newly, then the Exception does not Occurs.
| port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class);
| BindingProvider bindingProvider = (BindingProvider)port1;
|
| List<Handler> customHandlerChain = new ArrayList<Handler>();
| customHandlerChain.add(new ClientHandler());
| customHandlerChain.add(new WSAddressingClientHandler());
| bindingProvider.getBinding().setHandlerChain(customHandlerChain);
Does anybody have any idea on this? We are not getting enough responses on our previous posts for this issue. So I had opened a new thread and provided more information on this issue.
Thanks for reading this long post.
Regards,
Vinoth Kumar
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251412#4251412
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251412
14 years, 8 months
[JBoss Web Services Users] - regarding message types in bottom-up service generation
by wuyanbo
Hi,
I am learning web service using jboss 5 and jbossws as runtime. I have created a POJO which is quoted below:
| @WebService
| public class HelloWorld {
|
| @WebMethod
| public String sayHello(@WebParam(name="name") String name) {
| return "Hello, " + name;
| }
| }
|
The problem is when i deployed the service into jboss, at runtime, the wsdl file generated contains complex type definitions for the parameter and return value. I expected xsd:string as message type, but it wasn't so. Can anybody be kind to tell me why this happens and how to avoid it? Thanks
Here is the wsdl file generated:
| - <definitions name="HelloWorldService" targetNamespace="http://ws.wuyb.com/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://ws.wuyb.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
| - <types>
| - <xs:schema targetNamespace="http://ws.wuyb.com/" version="1.0" xmlns:tns="http://ws.wuyb.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
| <xs:element name="sayHello" type="tns:sayHello" />
| <xs:element name="sayHelloResponse" type="tns:sayHelloResponse" />
| - <xs:complexType name="sayHello">
| - <xs:sequence>
| <xs:element minOccurs="0" name="name" type="xs:string" />
| </xs:sequence>
| </xs:complexType>
| - <xs:complexType name="sayHelloResponse">
| - <xs:sequence>
| <xs:element minOccurs="0" name="return" type="xs:string" />
| </xs:sequence>
| </xs:complexType>
| </xs:schema>
| </types>
| - <message name="HelloWorld_sayHelloResponse">
| <part element="tns:sayHelloResponse" name="sayHelloResponse" />
| </message>
| - <message name="HelloWorld_sayHello">
| <part element="tns:sayHello" name="sayHello" />
| </message>
| - <portType name="HelloWorld">
| - <operation name="sayHello" parameterOrder="sayHello">
| <input message="tns:HelloWorld_sayHello" />
| <output message="tns:HelloWorld_sayHelloResponse" />
| </operation>
| </portType>
| - <binding name="HelloWorldBinding" type="tns:HelloWorld">
| <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
| - <operation name="sayHello">
| <soap:operation soapAction="" />
| - <input>
| <soap:body use="literal" />
| </input>
| - <output>
| <soap:body use="literal" />
| </output>
| </operation>
| </binding>
| - <service name="HelloWorldService">
| - <port binding="tns:HelloWorldBinding" name="HelloWorldPort">
| <soap:address location="http://127.0.0.1:8080/HelloWorld/HelloWorld" />
| </port>
| </service>
| </definitions>
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251282#4251282
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251282
14 years, 8 months
[JBoss Web Services] - Re: ...Port does not contain operation meta data for: {http:
by ksinno
Hi,
JBoss processes the HandlerTypes in the following order for JAXWS:
POST
ENDPOINT
PRE
Since the POST handler needs to parse some information from the soap message to identify the ENDPOINT handler chain to call, you should do your decrypting at the level of the POST handler.
To do this, you can annotate your webservice class with @EndpointConfig and define your post handlers in the file standard-jaxws-endpoint-config.xml under META-INF
Alternatively, to stay independent from JBoss specific code (ie no dependency to JBoss), you do the below configuration at the level of the deployment descriptors, by modifying the file standard-jaxws-endpoint-config.xml under [JBOSS_HOME]\server\[type]\deployers\jbossws.deployer\META-INF (path differs for JBoss 4.3 ... but same file name) and adding your post-handler chain (example below).
<endpoint-config>
| <config-name>Murex Security Handlers</config-name>
| <post-handler-chains>
| <javaee:handler-chain>
| <javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
| <javaee:handler>
| <javaee:handler-name>My Security Handler</javaee:handler-name>
| <javaee:handler-class>package.security.MySecurityClass</javaee:handler-class>
| </javaee:handler>
| </javaee:handler-chain>
| </post-handler-chains>
| </endpoint-config>
The Config-name you create should be referenced in your web.xml file inside your war file such as the following:
<context-param>
| <param-name>jbossws-config-name</param-name>
| <param-value>My Security Handler</param-value>
| </context-param>
Cheers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250884#4250884
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250884
14 years, 8 months