Hi Phil,
>Why put the client classes in TomCat's common/lib directory ???
Sorry, this was bad English on my part. Obviously the client classes go
in the (soap webapp's) WEB-INF/classes; whether you put the soap jarfile
there or in the common/lib directory depends on whether you want it to
be available to multiple webapps or just the one.
As I said, TomCat ignores your CLASSPATH, and will construct its own
based on the contents of the webapp's lib and classes directories and
the the various common directories (note that classes have to be in
a classes directory and jarfiles in a lib directory, and both have to
be inside their package heirarchy).
If you are sure that you have the classes where TomCat can locate them,
then it is possible that your soap deployment is failing. My understanding
of deployment in this sense is that it is persistent, so you should be
able to start TomCat, deploy a service, shutdown and restart TomCAt and
still see your service as deployed. If this isn't happening then you
aren't deploying your service and that is why you get the error message.
Another possibility is that you haven't specified the method(s) in your
class that you want to expose, or have mis-spelled or mis-capitalised
them in the deployment descriptor (I do the latter all the time and
now copy and paste the method names from the java source to be sure of
getting it right. Alternatively you may have mis-spelled or mis-capitalised
them in your client and are trying to call something other than what you
have exposed. Or you may not have specified your service's urn correctly
(again, this has to match between the client call and the server's
deployment descriptor.
My situation is complicated because JBoss deploys my webapp afresh every
time TomCat is started and there is no fixed path to my webapp directory,
so any persistent soap deployment info there is lost when the server
is restarted. To counteract this, I put the following in my web.xml:-
<context-param>
<param-name>ConfigFile</param-name>
<param-value>/WEB-INF/soap.xml</param-value>
</context-param>
This only worked as a context-param, I couldn't make it an init-param in
the rpcrouter servlet.
Then in /WEB-INF/soap.xml I have:-
<soapServer>
<configManager value="org.apache.soap.server.XMLConfigManager" >
<option name="filename" value="/WEB-INF/DeployedServices.xml" >
</configManager>
</soapServer>
Then my /WEB-INF/DeployedServices.xml contains my <isd:service> deployment
descriptors inside a <root></root> tag.
All of these files live in my soap app's WEB-INF directory so get unpackaged
every time JBoss deploys it, and the XMLConfigManager reads them in at
startup time, thereby ensuring that they are deployed. All paths are
relative to the movable webapp directory and so can be found without needing
to know where it lives.
It's only necessary to resort to such extremes if you are using a container
manager like JBoss, and it could also be done by telling the default
config manager to store its persistent information somewhere permanent, but
the latter wasn't an option for me.
Hope this is some help. I found that it often helped to look at the stack
traces output by TOmCat when the SOAP service failed, as these often
gave clues as to what the problem really was (but only if you have a twisted
mind and view them from the program's standpoint).
Regards,
John.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
