TC33b1 Context path behavior: Is this a bug or by design?

[Randall Parker]

I'm seeing two different paths as being accepted for pages in the same war file. I'm 
wondering 
if the behavior I'm seeing is by design or a bug. 

I installed the struts-documentation.war file in webapps and restarted Tomcat 3.3 b1. 
As 
expected I was able to access such URLs as:
   http://127.0.0.1:8080/struts-documentation/index.html
and 
   
http://127.0.0.1:8080/struts-documentation/api/org/apache/struts/taglib/bean/package-
summary.html#package_description

So the leading /struts-documentation mapped to the corresponding war file.

Then I decided to add to the /conf dir the following:
   apps-struts-documentation.xml






  
  
  
  



After stopping and restarting Tomcat I was then able (as expected) to access pages 
using 
the shorter /strutsdoc leading path. For instance:
   http://127.0.0.1:8080/strutsdoc/index.html

However, when I went back and tried the original:
  http://127.0.0.1:8080/struts-documentation/index.html
 that still worked. I even did Refresh and fired up a different brand of browser that 
hadn't 
previously visited either page to make sure the browser wasn't just loading the older 
URL from 
cache.

Well, I'd expect that when one defined the Context path in the xml file that that path 
would 
_replace_ the default path named after the war file. Is that not the case? Is this 
normal 
behavior or incorrect behavior?

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs build.xml tomcat-docs.xsl

[craigmcc]

craigmcc01/08/04 21:02:31

  Modified:webapps/tomcat-docs build.xml tomcat-docs.xsl
  Log:
  Pick up the WEB-INF directory when building the tomcat-docs webapp.
  
  Make the project-specific logo URL relative to {$relative-path}.
  
  Revision  ChangesPath
  1.5   +5 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- build.xml 2001/08/05 03:42:28 1.4
  +++ build.xml 2001/08/05 04:02:30 1.5
  @@ -37,6 +37,11 @@
 
   
   
  +
  +
  +  
  +
  +
   
   
 
  
  
  
  1.2   +2 -2  jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tomcat-docs.xsl   2001/08/05 03:42:28 1.1
  +++ tomcat-docs.xsl   2001/08/05 04:02:30 1.2
  @@ -1,7 +1,7 @@
   
   
   
  -
  +
   
   http://www.w3.org/1999/XSL/Transform";
 version="1.0">
  @@ -78,7 +78,7 @@
   
 
 
  -
  +
 
   
 PROJECT LOGO
  
  
  

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/images jakarta-logo.gif

[craigmcc]

craigmcc01/08/04 20:42:29

  Modified:webapps/tomcat-docs build.xml index.xml project.xml
   webapps/tomcat-docs/appdev deployment.xml index.xml
installation.xml introduction.xml processes.xml
project.xml source.xml
   webapps/tomcat-docs/config index.xml project.xml
  Added:   webapps/tomcat-docs tomcat-docs.xsl
   webapps/tomcat-docs/images jakarta-logo.gif
  Removed: webapps/tomcat-docs/appdev tomcat.gif
  Log:
  Update to a stylesheet that is (at present) local to the tomcat-docs web
  application sources, rather than being an external dependency on
  jakarta-site2.  In addition, this stylesheet does *not* try to load the
  "project.xml" file itself (which caused lots of relative reference
  problems).  Instead, each XML page includes an ENTITY declaration to
  define the project.xml file for that directory, and a "&project;"
  reference to load it.
  
  Update all existing pages to the new technology.
  
  Revision  ChangesPath
  1.4   +9 -35 jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/build.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- build.xml 2001/07/30 19:16:24 1.3
  +++ build.xml 2001/08/05 03:42:28 1.4
  @@ -18,16 +18,8 @@
 
   
   
  -  
  -  
  -
  -
  -
  -  
  -
  -
 
  -  
  +  
   
   
 
  @@ -91,54 +83,36 @@
 
 
   
  -
  -
  -
  -  
  -  
  -
  -
  -  
  -
  -
  -  
  -
   
   
  -
 
   
   
   
  -
  -  
  +  
   
   
   
  -
  -  
  +  
   
  -
  -
  -
   
 
   
  
  
  
  1.3   +5 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml 2001/07/30 19:16:24 1.2
  +++ index.xml 2001/08/05 03:42:28 1.3
  @@ -1,5 +1,10 @@
   
  +
  +]>
   
  +
  +  &project;
   
 
   Craig R. McClanahan
  
  
  
  1.3   +11 -10jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- project.xml   2001/07/30 19:16:24 1.2
  +++ project.xml   2001/08/05 03:42:28 1.3
  @@ -4,7 +4,7 @@
   
   The Tomcat 4 Servlet/JSP Container
   
  -http://jakarta.apache.org/tomcat/images/tomcat.gif";>
  +
 The Tomcat Servlet/JSP Container
   
   
  @@ -12,25 +12,26 @@
   
   
   
  -
  -
  -
  -
  +
  +
  +
  +
   
   
   
  -
  +
   
   
   
  -
  -
  +
  +
   
   
   
  -
  -
  +
  +
   
   
   
  +
   
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  
  
  
  
  
  http://www.w3.org/1999/XSL/Transform";
version="1.0">
  
  


  
  


http://jakarta.apache.org/'"/>



  
  









  
  


  
  
   - 
  

  


  



  
  
  
  
  
  
  
PAGE HEADER

  
  JAKARTA LOGO
  

  
  

  
  

  
  

  
  

  


  


  

  
PROJECT LOGO

  

  
  

  
HEADER SEPARATOR

  

  

  

  
  LEFT SIDE NAVIGATION
  

  
  
  RIGHT SIDE MAIN BODY
  

  
  

  
FOOTER SEPARATOR

  

  

  
PAGE FOOTER

  
  Copyright © 1999-2001, Apache Software Foundation
  

  

Re: Classloader problems. Tomcat won't load Xalan from WEB-INF/lib

[Craig R. McClanahan]

On 4 Aug 2001, burtonator wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> OK.
> 
> I running Tomcat under with Xalan under JDK 1.3.  I want to have
> Tomcat reload all my Xalan extensions when I recompile.
> 
> The only problem is that since the Tomcat core uses Xalan the system
> classloader is used and therefore when I recompile none of my new
> extension modifications are used.
> 
> OF course this normal behavior with the system classloader (
> sun.misc.Launcher$AppClassLoader ).  What I need to have happen is for
> Tomcat (when in a certain configuration) to ALWAYS use *it's*
> classloader even if a given class has been loaded by the system
> classloader.
> 
> Is this possible?  Can I have two classloaders in the same JVM with the same
> classes loaded from different locations?
> 
> Did that make sense?
> 
> I have tried to find more documentation on this but was unable to find any in
> the archives which helped.
> 

Tomcat 4 does what you are after.  It loads it's own XML parser from the
"$CATALINA_HOME/server/lib" directory, which won't interfere with use of
Xalan (or an XML parser) loaded in your web app.

There's a document describing Tomcat 4's internal class loading
architecture in the source distribution (accessible online via anonymous
CVS) at:

  catalina/docs/dev/classloaders.html


> Kevin
> 

Craig McClanahan


> - -- 
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
> Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 
> 
> My mind is glowing!
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
> 
> iD8DBQE7bJMTAwM6xb2dfE0RApUfAJwMX9y2lPCcD+Y4KQPlvVbgc29zsgCePk82
> 3c4V4puKUnm4pO06BR0OzLk=
> =AVyy
> -END PGP SIGNATURE-
> 
> 

Classloader problems. Tomcat won't load Xalan from WEB-INF/lib

[burtonator]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


OK.

I running Tomcat under with Xalan under JDK 1.3.  I want to have Tomcat reload
all my Xalan extensions when I recompile.

The only problem is that since the Tomcat core uses Xalan the system classloader
is used and therefore when I recompile none of my new extension modifications
are used.

OF course this normal behavior with the system classloader (
sun.misc.Launcher$AppClassLoader ).  What I need to have happen is for Tomcat
(when in a certain configuration) to ALWAYS use *it's* classloader even if a
given class has been loaded by the system classloader.

Is this possible?  Can I have two classloaders in the same JVM with the same
classes loaded from different locations?

Did that make sense?

I have tried to find more documentation on this but was unable to find any in
the archives which helped.

Kevin

- -- 
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

My mind is glowing!



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE7bJMTAwM6xb2dfE0RApUfAJwMX9y2lPCcD+Y4KQPlvVbgc29zsgCePk82
3c4V4puKUnm4pO06BR0OzLk=
=AVyy
-END PGP SIGNATURE-

Summation - Re: [VOTE] Sources in Binary Distributions

[Rob S.]

The *only* reason I brought this up in the first place was because I thought
it was an oversight in the build process.  "The *source* in the *bin* build
I downloaded doesn't seem right..." - what the good Mr. Cain had previously
stated.  If it WAS just a mere oversight, we can shave some time and space
off of the ever-expanding Internet and I feel good that I brought it to
someone's attention.

I never intended it to get all friggy.  If there's reason to have it there,
by all means keep it in!  I'll just continue to be puzzled by what "binary
distribution" means =)

Have a good long weekend (everyone in Canada w/Monday off at least ;)

- r

p.s. apologies to anyone upset or put out by this whole thing (Arun, Pier,
Christopher, Remy, etc.).

RE: ISAPI redirector

[Kevin Seguin]

the code is all in cvs.  you can browse the repositories from here:
http://jakarta.apache.org/site/cvsindex.html

see these:
jakarta-tomcat-connectors/jk/native/
jakarta-tomcat/src/native/

-kevin.

> 
> 
> I searched the archives for this list and found a few 
> references to the
> Visual Studio file that goes with the isapi_redirect.dll 
> however I couldn't
> find them anywhere.
> 
> Does anybody know how to get the source code for 
> isapi_redirect.dll (the
> workspace file or just the .c or .cpp files)?
> 
> 

cvs commit: jakarta-tomcat-connectors/webapp/lib wa_main.c

[pier]

pier01/08/04 11:25:57

  Modified:webapp/apache-1.3 mod_webapp.c
   webapp/lib wa_main.c
  Log:
  Fix for bug #2933. CGI scripts are now functional even when mod_webapp
  is running (took me 3 days to figure out WHY, darn!)
  
  Revision  ChangesPath
  1.22  +10 -11jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- mod_webapp.c  2001/07/25 03:30:42 1.21
  +++ mod_webapp.c  2001/08/04 18:25:57 1.22
  @@ -57,7 +57,7 @@
   
   /**
* @author  Pier Fumagalli 
  - * @version $Id: mod_webapp.c,v 1.21 2001/07/25 03:30:42 pier Exp $
  + * @version $Id: mod_webapp.c,v 1.22 2001/08/04 18:25:57 pier Exp $
*/
   
   #include 
  @@ -86,6 +86,13 @@
   /* MODULE AND LIBRARY INITIALIZATION AND DESTRUCTION */
   /* * */
   
  +/* Destroy the module and the WebApp Library */
  +static void wam_shutdown(server_rec *s, pool *p) {//void *nil) {
  +if (!wam_initialized) return;
  +wa_shutdown();
  +wam_initialized=wa_false;
  +}
  +
   /* Startup the module and the WebApp Library */
   static void wam_startup(server_rec *s, pool *p) {
   if (!wam_initialized) return;
  @@ -93,20 +100,12 @@
   wa_startup();
   }
   
  -/* Destroy the module and the WebApp Library */
  -static void wam_shutdown(void *nil) {
  -if (!wam_initialized) return;
  -wa_shutdown();
  -wam_initialized=wa_false;
  -}
  -
   /* Initialize the module and the WebApp Library */
   static const char *wam_init(pool *p) {
   const char *ret=NULL;
   
  -if(wam_initialized) return(NULL);
  +if(wam_initialized==wa_true) return(NULL);
   if ((ret=wa_init())!=NULL) return(ret);
  -ap_register_cleanup(p,NULL,wam_shutdown,NULL);
   wam_initialized=wa_true;
   return(NULL);
   }
  @@ -514,6 +513,6 @@
   NULL,   /* [10] logger */
   NULL,   /* [3] header parser */
   wam_startup,/* child initializer */
  -NULL,   /* child exit/cleanup */
  +wam_shutdown,   /* child exit/cleanup */
   NULL/* [1] post read_request handling */
   };
  
  
  
  1.10  +4 -1  jakarta-tomcat-connectors/webapp/lib/wa_main.c
  
  Index: wa_main.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/wa_main.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- wa_main.c 2001/07/19 23:50:03 1.9
  +++ wa_main.c 2001/08/04 18:25:57 1.10
  @@ -55,7 +55,7 @@
*   *
* = */
   
  -/* @version $Id: wa_main.c,v 1.9 2001/07/19 23:50:03 pier Exp $ */
  +/* @version $Id: wa_main.c,v 1.10 2001/08/04 18:25:57 pier Exp $ */
   #include 
   
   /* The current APR memory pool. */
  @@ -74,8 +74,11 @@
   const char *wa_init(void) {
   int x=0;
   
  +wa_debug(WA_MARK,"WebApp Library initializing");
  +
   /* Check the main APR pool. */
   if (wa_pool==NULL) {
  +wa_debug(WA_MARK,"Initializing APR");
   if (apr_initialize()!=APR_SUCCESS)
   return("Cannot initialize APR");
   if (apr_pool_create(&wa_pool,NULL)!=APR_SUCCESS)
  
  
  

ISAPI redirector

[James Leone]

I searched the archives for this list and found a few references to the
Visual Studio file that goes with the isapi_redirect.dll however I couldn't
find them anywhere.

Does anybody know how to get the source code for isapi_redirect.dll (the
workspace file or just the .c or .cpp files)?

Re: Sources in Binary Distributions

[Paul Speed]

Why not have three different downloads?  src, bin, and src + bin.
(ie: can't we all just get along? ;) )
-Paul Speed

"Rob S." wrote:
> 
> So what we have here is a minority of developers who look through the Tomcat
> source, versus the majority of people who have no interest in the /src dir.
> The argument is "leave src in there so that when I want to look at the
> source, i don't have to download a src dist".
> 
> For some reason, the "keep it in there" argument almost makes it sounds like
> the src is unavailable unless it's in the bin build.  Personally, for all of
> the people that could care less about the source, I don't think it's asking
> much for people who want to look at the source to go and get it...?
> 
> - r
> 
> > -Original Message-
> > From: Loïc Lefèvre [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 02, 2001 12:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Sources in Binary Distributions
> >
> >
> > Absolutely agree with you!
> >
> > -Message d'origine-
> > De : Arun Katkere [mailto:[EMAIL PROTECTED]]
> > Envoyé : jeudi 2 août 2001 17:28
> > À : '[EMAIL PROTECTED]'
> > Objet : RE: Sources in Binary Distributions
> >
> >
> > I don't generally throw in my $0.02 into a well worn thread and add to the
> > noise , but there is another issue which I didn't see anyone bring up.
> >
> > Having source around helps you with debugging. And if that
> > results in better
> > bug reports, i.e., instead of "it doesn't work and here is the
> > stack trace",
> > you get "it doesn't work because you didn't check for null around
> > this line
> > of this file", it is probably worth it.   Keep in mind that many of Tomcat
> > users are competent Java developers. And we are not talking about
> > the entire
> > build system here. Just the basic .java files. Not even native components
> > (which don't aid in this purpose). Sun's Java2 SDK includes the
> > source (just
> > the .java files) for I suspect the same reason.
> >
> > Personally, I download the source distribution only when there is
> > a critical
> > issue in Tomcat that we need resolved now, and patch and build with that
> > fix. Source in the binary on the other hand is useful for many
> > reasons even
> > if you discount the "first step towards getting people involved"
> > argument. A
> > quick check of some aspect of servlet/JSP spec(without going
> > through 100s of
> > pages of PDF). Help quickly identify whether the issue is with Tomcat or
> > your code. All on machines where you typically don't have the full
> > development environment set up (when we are talking about JSP and not
> > servlets).
> >
> > Of course, one can always download the "source distribution". So,
> > if you are
> > set on saving folks a few seconds (or minutes) of download time
> > at a slight
> > cost for those of us who do find it invaluable, that's fine.
> >
> > -arun
> >
> > > -Original Message-
> > > From: Rob S. [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 02, 2001 4:19 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Sources in Binary Distributions
> > >
> > >
> > > > I'd like to second that.  I am currently not involved in any active
> > > > development, but looking at sources contained in a binary dist is
> > > > certainly the first step towards getting involved (its on
> > > my list (o:  )
> > >
> > > So you *expect* the /src dir in a binary dist?  That's
> > > mind-blowing to me.
> > > If you're interested in TC development, your first thought
> > > isn't "Time to go
> > > d/l the src distro" it's "Time to d/l the bin dist so I can
> > > check out the
> > > src" ?
> > >
> > > I'm not making a huge stand here, I thought bringing up the
> > > suggestion was
> > > almost common sense.  It's a "bin" dist, i.e. !(src
> > > included).  I wouldn't
> > > expect it to be there 
> > >
> > > - r
> > >
> >
> >

RE: Sources in Binary Distributions

[Remy Maucherat]

I also plan to leave the source code in the Windows installer distribution, 
since IMO it's supposed to be a comprehensive "all-in-one" download. The source 
code is not installed by default.

Remy