Sorry but I am still experiencing issues. I would appreciate a fast
answer to this if it's possible. My questions are grouped at the end if
you don't want to read the whole post...
I have to repeat what was mentioned in bug XFIRE-582 = "For a fairly
simple project, starting with a WSDL ... we find that a client is unable
to deserialise the response message. ... The generated WSDL that XFire
displays through the Web-app also displays a similar issue, creating an
additonal schema where only existed in the original WSDL." This is a
stop-show issue and with a simple HelloWorld web service in Top Down
design I run into the same error because of duplicate schema in
generated wsdl (and the one that should be is not in the correct format
according to the original wsdl!).
Because of that I tried to implement a workaround using the original
wsdl. Now what was suggested in the previous post is valid only for
people using Spring + Xfire to develop webservices ( using
serviceRegistry defined in xfire.xml ...). What about the rest of us ?
If one is using only Xfire and has only the service.xml available ?
Introducing this in the "services.xml":
<wsdlURL>
file:/usr/local/..../WEB-INF/wsdl/Service.wsdl
</wsdlURL>
will result in seeing the original wsdl displayed in the browser but
this is NOT setting the WSDLWriter to point to the right original wsdl.
At run time my client is running into the error mentioned in my previous
post on this thread:
"http://archive.xfire.codehaus.org/user/1178926851.2156.42.camel%
40dddpavel-lnx.dynadocs.com"
and this is ONLY possible if the server (JBoss in my case) is using the
generated schema to deserialise the response message. The "Invalid
operation:" fault means that the operation has not been properly
discovered by the binding component. That is the case in the generated
wsdl because of the wrong schema (but not in the original one who
contains correct bindings for the related schema). Not sure if this is
because JBoss cache or persistent state (but I checked and cleaned all
deployments working only with one at a time) or because of XFire
directly.
1) Can you tell us how we can setup wsdl writer after the service is
created - for everybody else which are not using Spring + Xfire (in
order to use the original wsdl and not the generated one) ?
2) Upgrading to XFire 1.2.6, thanks Tomek, but I already added comments
in that thread long time ago. If we do what is suggested we can not use
MyEclipse for what it is (integrated IDE) because the GUI to generate
the web services points to the old libraries (and we have to generated
the artifacts in command line and use MyEclipse just as an editor).
Beside I had problems trying to upgrade to 1.2.5 (described in the
mentioned thread...) so I decided to stick with MyEclipse5.5M2 which
uses XFire 1.2.4. If somebody did the upgrade and still is able to use
the GUI then please share the knowledge.
I would like to say that this is urgent,
Thanks in advance,
Dragos
On Fri, 2007-11-05 at 19:40 -0400, Dragos Pavel wrote:
Hi All,
>
> Following this thread and also this one:
> http://osdir.com/ml/java.xfire.user/2006-05/msg00067.html
> I tried to use my original wsdl instead of the generated one.
>
> It was suggested:
> "Every service object have WSDLWriter property, where you can set
> service.setWSDLWriter(new ResourceWSDL(wsdl)); So your WSDL from file
> system will be used instead of generated one. If you are using
> spring config or services.xml file then you can write simple bean
> which will use serviceRegistry ( defined in xfire.xml ), retrieve
> service object from it and set that WSDL writer."
>
> How exactly can I do this with services.xml (because I don't use
> spring)? If I don't have "xfire.xml" in my project, how exactly I can
> use the serviceRegistry - so that later to complete first task ?
>
> What I did is this:
> I introduced the code into the constructor of the server
implementation
> class (which is referenced in the service bean in the service.xml).
The
> code is executed because I see the debug statements for the url)
>
> Here is the constructor of the server implementation class:
> public ServiceImpl()
> {
>
> // get registry from the XFire instance
> XFire xfire = XFireFactory.newInstance().getXFire();
> ServiceRegistry serviceRegistry = xfire.getServiceRegistry();
> //ddd - workaround for the wsdl:
> org.codehaus.xfire.service.Service service =
> serviceRegistry.getService("Service");
> try
> {
> File originalWSDL = new File
> ("/usr/local/..../WEB-INF/wsdl/Service.wsdl");
> service.setWSDLWriter(new ResourceWSDL(originalWSDL.toURL
> ()));
> System.out.println
> ("----------------"+originalWSDL.getAbsolutePath
()+"-----------------");
> System.out.println("----------------"+originalWSDL.toURL
> ().toString()+"-----------------");
> }
> catch (MalformedURLException e)
> {
> e.printStackTrace();
> }
>
> }
>
> And in the "services.xml" in inserted this:
>
> <wsdlURL>
> file:/usr/local/..../WEB-INF/wsdl/Service.wsdl
> </wsdlURL>
>
> Now I can see on the browser my original wsdl which is correct
(doesn't
> contain a duplicate schema) but when I run the client I get this
error:
>
> -------------------------------------------------------------------
> 19:05:06,024 INFO [DefaultFaultHandler] Fault occurred!
> org.codehaus.xfire.fault.XFireFault: Invalid operation:
> {http://dddpavel-lnx.dynadocs.com:8080/goodenergylixar/Service}User
> at org.codehaus.xfire.service.binding.WrappedBinding.readMessage
> (WrappedBinding.java:41)
> at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke
> (SoapBodyHandler.java:42)
> at org.codehaus.xfire.handler.HandlerPipeline.invoke
> (HandlerPipeline.java:131)
> at org.codehaus.xfire.transport.DefaultEndpoint.onReceive
> (DefaultEndpoint.java:64)
> at org.codehaus.xfire.transport.AbstractChannel.receive
> (AbstractChannel.java:38)
> at org.codehaus.xfire.transport.http.XFireServletController.invoke
> (XFireServletController.java:301)
> at org.codehaus.xfire.transport.http.XFireServletController.doService
> (XFireServletController.java:130)
> at org.codehaus.xfire.transport.http.XFireServlet.doPost
> (XFireServlet.java:116)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter
> (ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke
> (SecurityAssociationValve.java:175)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke
> (JaccContextValve.java:74)
> at org.apache.catalina.core.StandardHostValve.invoke
> (StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke
> (ErrorReportValve.java:105)
> at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke
> (CachedConnectionValve.java:156)
> at org.apache.catalina.valves.FastCommonAccessLogValve.invoke
> (FastCommonAccessLogValve.java:495)
> at org.apache.catalina.core.StandardEngineValve.invoke
> (StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service
> (CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process
> (Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol
> $Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
> (PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run
> (MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
> -------------------------------------------------------------------
> which is happening probably because in the end the server still uses
the
> generated wsdl instead of the published (i.e. original one).
>
> So I don't know what's wrong in my workaround implementation for
> original wsdl use but I understood that what I did is not the right
way
> to go.
>
> Can you guide me on the right way for this to work ?
>
> Thanks in advance.
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
