Hi Todd,
I know nothing about php or coldfusion clients, but based on my
experience of axis services and axis/.Net clients, I think the approach
you have taken of using a custom wsdl, and seperating out the common
types to your Global.xsd sounds like a good one.
However, I'm not sure why your service needs to access the wsdl or you
global.xsd? Once the service and all the data types defined in the
wsdl/global.xsd are generated, and deployed, and the clients have been
generated based on the wsdl/global.xsd (which I think is the situation?)
, there should be no need to access these. As long as the correct
address of the service is specified in the wsdl, and this address is
used by clients, their relative locations shouldn't matter at all in
terms of the generated clients invoking the service. If you haven't
already, check that the service address *you* specified in the wsdl is
the address used being by the clients. If the wsdl is accessed from axis
via a http://......./service?wsdl url when generating clients
automatically using something like WSDL2Java or the equivalents in other
languages, Axis sometimes changes the address in the wsdl it returns,
and if the clients use this incorrect address they will not be able to
invoke the service. This is why I have moved my wsdl files out of axis
completely and onto a public web server, and just put empty <wsdlFile>
tags in my wsdd to ensure that axis will not return a wsdl file at all.
Hope this helps,
Richard.
Todd Orr wrote:
Hey Richard,
Thanks for the reply! Let me give you a little background, maybe my
goals will become more clear than my previous explanations. I
developed a Web service using java2wsdl. That worked fine, but I
didn't like the lack of control over the nillable, min/max, etc
attributes. So, I altered the produced WSDL with my changes and
specified this to be used in the wsdd file. This worked fine. Then I
decided to extract some of the global data types (shared among several
services) into an xsd of its own that I then imported into the WSDL.
Even though the XML was valid, the Web service didn't work. I believed
that this failed because my WSDL specified a Global.xsd file relative
to the WSDL file instead of the full path. The service resolved at a
different address than the WSDLs' locations. When the service was
resolved, it could not see the Global.xsd because it was no longer
properly located relative to the WSDL. The next thought was to specify
the full URL of the xsd, but this won't work because of deployment
uncertainties. So, I thought that if I controlled the location of all
the XML files, I could alleviate this problem. So, I moved everything
to a publicly accessible directory and pointed the service to the WSDL
located publicly via the wsdd config. This doesn't work,
unfortunately. Event though the WSDL resolves, the service does not
listen at this location. So, my php and Coldfusion test clients could
create their stubs, but couldn't send requests. So, here I am
wondering how others have resolved this. Maybe the situation I've lead
myself into is incorrect. Perhaps there is a better way to define
global types thus negating the rest of the steps I took. My noobiness
is a hindrance, so I hope that I am not the only one that has tried to
do the task described above. Thanks for the input!
Thanks,
T
On 11/30/05, *Richard Gregory* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Todd,
I'm not sure whether I'm missing something here in exactly what
you want
to do - you don't mention why you want to have the wsdl files and
services outside WEB-INF. Anyway, I have a set up similar to what you
describe. The wsdl files are accessible from a regular web page whiich
is completely independent of axis
(http://mips.gsf.de/projects/biors/biors_ws.html
<http://mips.gsf.de/projects/biors/biors_ws.html>) because the
services
themselves are deployed on a cluster and the AxisServlet will not
return
my custom wsdl's, and in particular the service address,as I have
written them if I use the ?wsdl or click on the wsdl link in
AxisServlet
(there's another thread about that, and I've already raised a jira to
try to get this rectified). If I point WSDL2Java at these files,
it will
work fine, as I guess you have found, and I can use these stubs to
then
access my services within the axis webapp, which works fine for me.
I think what you are trying to do (if I underatand it correctly) is
probably impossible - to have the wsdl files and the service at
the same
location outside axis/WEB-INF, as I think the services themselves will
always have to be within axis/WEB-INF. I tried to have a look at
modifying the AxisServlet code to solve the problem I had, but I
needed
an external jar file to build the axis source and nobody on the list
could tell me where to find it, so I gave up and just went with the
solution above.
Cheers,
Richard.
Todd Orr wrote:
> guess not
>
> On 11/26/05, *Todd Orr* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> I've read up on how to tell Axis to use a specific wsdl
instead of
> auto-generating them. I still have not found any information on
> altering the public wsdl location. So, I moved my wsdls into a
> publicly accessible (outside of WEB-INF) directory. Now I can
> easily generate client stubs. However, I cannot submit a soap
> request to these locations.
>
> Is there a way to configure the public wsdl location, and the
> service's access point? Preferably, they'd be one in the
same. The
> big part of the problem is that I find the default inadequate.
>
> Thanks,
> T
>
>
