Re: mod_webapp and apache 2.0

[Justin Erenkrantz]

On Wed, Dec 05, 2001 at 07:29:58PM -0800, Charles Yates wrote:
> >On Wed, Dec 05, 2001 at 09:34:55AM -0800, Charles Yates wrote:
> >>   After getting errors from "apachectl configtest" relating
> >>to invalid port I added a Port directive to httpd.conf and got
> >>an error that Port directive had been replaced by Listen.  I then
> >>removed my Port directive, hacked on webapp.c and wa_config.c
> >>to hard code server Port references and . . . . Yay, it works!
> >
> >I think the webapp code in the j-t-c CVS repository is updated.
> >If not, then please post what you did and we can try and sort
> >out the "right" fix.  -- justin

Hmm.  Greg just brought this issue on dev@httpd, so this seems to 
be something that we are mangling pretty bad.  When we get a
resolution, I'll try to make sure that any patches are sent to
j-t-c (you may need not any if we fix it in httpd).  

Until then, sit tight and run with that patch.  =) -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: mod_webapp and apache 2.0

[Justin Erenkrantz]

On Wed, Dec 05, 2001 at 09:34:55AM -0800, Charles Yates wrote:
>After getting errors from "apachectl configtest" relating
> to invalid port I added a Port directive to httpd.conf and got
> an error that Port directive had been replaced by Listen.  I then
> removed my Port directive, hacked on webapp.c and wa_config.c
> to hard code server Port references and . . . . Yay, it works!

I think the webapp code in the j-t-c CVS repository is updated.
If not, then please post what you did and we can try and sort
out the "right" fix.  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] mod_webapp and Apache 2.0

[Justin Erenkrantz]

Gets rid of lame warnings against latest httpd-2.0 and APR.
-- justin

Index: webapp/apache-2.0/mod_webapp.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
retrieving revision 1.6
diff -u -r1.6 mod_webapp.c
--- webapp/apache-2.0/mod_webapp.c  2001/11/01 22:20:51 1.6
+++ webapp/apache-2.0/mod_webapp.c  2001/12/05 08:14:13
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* * */
 /* GENERIC DECLARATIONS  */
@@ -477,7 +478,7 @@
 
 /* Copy headers into webapp request structure */
 if (r->headers_in!=NULL) {
-apr_array_header_t *arr=apr_table_elts(r->headers_in);
+const apr_array_header_t *arr=apr_table_elts(r->headers_in);
 apr_table_entry_t *ele=(apr_table_entry_t *)arr->elts;
 int x=0;
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] mod_jk for Apache 2.0 minor fixes

[Justin Erenkrantz]

On Fri, Nov 30, 2001 at 07:25:40PM -0500, GAWLAS,JULIUS (HP-Cupertino,ex1) wrote:
> This patch contains minor fixes for mod_jk for Apache 2.0; 
> 
> Most important is the change in prototype of jk_post_config 
> which used to be void but now needs to return success code, 
> also changes to types of some variables to better confirm to 
> Apache 2.0 types.
> 
> Let me know if you have any comments.

FWIW, +1 (non-binding) from the httpd-2.0 peanut 
gallery.  =)  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mod_webapp & Solaris 8

[Justin Erenkrantz]

On Wed, Nov 28, 2001 at 10:32:05AM -0800, Justin Erenkrantz wrote:
> You could try:
> 
> LIBS="-Lgcc" \
> LDFLAGS=-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.1 \
> ./configure --enable-module=rewrite --enable-shared=rewrite

Ack, I meant -lgcc not -Lgcc.  Freezing cold sticky fingers.  -- justin


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Mod_webapp & Solaris 8

[Justin Erenkrantz]

On Wed, Nov 28, 2001 at 01:26:41PM -0500, Matt Goyer wrote:
> Tricky beast it is!
> 
> I installed gcc 3.0.1 using the sunfreeware package and it looks like
> it's sticking the lib files in 
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.1 so:
> 
> To configure Apache I'm doing:
> 
> LDFLAGS=-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.1 \
> ./configure --enable-module=rewrite --enable-shared=rewrite

You could try:

LIBS="-Lgcc" \
LDFLAGS=-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.1 \
./configure --enable-module=rewrite --enable-shared=rewrite

You need to force httpd to bring in libgcc (but Solaris's ld may
be stubborn about bringing it in if it isn't used).  

You may also have better luck if you get mod_webapp to compile 
statically.  The problem here is that the run-time link path on 
httpd is different than the link path that mod_webapp requires.
By compiling it statically, that problem goes away.

httpd-2.0 handles this much better since it'd bring in 
libgcc.  =)  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mod_webapp & Solaris 8

[Justin Erenkrantz]

On Wed, Nov 28, 2001 at 12:31:13PM -0500, mgoyer wrote:
> Httpd was built with gcc-3.0.1 the same version that I'm using for
> mod_webapp.

Then, just add -R/path/to/gcc-3.0.1/lib to your LDFLAGS for
httpd.

(Using gcc-3.0.1 on Solaris is a really tricky beast because
gcc doesn't add the -R flags to the binaries.)  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mod_webapp & Solaris 8

[Justin Erenkrantz]

On Wed, Nov 28, 2001 at 11:15:07AM -0500, Matt Goyer wrote:
> Syntax error on line 206 of /usr/local/apache/conf/httpd.conf:
> Cannot load /usr/local/apache/libexec/mod_webapp.so into server:
> ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file
> /usr/local/apache/libexec/mod_webapp.so: symbol __lshrdi3: referenced
> symbol not found

You need to compile Apache with the same compiler as you compiled 
mod_webapp.  So, if you are using gcc-3.0.1, make sure that httpd 
was built with gcc-3.0.1.  An executable built with gcc-3.0.1 knows 
where to find gcclib.  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: mod_webapp & apache2 problems:

[Justin Erenkrantz]

On Wed, Nov 21, 2001 at 09:22:02AM -0600, Brian P Millett wrote:
> Quick Synopsis of error (apache 2.0):
> Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf:
> Invalid port number (p<1) No "Port" statement found

Oooh, I bet it is related to the change that we committed to set
port to 0 internally to represent that the port for the virtual
server should be the port the connection actually comes in on.
It's now done dynamically by the core at run-time per connection
if port == 0 - which is the default for vhosts.  When the connection
is actually received, the port will be the correct value.

I'll take a gander at compiling webapp and posting a patch.  Can
you verify with gdb or whatnot that wa_cvirtualhost is getting
p=0?  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland

[Justin Erenkrantz]

On Sat, Nov 17, 2001 at 08:51:24PM +0100, [EMAIL PROTECTED] wrote:
> First of all I attempt to calmly summarize the problem and only then let my emotions 
>get through. 
> 
> My insufficient knowledge of AIX platforms prevents me from successfully compiling 
>mod_webapp (as well mod_jk) on AIX 4.3.3 platform.
>  
> Tomcat itself appears to be running flawlessly. Unfortunately due to my meager 
>knowledge of AIX I seem to be unable to recompile neither mod_webapp nor mod_jk for 
>the specified platform. Actually compilation worked fine in both cases. What did fail 
>was the ‘ld’ linker. As far as I can judge about possible cause of failure, the 
>linker requires a module export (.exp) file in order to be able successfully complete 
>linking process. In this respect AIX appears to differ from Unixes, as I had no 
>problems at all building mod_webapp & mod_jk under Linux (Mandrake 8.0 & Mandrake 
>8.1) as well as Solaris 8. The problem is aggravated by the management’s desire to 
>use IBM HTTP Server instead of plain Apache mainly due to IBM’s SSL support, which is 
>perceived to be more trustworthy and secure. 
> 
> Is my assumption right? If yes, is there a way I could generate that damn .exp file 
>for mod_webapp? I could also live with mod_jk as a fallback scenario. 
> 
> Please help.

My hypothesis here is that your biggest obstacle is your OS not your 
knowledge of it.  I wish there was a better answer, but you can't 
easily build custom complex DSOs in AIX.  (Switching OSes doesn't
seem like an option since you have IBM hardware.)

AIUI, the problem here is due to the AIX linker and how it handles
dependencies (that .exp file - it isn't hard to generate it, but the
linker doesn't know what to do with it anyway).  I have a feeling 
that it may stop mod_webapp from working as a DSO since it requires 
APR.

I know that Aaron Bannert spent some time working with the IBM
httpd folks (Victor, Greg, Bill, Jeff, etc.) trying to get AIX DSO 
support for Apache 2.0 and APR.  I believe the eventual conclusion 
from the IBM AIX gurus in Austin was that the linker is not capable 
of handling external dependencies in an acceptable manner.  Their
recommendation was to wait for the next major release of AIX which 
would have a new linker.  But, this isn't very helpful to you or 
to us httpd folks though.

I heard all of this second-hand via Aaron, so I may be missing
the key points, but I know the gist of the problem (AIX no gusto
DSOs).  I believe Aaron is lurking here, so he may be able to give 
more technical details and some pointers on what you may be able 
to do.

Therefore, I would consider focusing your efforts on getting mod_jk 
to work as it can be built as a self-contained DSO (it may require 
some hacking of the Makefiles though).  I think you will have a
much better chance of getting mod_jk to work than mod_webapp on 
AIX as a DSO.

> I have been informed by the management that if problem is not resolved by mid next 
>week Tomcat will be replaced with WebSphere 3.5 Standard Edition. 

Since you are running AIX, you may be best off being fully supported
by IBM - bite the bullet and use WebSphere 3.5.  You are already 
running their hardware, their OS, their HTTP server - their servlet 
engine isn't that much more to depend on.

Open-source projects can't fix IBM's closed-source linker.  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Performance of tomcat 3.2.3

[Justin Erenkrantz]

On Fri, Nov 16, 2001 at 09:16:18AM -0800, Michael Jennings wrote:
> Hi everyone,
> 
> I'm working on a project for a client that involves a servlet engine component. I 
>suggested tomcat
> since I am most familiar with it and it seems the most compliant servlet engine 
>around.
> My client has mentioned concerns about tomcat's performance and now is insisting on
> using IBM websphere 4.0

FWIW, I've heard of nothing but bad experiences with WebSphere.
> 
> My suspicion is that tomcat's performance will be fine for this application, but I 
>would
> like to have some hard numbers to back up my claim. Does anyone know of any kind
> of tool or code out there that can measure http and https performance?

http://httpd.apache.org/test/flood/

If you enable the HotSpot Server VM, you'll get about as good as
you can with any Java application.  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building mod_webapp on Solaris 8

[Justin Erenkrantz]

On Tue, Nov 13, 2001 at 01:55:51PM -0500, Matt Goyer wrote:
> I'm also having the same problem with libgcc when I try and build and
> compile my own mod_jk.
> 
> Any pointers on where libgcc should be so that Apache/mod_xx finds it would
> be appreciated.

Add -R/path/to/gcc-3.0/lib to your LDFLAGS.

> And this is the error I get when trying the pre-compiled mod_webapp for
> Solaris 8:
> Syntax error on line 206 of /usr/local/apache/conf/httpd.conf:
> Cannot load /usr/local/apache/libexec/mod_webapp.so into server: ld.so.1:
> /usr/local/apache/bin/httpd: fatal: relocation error: file
> /usr/local/apache/libexec/mod_webapp.so: symbol __lshrdi3: referenced symbol
> not found

This is a known bug when mixing the Forte (Sun) compiler with GCC.  
You must compile Apache and mod_webapp with the same compiler.  JF 
just checked in a patch to j-t-c that will detect this when building 
from source.  -- justin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows

[Justin Erenkrantz]

On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote:
> I'll grab the latest CVS and see how that works.
> 
> The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal
> and autoconf.  Cygwin includes all of these except libtool.  I built it and
> installed it into /usr/local/bin and bad things happened.  I put it into
> /usr/bin and things ran fine.

Ah, that's jk-specific.  It might be a good idea to try to remove the
automake dependency if at all possible as we don't require it for
httpd.  All of the others are required for Apache 2.0.  

Pier has a good build system with 2.0 for mod_webapp.  =)  -- justin

Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows

[Justin Erenkrantz]

On Tue, Oct 02, 2001 at 10:29:41AM -0500, Marc Saegesser wrote:
> Here's an update on where I stand right now on building/running mod_jk for
> Apache 2.0 beta 16.

Please don't use Apache 2.0.16.  Use the latest version from CVS.

Also, I'm not sure where automake is coming from - we don't use that.
Perhaps, you mean autoconf?  We also revamped the build system well 
after the 2.0.16 timeframe.  Hopefully, things might be smoother 
with the latest version.  -- justin

[PATCH] mod_webapp build cleanups...

[Justin Erenkrantz]

I finally got a chance to build mod_webapp from j-t-c with Apache 2.0.
Looks good and is quite easy to do.  Only problem is that we aren't 
handling directories properly.  If you do the examples webapp, you 
see a link to:

http://localhost:8080/examples/servlets/

Going there results in a bad response (actually nothing returned!), 
but

http://localhost:8080/examples/servlets/index.html

works.  I'm not terribly sure if httpd or Tomcat should be handling
this case (i.e. redirecting or handling DirectoryIndex-type semantics).
Somebody isn't handling it and that's not good.

You will find attached a patch that cleans up some of the build
process in j-t-c so that it works with Apache 2.0 cleanly and
fixes some tpyos and formatting quirks.  

The only questionable thing is that lib/libwebapp.a isn't built by 
libtool.  The simple straightforward ar and ranlib should work fine, 
but it may not work on all systems.  When linking mod_webapp.lo with
libwebapp.a, libtool emits a warning.  It may be worth it to try and 
use APR's libtool to compile and link all of the files in lib (this 
would produce lib/libwebapp.la).

Enjoy.  Oh, and Pier, thanks for dinner.  =-)  This is my 
payback...  -- justin

Index: webapp/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.20
diff -u -r1.20 Makefile.in
--- webapp/Makefile.in  2001/09/17 05:06:27 1.20
+++ webapp/Makefile.in  2001/10/01 06:39:24
@@ -107,6 +107,12 @@
 apache-1.3-clean:
@$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-1.3" MTGT="clean"
 
+apache-2.0-build:
+   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="build"
+
+apache-2.0-clean:
+   @$(MAKE) template MFLG="$(MAKEFLAGS)" MDIR="apache-2.0" MTGT="clean"
+
 template:
@ { \
$(ECHO) "" ; \
Index: webapp/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.39
diff -u -r1.39 configure.in
--- webapp/configure.in 2001/09/17 05:07:01 1.39
+++ webapp/configure.in 2001/10/01 06:39:24
@@ -177,7 +177,7 @@
 dnl Upd vars: N/A
 dnl -
 AC_ARG_WITH(tomcat,
-  [  --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
+  [  --with-tomcat[=DIR]   path of a Tomcat 4.0 distribution. (DIR defaults
   to \"/usr/local/tomcat\"). Not required and ignored
   when the --enable-java option is not specified.],
   [
@@ -241,7 +241,7 @@
 AC_MSG_CHECKING([for C API documentation])
 AC_ARG_ENABLE(apidocs-c,
   [  --enable-apidocs-c[=PERL]
-  enbale generation of C API documentation using
+  enable generation of C API documentation using
   ScanDoc (PERL is the name of the Perl interpreter
   used to run ScanDoc. If not specified this is
   looked up in your current path).],
@@ -302,7 +302,7 @@
 AC_MSG_CHECKING([for Java API documentation])
 AC_ARG_ENABLE(apidocs-java,
   [  --enable-apidocs-java[=JAVADOC]
-  enbale generation of Java API documentation using
+  enable generation of Java API documentation using
   JavaDoc (If JAVADOC is not set its value will be
   discovered by \"--enable-java\").],
   [
@@ -347,10 +347,10 @@
 dnl Upd vars: APR_SRCDIR
 dnl --
 AC_ARG_WITH(apr,
-  [  --with-apr[=DIR]path of an APR (Apache Portable Runtime) source
+  [  --with-apr[=DIR]  path of an APR (Apache Portable Runtime) source
   distribution or CVS snapshot. (DIR defaults to
-  \"./apr\"). Not required and ignored when the
-  --with-apxs2 option is specified.],
+  \"./apr\"). Not required and ignored when an
+  Apache 2.0 apxs is specified (--with-apxs).],
   [
 case "${withval}" in
 ""|"yes"|"YES"|"true"|"TRUE")
@@ -382,7 +382,7 @@
 dnl --
 AC_MSG_CHECKING([for Apache apxs])
 AC_ARG_WITH(apxs,
-  [  --with-apxs[=FILE]  build a shared Apache module. If FILE was not
+  [  --with-apxs[=FILE]build a shared Apache module. If FILE was not
   specified, then APXS will be searched within the
   current PATH. The Apache server version (1.3 or 2.0)
   will be automatically detected.],
@@ -425,7 +425,7 @@
   dnl Upd vars: APR_CFGFLG APR_VARFIL APR_LIBDIR APR_INCDIR
   dnl -
   MO

Re: Re: >> Apache/Tomcat Collaboration

[Justin Erenkrantz]

On Mon, Oct 01, 2001 at 01:49:20AM -0700, [EMAIL PROTECTED] wrote:
> I think option 2 ( in-process ) is what mod_jk is doing - the code has
> been written and used quite a bit in the last year. It didn't got all the
> attention that Ajp got, because it doesn't work with Apache1.3, only
> with IIS and NES and Apache2 ( and AolServer ).

I had a feeling you did this with other servers - just not with httpd.
With Apache 2.0?  Eh, how?  -- justin

Re: Re: >> Apache/Tomcat Collaboration

[Justin Erenkrantz]

On Mon, Oct 01, 2001 at 12:41:10AM -, Shailesh S. Gokhale wrote:
> ***
> Tomcat can be used as either a stand-alone container (mainly for development and 
>debugging) or as an add-on to an existing web server
> s are supported). This means that whenever you are deploying Tomcat you will have to 
>decide how to use it and, *** if you select options 2 or 3, you will also need to 
>install a web server adapter ***
> ***

Option 2 is unrealistic with httpd since you'd have to have share the 
memory/address space with the JVM which is just a generally bad idea.
In theory, yes, you could do it (no one has written code to do this
AFAIK).  Option 3 is what should be used with httpd - at least from 
my side of the fence.  -- justin

Re: >> Apache/Tomcat Collaboration

[Justin Erenkrantz]

On Sun, Sep 30, 2001 at 01:46:37PM -, Shailesh S. Gokhale wrote:
> 1. I understand that Tomcat can work with any (supported) web 
> server in two modes - 'In Proc' and 'Out of Proc'. I have 
> successfully configured Tomcat (Out of Proc) to work with Apache. 
> The question is how can I make it work 'In Proc' with Apache? 

I'm not aware how Apache will load the JVM, so I don't see how you
will get it to be "in proc."  AFAIK, all of the modules for all
webservers require an externally running copy of Tomcat.  I could
be wrong though.  I think some of them are smart enough to invoke
Tomcat if it isn't running, but that doesn't mean they are running
in the same process space.

> 2. In relation to the above, there seem to be two available 
> adapters for the Apache/Tomcat collaboration in the Windows 
> environment. One is ApacheModuleJServ.dll and another is 
> mod_jk.dll. [The second one replaces a more complex adapter 
> (mod_jserv.dll) available earlier and no longer used]. My 
> question is what is the difference between the two - that is 
> ApacheModuleJServ.dll and mod_jk.dll? 

I think ApacheModuleJServ.dll is just a renamed version of
mod_jserv.dll.  You should always be using mod_jk - mod_jserv
isn't supported anymore.  -- justin

Re: [J-T-C] Apache 2.0 code review required

[Justin Erenkrantz]

On Sat, Sep 15, 2001 at 12:50:27AM +0200, GOMEZ Henri wrote:
> Hi to all,
> 
> I've just commited updated code for Apache 1.3/2.0
>  
> I will need a serious code review on Apache 2.0 part
> and particulary the ws_read() which was grabbed from
> 1.3 and works (at least on Apache 2.0.24) but may 
> be optimized...

> ws_write() could need also a serious cleanup and see if the 
> CHUNK_SIZE of 4k is still valid.
> 
> /* Works with 4096, fails with 8192 */
> #define CHUNK_SIZE 4096

Should be no need for this chunking.  Just pass it all to 
ap_rwrite.  If that doesn't work, then we have problem on our end
that we need to fix.

Since you have a "common" infrastructure via callbacks, I don't think
you can take advantage of a lot of the new features in Apache 2.0.
Oh, well.  -- justin

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Justin Erenkrantz]

On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote:
> Since there is no official release of httpd-2.0, I am confident that nobody
> will actually care unless they're testing something... And by "testing" good
> practice says "get the HEAD of CVS and try it out yourself if it doesn't
> work". Development happens on "head" and if someone forks off for a little
> while to do some porting to some weird operating systems, at the end those
> changes will have to be integrated with HEAD, so, there's no point in
> sticking with backward compatibility AT THIS POINT.

+1 to what Pier said.  (Ryan may chip in here too...)

If you are using anything other than HEAD for httpd-2.0, I don't 
care much about any bug reports you may have.  The odds are that it'd
either be fixed or broken in a different manner.  =)  -- justin

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docsssl-howto.xml

[Justin Erenkrantz]

On Fri, Aug 31, 2001 at 02:48:56PM -0600, Christopher Cain wrote:
> Oh well ... as an unrepentant terminal geek, I'm glad I took the time to
> learn it on the command line. Like most Linux commands, it has a pretty
> steep learning curve, but once you're familiar with it it's really quite
> powerful =)

Hey, submit patches for the dev.apache.org site to add what you
learned.  I think the instructions there are pretty lacking.
FreeBSD has some nice introductory docs for committers.  Steal
from them.  =-)  

May be best to post to [EMAIL PROTECTED] with any docs about
this rather than tomcat-dev.  -- justin

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test Header.java HttpRequest.java

[Justin Erenkrantz]

On Tue, Aug 28, 2001 at 05:46:28AM -, [EMAIL PROTECTED] wrote:
> costin  01/08/27 22:46:28
> 
>   Modified:src/share/org/apache/tomcat/util/test Header.java
> HttpRequest.java
>   Log:
>   Fixes in the test suite. We must send 1.0 requests, since we can't handle
>   1.1 responses.

Out of curiosity, what is the problem with HTTP/1.1 responses?  -- justin

Re: Tomcat 3.2.3 and getPathInfo

[Justin Erenkrantz]

On Sun, Aug 26, 2001 at 10:24:30PM -0700, Jason Hunter wrote:
> So what does the Apache Web Server do for PATH_INFO on a request to
> http://foo.com/cgi-bin/somecgi/http://extra.com?

Ask for /index.html/http://extra.com with httpd-2.0, it strips out the
second /.

(gdb) print r->path_info
$5 = 0x813debc "/http:/extra.com"

HTH.  -- justin

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java

[Justin Erenkrantz]

On Tue, Aug 21, 2001 at 06:51:52PM -, [EMAIL PROTECTED] wrote:
> craigmcc01/08/21 11:51:52
> 
>   Modified:catalina/src/share/org/apache/catalina/core
> StandardServer.java
>   Log:
>   Fix for a DoS attack against the shutdown port, that could cause an "out
>   of memory" exception by sending a continuous stream of characters.  Now,
>   Tomcat will only listen for enough characters to match or not-match the
>   required password, then it shuts the port.

Now I'll know exactly how long the shutdown password is.  =-)  -- justin

Re: Patch to bug #345 complete ?

[Justin Erenkrantz]

On Mon, Aug 20, 2001 at 10:54:43AM -0700, Craig R. McClanahan wrote:
> I'm not sure I would make quite so blanket a statement as that.  If the
> servlet itself understands that the content it produces changes rarely, it
> can improve performance by respecting If-Modified-Since values.  To make
> this worthwhile, though, it will also need to control the value sent for
> the "Last-Modified" header, which you can do by overriding the
> getLastModified() method of HttpServlet.

True - you are correct.  But, this wouldn't be something that Tomcat 
could do by default - this would require that the servlet itself 
handle this and have appropriate logic via getLastModified().  
The servlet can handle it, but that's user code not Tomcat code.  
-- justin

Re: Patch to bug #345 complete ?

[Justin Erenkrantz]

On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
> 
> yes. I analyzed the HTTP header that's being sent and received by the
> browser.
> If-Modified-Since messages are sent to tomcat, and we are dealing with
> static files here (javascript and images). 
> So is tomcat doesn't have the '304 behavior' for static files ? It does
> send back 'last-modified' date information in the header, and that ALWAYS
> matches the 'If-modified-since' date. Are we looking at another tomcat 
> date bug here ?

It's more of a feature that was never written.  Tomcat has no code to
handle If-Modified-Since (based on a quick grep through the source 
code - I could be wrong).  You are welcome to write the code and apply 
it locally.  I'm not sure if it'll make it into the 3.x branch as I 
think it is frozen.  4.x is a possibility for inclusion, however.  (I 
seem to remember that you are using 3.x.)

However, you'll have to be aware that jsp's and servlets must ignore 
If-Modified-Since headers so the implementation can be tricky.  
-- justin

Re: Patch to bug #345 complete ?

[Justin Erenkrantz]

On Mon, Aug 20, 2001 at 09:18:53AM -0700, Henry Yeh wrote:
> 
> I have noticed that after applying the patch the date is now
> included in the tomcat HTTP response header, but it still
> does not send back "not modified 304" if the file requested
> hasn't been modified since the date specificed by the request ...
> 
> anyone has any ideas on how to fix this ? thanks !

Are you sending If-Modified-Since?  That doesn't look like it'd work 
in Tomcat.  

The 304 behavior doesn't apply to dynamic data as it is *always* 
regenerated.  So, I'm not even sure if you'd want it.  You definitely
don't want to look at the date on the jsp file as that tells you 
nothing (unlike static content).

Static content is a different story, but if you are serving static files
from Tomcat, you probably want a real HTTP server in front of it.  
-- justin

Re: project goals

[Justin Erenkrantz]

On Sun, Aug 19, 2001 at 11:16:52AM -0700, Mark Castillo wrote:
> Hi all,
> 
> Ok. After reading through some of the sources some questions came to mind.
> What are some of the specific goals of the project regarding robustness,
> performance, and security? At what point can we say that it is robust
> enough? fast enough? secure enough?

[ Take these $.02 from someone who isn't even a Tomcat committer.  These
  are my thoughts on your question.  PMCers may have defined goals. ]

Typically, Apache projects follow the goal of "correctness first,
performance second."  Since Tomcat is the reference implementation of 
Servlets/JSP, it should focus on implementing all aspects of the spec
correctly.  I believe that if the implementation is correct (provided
you have a solid spec - which I believe is the case here), it goes a 
long way towards providing robustness and security.

You, as the user (or auditor), must place your own judgments on whether
Tomcat is robust enough, fast enough, or even secure enough.  We do not
know your goals.  However, I believe that part of the beauty of Open 
Source is that if it doesn't meet your requirements, you can help out 
and contribute to the project so that it does meet your needs properly.  
That's why you have the source.  Enjoy.  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Wed, Aug 15, 2001 at 08:56:45AM -0400, Keith Wannamaker wrote:
> I am concerned that the loss of original escaping
> will break somebody.  For instance:

As Costin pointed out, the escaping of a URI does not change its
semantics - they should be treated as identical by anyone who follows
the URI spec.  Escaping where it wasn't escaped *shouldn't* break 
anyone.  

And, the whole question is what does Tomcat see the request as?  I 
could make a case that it should never know about the unparsed_uri, 
but only the uri that httpd finally resolved to and that mod_jk 
picked up.  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Tue, Aug 14, 2001 at 11:13:34PM -0400, Keith Wannamaker wrote:
> Costin's right.. seems like the problem encountered
> was that there was no way to recreate the encoding 
> (or lack thereof) on the original uri.  So the
> kludge/solution was to use the unparsed uri and 
> chop off the query string.

mod_jk chops off the r->unparsed_uri itself without copying.  Negative
points for style.  =-)  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Tue, Aug 14, 2001 at 08:12:31PM -0700, [EMAIL PROTECTED] wrote:
> On Tue, 14 Aug 2001, Justin Erenkrantz wrote:
> 
> > Which, of course, is the right solution.
> 
> Is it ? Re-escaping the URI will most likely generate something very
> different from the original, it's not symetrical. Getting a re-escaped
> request is different from "the original, unescaped" uri. That's the reason
> we use the unescaped uri...

Potentially, you are correct.  It may not be symmetrical.  However, 
httpd may jump in and rewrite the uri for you.  If that is a problem
(which is what the original poster was complaining about), then you
need to use r->uri instead and escape it.  Unless you want to only
pass the original string NOT what the server is serving.

I'm not sure what the Servlet spec says - use the original string 
that the client passed in, or use the "real" URI.  I'm out of my 
depth here.  *shrug*  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Wed, Aug 15, 2001 at 03:41:30AM +0100, Pier P. Fumagalli wrote:
> Justin Erenkrantz at [EMAIL PROTECTED] wrote:
> > 
> > I wonder how Pier is addressing this in mod_webapp.  I'll have to
> > look.  -- justin
> 
> Easy as 1.2.3... WARP has a concept of URI and QUERY STRING... Very separate
> things... All I do is
> 
> req->ruri=apr_pstrdup(req->pool,r->uri);
> req->args=apr_pstrdup(req->pool,r->args);
> 
> The URI goes into the URI, the query string goes into the query string...
> Apache does it for me, why should I bother? :)

Which, of course, is the right solution.  

But, do you have to (re)escape the uri (or, is that done in Java 
land?)?  Seems like the 2.2 spec says that the getRequestURI() 
function must return an escaped URI.  r->uri is unescaped.  Or, does 
2.3 say something different?  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Tue, Aug 14, 2001 at 07:25:32PM -0700, David Rees wrote:
> On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote:
> >
> > Unfortunately there are people who were breaking because
> > we didn't follow the spec.  The better way to fix it is
> > to create an inverse function for 
> > ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c]
> > in mod_jk... one that would 'unparse' the munged
> > r->uri rewrite and use it instead of r->unparsed_uri.
> 
> Hi,
> 
> OK, are you volunteering to write it?  ;-)  If not, I'll have to take a look
> when I get some time and see if I can figure it out.
> 
> As an aside, it appears that Tomcat 3.3 remains broken in this regard, as it
> uses r->uri instead of r->unparsed_uri.

My bad.  It is actually easier than I just said - s->req_uri isn't
the complete unparsed URI - just the path.

I didn't look high enough in mod_jk.c.  The version in j-t-c for 
apache-1.3 has:

s->query_string = r->args;

/*
 * The 2.2 servlet spec errata says the uri from
 * HttpServletRequest.getRequestURI() should remain encoded.
 * [http://java.sun.com/products/servlet/errata_042700.html]
 */
s->req_uri  = r->unparsed_uri;
if (s->req_uri != NULL) {
char *query_str = strchr(s->req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}

That strchr call is trying to remove the query string (dicking with
the unparsed_uri like that is a BAD idea - imagine logs looking at the
unparsed_uri).  

You could just have:

s->query_string = r->args;
/*
 * The 2.2 servlet spec errata says the uri from
 * HttpServletRequest.getRequestURI() should remain encoded.
 * [http://java.sun.com/products/servlet/errata_042700.html]
 */
s->req_uri  = ap_encode_uri(r->pool, r->uri);

That seems like it'd satisfy everyone.  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Tue, Aug 14, 2001 at 10:20:26PM -0400, Keith Wannamaker wrote:
> Hi David,
> 
> Unfortunately there are people who were breaking because
> we didn't follow the spec.  The better way to fix it is
> to create an inverse function for 
> ap_parse_uri(request_rec *r, const char *uri) [http_protocol.c]
> in mod_jk... one that would 'unparse' the munged
> r->uri rewrite and use it instead of r->unparsed_uri.

You *could* just call ap_escape_uri and try to recreate the relevant
pieces.  Rough pseudocode:

t1 = ap_escape_uri(r->uri)
t2 = ap_escape_uri(r->args)
mod_jk's->uri = strcat(r->uri, "?", r->args, NULL)

The root problem is that r->unparsed_uri and r->uri may not be 
identical in their context.  If you are using mod_rewrite, you could 
have:

r->unparsed_uri="/foo.jsp?bar=baz"
r->uri="/spaz.jsp"
r->args="bar=baz"

But, now you may have escaped something that wasn't originally escaped.
That may be bad as well.  -- justin

Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

[Justin Erenkrantz]

On Tue, Aug 14, 2001 at 06:13:24PM -0700, David Rees wrote:
> --- mod_jk.c.orig   Tue Aug 14 17:58:21 2001
> +++ mod_jk.cTue Aug 14 18:04:58 2001
> @@ -358,7 +358,7 @@
>  s->method   = (char *)r->method;
>  s->content_length = get_content_length(r);
>  s->query_string = r->args;
> -s->req_uri  = r->unparsed_uri;
> +s->req_uri  = r->uri;
>  if (s->req_uri != NULL) {
> char *query_str = strchr(s->req_uri, '?');
> if (query_str != NULL) {
> 
> After this change my URLs were getting rewritten as expected again.
> 
> Can we apply this change to the tree if there's nothing wrong with it for
> the next release?  This problem has affected a large number of users, just
> take a look at the tomcat-dev/user archives.

This breaks query strings.

r->uri contains only the path portion of the URL.  r->unparsed_uri
contains the URL in its "virgin" format - as sent by the client.

You can see that mod_jk is looking for the query string (look at the
strchr two lines down) - it won't be there in the r->uri.  You now
need to modify mod_jk to look at r->args.  

But, if you need access to the encoded URI (which is what the comment
above that line in the j-t-c version of mod_jk seems to indicate), the 
only way to do it in httpd is to do with unparsed_uri.  All of the 
other parameters (i.e. r->uri) have been escaped already.  

I'm not sure what the solution is.  But, this one kills off query 
strings to servlets.  That's even worse than losing internal rewrite 
capabilities.

I wonder how Pier is addressing this in mod_webapp.  I'll have to 
look.  -- justin

Re: [Fwd: GTest in watchdog fails with Apache...]

[Justin Erenkrantz]

On Mon, Aug 06, 2001 at 05:25:03PM +0100, Pier P. Fumagalli wrote:
> Justin Erenkrantz at [EMAIL PROTECTED] wrote:
> 
> > On Mon, Aug 06, 2001 at 11:17:18AM +0200, jean-frederic clere wrote:
> >> I have tested it with 1.3.20 it behaves the same way.
> > 
> > This is correct behavior on httpd's part.  It is a bug in Tomcat
> > (rather the Watchdog test).
> > 
> > The server should respond with the highest HTTP version it
> > supports.  Somewhere in the RFC is the rules for how to determine
> > whether it should be upgraded or not (it must still be parsable by
> > the original request version).  Roy or someone else can jump in here
> > if they want to discuss that vagaries of upgrading the response
> > version, but this is expected behavior.  -- justin
> 
> I can't find this written anywhere in the HTTP spec (rfc 2616). Section 6.1
> describes how the first line of an HTTP response is composed, but it doesn't
> say anything about the version number to be used.
> 
> I can assume (by some observations made on what's going on between my client
> (OmniWeb PRO 4.01 for OS/X) and Apache, that the client posts a request as
> HTTP/1.0, if the response is HTTP/1.1, then all following requests will be
> made with the upgraded protocol version...
> 
> But actually the spec (as far as I can see from a brief re-reading) doesn't
> specify anything about it...

Let the spec war begin.  =-)

RFC 2616 - Section 3.1 - HTTP Version:

   The HTTP version of an application is the highest HTTP version for
   which the application is at least conditionally compliant.

RFC 2145 goes into specific detail about this problem (what to send)
- see Section 2.3:
---

   An HTTP client SHOULD send a request version equal to the highest
version for which the client is at least conditionally compliant, and
whose major version is no higher than the highest version supported
by the server, if this is known.  An HTTP client MUST NOT send a
version for which it is not at least conditionally compliant.

An HTTP client MAY send a lower request version, if it is known that
the server incorrectly implements the HTTP specification, but only
after the client has determined that the server is actually buggy.

An HTTP server SHOULD send a response version equal to the highest
version for which the server is at least conditionally compliant, and
whose major version is less than or equal to the one received in the
request.  An HTTP server MUST NOT send a version for which it is not
at least conditionally compliant.  A server MAY send a 505 (HTTP
Version Not Supported) response if cannot send a response using the
major version used in the client's request.

---

Of course, I could be misunderstanding it all.  But, the chances of
httpd's HTTP parser being incorrect w.r.t. the spec or the intent of 
the authors is very very slim.  FWIW, IIS and iPlanet both behave 
identically to Apache (try out microsoft.com and netscape.com).

I'll now get out of the way to make room for the spec police.  -- justin

Re: Problems Compiling mod_webapp and APR on Solaris

[Justin Erenkrantz]

[ CCing dev@apr ]

On Wed, Jul 25, 2001 at 03:56:58PM +0100, Pier P. Fumagalli wrote:
> Klaus Sonnenleiter at [EMAIL PROTECTED] wrote:
> 
> > Has anybody successfully compiled mod_webapp and/or the APR library on
> > Solaris? I was able to compile everything without any trouble on a RedHat
> > 7.1 system. But when I tried the same version of the sources (tonight's
> > CVS) on Solaris, it failed miserably (some output below). The errors seem
> > to be related to the APR library and I've tried to use a more recent one
> > which compiles without problems, but it creates conflicts when compiling
> > the mod_webapp module (it requires a different number of parameters and I
> > remember from a discussion here that it was considered safer to stay with
> > the older library).
> > 
> > TIA
> > 
> > -- snip -
> > 
> > Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr...
> > make[1]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
> > Making all in strings
> > make[2]: Entering directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[3]: Entering directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent
> > --mode
> > =compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7 -D_POSIX_PTHREAD_SEMANTICS
> > -D_REENT
> > RANT   -I../include -I../include/arch/unix  -c apr_cpystrn.c && touch
> > apr_cpystrn.lo
> > In file included from apr_cpystrn.c:55:
> > ../include/apr.h:187: #error Can not determine the proper size for apr_int64_t
> > ../include/apr.h:242: #error Can not determine the proper size for ssize_t
> > ../include/apr.h:245: #error Can not determine the proper size for size_t
> > ../include/apr.h:254: #error Can not determine the proper size for apr_int64_t
> > make[3]: *** [apr_cpystrn.lo] Error 1
> > make[3]: Leaving directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
> > make: *** [apr-all] Error 2
> 
> What version of APR does generate this error?
> 
> > Compiling sources in /home/klaus/jakarta-tomcat-connectors/webapp/apr...
> > make[1]: Entering directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
> > Making all in strings
> > make[2]: Entering directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[3]: Entering directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > /bin/sh /home/klaus/jakarta-tomcat-connectors/webapp/apr/libtool --silent
> > --mode=compile gcc-DHAVE_CONFIG_H -DSOLARIS2=7
> > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT   -I../include
> > -I../include/arch/unix  -c apr_cpystrn.c && touch apr_cpystrn.lo
> > In file included from apr_cpystrn.c:64:
> > /usr/include/string.h:43: warning: conflicting types for built-in function
> > `memcpy'
> > /usr/include/string.h:45: warning: conflicting types for built-in function
> > `strcpy'
> > /usr/include/string.h:51: warning: conflicting types for built-in function
> > `memcmp'
> > /usr/include/string.h:52: warning: conflicting types for built-in function
> > `strcmp'
> > apr_cpystrn.c:84: conflicting types for `apr_cpystrn'
> > ../include/apr_strings.h:203: previous declaration of `apr_cpystrn'
> > apr_cpystrn.c:126: conflicting types for `apr_tokenize_to_argv'
> > ../include/apr_strings.h:224: previous declaration of `apr_tokenize_to_argv'
> > apr_cpystrn.c:235: conflicting types for `apr_collapse_spaces'
> > ../include/apr_strings.h:212: previous declaration of `apr_collapse_spaces'
> > make[3]: *** [apr_cpystrn.lo] Error 1
> > make[3]: Leaving directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory
> > `/home/klaus/jakarta-tomcat-connectors/webapp/apr/strings'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/klaus/jakarta-tomcat-connectors/webapp/apr'
> > make: *** [apr-all] Error 2
> 
> And this?
> 
> Did you try with the "safe" sources of APR I posted on
> http://www.apache.org/~pier/

FWIW, I'm definitely not seeing these sorts of errors on Solaris 
or Linux.  Odd.  This is with an updated (as of last night or this
morning) CVS copy of APR?

Did you use the same sources for building with Linux and Solaris?
"make clean" was run?  These errors just don't make any sense.  
-- justin

Re: [TC4.0] Disabling debug output...

[Justin Erenkrantz]

On Thu, Jul 19, 2001 at 12:16:27AM +0100, Pier P. Fumagalli wrote:
> Checking out the source code, I see a lot of // (commented out lines) when
> debug() is supposed to be called...
> Can't we have a global constant boolean called DEBUG and replace the // with
> if (DEBUG), so that we can simply compile in and out the debugging
> information without touching the sources?
> 
> Check out org.apache.catalina.connector.warp.Constants and WarpLogger... Old
> trick we used in JServ. :)

I *believe* most Java compilers do not have constant conditional 
optimizations (they certainly could, but I don't think they did last
time I checked).  Without that optimization, you must check that 
value each time you execute the statement.  That might hurt.  -- justin

Re: mod_webapp

[Justin Erenkrantz]

On Wed, Jul 18, 2001 at 06:29:31PM +0200, jean-frederic clere wrote:
> I would advise to use a tagged version of APR in mod_webapp. Using the lastest
> one is/was not a good idea.
> 
> I am using the APR tagged "APACHE_2_0_20" for testing mod_webapp and it compiles
> Ok at least on 2 of test plateforms I use. (ReliantUnix and Linux).

Keep in mind that we're still changing stuff around and we're not 
keeping backwards compatibility with anything because we haven't 
officially released APR.  So, if you use an older tagged version for 
a while, you'll get stuck with a bunch of updates all at once that 
may not make any sense.  

Furthermore, this whole inherit thing wasn't the most thought-out 
patch we've committed into APR.  I think we have a solution that is 
better and reverts us back to the old API.  Bear with us.  =)  
-- justin

Re: mod_webapp

[Justin Erenkrantz]

On Wed, Jul 18, 2001 at 04:43:57PM +0100, Pier P. Fumagalli wrote:
> I have an old pre-sms version of APR I'm using, and it seems it's working on
> most platforms "as-is"... I might ask the APR guys to tag it with
> "MOD_WEBAPP_1_0", or redistribute it in a nice tarball...

Ha!  -- justin

Re: mod_webapp

[Justin Erenkrantz]

On Wed, Jul 18, 2001 at 05:28:25PM +0200, jean-frederic clere wrote:
> The CVS I have does not compile because apr_socket_create()... It misses the
> inherit parameter!
> APR has added it to the apr_socket_create(). Should I fix it or just tell we
> need a tagged APR (like APACHE_2_0_20).

I think it may get reverted back.  Dean just vetoed this (well, rather,
he said, "I object.").  There is a series of +1s to taking it back out
and making the inherit call explicit.  -- justin

Re: FW: latest cvs checkout test

[Justin Erenkrantz]

On Mon, Jul 16, 2001 at 06:34:48PM +0100, Pier P. Fumagalli wrote:
> I just tried it on Nagoya, and it does the same for me...
> Do someone has _ANY_ clue of WTF is going on

Yeah, I've seen this before (Solaris, too).  I had to add -lgcc.  
Don't ask me why the linker didn't pick up on that automagically.
I never took the time to figure out why I had to do it.  I'd
be curious to find out why though.  -- justin

> -- Forwarded Message
> From: "Brian P. Millett" <[EMAIL PROTECTED]>
> Date: Mon, 16 Jul 2001 12:34:48 -0500
> To: Pier Fumagalli <[EMAIL PROTECTED]>
> Subject: latest cvs checkout test
> 
> Hi Pier,
> Here are my results from the latest cvs checkout and build:
> 
> (Solaris 8, x86; gcc version 2.95.2; java version "1.4.0-beta"; apache
> 1.3.20)
> 
> Steps:
> 1)rm -rf jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 2) cvs co jakarta-servletapi-4 jakarta-tomcat-4.0
> jakarta-tomcat-connectors
> 3) cd jakarta-tomcat-connectors/webapp; cvs co apr
> 4) cd jakarta-servletapi-4; ./build.sh dist (and install)
> 5) cd jakarta-tomcat-4.0; ./build.sh dist (and install)
> 6) cd jakarta-tomcat-connectors/webapp
> 7) sh support/buildconf.sh
> 8) ./configure --with-apxs=/opt/apache/bin/apxs
> 9) cp apache-1.3/mod_webapp.so /opt/apache/libexec/
> 10) /etc/init.d/tomcatctl start
> 11) /etc/init.d/apachectll start
> 
> Cannot load /opt/apache/libexec/mod_webapp.so into server:
> ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file
> /opt/apache/libexec/mod_webapp.so: symbol __divdi3: referenced symbol
> not found
> /opt/apache/bin/apachectl start: httpd could not be started
> 
> Otherwise, it looks OK.  The __divdi3 symbol is found in libgcc.a
> 
> /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/libgcc.a[_divdi3.o]:
> 
> [Index]   Value  SizeType  Bind  Other Shndx   Name
> 
> [2] | 0|   0|SECT |LOCL |0|2  |
> [3] | 0|   0|SECT |LOCL |0|3  |
> [4] | 0|   0|SECT |LOCL |0|4  |
> [5] | 0|   0|SECT |LOCL |0|5  |
> [7] | 0|   0|SECT |LOCL |0|6  |
> [6] | 0| 256|OBJT |LOCL |0|5  |__clz_tab
> [8] | 0| 414|FUNC |GLOB |0|2  |__divdi3
> [1] | 0|   0|FILE |LOCL |0|ABS|libgcc2.c
> 
> 
> Is that being referenced in apr?  If so, why?  Or is my gcc installation
> broke?
> 
> Take care.
> 
> --
> Brian Millett
> Enterprise Consulting Group "Shifts in paradigms
> (314) 205-9030 often cause nose bleeds."
> [EMAIL PROTECTED]   Greg Glenn
> 
> 
> -- End of Forwarded Message

Re: [DOC] TOC - thoughts

[Justin Erenkrantz]

On Mon, Jul 16, 2001 at 12:21:55PM +0200, jean-frederic clere wrote:
> > I had to work around some issues with that OS myself writing the Service
> > code, and definitely, I wouldn't trust that "thing" not even to drive my
> > coffee pot, but, of course, that's me. Get a decent and "real" OS, don't
> > fight with those issues (Solaris 8 on x86 is far better, IMVHO, and it's
> > downloadable for free... S...)
> 
> But do you get the sources with it? ;-(?

http://www.sun.com/software/solaris/source/

I'm with Pier on this.  Solaris 8/Intel is awfully nice.  -- justin

Re: Somebody get me off this List PLEASE!!!!!!!!!!!!!!!!

[Justin Erenkrantz]

On Thu, Jul 05, 2001 at 06:10:42PM +0100, Andy Armstrong wrote:
> "Swart, James (Jim) ** CTR **" wrote:
> > 
> > why is it everyone has such a hard time getting off this list?  Someone put
> > me in charge of getting people off the jarkata maillists, I'll make sure
> > it's done to ensure these floods of "get me off here" is done... Sound good?
> 
> Can't it be automated? What are the lists running on?

Apache.org is using ezmlm.  The problem is when users don't confirm the
unsubscription or send it from the wrong address.  It is automated, but
it isn't idiot-proof.

It'd be nice to have a human moderator who reads tomcat-dev and can 
manually take people off the list when they start to complain on-list.  
-- justin

Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]

[Justin Erenkrantz]

On Mon, Jul 02, 2001 at 07:38:55PM -0700, Si Ly wrote:
> I submitted a very simple patch last week, and I haven't heard from
> anyone about it.  It seems to me that "outsiders" (non-committers)
> can't get anything into CVS because the committers are not looking at
> the patches, for whatever reasons.
> 
> Or maybe it's because there are problems with the patches?  Even if
> that's the case, a response would still be appreciated.  Otherwise,
> what encouragement is there for future submissions?

FWIW, if at first you don't succeed in getting a reply, repost your 
patch.  

I typically wait about a week in between submissions.  

After about the third week, I usually drop the patch if no one has
responded.  =)  

And, please don't take non-responsiveness personally.  It is probably
more the case that the people with commit access don't believe that your
problem is worth fixing.  You'll need to make a convincing argument to
stop them from hitting the "delete" key when reading the message.
-- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Mon, Jul 02, 2001 at 06:09:44PM +0200, GOMEZ Henri wrote:
> >Realistically though, APR is fairly stable API-wise.  There *are* 
> >going to be some minor changes and tweaks along the way.  But, they 
> >should all be for the better (like the util_date migration).
> 
> I'm confident that APR is stable, but what we need is a RELEASE.

Hmm, I wonder if we should do a T&R with APR to give a "release"
that is separate from httpd-2.0.  I don't see any reason why we 
couldn't do this.  I just have no clue how to do the T&R.  My
understanding is that anyone with commit privs can do that.
I'll look into it though.

BUT, I think that the precedent with the APR-using projects is to
require a source checkout.  Subversion and httpd-2.0 both require 
the current CVS version of APR.  This allows APR to not have to 
maintain backward compatibility with "previous" releases (not
that we would anyway).

> >And, I guess, my point is that we should start that transition now.
> >Start to write a mod_jk that is built around APR.  By the time 
> >that is done, Apache 2.0 may even be release candidate.  Or not.  
> 
> What about working an APR wrapper ? ie something which wrap OS calls
> to APR or native calls ? And make mod_jk call wrapper functions ?

I think that defeats the purpose of APR.  If APR isn't doing it right,
then APR needs to be fixed.  APR should definitely support any platforms
that you are concerned about (i.e. Win32, etc.).  Which, of course, 
means that httpd-2.0 will run on those platforms as well.

The idea is that APR would better support these platforms than rewriting
the same code in mod_jk.  And, ideally, if you build around APR, you
will simplify the build process because APR will figure out all the OS
trickiness for you.

> But even APR will only cover OS calls, and didn't solve the problems of
> linking with web-server differents from Apache (IIS/iPlanet/Domino...)

Correct, but the core jk components could still be built around APR.  
And, I imagine that the problem of other webservers has to do more with 
their specific OS than the web server (i.e. linking in APR).

And, hopefully, I'll have time at some point to actually back up what I
am saying with code.  I've just got a bazillion other things on my plate
right now.  =)  -- justin aka "APR evangelist"

Re: problem with mod_webapp

[Justin Erenkrantz]

On Mon, Jul 02, 2001 at 10:29:39AM +0200, GOMEZ Henri wrote:
> APR will be the future, but it still in changing state.
> Do you want to works on a moving API ? 
> We need a release and binary builds for majors OS

When I have commit access to APR, yeah, I do.  =)  (That change to the 
util_date.h is because of me - actually, I think that you should just
assume that they have the latest build of Apache 2.0 if they are using
Apache 2.0 - it is still "beta" and I use that term loosely...)

Realistically though, APR is fairly stable API-wise.  There *are* 
going to be some minor changes and tweaks along the way.  But, they 
should all be for the better (like the util_date migration).

> My opinion, and I like to see others J-T-C users/developpers is
> that we could use APR in mo_jk when it will more stable and
> allready installed in web-server. So APR/MOD_JK will be fine
> when will start the move from Apache 1.3 to Apache 2.0.
> 
> At that time we'll have a release of THAT APR and have
> it on others platforms supported by mod_jk, IIS, iPlanet, 
> Netware, Windows..

And, I guess, my point is that we should start that transition now.
Start to write a mod_jk that is built around APR.  By the time 
that is done, Apache 2.0 may even be release candidate.  Or not.  
-- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Sun, Jul 01, 2001 at 04:30:55PM -0400, Donald Ball wrote:
> so is there still interest in a patch for the mod_webapp docs or has focus
> been shifted over to mod_jk?

I'd like to see a patch, but that's me.  =)  Pier probably can tell you
what he's doing with mod_webapp.  I'm not a fan of mod_jk, but if
Costin's proposals for mod_jk with ajp14 configuration simplification 
come through, I might very well change my mind.  

I don't have commit access, so I don't really matter... -- justin

Re: how can i be a developer for the tomcat project..?

[Justin Erenkrantz]

On Sat, Jun 30, 2001 at 11:13:24PM +0100, hiten pandya wrote:
> hi everyone...
> 
> hope everyones is fine,
> 
> i have downloaded the latest copy of the tomcat server from the cvs 
> repository,

Please see:

http://jakarta.apache.org/site/getinvolved.html
http://jakarta.apache.org/site/source.html

You can submit patches (see the second link) to this list and people 
with commit access will commit them if they feel that the patch is 
worth committing.

Typically, people obtain commit access to ASF projects after providing 
improvements and patches over a period of time to the project.

HTH.  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Fri, Jun 29, 2001 at 06:38:34PM -0700, [EMAIL PROTECTED] wrote:
> Please don't take this personally - I put some (free) time into
> this, and if I don't like your solution doesn't mean I consider you an
> "idiot" ( or that I'll not use the same solution, as it's considerably
> easier to implement :-)
> 
> I spent a whole night reading the mod_webapp sources and trying to
> understand how this magic autoconfiguration works. There is a big interest
> in simpler configuration for apache+tomcat, and your code was the first
> place to look for something that can be merged into mod_jk. 

One thing that mod_webapp has going for it is that it is based on APR
(this makes the webapp code much simpler).  In my experience with 
mod_jk, I've always had problems getting the right defines for my 
platform (as there is no configure script - somehow, I remember J.F. 
Clere adding some stuff to j-t-c).  But, I think that for native 
platform code, you'll get a big win by using APR.

The problem with APR is that you need to have a coherent strategy for 
using it.  APR works, but it is still rough (esp. with "installed" 
APR).  As discussed on dev@apr (think tomcat-dev was CCed), the two 
main projects that use APR (Subversion and httpd-2.0) both rely on 
the source - not the installed version of APR.  Not to say that using
the installed version is impossible, but just that no one else has
really done this yet.

I just ran into a problem with mod_jk from TC 3.2 where it wasn't
dealing with the socket code correctly (this was fixed in 3.2.2, FWIW).
It just seems that APR could allow the j-t-c folks to not worry about
some lower-level stuff AND you get immediate cross-platform
functionality of any code that you write.  IMHO, that can't be 
underestimated.  Let APR handle all of the odd OS stuff and focus on
what it is that you are trying to do.  You'll end up with better code
all around.

My $.02 as an APR zealot.  -- justin

Re: [Tomcat Documentation Redactors To Hire] - WAS: TOMCAT SUCKS

[Justin Erenkrantz]

On Fri, Jun 29, 2001 at 09:41:52AM +0200, GOMEZ Henri wrote:
> So who will be interested in working on the Tomcat Documentation ?

I'd be willing to proofread and validate any docs for the j-t-c (i.e.
Apache/Tomcat integration).  I don't have time to actually write the
docs, but I could conceivably help those who don't understand how it 
works, but do have the time and patience to learn it and write docs
for it.  

Anyone who is interested, just drop me a line.

Writing end-user documentation is a good way of finding holes in a 
design that may not be obvious from the code itself.  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Thu, Jun 28, 2001 at 11:21:52PM -0400, Donald Ball wrote:
> i care very much about mod_webapp. er, well, to be more clear, i care very
> much about having an apache-tomcat connector module that doesn't require
> me to put the same configuration data in two completely different places.
> i presume mod_webapp is the only component trying to tackle that job, but
> if there are others, i'm all ears.

As I see it, that is the big user difference.  But, I'm not familiar 
enough with the underlying protocols (warp v. ajp) to tell you from the
network level how different they are.  I could be wrong here.

> anyway, i just ran some benchmarks and mod_webapp hasn't choked once, but
> it is significantly slower than tomcat standalone. for 100 requests at
> concurrency 10, it typically takes apache+tomcat 45 seconds, while tomcat
> gets through at about 30 seconds. logging could account for some of this,
> as mod_webapp and/or the java warp connector seem to be very verbose.
> nonetheless, do others experience this?

Tomcat's HTTP standalone connector isn't very good at parsing HTTP
(but, I know the HTTP protocol too well to know where the pitfalls are).  
IMHO, Tomcat shouldn't be allowed to be a web server on its own.  It 
needs a connector in front of it.  So, just from a standards compliance
standpoint, Tomcat's HTTP connector has major issues with it.  ASF has a
very fine Web server available, so Tomcat doesn't need to be a HTTP 
server.

And, yes, mod_webapp is WAY too verbose.  I hope that will be 
addressed soon (or I'll submit a patch to do so when I can get around 
to it).  The other advantage of using mod_webapp (or mod_jk) is that 
you can now serve static pages from Apache which should blow away 
Tomcat w.r.t. speed.  My bet is that Pier has just focused on 
functionality, not tuning the Warp code for performance.

> oh, also, i ran into an OutOfMemory error when i really slammed the
> server. i hadn't experienced that before with tomcat standalone. could
> there be a memory leak in the WarpConnector code? has anyone else run into
> this?

Hmm, I haven't seen anything, but I also haven't done massive load tests
on it.  I thought Java wasn't supposed to have memory leaks?  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Fri, Jun 29, 2001 at 03:49:15AM +0100, Pier P. Fumagalli wrote:
> I've checked out actually in detail what APR does for building itself, and a
> lot of resourceful information can be found also in build/rules.mk, that
> gets generated by the APR configure script... I believe that using that an
> APRVAR we could keep the webapp configure script to a minimum, and work from
> what actually APR provides us...

APR's build process is a lot better since Roy cleaned it up.  So, it
might be good to rethink how you build webapp since those changes.  It
is really nice now.  (apr-util needs to be cleaned up, but it shouldn't
be that bad.)  Again, we don't get a lot of feedback from other projects
that use APR (I don't track subversion), so any improvements are
welcomed.  There might be gaps that we haven't thought of yet.

> I'm still pretty concerned by the extensive use of LibTool in APR, but I
> believe that actually tying up more closely the build process to the APR one
> wouldn't be so bad...

It saves us so much effort on configuring that libtool is really, really
worth it.  I think there are a few platforms where libtool isn't
supported, but I think there is aplibtool.c flying around that
mimics libtool for platforms that aren't supported.  Again, I think that
using APR from source just makes a lot more sense.  Don't make it harder
than it has to be.

> BTW, thanks Justyn for the number of hints you're posting today, it's
> finally nice to see someone giving some "technical" advices to the whole
> webapp stuff (I thought I was completely alone on this)... Keep doing it! :)

I'll try to keep posting where I think I might have something to say.
I was building mod_webapp a few days ago, so I ran into the same things
that Don was running into.  If I can help others, it's worth it.  =)
-- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Fri, Jun 29, 2001 at 03:03:47AM +0100, Pier P. Fumagalli wrote:
> Justin Erenkrantz at [EMAIL PROTECTED] wrote:
> > 
> > Yup, that's what httpd-2.0 does.  Just require them to slap the apr
> > sources in srclib (or something like that).
> 
> We don't have to stick it into the CVS, but we can have a "make srcdist"
> target that builds up a tarball with all sources (including APR). That could
> definitely work, and add some developer related documentation on how to
> build straight out from CVS...
> 
> > APR isn't standalone just yet.
> 
> But it works _great_...

I was rather pointing out that you were relying on "installing" APR.
I don't think we've ever actually tried installing APR standalone
because the main driving force is httpd-2.0, which relies on APR being
in source form.  =)

We could certainly get it to work better after an "install," but at
least from the httpd-2.0 side, we haven't focused on that too much.

Any hints here would be appreciated.  When I built mod_webapp, I hacked
the Makefiles to use my local source copy of APR.  I also managed to
build a static mod_webapp.  Very useful for debugging.  Once you've
cleaned the build up for mod_webapp, I can try finagling a patch to
submit that will allow mod_webapp to be compiled into one .a file that
can then be thrown into Apache.  

I'll also prolly write an apache-2.0 module for webapp based on what
you have.  (mod_webapp really deserves to run under httpd-2.0 because 
of the APR usage.)  However, I'm going to be sidetracked by the APR
pools for a little bit (see my recent dev@apr posts).  -- justin

Re: problem with mod_webapp (fwd)

[Justin Erenkrantz]

On Thu, Jun 28, 2001 at 10:07:57PM -0400, Donald Ball wrote:
> hate to be plaintive, but i'd really appreciate any suggestions y'all
> would have to offer on this. so close, and yet...

As Pier said, just add ServerName.

Be nice if you took all of this info and submitted a patch for the docs.
I'd bet someone would commit it.  I know Aaron Bannert submitted a patch
for j-t-c to help installation, but no one committed it.  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Fri, Jun 29, 2001 at 02:31:50AM +0100, Pier P. Fumagalli wrote:
> Pier P. Fumagalli at [EMAIL PROTECTED] wrote:
> 
> > Justin Erenkrantz at [EMAIL PROTECTED] wrote:
> > 
> >> On Thu, Jun 28, 2001 at 05:09:31PM -0400, Donald Ball wrote:
> >>> strange, libapr seems to include libmm, but i went ahead and built and
> >>> installed libmm seperately in /usr/local/lib. okay, geez, now i get this
> >>> error:
> >> 
> >> It includes it, but mod_webapp doesn't link it.  It seems that Pier is
> >> whipping up a new process for mod_webapp that fixes this.  Cool.
> > 
> > Oh, just found out about the existance of APR_VARS, I heard about it, but
> > was never able to spot it... (yeah yeah, I'm dumb, what-EVER! :)
> 
> What if (random thoughts coming out now), instead of requiring people to
> build APR (since that seems the biggest source of problems), we don't simply
> ask them where the tarball is, and then in our configure script, we
> configure it, and then build it together while building the module...
> 
> In that way we won't have troubles with previous APR installations/builds,
> we _know_ what we're going to supply to the APR configure script and we
> solve all those troubles?

Yup, that's what httpd-2.0 does.  Just require them to slap the apr
sources in srclib (or something like that).

APR isn't standalone just yet.  I was shocked when I saw that
mod_webapp required an install of APR.  =)  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Thu, Jun 28, 2001 at 05:09:31PM -0400, Donald Ball wrote:
> strange, libapr seems to include libmm, but i went ahead and built and
> installed libmm seperately in /usr/local/lib. okay, geez, now i get this
> error:

It includes it, but mod_webapp doesn't link it.  It seems that Pier is
whipping up a new process for mod_webapp that fixes this.  Cool.

> [root@chngw apache]# apachectl configtest
> Syntax error on line 42 of /usr/local/apache/conf/httpd.conf:
> Cannot add module via name 'webapp_module': not in list of loaded modules
> 
> httpd.conf contains:
> 
> LoadModule webapp_module libexec/mod_webapp.so
> AddModule webapp_module

AddModule mod_webapp.c
-- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

On Thu, Jun 28, 2001 at 04:52:01PM -0400, Donald Ball wrote:
> On Thu, 28 Jun 2001, Justin Erenkrantz wrote:
> 
> > You need to link against MM (static) to your compilation.  See
> > apr/shmem/unix/mm/.libs/libmm.a.  mod_webapp should be taking
> > advantage of APRVARS (which has this information).  It doesn't
> > seem to be doing so.  -- justin
> 
> pardon my ignorance, what should be statically linked? mod_webapp.so?
> libwebapp.a? do you have a sample apxs or gcc invokation that i could
> follow?

You should be able to add 

"-L/path/to/apr/shmem/unix/mm/.libs -lmm"

to your apxs -c command line (after mod_webapp.c, if I recall the 
link order correctly).  This tells the compiler to include the MM
library - which you aren't including.  -- justin

Re: problem with mod_webapp

[Justin Erenkrantz]

You need to link against MM (static) to your compilation.  See 
apr/shmem/unix/mm/.libs/libmm.a.  mod_webapp should be taking
advantage of APRVARS (which has this information).  It doesn't 
seem to be doing so.  -- justin

On Thu, Jun 28, 2001 at 04:26:10PM -0400, Donald Ball wrote:
> On Thu, 28 Jun 2001, kevin seguin wrote:
> 
> > use a non-threaded apr with apache 1.3.
> 
> thanks. i built apr with --disable-threads and now i get this:
> 
> [root@chngw apr]# apachectl configtest
> Syntax error on line 41 of /usr/local/apache/conf/httpd.conf:
> Cannot load /usr/local/apache/libexec/mod_webapp.so into server:
> /usr/local/lib/libapr.so.0: undefined symbol: mm_create
> 
> any additional helpful suggestions?
> 
> - donald

Re: [jtc] tabs policy??

[Justin Erenkrantz]

On Sun, Jun 24, 2001 at 08:52:03AM -0500, kevin seguin wrote:
> GOMEZ Henri wrote:
> > 
> > I'm using tab = 4 so +1 there.
> > 
> 
> it's important to make the distinction between indent level and number
> of spaces per tab -- they are totally different.  i'm for 4 space indent
> level, tabs set to 8 spaces (the standard).  tabs set to 4 spaces is
> bad.  when some people use 4 space tabs, and some use 8, and there are
> tabs in source code, you're just asking for unreadable code.

That just leads to formatting problems because people don't understand
that.  If you must have tabs, they should be the same as the indention 
level, not some factor of the indention level.  This doesn't have to be 
complicated.  One tab == one indention level.

There is a reason that the Apache standard says "no tabs."  They are
evil.  And, tabs inherently lead to "unreadable code" anyway. 
-- justin

Re: [jtc] tabs policy??

[Justin Erenkrantz]

On Fri, Jun 22, 2001 at 07:17:37PM -0500, kevin seguin wrote:
> so, is there a tabs policy in jakarta?  like the number of spaces per
> tab (4 vs. 8), of no tabs in source code?  i ask because i just got the
> latest jtc source, and when i open up some of the files in emacs (in
> which i have tab width set to 8 spaces), some lines are indented 4
> spaces, and some 8.  what it looks like is someone used an editor with
> tabs configured to be 4 spaces, but insert tab characters rather than
> spaces.  anyway, it's quite unreadable, so that why i ask ;)  (i hope
> this doesn't start a war ;-))

According to the Jakarta site, I believe the Java code goes under:

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Spaces vs. tabs aren't specified, but it says indention of 8.

I'd imagine that the j-t-c code (non-Java code) uses the traditional
Apache style:

http://dev.apache.org/styleguide.html

But, that isn't specified anywhere.

I wish that the Java code used the Apache style.  I find indention of 
8 with hard tabs to be downright awful.  Some of us don't use GUI 
editors.  =)  -- justin

Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?

[Justin Erenkrantz]

On Tue, Jun 19, 2001 at 06:16:15PM +0200, Gomez Henri wrote:
> webapp: mod_webapp/warp protocol (only ajp14)

( Fodder for a STATUS file... )

FWIW, redirects are broken with mod_webapp.  This is due to the fact
that mod_webapp isn't passing enough information to the Java side about
the requested URL (it seems to be only passing in the path - i.e. 
/index.html).  

Warp looks like it needs to know about the scheme, host, port, etc.
This is causing problems in the
javax.servlet.http.HttpUtils.getRequestURL code because there is no
scheme, host, port, etc.  

java.lang.NullPointerException 
at javax.servlet.http.HttpUtils.getRequestURL(HttpUtils.java:338)
at 
org.apache.catalina.connector.HttpResponseBase.toAbsolute(HttpResponseBase.java:669)
at 
org.apache.catalina.connector.HttpResponseBase.sendRedirect(HttpResponseBase.java:1072)
at 
org.apache.catalina.connector.HttpResponseFacade.sendRedirect(HttpResponseFacade.java:150)

I'm thinking that Apache httpd can just pass along all of the URL
information it has.  But, will warp be able to handle it?  So, instead
of passing /index.html, pass http://foo.example.com/index.html as the
URL?

I will try to take a look at this, but if someone with more knowledge 
can take a look at it and beat me to it, I'd appreciate it.  -- justin

Re: [j-t-c] OS poll => [j-t-c] webserver poll

[Justin Erenkrantz]

On Thu, Jun 14, 2001 at 10:28:47AM +0200, GOMEZ Henri wrote:
> mod_jk support Apache 2.0
> 
> And TC 4.0 as preliminary support for ajp13 used
> in mod_jk.
> 
> Could you take a look at it ?

Okay, what's the difference between mod_webapp and mod_jk?  I thought
that mod_webapp was the preferred TC 4.0 connector?  This seems like
this is worthy of a FAQ.  We've still got people using mod_jserv...

Oh, is it that mod_webapp uses the Warp protocol, not ajp13?  Does 
ajp13 support the TC 4.0 hot-deploy functionality?  -- justin

Re: [j-t-c] OS poll => [j-t-c] webserver poll

[Justin Erenkrantz]

On Thu, Jun 14, 2001 at 09:39:58AM +0200, jean-frederic clere wrote:
> I made a first try some months ago and get it started on a non-threaded machine,
> by adding #define APACHE20 but the code has evolved a lot from that time. Should
> I try again in the today code?

If you've got time.  You might not be able to use #ifdef the changes -
you probably want to split it out into another directory.  The module
structs are just too different - it'd be too confusing.  And, 
mod_webapp (depending upon on the webapp library works - haven't looked
at it) should probably be a filter...

As I said, when I have some spare time, I'll try to look at it if no one
else has by then.  But, I don't have commit privs to j-t-c, so you could 
do it a bit more efficiently than I.  =)  -- justin

Re: ICAP servlet classes (was: Tomcat Architecture)

[Justin Erenkrantz]

On Wed, Jun 13, 2001 at 02:34:17PM -0400, Salim Virani wrote:
> Hi Justin,
> 
> I faced a similar problem. I figured I could write my own server/servlet API
> .. which is what I did.
> 
> Just curious  was your implementation in Java ??? And are you working
> for a company or this is some school project ??

We had a client who requested the use of the NetApp NetCache proxies
with ICAP.  We used Apache 1.3 as the base.  We didn't believe that 
Java was scalable enough for our needs (commercial site).  We ended 
up tossing the guts of Apache's protocol engine and came up with one 
that worked only with ICAP.  What Craig just suggested for Tomcat might
work better than what we did with Apache, but we needed high-performance 
- hence C code.  HotSpot only does so much.  =)

Roy Fielding (here at eBuilt) and Don Gillies (at NetApp) had some
interesting exchanges over how to interpret the HTTP spec.  Don 
Gillies' implementation of ICAP in the NetApp boxes was quite buggy 
and awful.  The WG's reference implementation of ICAP is a perl 
script.  And, that script isn't even remotely RFC2616 compliant.
The WG has now dropped all pretenses of making ICAP HTTP-compliant.
The next revision of the ID will have this noted.

If we had to do it all over again, we would never use ICAP.  The idea of
ICAP in and of itself isn't bad, but their implementation has no clue
what it wants to be.

I'd recommend subscribing to the ICAP mailing list
([EMAIL PROTECTED]) if you haven't already.  -- justin

Re: ICAP servlet classes (was: Tomcat Architecture)

[Justin Erenkrantz]

On Wed, Jun 13, 2001 at 08:06:42PM +0200, Fabian Loschek wrote:
> Hello,
> 
> > I would like Tomcat to serve requests for a new Internet Draft Protocol
> > named ICAP. The intension is to develop HTTP like ICAP servlet base classes
> > to allow writing ICAP applications.
> >
> > Can someone give me pointers/references of where can I start ??
> 
> I'm looking for something similar for writing an ICAP Servlet for my
> master thesis, have you gotten hold of any references or code snipplets?

Good luck.  We had to rip out the protocol engine in Apache to get ICAP 
working.  It isn't even remotely HTTP-compliant.

The yahoos on the ICAP WG claim that any HTTP-compliant server will work
with ICAP.  Don't believe them as they've never tried it.  We have.
It's awful.  -- justin

Re: [j-t-c] OS poll => [j-t-c] webserver poll

[Justin Erenkrantz]

On Wed, Jun 13, 2001 at 10:57:16AM +0200, GOMEZ Henri wrote:
> Now which webservers are you using :
> 
> - Apache 1.3  (Apache, Apache/SSL or Apache-mod_ssl)
> - Apache 2.0
> - Domino
> - IIS 4/5/2000
> - JNI 
> - Netscape/IPlanet
>  
> This quick poll will help us know on which direction must be put
> the most effort. I bet for Apache 1.3 on Unix boxes

Yeah, but we should concentrate on getting a mod_webapp functional on
Apache 2.0 (so you can have Tomcat4 with Apache 2.0).  Looking at the 
j-t-c repository, I don't think Apache 2.0 is supported by mod_webapp 
yet.  (BTW, what's the status of hot deploy in mod_webapp for Apache 
1.3?)

Depending upon what I get involved with on the httpd side, I could
spend a few hours trying to get mod_webapp.c ported to Apache 2.0.  
I probably won't be able to look at it for a couple of weeks though.
I can't imagine it'd take more than a few hours.  If you port it to 
using the new filters API, that might take a bit longer.  -- justin

Re: RedHat 7.1 and MOD_WEBAPP anyone?

[Justin Erenkrantz]

[ CCed to dev@apr ]

On Mon, Jun 11, 2001 at 02:32:25PM -0700, Craig R. McClanahan wrote:
> (4) Tested configuration (/etc/rc.d/init.d/apache configtest) and got
> the following error message:
> 
> Syntax error on line 1027 of /usr/local/apache/conf/httpd.conf:
> Cannot load /usr/local/apache/libexec/mod_webapp.so into server:
>   /usr/local/lib/libapr.so.0: undefined symbol: mm_create
> 
> (The line number points at the LoadModule line)

I bet APR isn't copying over the shared MM library.  I think we were
debating whether we are going to toss MM entirely.  Not sure what came
of that.  Nothing in the install target for APR indicates that we'd copy
the MM library.  Oops.  -- justin