You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by "Javier A. Soltero" <ja...@covalent.net> on 2001/06/06 22:27:34 UTC
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: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Peer - Home Office <pb...@tampabay.rr.com>.
I've been reading this thread with great interest. I'm experiencing the
same observations that Christian has made. IMO the reason the SOAP examples
from Apache's soap-2.2 implementation work is because they're packaged with
the soap war file AND that the soap.jar file is in the classpath of the
tomcat server. When I create my own war file, loading into it the contents
of soap.jar (in the WEB-INF/classes directory) along with my classes and
soap services, the applications are installed predictably in tomcat but will
*not* work unless I also include classpath information for the application
in the tomcat server's classpath env. variable at startup. I'm new to this,
but I ran a bunch of experiments over the last few days, pulled out lots of
my hair, and think I've proved this... but I've been wrong too many times in
the past to be confident ;)
Peer
-----Original Message-----
From: Christian Bernard [mailto:cbernard@nagora.com]
Sent: Friday, June 08, 2001 7:03 AM
To: soap-user@xml.apache.org
Subject: RE: Class Loading in SOAP/Tomcat
I confirm that Tomcat is able to find the classes and libs of a web
application that is located under the "webapps" directory (application
context). The class loading is done from either
webapps/myapp/WEB-INF/classes or webapps/myapp/WEB-INF/lib. If the classes
or libs are not found in these directories, the container try to retrieve
the classes and libs from its own classpath.
The Apache SOAP examples are found by the container because they are melt
with the SOAP implementation classes into the same soap.jar. This is why the
SOAP examples are OK. But this is not correct regards to the Servlet API
specification. I think that :
1. the SOAP implementation classes should be in the container classpath
(minimal soap.jar),
2. the admin tool classes should be a web application war file located under
the webapps directory,
3. the SOAP examples should be a web application war file located under the
webapps directory.
If one writes a new Web Service, it's not the right way to add the related
stuff (classes and libs) into the soap.jar. Recently, I had to write a Web
Service and the service didn't work until I add
webapps\mywebserviceapp\WEB-INF\classes into the Tomcat classpath. This is
the confirmation of what Javier has noticed by reading the source code.
I think that the problem is : why the actual SOAP implementation can't try
to use the web service application classloader before the container
classloader ?
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, June 08, 2001 11:11 AM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Peer - Home Office <pb...@tampabay.rr.com>.
I've been reading this thread with great interest. I'm experiencing the
same observations that Christian has made. IMO the reason the SOAP examples
from Apache's soap-2.2 implementation work is because they're packaged with
the soap war file AND that the soap.jar file is in the classpath of the
tomcat server. When I create my own war file, loading into it the contents
of soap.jar (in the WEB-INF/classes directory) along with my classes and
soap services, the applications are installed predictably in tomcat but will
*not* work unless I also include classpath information for the application
in the tomcat server's classpath env. variable at startup. I'm new to this,
but I ran a bunch of experiments over the last few days, pulled out lots of
my hair, and think I've proved this... but I've been wrong too many times in
the past to be confident ;)
Peer
-----Original Message-----
From: Christian Bernard [mailto:cbernard@nagora.com]
Sent: Friday, June 08, 2001 7:03 AM
To: soap-user@xml.apache.org
Subject: RE: Class Loading in SOAP/Tomcat
I confirm that Tomcat is able to find the classes and libs of a web
application that is located under the "webapps" directory (application
context). The class loading is done from either
webapps/myapp/WEB-INF/classes or webapps/myapp/WEB-INF/lib. If the classes
or libs are not found in these directories, the container try to retrieve
the classes and libs from its own classpath.
The Apache SOAP examples are found by the container because they are melt
with the SOAP implementation classes into the same soap.jar. This is why the
SOAP examples are OK. But this is not correct regards to the Servlet API
specification. I think that :
1. the SOAP implementation classes should be in the container classpath
(minimal soap.jar),
2. the admin tool classes should be a web application war file located under
the webapps directory,
3. the SOAP examples should be a web application war file located under the
webapps directory.
If one writes a new Web Service, it's not the right way to add the related
stuff (classes and libs) into the soap.jar. Recently, I had to write a Web
Service and the service didn't work until I add
webapps\mywebserviceapp\WEB-INF\classes into the Tomcat classpath. This is
the confirmation of what Javier has noticed by reading the source code.
I think that the problem is : why the actual SOAP implementation can't try
to use the web service application classloader before the container
classloader ?
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, June 08, 2001 11:11 AM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
I confirm that Tomcat is able to find the classes and libs of a web
application that is located under the "webapps" directory (application
context). The class loading is done from either
webapps/myapp/WEB-INF/classes or webapps/myapp/WEB-INF/lib. If the classes
or libs are not found in these directories, the container try to retrieve
the classes and libs from its own classpath.
The Apache SOAP examples are found by the container because they are melt
with the SOAP implementation classes into the same soap.jar. This is why the
SOAP examples are OK. But this is not correct regards to the Servlet API
specification. I think that :
1. the SOAP implementation classes should be in the container classpath
(minimal soap.jar),
2. the admin tool classes should be a web application war file located under
the webapps directory,
3. the SOAP examples should be a web application war file located under the
webapps directory.
If one writes a new Web Service, it's not the right way to add the related
stuff (classes and libs) into the soap.jar. Recently, I had to write a Web
Service and the service didn't work until I add
webapps\mywebserviceapp\WEB-INF\classes into the Tomcat classpath. This is
the confirmation of what Javier has noticed by reading the source code.
I think that the problem is : why the actual SOAP implementation can't try
to use the web service application classloader before the container
classloader ?
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, June 08, 2001 11:11 AM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
I confirm that Tomcat is able to find the classes and libs of a web
application that is located under the "webapps" directory (application
context). The class loading is done from either
webapps/myapp/WEB-INF/classes or webapps/myapp/WEB-INF/lib. If the classes
or libs are not found in these directories, the container try to retrieve
the classes and libs from its own classpath.
The Apache SOAP examples are found by the container because they are melt
with the SOAP implementation classes into the same soap.jar. This is why the
SOAP examples are OK. But this is not correct regards to the Servlet API
specification. I think that :
1. the SOAP implementation classes should be in the container classpath
(minimal soap.jar),
2. the admin tool classes should be a web application war file located under
the webapps directory,
3. the SOAP examples should be a web application war file located under the
webapps directory.
If one writes a new Web Service, it's not the right way to add the related
stuff (classes and libs) into the soap.jar. Recently, I had to write a Web
Service and the service didn't work until I add
webapps\mywebserviceapp\WEB-INF\classes into the Tomcat classpath. This is
the confirmation of what Javier has noticed by reading the source code.
I think that the problem is : why the actual SOAP implementation can't try
to use the web service application classloader before the container
classloader ?
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, June 08, 2001 11:11 AM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
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" <ja...@covalent.net>
To: <so...@xml.apache.org>
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: javier@mofongo.sfo.covalent.net
> > [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> > Sent: Wednesday, June 06, 2001 10:28 PM
> > To: soap-user@xml.apache.org
> > 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: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> > For additional commands, email: soap-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat
Posted by "Javier A. Soltero" <ja...@covalent.net>.
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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat
Posted by "Javier A. Soltero" <ja...@covalent.net>.
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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat - seems to be a bug
Posted by Christian Bernard <cb...@nagora.com>.
Yes, I have the same feeling like you about that situation.
The problem you had seems to have the same origin as the problem I met with
a web app, and other people too. I think that you have clearly exposed the
reason of that strange behavior.
I hope that this problem will be addressed for the newer versions, by
someone which has a good knowledge of this part of the Apache
implementation. For now, we have a better workaround than modifying the
engine's classpath.
Christian Bernard
-----Original Message-----
From: Andreas Ullmann [mailto:Andreas.Ullmann@mathema.de]
Sent: Friday, August 10, 2001 1:43 PM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat - seems to be a bug
Seems that this is a bug in apaches SOAP.
Because:
I tried to acces an EJB which is running in Weblogic 6 via a JavaBean
accessed
from the RPCRouter.
The JavaBean wasn't able to get a reference an the EJB, although the JNDI
lookup
was successfully.
After a looooooooong period of trying around I copied the EJB-Jar into
\webapps\myapp\WEB-INF\lib where the soap.jar was allready located.
After that it worked!
The reason for that is that the apaches soap puzzles things with the
classloader. Apache does not correctly handle the inheritance hierarchie of
the
classloader as needed for application servers. So it was only possible to
access
the EJB, because the EJB-jar and the SOAP-jar were both loaded from the same
classloader.
Andreas Ullmann
Christian Bernard wrote:
> Hi All,
>
> I've recently noticed some very interesting things about that problem.
Here
> are the facts :
>
> 0. Suppose Your Web Service application is deployed at
> %TOMCAT_HOME%\webapps\myapp.
>
> 1. It's not necessary to add the statement set
> CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
> if you add the soap.jar, activation.jar and mail.jar to your
> %TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
> the message "BadTargetObjectURI - Unable to resolve target object" for
which
> I reported to the SOAP list.
> In this case, you should have a classpath which looks like this one :
>
> Using CLASSPATH:
>
C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
>
b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
> 3.0\lib\tools.jar
>
> 2. If you dont put these jars in your lib directory, it's mandatory to add
> the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to
the
> tomcat.bat file. Otherwise, you will get the well-known message
> "BadTargetObjectURI - Unable to resolve target object". This was my first
> solution.
>
> The first point is very interesting for the deployment phase, because it's
> not necessary to modify the engine's classpath to deploy a new web
service.
> It makes it possible to have several web services in the same engine which
> don't use the same SOAP implementation version, and to deploy them by
> packaging war files. The only change to make to the original engine's
> classpath is to add the xerces.jar in the front of the classpath as stated
> in the Apache SOAP documentation.
>
> I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
> 2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
> Apache SOAP 2.1 implementation.
>
> Christian BERNARD
> NAGORA Technologies
>
> -----Original Message-----
> From: Christian Bernard [mailto:cbernard@nagora.com]
> Sent: Thursday, June 07, 2001 10:58 AM
> To: soap-user@xml.apache.org
> Subject: RE: Class Loading in SOAP/Tomcat
>
> 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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat - seems to be a bug
Posted by Christian Bernard <cb...@nagora.com>.
Yes, I have the same feeling like you about that situation.
The problem you had seems to have the same origin as the problem I met with
a web app, and other people too. I think that you have clearly exposed the
reason of that strange behavior.
I hope that this problem will be addressed for the newer versions, by
someone which has a good knowledge of this part of the Apache
implementation. For now, we have a better workaround than modifying the
engine's classpath.
Christian Bernard
-----Original Message-----
From: Andreas Ullmann [mailto:Andreas.Ullmann@mathema.de]
Sent: Friday, August 10, 2001 1:43 PM
To: soap-user@xml.apache.org
Subject: Re: Class Loading in SOAP/Tomcat - seems to be a bug
Seems that this is a bug in apaches SOAP.
Because:
I tried to acces an EJB which is running in Weblogic 6 via a JavaBean
accessed
from the RPCRouter.
The JavaBean wasn't able to get a reference an the EJB, although the JNDI
lookup
was successfully.
After a looooooooong period of trying around I copied the EJB-Jar into
\webapps\myapp\WEB-INF\lib where the soap.jar was allready located.
After that it worked!
The reason for that is that the apaches soap puzzles things with the
classloader. Apache does not correctly handle the inheritance hierarchie of
the
classloader as needed for application servers. So it was only possible to
access
the EJB, because the EJB-jar and the SOAP-jar were both loaded from the same
classloader.
Andreas Ullmann
Christian Bernard wrote:
> Hi All,
>
> I've recently noticed some very interesting things about that problem.
Here
> are the facts :
>
> 0. Suppose Your Web Service application is deployed at
> %TOMCAT_HOME%\webapps\myapp.
>
> 1. It's not necessary to add the statement set
> CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
> if you add the soap.jar, activation.jar and mail.jar to your
> %TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
> the message "BadTargetObjectURI - Unable to resolve target object" for
which
> I reported to the SOAP list.
> In this case, you should have a classpath which looks like this one :
>
> Using CLASSPATH:
>
C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
>
b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
> 3.0\lib\tools.jar
>
> 2. If you dont put these jars in your lib directory, it's mandatory to add
> the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to
the
> tomcat.bat file. Otherwise, you will get the well-known message
> "BadTargetObjectURI - Unable to resolve target object". This was my first
> solution.
>
> The first point is very interesting for the deployment phase, because it's
> not necessary to modify the engine's classpath to deploy a new web
service.
> It makes it possible to have several web services in the same engine which
> don't use the same SOAP implementation version, and to deploy them by
> packaging war files. The only change to make to the original engine's
> classpath is to add the xerces.jar in the front of the classpath as stated
> in the Apache SOAP documentation.
>
> I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
> 2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
> Apache SOAP 2.1 implementation.
>
> Christian BERNARD
> NAGORA Technologies
>
> -----Original Message-----
> From: Christian Bernard [mailto:cbernard@nagora.com]
> Sent: Thursday, June 07, 2001 10:58 AM
> To: soap-user@xml.apache.org
> Subject: RE: Class Loading in SOAP/Tomcat
>
> 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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat - seems to be a bug
Posted by Andreas Ullmann <An...@mathema.de>.
Seems that this is a bug in apaches SOAP.
Because:
I tried to acces an EJB which is running in Weblogic 6 via a JavaBean accessed
from the RPCRouter.
The JavaBean wasn't able to get a reference an the EJB, although the JNDI lookup
was successfully.
After a looooooooong period of trying around I copied the EJB-Jar into
\webapps\myapp\WEB-INF\lib where the soap.jar was allready located.
After that it worked!
The reason for that is that the apaches soap puzzles things with the
classloader. Apache does not correctly handle the inheritance hierarchie of the
classloader as needed for application servers. So it was only possible to access
the EJB, because the EJB-jar and the SOAP-jar were both loaded from the same
classloader.
Andreas Ullmann
Christian Bernard wrote:
> Hi All,
>
> I've recently noticed some very interesting things about that problem. Here
> are the facts :
>
> 0. Suppose Your Web Service application is deployed at
> %TOMCAT_HOME%\webapps\myapp.
>
> 1. It's not necessary to add the statement set
> CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
> if you add the soap.jar, activation.jar and mail.jar to your
> %TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
> the message "BadTargetObjectURI - Unable to resolve target object" for which
> I reported to the SOAP list.
> In this case, you should have a classpath which looks like this one :
>
> Using CLASSPATH:
> C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
> b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
> 3.0\lib\tools.jar
>
> 2. If you dont put these jars in your lib directory, it's mandatory to add
> the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the
> tomcat.bat file. Otherwise, you will get the well-known message
> "BadTargetObjectURI - Unable to resolve target object". This was my first
> solution.
>
> The first point is very interesting for the deployment phase, because it's
> not necessary to modify the engine's classpath to deploy a new web service.
> It makes it possible to have several web services in the same engine which
> don't use the same SOAP implementation version, and to deploy them by
> packaging war files. The only change to make to the original engine's
> classpath is to add the xerces.jar in the front of the classpath as stated
> in the Apache SOAP documentation.
>
> I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
> 2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
> Apache SOAP 2.1 implementation.
>
> Christian BERNARD
> NAGORA Technologies
>
> -----Original Message-----
> From: Christian Bernard [mailto:cbernard@nagora.com]
> Sent: Thursday, June 07, 2001 10:58 AM
> To: soap-user@xml.apache.org
> Subject: RE: Class Loading in SOAP/Tomcat
>
> 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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
Re: Class Loading in SOAP/Tomcat - seems to be a bug
Posted by Andreas Ullmann <An...@mathema.de>.
Seems that this is a bug in apaches SOAP.
Because:
I tried to acces an EJB which is running in Weblogic 6 via a JavaBean accessed
from the RPCRouter.
The JavaBean wasn't able to get a reference an the EJB, although the JNDI lookup
was successfully.
After a looooooooong period of trying around I copied the EJB-Jar into
\webapps\myapp\WEB-INF\lib where the soap.jar was allready located.
After that it worked!
The reason for that is that the apaches soap puzzles things with the
classloader. Apache does not correctly handle the inheritance hierarchie of the
classloader as needed for application servers. So it was only possible to access
the EJB, because the EJB-jar and the SOAP-jar were both loaded from the same
classloader.
Andreas Ullmann
Christian Bernard wrote:
> Hi All,
>
> I've recently noticed some very interesting things about that problem. Here
> are the facts :
>
> 0. Suppose Your Web Service application is deployed at
> %TOMCAT_HOME%\webapps\myapp.
>
> 1. It's not necessary to add the statement set
> CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
> if you add the soap.jar, activation.jar and mail.jar to your
> %TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
> the message "BadTargetObjectURI - Unable to resolve target object" for which
> I reported to the SOAP list.
> In this case, you should have a classpath which looks like this one :
>
> Using CLASSPATH:
> C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
> b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
> 3.0\lib\tools.jar
>
> 2. If you dont put these jars in your lib directory, it's mandatory to add
> the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the
> tomcat.bat file. Otherwise, you will get the well-known message
> "BadTargetObjectURI - Unable to resolve target object". This was my first
> solution.
>
> The first point is very interesting for the deployment phase, because it's
> not necessary to modify the engine's classpath to deploy a new web service.
> It makes it possible to have several web services in the same engine which
> don't use the same SOAP implementation version, and to deploy them by
> packaging war files. The only change to make to the original engine's
> classpath is to add the xerces.jar in the front of the classpath as stated
> in the Apache SOAP documentation.
>
> I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
> 2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
> Apache SOAP 2.1 implementation.
>
> Christian BERNARD
> NAGORA Technologies
>
> -----Original Message-----
> From: Christian Bernard [mailto:cbernard@nagora.com]
> Sent: Thursday, June 07, 2001 10:58 AM
> To: soap-user@xml.apache.org
> Subject: RE: Class Loading in SOAP/Tomcat
>
> 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: javier@mofongo.sfo.covalent.net
> [mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
> Sent: Wednesday, June 06, 2001 10:28 PM
> To: soap-user@xml.apache.org
> 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: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
Hi All,
I've recently noticed some very interesting things about that problem. Here
are the facts :
0. Suppose Your Web Service application is deployed at
%TOMCAT_HOME%\webapps\myapp.
1. It's not necessary to add the statement set
CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
if you add the soap.jar, activation.jar and mail.jar to your
%TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
the message "BadTargetObjectURI - Unable to resolve target object" for which
I reported to the SOAP list.
In this case, you should have a classpath which looks like this one :
Using CLASSPATH:
C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
3.0\lib\tools.jar
2. If you dont put these jars in your lib directory, it's mandatory to add
the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the
tomcat.bat file. Otherwise, you will get the well-known message
"BadTargetObjectURI - Unable to resolve target object". This was my first
solution.
The first point is very interesting for the deployment phase, because it's
not necessary to modify the engine's classpath to deploy a new web service.
It makes it possible to have several web services in the same engine which
don't use the same SOAP implementation version, and to deploy them by
packaging war files. The only change to make to the original engine's
classpath is to add the xerces.jar in the front of the classpath as stated
in the Apache SOAP documentation.
I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
Apache SOAP 2.1 implementation.
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Christian Bernard [mailto:cbernard@nagora.com]
Sent: Thursday, June 07, 2001 10:58 AM
To: soap-user@xml.apache.org
Subject: RE: Class Loading in SOAP/Tomcat
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: javier@mofongo.sfo.covalent.net
[mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
Sent: Wednesday, June 06, 2001 10:28 PM
To: soap-user@xml.apache.org
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: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
Hi All,
I've recently noticed some very interesting things about that problem. Here
are the facts :
0. Suppose Your Web Service application is deployed at
%TOMCAT_HOME%\webapps\myapp.
1. It's not necessary to add the statement set
CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the tomcat.bat file
if you add the soap.jar, activation.jar and mail.jar to your
%TOMCAT_HOME%\webapps\myapp\WEB-INF\lib. If you do that, you will not get
the message "BadTargetObjectURI - Unable to resolve target object" for which
I reported to the SOAP list.
In this case, you should have a classpath which looks like this one :
Using CLASSPATH:
C:\Xerces_1.4.0\xerces.jar;..\classes;..\lib\ant.jar;..\lib\jasper.jar;..\li
b\jaxp.jar;..lib\parser.jar;..\lib\servlet.jar;..\lib\webserver.jar;C:\Jdk1.
3.0\lib\tools.jar
2. If you dont put these jars in your lib directory, it's mandatory to add
the statement set CP=%CP%;%TOMCAT_HOME%\webapps\myapp\WEB-INF\classes to the
tomcat.bat file. Otherwise, you will get the well-known message
"BadTargetObjectURI - Unable to resolve target object". This was my first
solution.
The first point is very interesting for the deployment phase, because it's
not necessary to modify the engine's classpath to deploy a new web service.
It makes it possible to have several web services in the same engine which
don't use the same SOAP implementation version, and to deploy them by
packaging war files. The only change to make to the original engine's
classpath is to add the xerces.jar in the front of the classpath as stated
in the Apache SOAP documentation.
I've made these tests with the Sun's JDK 1.3.0 and 1.2.2-006 on a Windows
2000 Professionnal workstation with the Apache Tomcat 3.2.2 engine and the
Apache SOAP 2.1 implementation.
Christian BERNARD
NAGORA Technologies
-----Original Message-----
From: Christian Bernard [mailto:cbernard@nagora.com]
Sent: Thursday, June 07, 2001 10:58 AM
To: soap-user@xml.apache.org
Subject: RE: Class Loading in SOAP/Tomcat
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: javier@mofongo.sfo.covalent.net
[mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
Sent: Wednesday, June 06, 2001 10:28 PM
To: soap-user@xml.apache.org
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: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
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: javier@mofongo.sfo.covalent.net
[mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
Sent: Wednesday, June 06, 2001 10:28 PM
To: soap-user@xml.apache.org
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: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: Class Loading in SOAP/Tomcat
Posted by Christian Bernard <cb...@nagora.com>.
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: javier@mofongo.sfo.covalent.net
[mailto:javier@mofongo.sfo.covalent.net]On Behalf Of Javier A. Soltero
Sent: Wednesday, June 06, 2001 10:28 PM
To: soap-user@xml.apache.org
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: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org