[JBossWS] - Looking to pass complex types in web service...
by dakk
OK, so I am a newbie... I've got the example from chapter 12 running -- the Hello example -- that passes a string. I'd like to modify the example to pass in say 2 strings, and return a complex type that is made up of ints and strings. I am using JBoss 4.2.0, and JWSDP 2.
I think I've gotten a long way (I can at least invoke the service) but I am getting serialization errors (null ptr error) from com.sun.xml.rpc.encoding.DynamicInternalTypeMappingRegistry.getSerializer() - where the cause is emanating from com.sun.xml.rpc.encoding.literal.ValueTypeLiteralSerializer.doSetTargetClass().
What I am wondering is if I can really use the same approach that the Hello example used (i.e., ServiceFactory.createService, service.getPort, and then invoke my service method), or if I really need to use another API to pass complex types.
Any help would be appreciated!
Norm
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166716#4166716
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166716
17 years, 9 months
[JBossWS] - SchemaValidation doesn't work with some special characters
by Houla
Hi everyone!
We're trying to use @SchemaValidation for our WebService. It works great as long as there is no umlaut (a special german letter like an o with two dots on top) in the content. If there is one, we get the following exception:
| org.jboss.ws.WSException: org.xml.sax.SAXParseException: Invalid byte 1 of 1-byte UTF-8 sequence.
| at org.jboss.ws.WSException.rethrow(WSException.java:68)
| at org.jboss.ws.core.soap.SOAPBodyElementDoc.validatePayload(SOAPBodyElementDoc.java:130)
| at org.jboss.ws.core.soap.SOAPBodyElementDoc.transitionTo(SOAPBodyElementDoc.java:82)
| at org.jboss.ws.core.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:173)
| at org.jboss.ws.core.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:263)
| at org.jboss.ws.core.EndpointInvocation.getRequestParamValue(EndpointInvocation.java:115)
| at org.jboss.ws.core.EndpointInvocation.getRequestPayload(EndpointInvocation.java:135)
| at org.jboss.ws.core.server.DelegatingInvocation.getArgs(DelegatingInvocation.java:82)
| at org.jboss.wsf.container.jboss42.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:95)
| at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:221)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:466)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:284)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:201)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:134)
| at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
| 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:613)
| ...
|
We had a look on the source of the JBossWS-code and found the following line in org.jboss.ws.extensions.validation.SchemaValidationHelper:
| ByteArrayInputStream bais = new ByteArrayInputStream(inxml.getBytes());
|
It works perfectly (at least on our tests) if we change it to
| ByteArrayInputStream bais = new ByteArrayInputStream(inxml.getBytes("UTF-8"));
|
But: We're not sure if this is a general solution. While digging deeper through the code we found the following: In InputSource (which is used by the parser which validates the document), there should be some magical automation which should determine the right encoding. But that doesn't seem to work. It seems that this automatism allways determines UTF-8, even if it is ISO-8859-1 or MacRoman or ...
We're using JBossAS 4.2.2 whith JBossWS 3.0.1 or 3.0.2 GA under MacOS 10.4.
Does anyone have an idea whats going wrong here? Do I do something wrong or is it a bug in JBossWS?
Thanks!
Houla
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166713#4166713
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166713
17 years, 9 months