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.
On Mon, 2007-30-04 at 21:34 +0200, Tomek Sztelak wrote:
> thx
>
> On 4/30/07, Matthew Graham <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > OK - I've added it to the end of "Client and Server Stub generation from
> > WSDL" page.
> >
> > Cheers,
> >
> > Matthew
> >
> > Tomek Sztelak wrote:
> > > You can add this info to XFire docs. On every page there is small
> > > [edit] link on the right side menu, so it would be great if you can
> > > add this somewhere :D
> > >
> > > On 4/30/07, Matthew Graham <[EMAIL PROTECTED]> wrote:
> > >> Hi,
> > >>
> > >> After digging around in the JavaDocs a bit, I discovered that the way to
> > >> do this is:
> > >>
> > >> service.setWSDLWriter(new ResourceWSDL("myService.wsdl"));
> > >>
> > >> It would be nice if this was documented somewhere :-)
> > >>
> > >> Cheers,
> > >>
> > >> Matthew
> > >>
> > >> Matthew Graham wrote:
> > >> > Hi,
> > >> >
> > >> > Further to this, is there any way to force the service to actually
> > >> > return the WSDL file that was used to generate the stub code instead
> > >> > of XFire generating it?
> > >> >
> > >> > Cheers,
> > >> >
> > >> > Matthew
> > >> >
> > >> > Matthew Graham wrote:
> > >> >> Hi,
> > >> >>
> > >> >> I'm using XFire 1.2.2 with XmlBeans binding from a WSDL defined with:
> > >> >>
> > >> >> <wsdl:definitions
> > >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> > >> >> xmlns:http="http://schemas.xmlsoap.org/wsdl/http/";
> > >> >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> > >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > >> >> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
> > >> >>
> > >> >>
> > >> xmlns:vos.contract.1.0="http://www.net.ivoa/xml/VOSpaceContract-v1.0rc6";
> > >> >>
> > >> >> xmlns:vos.types.1.0="http://www.net.ivoa/xml/VOSpaceTypes-v1.0rc6";
> > >> >> xmlns="http://www.net.ivoa/xml/VOSpaceContract-v1.0rc6";
> > >> >> targetNamespace="http://www.net.ivoa/xml/VOSpaceContract-v1.0rc6";>
> > >> >>
> > >> >> The stub code generated from this is in the package
> > >> >> edu.caltech.nvo.vospace.
> > >> >>
> > >> >> However, when I expose my service and get its WSDL with ?wsdl, this
> > >> >> has the package name as the main namespace:
> > >> >>
> > >> >> <wsdl:definitions targetNamespace="http://vospace.nvo.caltech.edu";
> > >> >> xmlns:tns="http://vospace.nvo.caltech.edu";
> > >> >> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
> > >> >> xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
> > >> >> xmlns:ns1="http://www.net.ivoa/xml/VOSpaceContract-v1.0rc6";
> > >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > >> >> xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
> > >> >> xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
> > >> >> xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
> > >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";>
> > >> >>
> > >> >> Unfortunately this still seems to be a problem with 1.2.5.
> > >> >>
> > >> >> Any ideas?
> > >> >>
> > >> >> Cheers,
> > >> >>
> > >> >> Matthew
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> To unsubscribe from this list please visit:
> > >> >>
> > >> >> http://xircles.codehaus.org/manage_email
> > >> >>
> > >> >
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe from this list please visit:
> > >> >
> > >> > http://xircles.codehaus.org/manage_email
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe from this list please visit:
> > >>
> > >> http://xircles.codehaus.org/manage_email
> > >>
> > >>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
