Re: [xfire-user] Wrong target namespace in generated WSDL

2007-05-11 Thread Dragos Pavel
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

Re: [xfire-user] Wrong target namespace in generated WSDL

2007-04-30 Thread Matthew Graham

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



Re: [xfire-user] Wrong target namespace in generated WSDL

2007-04-30 Thread Matthew Graham

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



Re: [xfire-user] Wrong target namespace in generated WSDL

2007-04-30 Thread Tomek Sztelak

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





--
-
When one of our products stops working, we'll blame another vendor
within 24 hours.

-
To unsubscribe from this list please visit:

   http://xircles.codehaus.org/manage_email



Re: [xfire-user] Wrong target namespace in generated WSDL

2007-04-26 Thread Matthew Graham

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