Sri,
Its probably cleanest to create a webapps\WEB-INF\classes under your
app-server directory and expose this in Tomcat's server.xml configuration
file. (this might be what J2EE recommends also). In this folder, you could
put either a tree of classes or a composite jar file. Either way, this needs
to be an explicit entry in the Tomcat classpath.
I agree, duplicating it in two places sounds kludgey. And this is likely not
a SOAP issue or feature :)
--KH
-----Original Message-----
From: Sri Sankaran [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 27, 2001 10:03 AM
To: Soap User (E-mail)
Subject: Is it a feature or a bug?
Products used:
Apache SOAP 2.2
Tomcat 3.2.2
Windows NT
I'm not sure if the following is a Tomcat issue or a SOAP issue or just a
feature:
Tomcat loads the classes that are in the WEB-INF/classes and WEB-INF/lib
directories. Therefore, you can deploy your application to either locations
as a jar or a tree of class files. If you have a browser-based JSP/servlet
application there is no problem.
The problem arises when you try to reference one of the (above) application
classes that has been exposed as a web-service. One would assume that since
Tomcat has loaded it (the application class), it would be accessible to the
rpcrouter. Au contraire! Try as you might you get the BadTargetObjectURI
fault code.
The only ways around it that I have found are:
(a) to explode the deployed jar file to some other location and add that
location to Tomcat's classpath.
This is ugly because I have to duplicate my deployment -- one for web
users and one to please SOAP.
OR
(b) to deploy the application as a tree of classes under the WEB-INF/classes
directory and include that directory in Tomcat's classpath. This is equally
abhorrent -- because I'd rather deploy as a Jar file and secondly if Tomcat
loads it anyway, why does one have to include it in it's classpath?
Sri
