Hi Javier,
I met the same problem with Tomcat 3.2.1 and Apache SOAP 2.1.
The normal way to deploy a web application, as stated in the Servlets API
specification is to use the war files and to place them under the "webapps"
directory of the server. When a user asks for a resource located in the war
file for the first time, the server engine first extracts the war file
content under the "webapps" directory and then passes the control to the
application. If the application needs a class from the newly deployed
application, the server engine first search the class into the local
application context (application classpath), and then if not found search
into the global context (server classpath). By this way, the new web
application may be deployed without stopping the server.
Tomcat has implemented this operation mode.
This is broken when the web application contains a Web Service and uses the
SOAP package. The class(es) which implement the Web Service must be added
into the server classpath. If this is not done, the BadTargetObjectURI error
"Unable to resolve target object" is raised. This is a bad thing because,
it's now mandatory to stop the web server to deploy such an application.
I think the problem is located in the manner that the SOAP package uses to
create the Web Service class instances. I don't know if there is a simple
solution to that problem.
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Javier A. Soltero
Sent: Wednesday, June 06, 2001 10:28 PM
To: [EMAIL PROTECTED]
Subject: Class Loading in SOAP/Tomcat
Hi All,
I have a question regarding how classes which are made available via the
soap interface are loaded by Apache Soap when soap runs inside the
Tomcat 3.2 container. Essentially, I would like to package my soap
server application as a war file which will be deployed into Tomcat. My
expectation would be that when the RPCRouter is going to instantiate a
class called via SOAP, it will be able to do so solely by looking at the
classes that were packaged in the war file. In trying to prove this,
I have found that SOAP (or perhaps Tomcat) requires any class which is
going to be loaded by it to be in the classpath which *started* tomcat.
This makes it difficult to be able to package SOAP server applications
which can just be dropped into Tomcat (or any other Servlet container)
without having to modify the classpath with which the container is
started.
Does anyone out there have any experience/knowledge about the expected
behaviour? Is this question outside the scope of SOAP and more directly
related to Tomcat's class loader?
any help or insight greatly appreciated.
-javier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
