[JBossWS] - Top-down development problem
by PeterJ
I am trying to follow the docs at http://jbws.dyndns.org/mediawiki/index.php/JAX-WS_User_Guide#Top-Down_.28... to create a Web service using the top-down method. What I did was first use the bottom-up method, and after deploying the Web service, I ran wsprovide to create the WSDL. In addition, I wrote a client that that accessed the Web service to ensure that it works. So far so good.
Then I used wsconsume to create the Java stubs, using the interface that was generated to write my Web service endpoint class, packaged the necessary classes, web.xml and wsdl in a war file and deployed it. Now when I access the endpoint with my client, I get an error because the container is attempting to instantiate the interface, not the implementation class.
My Web service looks exactly like the one in the documentation, with a few changes:
1) When I created the original bottom-up endpoint, I added the @SOAPBinding(style=SOAPBinding.Style.RPC) annotation to it. Thus when the wsconsume generated the stubs from the WSDL, I got only two classes: Echo.java and EchoService.java.
2) Since I wanted to use the original WSDL, I modified the generated Echo.java to reference the WSDL that I packaged in the war file (without this change, JBossWS will re-generate the WSDL when the web service is deployed, which sort of defeats the whole purpose of top-down development; I could never figure out if there was a default WSDL location; and this property was ignored when I placed it on the implementation class):
@WebService(name="Echo", targetNamespace = "http://echo/", wsdlLocation="WEB-INF/wsdl/EchoService.wsdl")
My war file has the following contents:
WEB-INF/classes/echo/Echo.class
WEB-INF/classes/echo/EchoImpl.class
WEB-INF/web.xml
WEB-INF/wsdl/EchoService.wsdl
When I run my client, I get the following error on the server:
09:07:10,941 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
java.lang.InstantiationException: echo.Echo
at java.lang.Class.newInstance0(Class.java:335)
at java.lang.Class.newInstance(Class.java:303)
at org.jboss.ws.core.server.ServiceEndpointInvokerJSE.createServiceEndpoint(ServiceEndpointInvokerJSE.java:69)
at org.jboss.ws.core.server.AbstractServiceEndpointInvoker.invoke(AbstractServiceEndpointInvoker.java:130)
at org.jboss.ws.core.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:204)
at org.jboss.ws.core.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:440)
at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(AbstractServiceEndpointServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(AbstractServiceEndpointServlet.java:75)
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:228)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:86)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:595)
By the way, I am running JBossWS 1.2 on JBoss AS 5.0 beta2 (pulled on March 5th)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030294#4030294
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030294
19 years
[JBossWS] - Example ProviderBeanMessage
by zauberlehrling
Hi,
I slightly modified the Provider example ProviderBeanMessage:
package org.jboss.test.ws.jaxws.samples.provider;
|
| // $Id: ProviderBeanMessage.java 2193 2007-01-30 16:33:53Z thomas.diesler(a)jboss.com $
|
| import javax.xml.soap.SOAPMessage;
| import javax.xml.ws.Provider;
| import javax.xml.ws.Service;
| import javax.xml.ws.ServiceMode;
| import javax.xml.ws.WebServiceProvider;
| import javax.ejb.Stateless;
|
| /**
| * Test a Provider<SOAPMessage>
| *
| * @author Thomas.Diesler(a)jboss.org
| * @since 29-Jun-2006
| */
| @Stateless
| @WebServiceProvider(
| serviceName = "ProviderService",
| portName = "ProviderPort",
| targetNamespace = "http://org.jboss.ws/provider",
| wsdlLocation = "Provider.wsdl")
| @ServiceMode(value = Service.Mode.MESSAGE)
| public class ProviderBeanMessage implements Provider<SOAPMessage>
| {
| public SOAPMessage invoke(SOAPMessage request)
| {
| return request;
| }
| }
So it's a stateless session bean. I put the class together with the file Provider.wsdl into a jar file and successfully deployed the archive.
The deployment was fine and I can see the wsdl under: http://localhost:8080/Provider/ProviderBeanMessage?wsdl
My problem: When I call the webservice with the eclipse webservice explorer I get the following error message:
anonymous wrote : The SOAP response failed schema validation. Please switch to the source view for the SOAP response in XML format.
|
My setup:
JBOSS_HOME: L:\..\build\output\jboss-5.0.0.Beta2
JAVA: C:\Programme\Java\jdk1.5.0_10\bin\java
..
[ServiceEndpointManager] jbossws-2.0.0.DEV (build=200703171222)
Best regards,
Frank
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030289#4030289
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030289
19 years
[JBossWS] - Re: webservicess
by PeterJ
Do it correctly and it will work. :-)
But seriously, you have not given us any information about the problem you are having so how could we help you solve it?
First, which version of JBoss Application Server are you using? 4.0 is ambiguous, is it 4.0.5, 4.0.4, 4.0.3SP1, 4.0.2, 4.0.1, 4.0.0?
Second, what version of JBoss Web Services (JBossWS) are you using? 1.2.0? 1.0.4?
Third, did you follow the installation instructions to install JBossWS?
Fourth, you mention a "sample", which of the sample applications are you running?
Fifth, what error are you getting? Please post the stack trace.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030247#4030247
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030247
19 years
[JBossWS] - Re: WSDL-location help?
by oskar.carlstedt
Hi!
Thanks for your help. I'm sorry to say, that is not what I actually need or do. I want to have control over my contract (the WSDL-file). That is why I'm using contract first development. I have external parts using my services (contracts). Therefore generated contacts is not a good solution for me. But that is another topic.
So, I have created the WSDL-file, and my own web service provider. I had to do this because I want to use xml beans as data binding framework.
| @Stateless
| @WebServiceProvider(
| serviceName = "MyService",
| portName = "MyServiceSoap11Port",
| targetNamespace = "http://my.domain.com/my-service",
| wsdlLocation = "WEB-INF/wsdl/my-service.wsdl")
| @ServiceMode(value = Service.Mode.PAYLOAD)
| public class MyServiceEndpointProvider implements Provider<Source> {
| ...
| }
|
So, what I want to do is to point out wsdlLocation="http://..." instead of wsdlLocation="WEB-INF/...".
Why do I want to do this? Just because I see the contract as a complete separate part of the solution. My service (might be services) implements this contract. I might have several services that implements the same contract, but doing different things in different situations.
So, my question still is: Is it a must to point out the wsdlLocation to a local path within the generated war.
Best
Oskar
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030131#4030131
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030131
19 years