Classloading via the lib and classes directory of the WAR file
certainly works in Tomcat. Have you tried the using the war
file that came with the distribution? THat has the samples in
the classes dir too and those load just fine. If you add more
stuff to it then that'll work too.
The reason that class loading is via the class loader that
loaded the servlets is exactly to enable this. That in fact
allows one to put the soap.jar itself on the server classpath
and put only application specific stuff in each war. That (IMO)
is the preferred deployment model.
Sanjiva.
----- Original Message -----
From: "Javier A. Soltero" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 07, 2001 9:57 PM
Subject: Re: Class Loading in SOAP/Tomcat
> Hi Christian,
>
> I actually poked around the SOAP source (2.2) to see exactly how Class
Loading
> was accomplished by the SOAP package. From the code, I saw that the
RPCRouter
> actually seems to ask the servlet container for its class loader. This
would
> suggest that Tomcats class loader would be the one to decide whether the
class
> can be found or not. Furthermore, it would also suggest that, as with
other
> webapps, class loading is done from either WEB-INF/classes or WEB-INF/lib
...
> unfortunately neither is true.
>
> I was hoping perhaps one of the SOAP developers could clarify this
behavior. It
> seems like it would be a natural thing to be able to deploye war files
which
> act as soap servers. So... second attempt... any developers out there who
can
> give some more clarification on this??!?!
>
> thanks,
>
> -javier
>
> Christian Bernard wrote:
>
> > 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]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
