RE: Sources in Binary Distributions
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
Re: Sources in Binary Distributions
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 shrug - r
ISAPI redirector
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
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 mailto:[EMAIL PROTECTED]
- * @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 httpd.h
@@ -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 wa.h
/* 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)
RE: ISAPI redirector
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)?
Summation - Re: [VOTE] Sources in Binary Distributions
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.).
Classloader problems. Tomcat won't load Xalan from WEB-INF/lib
-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-
Re: Classloader problems. Tomcat won't load Xalan from WEB-INF/lib
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-
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/images jakarta-logo.gif
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 @@
property name=site.xsl
value=../../../jakarta-site2/xdocs/stylesheets/site.xsl/
- !-- === BUILD: Initialization == --
- target name=build-init
-!-- Required only for the Ant Bugzilla #603 workaround --
-tstamp/
-property name=webapp.work
value=${java.io.tmpdir}/${webapp.name}${DSTAMP}${TSTAMP}/
- /target
-
-
!-- === BUILD: Create Directories == --
- target name=build-prepare depends=build-init
+ target name=build-prepare
mkdir dir=${webapps.build}/
mkdir dir=${webapps.build}/${webapp.name}/
/target
@@ -91,54 +83,36 @@
!-- = BUILD: XML-HTML Generation === --
target name=build-main depends=build-static
-!-- Workaround for Ant 1.3 bug (Bugzilla #603) where the style
- attribute is resolved relatively even if it is absolute! Copy
- the source tree to a temporary directory, and interpolate the
- XSLT stylesheet appropriately --
-mkdir dir=${webapp.work}/
-copytodir=${webapp.work}
- fileset dir=./
- fileset dir=${site2.home}/xdocs/stylesheets includes=site.xsl/
-/copy
-copytodir=${webapp.work}/appdev
- fileset dir=${site2.home}/xdocs/stylesheets includes=site.xsl/
-/copy
-copytodir=${webapp.work}/config
- fileset dir=${site2.home}/xdocs/stylesheets includes=site.xsl/
-/copy
!-- Top Level Directory --
-style basedir=${webapp.work}
+style basedir=.
destdir=${webapps.build}/${webapp.name}
extension=.html
- style=site.xsl
+ style=tomcat-docs.xsl
excludes=build.xml project.xml
includes=*.xml
param name=relative-path expression=./
/style
!-- Application Developer's Guide --
-style basedir=${webapp.work}/appdev
+style basedir=appdev
destdir=${webapps.build}/${webapp.name}/appdev
extension=.html
- style=site.xsl
+ style=../tomcat-docs.xsl
excludes=project.xml
includes=*.xml
- param name=relative-path expression=./
+ param name=relative-path expression=../
/style
!-- Server Configuration Reference --
-style basedir=${webapp.work}/config
+style basedir=config
destdir=${webapps.build}/${webapp.name}/config
extension=.html
- style=site.xsl
+ style=../tomcat-docs.xsl
excludes=project.xml
includes=*.xml
- param name=relative-path expression=./
+ param name=relative-path expression=../
/style
-
-!-- Remove the temporary directory for the Ant bug workaround --
-delete dir=${webapp.work} /
/target
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 @@
?xml version=1.0?
+!DOCTYPE document [
+ !ENTITY project SYSTEM project.xml
+]
document
+
+ project;
properties
author email=[EMAIL
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs build.xml tomcat-docs.xsl
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 @@
/fileset
/copy
+!-- WEB-INF Static Files --
+copytodir=${webapps.build}/${webapp.name}/WEB-INF
+ fileset dir=WEB-INF/
+/copy
+
!-- Application Developer's Guide Examples --
copytodir=${webapps.build}/${webapp.name}/appdev
fileset dir=appdev includes=*.txt/
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 @@
?xml version=1.0 encoding=ISO-8859-1?
!-- Content Stylesheet for tomcat-docs Documentation --
-!-- $Id: tomcat-docs.xsl,v 1.1 2001/08/05 03:42:28 craigmcc Exp $ --
+!-- $Id: tomcat-docs.xsl,v 1.2 2001/08/05 04:02:30 craigmcc Exp $ --
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
@@ -78,7 +78,7 @@
xsl:value-of select=project/@href/
/xsl:variable
xsl:variable name=src
-xsl:value-of select=project/logo/@href/
+xsl:value-of select=$relative-path/xsl:value-of
select=project/logo/@href/
/xsl:variable
xsl:commentPROJECT LOGO/xsl:comment
TC33b1 Context path behavior: Is this a bug or by design?
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 ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ /Context /webapps 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?
