Home directory/ location for schema for WSDLs

["Srinivasan, Latha" <la...@hp.com>]

Hi,
 
I downloaded the latest bits of Apollo and have been playing around with
separating the xsd file and the corresponding WSDL definitions. Even
though I provided an absolute location where the schema can be found in
my import statement in the WSDL, I get an error that indicates that the
"ant generate" task cannot locate the xsd file. 
 
I am assuming the home directory for the Apollo installation is:
$APOLLO_DIR/webapps/wsrf , but when I copied my xsd file to a
subdirectory off that, it still didn't work. 
 
Are there any guidelines around where developers should be storing their
WSDLs/XSDs etc.
 
Thanks
Latha
 
 
-

Re: Home directory/ location for schema for WSDLs

[Ian Springer <ip...@apache.org>]

Srinivasan, Latha wrote:

> Hi,
>  
> I downloaded the latest bits of Apollo and have been playing around 
> with separating the xsd file and the corresponding WSDL definitions. 
> Even though I provided an absolute location where the schema can be 
> found in my import statement in the WSDL, I get an error that 
> indicates that the "ant generate" task cannot locate the xsd file.
>  
> I am assuming the home directory for the Apollo installation is: 
> $APOLLO_DIR/webapps/wsrf , but when I copied my xsd file to a 
> subdirectory off that, it still didn't work.
>  
> Are there any guidelines around where developers should be storing 
> their WSDLs/XSDs etc.
>  
> Thanks
> Latha
>  

Hi Latha,

What we generally recommend is using relative URLs for all WSDL and XSD 
imports or includes. This eliminates the need to be connected to the Net 
or to know your final deployment location in order to specify an 
absolute URL. For example, in myservice.wsdl, import foo.xsd as follows:

<xsd:import namespace="http://xyz.com/schema/foo"
                   schemaLocation="../xsd/foo.xsd" />

NOTE: In order for relative import/include URLs to resolve properly at 
runtime, it is important that all your relative import/include URLs 
begin with "../". The reason for this is that when deployed to Axis (and 
many other SOAP platforms), the base URL for a service's WSDL looks like:

http://myserver.xyz.com/wsrf/services/myservice?wsdl

/wsrf/services/* maps to the AxisServlet, and other URLs of the form 
/wsrf/* map to the wsrf webapp's document root. Since we want to be able 
to store our imported/included XSDs and WSDLs in the document root and 
for remote clients to be able to resolve our imports and includes, it is 
necessary to begin the import/include URLs with "../", which takes us up 
out of /wsrf/services/ into /wsrf/.

For example, we would deply myservice.wsdl to the wsrf webapp as follows:

wsrf/
    WEB-INF/
       classes/
          wsdl/
             myservice.wsdl  (Axis loads this via a classloader lookup)
    xsd/
       foo.xsd

A client retrieves myservice.wsdl via a GET request for 
http://myserver.xyz.com/wsrf/services/myservice?wsdl. It needs to 
retrieve the imported schema "../xsd/foo.xsd". It resolve s this 
relative URL using 
"http://myserver.xyz.com/wsrf/services/myservice?wsdl" as the base URL, 
which yields "http://myserver.xyz.com/wsrf/xsd/foo.xsd", which is the 
correct URL for foo.xsd as deployed above.

Note, to generate, you'd make sure your files are orgranized as follows:

somedir/
    wsdl/foo.wsdl
    xsd/foo.xsd

so that Wsdl2Java is able to resolve the import of "../xsd/foo.xsd".

I know this is confusing, but it's the most versatile solution we've found.

Regards,
Ian


---------------------------------------------------------------------
To unsubscribe, e-mail: apollo-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: apollo-dev-help@ws.apache.org