At 02:28 PM 6/19/2001 +0100, Dylan J Browne wrote:
>Further to my previous email, I had seen the previous mails about setting up
>classpath to include the soap-2_2 directory. I had neglected to do this
>previously which gave a NoClassDef error, then once I had included the
>soap-2_2 dir, I started getting the "class name cannot be resolved" errors:
>
> "Fault Code = SOAP-ENV:Client
> Fault String = Deployment error in SOAP service 'urn:AddressFetcher': class
>na
>me 'samples.addressbook.Address' could not be resolved:
>samples.addressbook.Addr
>ess"
Well, that error is coming from step 0 of DeploymentDescriptor.java; you can
find the source, and see that what's blowing up is presumably
ctx.loadClass("samples.addressbook.Address")
where ctx is a SOAPContext object whose loadClass method may use the default
Class.forName or on the other hand may use a ClassLoader set for it, and
I think you're seeing the classloader set by RPCRouterServlet; in either case
the error being labelled as "could not be resolved" by DeploymentDescriptor
is actually a ClassNotFoundException. I think what's happening is that your
class is now visible to the general loader but not to the servlet loader,
and if it were happening to me I would just try different ways of putting it
on the classpath, along the general lines I was saying before.
If there's an expert around who actually understands how this works and
can explain it, that would be nice. If there were a way to have these error
messages actually come out and say what the effective classpath was for the
classloader in question, that would be nicer...I suspect that classpath
questions on this list would be much reduced. If it's really an
AdaptiveServletLoader (I admit I'm too confused just now to tell) wouldn't
a getClassPath() be usable here? I definitely need some more coffee.
Tom Myers
