RE: Trying New Connectors Build Stuff

[GOMEZ Henri]

I'm pleased to see how the thing moved in mod_webapp since
the jakarta-tomcat-connectors is in CVS and after all the
AJP14 discussion.

Did we'll see another brake in connector side ?


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, May 13, 2001 8:01 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Trying New Connectors Build Stuff
>
>
>kevin seguin at [EMAIL PROTECTED] wrote:
>> 
>>> Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which 
>is the module I'm
>>> writing right now...
>> 
>> so... iis is next, right ;-)
>
>Yes, IIS is next, I just need to install Win2K on my only 
>Intel box I have.
>It's a very old Pentium 366 and I hope I'll be able to get it 
>working with
>MSVC or CygWin (BTW, which one do you prefer, guys?)
>
>Pier
>

RE: [PROPOSAL] jakarta-tomcat-connectors renaming

[GOMEZ Henri]

>
>-1.

>mod_jk isn't the only connector out there ;-)

yes, there is also mod_webapp, mod_jserv.

We discussed last weeks about renaming jk/jk_ stuff
in native code and I worked this week-end in converting 
all jk/jk_ stuff to jtc/jtc_ in native code. 

Why ? To help users having at the same time in their web-server
the jk (actual) and jtc (future).

I was thinking that AJP14 developpement to be conducted in 
mod_jtc instead of mod_jk but I'm not sure now ?

>If you have that kind of directory structure, the source for all the
>connectors will get all mixed up.
>So it should be jakarta-tomcat-connectors/mod_jk/src/native/apache1.3/

Kevin put it under :

jakarta-tomcat-connectors/jk/

The native code will be so in 

jakarta-tomcat-connectors/jk/src/native/apache1.3/
jakarta-tomcat-connectors/jk/src/native/apache2.0/
jakarta-tomcat-connectors/jk/src/native/common/

RE: Trying New Connectors Build Stuff

[GOMEZ Henri]

Will you also Jon, contribute to jakarta-tomcat-connectors ?

You were invited with Pier last week and there is still no
anwsers :)


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jon Stevens [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, May 13, 2001 10:07 PM
>To: tomcat-dev
>Subject: Re: Trying New Connectors Build Stuff
>
>
>on 5/13/01 10:43 AM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote:
>
>> Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which 
>is the module I'm
>> writing right now... Could I call it --with-apxs2 ??? How 
>does that sound?
>
>No need. That is the point of --with-apxs[=FILE]... you can 
>optionally point
>to any apxs installation.
>
>Note: I'm thinking of adding --with-apache back like it was in 
>Jserv...that
>will be used conditionally with --with-apxs. In other words, 
>you specify one
>or the other, not both. --with-apache would then be used for 
>people who are
>building Apache statically. The problem with that, is supporting both
>options is a pain in the ass, however, stealing the code from Jserv's
>autoconf should be easy...
>
>-jon
>
>-- 
>If you come from a Perl or PHP background, JSP is a way to take
>your pain to new levels. --Anonymous
>
>

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

>I have started a configure.in and makefile(s).in for the
>jakarta-tomcat-connectors.

Thanks great works :!

>Currently I have just prepared it for Apache2.0 and Apache1.3, 
>before going on I
>have some questions:
>
>- The idea is to have one configure.in in
>jakarta-tomcat-connectors/jk/src/native and a makefile.in for 
>each supported
>WebServer. Does it sound Ok?

Seems good, since users could go directly to their preferred
web-server. I saw no advantage to try to resolv in a top
configure all the case (AP1.3/2.0/IIS/NES)...

>- Should I already think of using APR? - Just that some of my 
>plateform are not
>(yet) supported and I am reluctant of adding more #idef in the code -

If your platform are not supported and that #ifdef could help, let's
go. And maybe to avoid #ifdef USE_APR in all the code, we could create 
1/2 C wrapper files ?

>- What should I do with the other WebServers (netscape, jni etc)?

netscape and jni will need support. May be Cosin could take a look
at JNI since he play with it, but there is an open position for a 
NETSCAPE USER/DEV. But in each cache what about providing skeleton
configure.in ?

>The configure.in assumes that the Apache connectors sub-directories are
>apache-1.3 and apache-2.0. I think that more consistant with 
>mod_webapp.

I'll fix that ASAP..

>Please, have a look to the attached files and make comments :=) 

Thanks again.

RE: JNDI/LDAP realm

[GOMEZ Henri]

Why not having all realm code (JDBC/JNDI/LDAP/JAAS) shared
in a common tomcat subproject ?

ie: jakarta-tomcat-realms 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Steve Downey [mailto:[EMAIL PROTECTED]]
>Sent: Monday, May 14, 2001 6:40 PM
>To: [EMAIL PROTECTED]
>Subject: RE: JNDI/LDAP realm 
>
>
>The downside to binding with the supplied credentials is that 
>it chews up a
>file descriptor. For light loads, it's not an issue. For heavy 
>loads, it can
>be a big issue. If the app server binds administratively, you 
>can get by
>with two connections, one for reading and one for writing. Or 
>even one, if
>you're not replicating LDAP.
>
>All in all, making it configurable is probably a good idea.
>
>> -Original Message-
>> From: Ellen Lockhart [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, May 13, 2001 12:58 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: JNDI/LDAP realm 
>> 
>> 
>> I preferred binding to the directory with supplied 
>> credentials because it
>> allows the realm implementation to use an anonymous password 
>> for the rest of
>> what it needs.
>> 
>> To allow for DN's in the directory that may not be composed 
>> of the same
>> attributes as other DN's, one thing I was thinking about 
>> doing to the one I
>> submitted was to configure what the login attribute is (cn, 
>> uid, etc.) and
>> search for it (with anonymous login) to get the dn, then bind to the
>> directory with the resultant DN and the user-entered password to
>> authenticate.  This might be a little less efficient than 
>> just searching and
>> getting the password as well, but is more secure than having the root
>> password to the ldap server where it might be accessible by someone.
>> 
>> 
>> - Original Message -
>> From: "John Holman" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Sunday, May 13, 2001 5:02 AM
>> Subject: JNDI/LDAP realm
>> 
>> 
>> > The current JNDI realm implementation in Tomcat 4 is based 
>on code I
>> > submitted, which was subsequently modified and committed by Craig.
>> >
>> > Two significant changes he made are:
>> >
>> > - the original code found the DN of the user by searching 
>> the directory.
>> The
>> > current implementation, like Ellen Lockhart's recent submission,
>> determines
>> > the DN by substituting the username into a string.
>> >
>> > - the original code supported a mode in which the user is 
>> authenticated by
>> > binding to the directory with the supplied credentials (as 
>> does Ellen's).
>> > The code for this was removed, with a comment in the commit 
>> log that this
>> > mode should be supported probably in a separate 
>> implementation class.
>> >
>> > I did comment on this in an earlier message, but got no 
>> response - so I'm
>> > trying again now there is another little wave of interest :)
>> >
>> > Determining the DN. The pattern substitution method in the current
>> > implementation is obviously more efficient when applicable 
>> but the search
>> > method is more general. For example, unlike the current 
>> implementation,
>> > search can handle the following common use cases:
>> >
>> > - users are stored within multiple nodes in the directory 
>> (e.g. they may
>> be
>> > held under different
>> > organisational units)
>> >
>> > - the attribute used in distinguished names is not the same 
>> as that the
>> user
>> > enters into the basic authentication dialog box (e.g. the 
>> user might enter
>> > mail address as the username rather than uid; the directory 
>> might use
>> > commonName as a component of distinguished names rather than uid).
>> >
>> > So there are really two orthogonal issues for user 
>> authentication each
>> with
>> > two options:
>> >
>> > - how the dn for the user is determined (configuration template vs
>> directory
>> > search)
>> > - how authentication is done (system login vs binding as the user)
>> >
>> > I think it's important that Tomcat supports the missing 
>> combinations of
>> > options. In fact, the most common strategy when using a 
>> directory for
>> > authentication is probably "search then bind", neither 
>> component of which
>> is
>> > supported by the current implementation.  For example, this is the
>> strategy
>> > taken by pam_ldap and by the auth_ldap Apache module.
>> >
>> > I'd be happy to have a go at adding the missing 
>> functionality, but would
>> > like some feedback first as to whether people think this is 
>> a good idea.
>> > Also opinions as to whether we should have one, two or even 
>> four classes
>> to
>> > implement the different combinations (with multiple classes 
>> maybe derived
>> > from a base JNDIRealm class). We should take into account 
>> which variation
>> is
>> > likely to lead to the simplest and clearest configuration 
>> documentation
>> ...
>> >
>> >

RE: [PATCH] Secure defaults in server.xml + support for "multihomed" machines

[GOMEZ Henri]

+1


>-Original Message-
>From: Andrey Kartashov [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, May 13, 2001 12:12 AM
>To: [EMAIL PROTECTED]
>Subject: [PATCH] Secure defaults in server.xml + support for
>"multihomed" machines
>
>
>
>This patch is a result of our previous discussion with Henry 
>about making
>more secure default bindings in "server.xml".
>
>Summary of changes:
>src/etc/server.xml:
>   Added address="127.0.0.1" parameter to Ajp interceptors 
>that should make
>   them bind to "localhost" by default (At the very least 
>someone won't be
>   able to shutdown a server remotly now)
>
>src/share/org/apache/tomcat/modules/server/Ajp12Interceptor.java:
>   Fixed to make it print IP into conf/ajp12.id in all the cases
>   ( address.toString() does not always work the way we need here)
>
>src/share/org/apache/tomcat/util/IntrospectionUtils.java:
>   Added support for method setXXX( InetAddress ) which is 
>needed to do
>   all the stuff described above.
>
>src/share/org/apache/tomcat/util/net/PoolTcpEndpoint.java:
>   Fixed to make work properly when bound to interface 
>other than "localhost"
>
>
>Attached please find diff.txt with all this changes.
>Diff is made using "cvs diff" against current state of 
>jakarta-tomcat CVS
>repository.
>
>Please let me know what you think:)
>
>-- 
>oo Andrey
>oo
>oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
>"All mail clients suck. This one just sucks less."
>   -- http://www.mutt.org/  Jeremy Blosser
>oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
>

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

>I have started a configure.in and makefile(s).in for the
>jakarta-tomcat-connectors.
>Currently I have just prepared it for Apache2.0 and Apache1.3, 
>before going on I
>have some questions:

I tested the configure/makefile stuff and it works well but
could you also add the java detection for JNI support ?

ie: --with-java=/usr/jdk1.3.0/ 

Many users asked about statically compiling mod_jk in Apache, 
could you add a --with-apache flag ?

Do you think we could add also the config dir path to have
default mod_jk.conf and workers.properties installed ?

feature which could be added, is the config 

ie: --sysconfdir=/etc/httpd/conf(à la Redhat)


Thanks for that contribution

web_app in jakarta-tomcat-connectors ?

[GOMEZ Henri]

What about importing the mod_webapp code in 
jakarta-tomcat-connectors ?

There is allready jk stuff (native, java), we could
also have here a 'wa' subdir 

jakarta-tomcat-connectors/wa/src/native/apache-1.3/
jakarta-tomcat-connectors/wa/src/native/apache-2.0/
jakarta-tomcat-connectors/wa/src/native/include/
jakarta-tomcat-connectors/wa/src/java/


The idea is to provide to new users a common area when
he's looking for web-server to servlet-engine connectors.
 
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: Trying New Connectors Build Stuff

[GOMEZ Henri]

>> You were invited with Pier last week and there is still no
>> anwsers :)
>
>Was I? Whops, didn't notice... Sorry... What should I do? 
>Throw away all my
>code and start working on JK? 

Who asked you to drop your code ?) 
I was asking for import of the wa code in 
jakarta-tomcat-connectors.

Could you tell us what's the problem with JK ? 
A sort of 'not invented here syndrom' ?) (joke...)

>I love working with bleeding 
>edge stuff...

And most users like to work with stable stuff.

>Like: mod_webapp doesn't compile on Solaris because APR has a 
>bug... Isn't
>it fun? Code maintenance is not for me :) :) :) :)

APR team does the code maintenance for you...

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

>> > The configure.in assumes that the Apache connectors 
>sub-directories are
>> > apache-1.3 and apache-2.0. I think that more consistant 
>with mod_webapp.

done

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

>My idea is to build one connector per call of configure/make, 
>--with-java should
>build the JNI support, correct?
>I have noted that common contains jk_jni_worker.c, should not 
>we move it in jni?

no, jk_jni_worker could also be used into apache 1.3/2.0.
And that's HOW IBM use mod_jk on at least AS/400 using JNI
instead of AJP12/AJP13...

>> Many users asked about statically compiling mod_jk in Apache,
>> could you add a --with-apache flag ?
>
>Yes, but we cannot use apxs for that... Following the ideas of 
>mod_webapp we
>should libtool for this purpose.
>Then it is more easy to use libtool for everything.

apxs is for DSO but the question was how to be sure the
mod_jk stuff could be compiled statically in apache ?

>> 
>> Do you think we could add also the config dir path to have
>> default mod_jk.conf and workers.properties installed ?
>> 
>> feature which could be added, is the config
>> 
>> ie: --sysconfdir=/etc/httpd/conf(à la Redhat)
>
>If we use --with-apxs the conf is given by apxs, in case we 
>use --with-apache
>yes.
>This means we need to support "make install".

PS: I commited your Makefile and configure stuff !!!

RE: virus warnings and

[GOMEZ Henri]

What's the problem here ?

I received only one copy

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jay Doggett [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 15, 2001 1:11 PM
>To: [EMAIL PROTECTED]
>Subject: virus warnings and
>
>
>In addition to the multiple virus warnings I am now receiving multiple
>copies of each message sent to the list.
>
>   Is it a wise idea to ban users who contaminate the 
>list. I am starting to
>think that it is necessary.
>
>Jay
>
>-Original Message-
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 15, 2001 7:03 AM
>To: [EMAIL PROTECTED]
>Subject: RE: configure for jakarta-tomcat-connectors
>
>
>>My idea is to build one connector per call of configure/make,
>>--with-java should
>>build the JNI support, correct?
>>I have noted that common contains jk_jni_worker.c, should not
>>we move it in jni?
>
>no, jk_jni_worker could also be used into apache 1.3/2.0.
>And that's HOW IBM use mod_jk on at least AS/400 using JNI
>instead of AJP12/AJP13...
>
>>> Many users asked about statically compiling mod_jk in Apache,
>>> could you add a --with-apache flag ?
>>
>>Yes, but we cannot use apxs for that... Following the ideas of
>>mod_webapp we
>>should libtool for this purpose.
>>Then it is more easy to use libtool for everything.
>
>apxs is for DSO but the question was how to be sure the
>mod_jk stuff could be compiled statically in apache ?
>
>>>
>>> Do you think we could add also the config dir path to have
>>> default mod_jk.conf and workers.properties installed ?
>>>
>>> feature which could be added, is the config
>>>
>>> ie: --sysconfdir=/etc/httpd/conf(à la Redhat)
>>
>>If we use --with-apxs the conf is given by apxs, in case we
>>use --with-apache
>>yes.
>>This means we need to support "make install".
>
>PS: I commited your Makefile and configure stuff !!!
>

RE: Trying New Connectors Build Stuff

[GOMEZ Henri]

>So we have 2 cygwin (amy+jon) and 1 msvc (kevin)... I hoped to 
>have more feedback... 
msvc is the de-facto reference in Windows World

+1 for msvc

RE: web_app in jakarta-tomcat-connectors ?

[GOMEZ Henri]

>> jakarta-tomcat-connectors/wa/src/native/apache-1.3/
>> jakarta-tomcat-connectors/wa/src/native/apache-2.0/
>> jakarta-tomcat-connectors/wa/src/native/include/
>> jakarta-tomcat-connectors/wa/src/java/
>> 
>> 
>> The idea is to provide to new users a common area when
>> he's looking for web-server to servlet-engine connectors.
>
>Bah... I don't see any advantage for that, but you're more 
>than welcome to
>do it. Actually, let's ask to the list:
>
>[+1] Let's move mod_webapp and all its related stuff in 
>jakarta-connectors.
>[ 0] I don't give a damn.
>[-1] Keep it where it is because (please explain)
>
>Pier: 0

Didn't the jakarta-tomcat-connectors goal is to remove
the connectors stuff from the servlet-engine code ?

+1 in that case.

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3

[GOMEZ Henri]

getRemoteHost() is now fixed in CVS :)

Same that TC 3.2.2

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 15, 2001 3:00 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
>
>
>larryi  01/05/15 05:59:53
>
>  Modified:.RELEASE-PLAN-3.3
>  Log:
>  Update to move getRequestURI problem to Beta 1.
>  
>  Indicate requirement in Milestone 3 to check security 
>problem of URL's with
>  escape sequences being able to reveal JSP source.
>  
>  Indicate requirement in Beta 1 to address problem of 
>getResource() allowing
>  access to files outside the web application with paths 
>containing the right
>  escape sequences.
>  
>  Revision  ChangesPath
>  1.11  +8 -5  jakarta-tomcat/RELEASE-PLAN-3.3
>  
>  Index: RELEASE-PLAN-3.3
>  ===
>  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v
>  retrieving revision 1.10
>  retrieving revision 1.11
>  diff -u -r1.10 -r1.11
>  --- RELEASE-PLAN-3.3 2001/05/15 09:47:52 1.10
>  +++ RELEASE-PLAN-3.3 2001/05/15 12:59:49 1.11
>  @@ -75,7 +75,7 @@
>   
>Known issues in order of priority
>   
>  - 1. getRequestURI() should return an encoded string (if 
>feasible)
>  + 1. Verify that JSP source is not served when escaping 
>tricks are used
>2. Update build process to create archives and 
>internal directory
>   structure consistent with other Jakarta projects, i.e. use
>   jakarta-tomcat-3.3-xxx.
>  @@ -105,13 +105,16 @@
>  object in the session.  The spec calls for the reverse.
>   B. setAttribute() doesn't call valueUnbound() for the
>  object it replaces, if present.
>  - 3. Session recyling includes keeping the 
>HttpSessionFacade.  I believe
>  + 3. Fix getResource() to not allow access to files 
>outside of the web
>  +application.
>  + 4. Session recyling includes keeping the 
>HttpSessionFacade.  I believe
>   this represents a security risk.   May need to 
>discard session
>   facades, or at least discard them for untrusted web 
>applications.
>  - 4. Update getRemoteHost() to be consistent with Tomcat 
>3.2.2, which
>  + 5. getRequestURI() should return an encoded string
>  + 6. Update getRemoteHost() to be consistent with Tomcat 
>3.2.2, which
>   does a reverse DNS lookup.
>  - 5. Verify no reqressions.
>  - 6. TBD...
>  + 7. Verify no reqressions.
>  + 8. TBD...
>   
>   
>   Tomcat 3.3 Beta 2:
>  
>  
>  
>

RE: [jakarta-tomcat-connectors] a dilemma ...

[GOMEZ Henri]

>so, i'm looking at decoupling the Ajp13 java stuff from servlet
>container code. 
>
>some background... in tomcat 3, the ajp code takes a core 
>tomcat Request
>object and adds decoded information from the ajp request into the
>Request object.  when i ported this code from tomcat 3 to tomcat 4, i
>used an object that extended a core tomcat 4 class, HttpBaseRequest.
>
>the dilemma is what to pass to the ajp code that accepts 
>requests in the
>new world where this code could be used by any servlet container.  the
>choices as i see them are:

A study of common interface to this specialized ORB/HTTP
could be conducted now. Tomcat has no more than 3 differents
implementations (3.2/3.3/4.0)...

It will be profitable to all tomcat community to have people
from differents teams 3.2/3.3/4.0 speak of this subject...
 
>anyway, i'm not really sure what the best approach is -- 
>that's why it's
>a dilemma :) -- so, i'm looking for opinions, suggestions, etc. here.

The best solution will came from discussion in tomcat-dev.
And if there is no discussion here, I suggest you ask the question
to others communities, for example the one from jetty.org

RE: Trying New Connectors Build Stuff

[GOMEZ Henri]

>I ask mostly because I've put a lot of effort into cleaning up and
>documenting that code, and I hope that it is now much more 
>workable.  

Your documentation is a great help in extending the jk in
jakarta-tomcat-connectors to add ajp14 support.

I'll try to also comments my code to help it being understoud
by users and commiters, and of course code review. Just take
a look in jakarta-tomcat-connectors/jk/src/native...

>If you
>still find it difficult to read/understand, I'd love to know 
>how/where.  I
>still hold out hope that at some point in the future the mod_webapp
>protocoal (warp?) could be supported by mod_jk, so there would 
>be only one C
>code base to support.

mod_webapp is too different from mod_jk, and there will be 2 
native code base to support, to avoid that :

- Someone implements the warp protocol in mod_jk

- Someone implements ajp12 or ajp13 in mod_webapp

RE: [PATCH] configure.in for jakarta-tomcat-connectors

[GOMEZ Henri]

Thanks for the configure stuff JF.

Stay all tuned since I'll upload today or tomorrow 
updated stuff for mod_jk and ajp14..


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

>> I have added the detection of the JAVA_HOME and OS that will 
>be need for the jni
>> connector.
>> It is a copy of acinclude.m4 of JServ and some improvements. ;=)
>> 
>> Please check it and commit it.
>> 
>> Cheers
>> 
>> Jean-frederic
>
>Oops... I have suddenly remember that the attachement was missing.
>
>Jean-frederic
>

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

 
>> Error - it shouldn't be in common...

Are you sure ?

in jk_jni_worker there is a jni_worker_factory() which is 
referenced in jk_worker_list.h which is used to determine
workers in jk_worker.c (get_factory_for).

If jk_jni_worker is removed from common, it should be also
removed from the list of know workers (in jk_worker_list.h)
or mod_jk will have to be built with ../common/*.c and ../jni/*.c ?

Thansk to clarify

>But it should be in jni.

Are yo
>> jk_jni_worker uses JNI to start tomcat in the same process with
>> Apache(2.0) or IIS/NES and uses in-process calls instead of TCP/IP.
>
>That means it should be configured for apache with configure 
>--enable-jni
>--with-apxs=path_to_apxs --with-java-home=path_to_java_home correct?
>
>Does someone knows how to guess OS_TYPE? That is for "-I$(JAVA_INCLUDE)
>-I$(JAVA_INCLUDE)/$(OS_TYPE)"

Not easy with configure but libtool seems to have that :)

>> 
>> It should be the fastest - but it's the hardest to debug, 
>and it hasn't
>> been tunned too much. ( it is similar with the NES servlet container,
>> which runs in-process too, or with mod_perl/mod_php  ).
>> 
>> Costin
>> 
>
>+++ CUT +++
>

RE: [jakarta-tomcat-connectors] a dilemma ...

[GOMEZ Henri]

>> The problem is not only the Request object, but the whole 
>infrastructure
>> needed for efficient communication ( MessageBytes, Headers, etc ).
>> 
>
>i've started down this path (1).  there's a bunch of stuff in tomcat 3
>(like MessageBytes) that would be useful...  i posted a 
>message a couple
>days ago about putting these kinds of things in a common place, but got
>no response.  so, i started using a way scaled down version of my own
>MessageBytes as a placeholder.

I asked for that one or two weeks ago , at the time I asked 
for jakarta-tomcat-connector). I asked then for a jakarta-tomcat-commons 
sub-project, but there was no usefull answer (only flams and polemics).

We asked also last week for a new CVS, jakarta-tomcat-realms but there is
still no answers ? 


>> In both cases you'll need an adapter - if the connector defines an
>> interface with set methods, you still need a 
>container-specific object
>> that implements that interface.
>> 
>> If you use concrete objects - you'll need a 
>container-specific adapter,
>> that implements container-specific interfaces on top of the connector
>> objects.
>> 
>> In both cases you need an adapter - but in the first case 
>you have much
>> more "power" and flexibility in doing "smart" optimizations 
>( like delay
>> the send of the headers or pre-processing more on the server side ).
>> 
>> The connector must deal with the communication between servlet
>> container and web server - and it must hide some of the 
>complexity ( like
>> how buffers are managed ).
>> 
>> Costin
>> 
>> >
>> > presumably, any container in which the ajp connector is 
>being used will
>> > already have some request object with a bunch of set 
>methods, so the
>> > interface approach is probably less work.  however, the 
>concrete object
>> > approach is probably more efficient, as it's probably 
>easier to delay
>> > conversion from bytes to strings in this case.
>> 
>> >
>> > anyway, i'm not really sure what the best approach is -- 
>that's why it's
>> > a dilemma :) -- so, i'm looking for opinions, suggestions, 
>etc. here.
>

RE: Servlet Upload Data Corruption

[GOMEZ Henri]

>Could you explain a little more what these diffs accomplish?  My
>understanding of the fix that went into revision 1.5.2.4 to 
>fix the file upload problem was that doRead() returns an 'int' and was 
>causing the byte >0xFF to be sign extended into the integer -1 which is the
EOF 
>return value for doRead().  

Commited by Dan or Keith ?)

>The byte array version of doRead() should only 
>return -1 if
>there really isn't any more data.  The actualy contents of the 
>bytes read, because they aren't interpretted, don't matter at all.

The problem is related to encoding ?)
How did the data are then passed (and translated) 
from byte[] to the servlet ?

>I don't see how the byte array returned is any different in the patched
>version then what it was before.  Converting a byte into a 
>char and then masking off all but the lowest 8 bits and then turning the 
>results back into a byte looks like a no-op to me.

+1

RE: submitting a patch

[GOMEZ Henri]

>I have found a bug and fixed it in the Tomcat NT
>service program. How do I submit it? Do you guys take
>bug fixes from independent people. I had heard from
>several people that they had submitted bug fixes and
>you guys told them to f*** off (not necessarily in
>those terms).

Let's send the diff (mod_jk / nt_service ?) and we'll 
discuss the patches on the dev list.
It's an Open-Source project and contributions are allways 
welcome.

:)

[VOTE] New Committer: Jean-Frederic Clere

[GOMEZ Henri]

I would like to propose Jean-Frederic Clere as a new committer. 

He make many contribution in jakarta-tomcat, jakarta-tomcat-4.0
and now in jakarta-tomcat-connectors, and we help us with 
stuff like autoconf, APR and exotics systems :)

Vote Please

RE: [PATCH] Tomcat 3.3 m3 mod_jk-howto.html (new Bug #1809)

[GOMEZ Henri]

Commited,

Thanks...

>-Original Message-
>From: Hans Schmid [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 18, 2001 5:00 PM
>To: [EMAIL PROTECTED]
>Subject: [PATCH] Tomcat 3.3 m3 mod_jk-howto.html (new Bug #1809)
>
>
>Hello,
>
>I just installed Tomcat3.3-m3 with ajpv13 behind Apache 1.3.19 
>on Win2000.
>
>While setting up mod_jk with ajp1.3, I noticed a bug in the
>mod_jk-howto.html
>It states:
>
>
>Add the following block to your TOMCAT_HOME/conf/server.xml file.
>
>
>  value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/>
>  
>
>
>
>but this is the way Tomcat 3.2.2 has to be setup.
>
>In TC 3.3 the entry should be:
>
>className="org.apache.tomcat.modules.server.Ajp13Interceptor"
> port="8009" />
>
>
>and its enabled by default.
>
>Anyway, I have attatched diffs against 
>/src/doc/mod_jk-howto.html. This is
>the new paragraph:
>
>---
>-
>---
>(Optional) Configuring Tomcat to use the Ajpv13 protocol
>mod_jk can use either the original Ajpv12 protocol or the newer Ajpv13
>protocol. If you choose the latter, you need to activate the "Ajp13"
>Connection Handler in Tomcat. This will give you the benefit 
>of a faster
>protocol and the ability to identify requests made via HTTPS.
>
>Add the following block to your TOMCAT_HOME/conf/server.xml file.
>
>  value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/>
>  
>
>
>The server.xml file already has a block similar to this for Ajp12
>connections on port 8007 (as delivered by mod_jserv). Even if you think
>you're only using Ajp13, you probably don't want to delete 
>this connector --
>it's required to shut down Tomcat.
>---
>-
>---
>
>There is a mod_jk-howto.html in proposals as well. I don't 
>know, if this
>patch should be applied to this one as well.
>
>I hope this helps a little bit since there seems to be so much 
>confusion in
>the user-list about setting up mod_jk.
>
>Best regards,
>
>Hans
>

AJP14 work on-progress

[GOMEZ Henri]

Hi to all,

I updated the CVS with preliminary code for ajp14,
just for review since it's not working now.

One question who how to access md5 functions under 
IIS/NETSCAPE ? (APR is not yet a solution :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: [VOTE] Final release of Tomcat 3.2.2

[GOMEZ Henri]

>Vote to release the tomcat_32 branch as Tomcat 3.2.2.
>
>[X] +1.  I agree with the proposal and I will help support
> the release.
>[ ] +0.  I agree with the proposal but I will not be able
> to help support the release.
>[ ] -0.  I don't agree with the proposal but I won't stop
> the release.
>[ ] -1.  I disagree with the proposal and will explain my
> reasons.
>

My usual RPMs (java and native for Linux) contributions.

A big hi to Marc 'Just-In-Time' Release Manager :)

RE: 3.2.2 mod_jk encoding issue

[GOMEZ Henri]

Seems correct to me.

BTW, with the jakarta-tomcat-connector,
this kind of native bugs fixes will appears
outside TC 3.2/3.3/4.0 soon.

I'll correct that on mod_jk in TC 3.3 and
jakarta-tomcat-connector

To be fixed also in mod_webapp.

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 18, 2001 10:10 PM
>To: [EMAIL PROTECTED]
>Subject: 3.2.2 mod_jk encoding issue
>
>
>The 2.2 servlet spec errata says the uri from
>HttpServletRequest.getRequestURI() should remain encoded.
>[http://java.sun.com/products/servlet/errata_042700.html]
>
>Tomcat 3.2 standalone handles this correctly, but the
>mod_jk connector does not.
>
>The connector uses the decoded uri from Apache (r->uri).
>I believe the correct value to return is the raw, encoded
>url (r->unparsed_uri), stripped of the query string, per
>the servlet javadoc.
>[http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet
>/http/HttpSer
>vletRequest.html#getRequestURI()]
>
>Of course I will defer to the RM's judgement, but I'd like
>to commit the following patch to the 3.2 branch prior to
>next Friday:
>
>===
>RCS file: 
>/home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
>retrieving revision 1.7.2.3
>diff -u -r1.7.2.3 mod_jk.c
>--- mod_jk.c2001/02/17 05:24:00 1.7.2.3
>+++ mod_jk.c2001/05/18 21:05:16
>@@ -358,7 +358,13 @@
> s->method   = (char *)r->method;
> s->content_length = get_content_length(r);
> s->query_string = r->args;
>-s->req_uri  = r->uri;
>+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;
>+   }
>+}
>
> s->is_ssl   = JK_FALSE;
> s->ssl_cert = NULL;
>
>Ditto for /home/cvs/jakarta-tomcat/src/native/apache2.0/Attic/mod_jk.c
>
>Comments?
>
>Keith
>

RE: 3.2.2 mod_jk encoding issue

[GOMEZ Henri]

Resin 1.2.5 and 2.0b2 also use uri instead of unparsed_uri.

So what ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 18, 2001 11:27 PM
>To: [EMAIL PROTECTED]
>Subject: RE: 3.2.2 mod_jk encoding issue
>
>
>Seems correct to me.
>
>BTW, with the jakarta-tomcat-connector,
>this kind of native bugs fixes will appears
>outside TC 3.2/3.3/4.0 soon.
>
>I'll correct that on mod_jk in TC 3.3 and
>jakarta-tomcat-connector
>
>To be fixed also in mod_webapp.
>
>-
>Henri Gomez ___[_]
>EMAIL : [EMAIL PROTECTED](. .) 
>PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>
>
>
>>-Original Message-
>>From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, May 18, 2001 10:10 PM
>>To: [EMAIL PROTECTED]
>>Subject: 3.2.2 mod_jk encoding issue
>>
>>
>>The 2.2 servlet spec errata says the uri from
>>HttpServletRequest.getRequestURI() should remain encoded.
>>[http://java.sun.com/products/servlet/errata_042700.html]
>>
>>Tomcat 3.2 standalone handles this correctly, but the
>>mod_jk connector does not.
>>
>>The connector uses the decoded uri from Apache (r->uri).
>>I believe the correct value to return is the raw, encoded
>>url (r->unparsed_uri), stripped of the query string, per
>>the servlet javadoc.
>>[http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet
>>/http/HttpSer
>>vletRequest.html#getRequestURI()]
>>
>>Of course I will defer to the RM's judgement, but I'd like
>>to commit the following patch to the 3.2 branch prior to
>>next Friday:
>>
>>===
>>RCS file: 
>>/home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
>>retrieving revision 1.7.2.3
>>diff -u -r1.7.2.3 mod_jk.c
>>--- mod_jk.c2001/02/17 05:24:00 1.7.2.3
>>+++ mod_jk.c2001/05/18 21:05:16
>>@@ -358,7 +358,13 @@
>> s->method   = (char *)r->method;
>> s->content_length = get_content_length(r);
>> s->query_string = r->args;
>>-s->req_uri  = r->uri;
>>+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;
>>+   }
>>+}
>>
>> s->is_ssl   = JK_FALSE;
>> s->ssl_cert = NULL;
>>
>>Ditto for /home/cvs/jakarta-tomcat/src/native/apache2.0/Attic/mod_jk.c
>>
>>Comments?
>>
>>Keith
>>
>

RE: 3.2.2 mod_jk encoding issue

[GOMEZ Henri]

>I just tried this and verified the orginal bug and that the 
>proposed patch
>does fix the problem.  I'm OK with committing to the tomcat_32 branch.
>
>DOES ANYONE ELSE OUT THERE HAVE ANYTHING THEY WANT TO TELL ME?
>
>Resin would not appear to be compliant with the specification. 
> The 4/27/00
>errata indicates that getRequestURI() should return the encoded value.

I was fair-play and indicate them the mistake ... :))

RE: [ANNOUNCEMENT] Tomcat 3.3 Milestone 3

[GOMEZ Henri]

The RPM are available with a new package, tomcat-webapps
which hold ADMIN, ROOT and EXAMPLES webapps as requested
by many on the user list :)

Also a big hi to Larry for this release :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: Problems with APR under Linux...

[GOMEZ Henri]

May I recommand you Pier, try another Redhat release than the 7.1.
It's a new release and for example I've got problems building
latest Apache 2.0 under RH 7.1.

Better test with Redhat 6.2 which is very stable and known.

Regards

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, May 19, 2001 2:58 AM
>To: Greg Stein; 
>Cc: [EMAIL PROTECTED]
>Subject: Re: Problems with APR under Linux...
>
>
>Greg Stein at [EMAIL PROTECTED] wrote:
>> 
>> Right. Adding -lpthread manually is absolutely the wrong 
>thing for your app
>> to do. That was poor advice.
>> 
>> 
>> APR generates a shell script called APRVARS. That should 
>have everything
>> that you need for compiling your app, and for linking your 
>app to APR and
>> its dependent libraries.
>> 
>> Note: it is best to compile your app with the flags from 
>APRVARS so that you
>> don't get skewed compile options between APR and your app. 
>Yes, there are
>> well-defined binary interfaces, but heck: APR figured it all 
>out for you, so
>> go ahead and use it :-)
>
>You're the man :) :) Thanks a lot, will dig into that tomorrow 
>morning...
>
>Pier
>

RE: upload data corruption report

[GOMEZ Henri]

Hi DAK,

I tested the server/client with 'b' and without and didn't have
any problems with Tomcat 3.3-m3 (with ajp13)

Could try this distro also ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: DAK [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, May 20, 2001 6:24 AM
>To: [EMAIL PROTECTED]
>Subject: upload data corruption report
>
>
>I've been asked to provide more information, so here is combination of 
>the two messages I posted with some more commentary and attachments.
>
>It pertains to Tomcat-3.2.1 and looks to be  the same in 3.2.2.b4. I'm 
>running Apache 1.3.17 on Win 2K Professional. I'm also using mod_jk
>
>I have some client code that sends a jar file to the servlet. The jar 
>file was getting corrupted. After much digging, I found a CVS 
>commit to 
>Ajp13ConnectorRequest.java that mentioned a problem like this with the 
>doRead() method. It turns out the the same applies to the 
>doRead(byte[], 
>int, int) method. The same problem exists in the 
>Ajp12ConnectionHandler 
>for that byte array read. Single byte reads for both protocols 
>work just 
>fine. I'm including the diffs for these classes to show what 
>I'm talking 
>about.
>
>
>I finally got out from under some work and was able to make some test 
>code. I'm attaching the client and servlet code.
>The code transfers a couple parameters, then a binary file (I 
>was using 
>a .jar). If you call the client with
>"BinTestClient localhost something.jar b", it uses 
>byte-by-byte read on 
>the server to spool the file to a temp file. If you call the client 
>without the 'b', it uses the byte-array read that I was complaining 
>about.  Transfer a file, then try "jar tvf test.jar" to see if it 
>works. I uses a jar that contains .jpg images and when using the byte 
>array read method, it creats a corrupt jar file. If I apply my fix to 
>the Ajp13ConnectorRequest class, it works fine.
>(I tried a jar that contained class files and it worked anyway...)
>I'd like for someone else to try this out to make sure I didn't screw 
>something up. The code seems pretty simple.
>I discovered this when using JarIn/OutputStream to transfer data from  
>client to servlet.I've seen this type of thing in Java before when 
>writing code that talks to hardware (such as touchscreen driver and 
>scanner drivers).
>
>   David
>

RE: Tomcat Interceptors - proof read, anyone?

[GOMEZ Henri]

Excellent,

Please switch from GPL to Apache...

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

AJP14 - updated doc

[GOMEZ Henri]

Find attached the latest revision of AJP14.

Thanks to comments since the work on ajp14 is
still in progress and many code will be commited
next week, all for handling AJP14 ...

Regards

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



/***
 * Description: Proposal for Apache JServ 1.4  *
 * Author:  Henri Gomez <[EMAIL PROTECTED]>   *
 * Version: $Revision: 1.3 $   *
 ***/

This document is a proposal of evolution of the current
Apache JServ Protocol version 1.3, also known as ajp13.  
I'll not cover here the full protocol but only the add-on from ajp13.

This pass include comments from the tomcat-dev list and
misses discovered during developpment.

Missing features in AJP13
-

ajp13 is a good protocol to link a servlet engine like tomcat to a web server like 
Apache: 

* use persistants connections to avoid reconnect time at each request
* encode many http commands to reduce stream size
* send to servlet engine many info from web server (like SSL certs)

But ajp13 lacks support for : 

* security between web server and servlet engine.
  Anybody can connect to an ajp13 port (no login mecanism used)
  You could connect, for example with telnet, and keep the remote thread
  up by not sending any data (no timeout in connection)

* context information passed from servlet engine to web server.
  Part of the configuration of mod_jk, the web server connector, is to
  indicate to the web server which URI to handle. 
  The mod_jk JkMount directive, told to web server which URI must be 
  forwarded to servlet engine.
  A servlet engine allready knows which URI it handle and TC 3.3 is
  allready capable to generate a config file for mod_jk from the list
  of available contexts.
 
* state update of contexts from servlet engine to web server.
  Big site with farm of Tomcat, like ISP and virtuals hosters,
  may need to stop a context for admin purposes. In that case the front
  web server must know that the context is currently down, to eventually
  relay the request to another Tomcat
 
* verify state of connection before sending request.
  Actually mod_jk send the request to the servlet engine and next wait 
  for the answer. But one of the beauty of the socket API, is you that 
  you could write() to a closed connection without any error reporting, 
  but a read() to a closed connection return you the error code. 


AJP14 add-ons to AJP13
--


Let's descrive here the features and add-on that will be added to AJP13, 
which will became AJP14. Since this document is a proposal, a resonable level 
of chaos must be expected at start.
Be sure that discussion on tomcat list will help clarify points, add 
features but the current list seems to be a 'minimun vital'

* Advanced login features at connect time

* Basic authorisation system, where a shared secret key is
  present in web server and servlet engine.

* Basic protocol negociation, just to be sure that if functionnalities are added
  to AJP14 in the future, current implementations will still works.

* Clean handling of 'Unknown packets'

* Extended env vars passed from web-server to servlet engine.

Advanced login
--

1) WEB-SERVER send LOGIN INIT CMD + NEGOCIATION DATA + WEB SERVER INFO

2) TOMCAT respond with LOGIN SEED CMD + RANDOM DATA

3) WEB-SERVER calculted the MD5 of RANDOM DATA+SECRET DATA

4) WEB-SERVER send LOGIN COMP CMD + MD5 (SECRET DATA + RANDOM DATA)

5) TOMCAT respond with LOGIN STATUS CMD + NEGOCIED DATA + SERVLET ENGINE INFO


To prevent DOS attack, the servlet engine will wait
the LOGIN CMD only 15/30 seconds and reports the
timeout exception for admins investigation.

The login command will contains basic protocol
negociation information like compressing ability, 
crypto, context info (at start up), context update at 
run-time (up/down), level of SSL env vars, AJP protocol
supported (AJP14/AJP15/AJP16...)

The Web server info will contain web server info and
connector name (ie Apache 1.3.19 + mod_ssl 2.8.2 + mod_jk 3.3 + mod_perl 1.25).

The servlet engine will mask the negociation mask with it's own
mask (what it can do) and return it when loggin is accepted.

This will help having a basic ajp14 implementation
on a web-server working with a more advanced ajp14 on
the servlet engine side or vice-versa.

AJP13 was designed to be small and fast and so many
SSL informations present in the web-server are not
forwarded to the servlet engine. 

We add here four negociations flags to provide more
informations on client SSL data (certs), server SSL datas
, crypto used, and misc datas (timeout...). 

RE: about warp protocol

[GOMEZ Henri]

Better to write a disector for Ethereal :)

www.ethereal.com

May be something to do also for ajp12/13/14 ?)


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 22, 2001 10:45 PM
>To: [EMAIL PROTECTED]; egcs12md
>Subject: Re: about warp protocol
>
>
>I'm writing a WARP debugger... Hold on :) :) :)
>
>Pier
>
>egcs12md at [EMAIL PROTECTED] wrote:
>
>>  Hi, I find MOD_WEBAPP in Tomcat 4.0b5 can't accord with
>> src\connectors\docs\warp.html, and Tomcat-Apache frozen at 
>http GET. this is
>> data transfer from start up:
>> ***
>> httpd send 14 bytes at 2001-05-21 18:47:11.391
>>  : 00 00 00 00 00 08 00 04 65 67 63 73 00 50   
>egcs.P
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.431
>>  : 00 00 00 01 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.431
>>  : 00 00   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.431
>>  : 00 00   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.431
>>  : 00 02   ..
>> 
>> httpd send 24 bytes at 2001-05-21 18:47:11.441
>>  : 00 16 00 00 00 07 6d 61 6e 61 67 65 72 00 09 2f 
>..manager../
>> 0010 : 6d 61 6e 61 67 65 72 2f manager/
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.441
>>  : 00 00 00 03 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.441
>>  : 00 02   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.441
>>  : 00 00   ..
>> 
>> httpd send 12 bytes at 2001-05-21 18:47:11.441
>>  : 00 00 00 08 00 04 65 67 63 73 00 50 
>..egcs.P
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.451
>>  : 00 00 00 01 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.451
>>  : 00 00   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.451
>>  : 00 00   ..
>> 
>> httpd send 24 bytes at 2001-05-21 18:47:11.451
>>  : 00 02 00 14 00 00 00 06 77 65 62 64 61 76 00 08 
>webdav..
>> 0010 : 2f 77 65 62 64 61 76 2f /webdav/
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.451
>>  : 00 00 00 03 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.461
>>  : 00 03   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.461
>>  : 00 00   ..
>> 
>> httpd send 12 bytes at 2001-05-21 18:47:11.461
>>  : 00 00 00 08 00 04 65 67 63 73 00 50 
>..egcs.P
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.461
>>  : 00 00 00 01 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.461
>>  : 00 00   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.461
>>  : 00 00   ..
>> 
>> httpd send 20 bytes at 2001-05-21 18:47:11.461
>>  : 00 02 00 10 00 00 00 04 61 70 70 32 00 06 2f 61 
>app2../a
>> 0010 : 70 70 32 2f pp2/
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.471
>>  : 00 00 00 03 00 02   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.471
>>  : 00 00   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.471
>>  : 00 01   ..
>> 
>> httpd send 12 bytes at 2001-05-21 18:47:11.471
>>  : 00 00 00 08 00 04 65 67 63 73 00 50 
>..egcs.P
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.481
>>  : 00 00 00 01 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.481
>>  : 00 00   ..
>> 
>> httpd send 2 bytes at 2001-05-21 18:47:11.481
>>  : 00 00   ..
>> 
>> httpd send 18 bytes at 2001-05-21 18:47:11.481
>>  : 00 02 00 0e 00 00 00 03 61 70 70 00 05 2f 61 70 
>app../ap
>> 0010 : 70 2f   p/
>> 
>> jspd send 6 bytes at 2001-05-21 18:47:11.602
>>  : 00 00 00 03 00 02   ..
>> 
>> jspd send 2 bytes at 2001-05-21 18:47:11.602
>>  : 00 00 

RE: Vacation

[GOMEZ Henri]

> 
>> The buffers do belong to jakarta-tomcat-connectors/util, and 
>in a perfect
>> world we wouldn't have them duplicated - 3.3 should only use 
>what's in
>> connectors.
>> 
>> I wouldn't mind making tomcat-connectors/util the "master" 
>source for the
>> buffer stuff, but it needs some changes in the build 
>scripts. I'm not sure
>> how other people would feel about this - we are very close 
>to 3.3beta.
>> 
>
>it would be great to have the buffer code in one place, but, i've never
>really been comfortable with jakarta-tomcat-connectors/util being that
>place.  it would make more sense to me to have something like
>jakarta-tomcat-util, where common utility code like the buffers stuff
>could live.  jtc should be just for connectors.

+1 and again why not a jakarta-tomcat-commons ?

>
>if people don't want a whole new module for utility code, then 
>i suppose
>jtc is the next best place...
>
>-kevin.
>

RE: cvs commit:jakarta-tomcat/src/share/org/apache/tomcat/util/buf DateTool.java

[GOMEZ Henri]

>> >
>> > It has all to do with "standards". Tabs have been used for 
>indentation
>for
>> > at least the last 15 years ( that's when I started playing with
>computers-
>> > and the tab was there ).
>>
>> But the point is that we're using SPACES... Since _EVER_... 
>Discussion
>> closed.
>
>I really doubt you guys have been using spaces everywhere 
>since JServ. Look
>at Craig's source for JServ 2 (err, I mean, Catalina) : there are tabs
>everywhere ;)
>
>Frankly, I don't think we should make a big deal of the whole issue.

Space Wars - Vi Strike Back ?)

RE: connector status in tomcat 4

[GOMEZ Henri]

>My question is what the status is on the apache connector in 
>tomcat 4. I've
>been testing Jakarta 4 in standalone mode and is very pleased 
>with it, but
>we can't run it like that once we release the system for all 
>our students..
>;)

There is actually 2 connectors for Apache Tomcat 4.0 :

- warp/webapp : Developped specifically for TC 4.0 have 
  autoconfig stuff but lack load-balancing or IIS/NES support

- ajp13/jk : Available since TC 3.2, works with TC 3.3 and
  now with 4.0 (thanks to Kevin). Miss the autoconfig stuff 
  (will came in ajp14) but have load-balancing and IIS/NES
  support.

Your contribution must match your need !) 

RE: connector status in tomcat 4

[GOMEZ Henri]

>I thought the idea of warp/webapp was that it was to support 
>servlet api 2.3 
>and ajp/jk couldn't eaily be modified to support the new specs.

What's the supposed features in 2.3 that ajp/jk couldn't support ?
At least there will be in ajp14/jk the autoconfig (ie list of
URL/URI handled ) =>

/examples/servlet/*
/examples/*.jsp
/examples/*.xml

>
>Dave
>[EMAIL PROTECTED]
>
>
>>From: kevin seguin <[EMAIL PROTECTED]>
>>Reply-To: [EMAIL PROTECTED]
>>To: [EMAIL PROTECTED]
>>Subject: Re: connector status in tomcat  4
>>Date: Mon, 28 May 2001 09:52:43 -0500
>>
>> >
>> > Ok, so which one would you say should has highest priority?
>> >
>>
>>that probably depends on who you ask ;-)
>>
>> > Having a quick look at the CVS repository I see 
>>jakarta-tomcat-connectors,
>> > which contains the jk-park, and in jakarta-tomcat I see 
>the warp/webapp. 
>>Is
>> > this right? Won't ajp13/jk be included in tc4? Is it going to be 
>>replaced by
>> > warp/webapp?
>> >
>>
>>jakarta-tomcat-connectors (jtc) is a new module where connectors like
>>ajp, warp/webapp, etc. should live.  the idea is that the 
>core parts of
>>connectors should be container-agnostic.  only the request/response
>>adapters should know about containers.
>>
>>ajp/jk will not be "included" in tc4, but it will support tc4 -- there
>>will be (is) an ajp13 connector for tc 4 (it's is a work in progress).
>>going forward, ajp connectors for tc 3, tc 4, and maybe other 
>containers
>>will live in jtc.
>>
>>warp/webapp will not replace ajp/jk, but it will give you another
>>choice.  you'll be free to make the decision yourself as to what
>>connector you want to use.
>>
>> > // Erik
>> >
>> > > -Original Message-
>> > > From: kevin seguin [mailto:[EMAIL PROTECTED]]
>> > > Sent: Monday, May 28, 2001 3:05 PM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: Re: connector status in tomcat 4
>> > >
>> > >
>> > > GOMEZ Henri wrote:
>> > > >
>> > > > >My question is what the status is on the apache connector in
>> > > > >tomcat 4. I've
>> > > > >been testing Jakarta 4 in standalone mode and is very pleased
>> > > > >with it, but
>> > > > >we can't run it like that once we release the system for all
>> > > > >our students..
>> > > > >;)
>> > > >
>> > > > There is actually 2 connectors for Apache Tomcat 4.0 :
>> > > >
>> > > > - warp/webapp : Developped specifically for TC 4.0 have
>> > > >   autoconfig stuff but lack load-balancing or IIS/NES support
>> > > >
>> > > > - ajp13/jk : Available since TC 3.2, works with TC 3.3 and
>> > > >   now with 4.0 (thanks to Kevin). Miss the autoconfig stuff
>> > > >   (will came in ajp14) but have load-balancing and IIS/NES
>> > > >   support.
>> > > >
>> > >
>> > > er...  the load-balancing doesn't work yet for tc 4 -- 
>the java side 
>>of
>> > > it hasn't been done yet.  it shouldn't be too hard to do 
>though :)  i
>> > > think it's just a matter of figuring out what to do with 
>jvmRoute on 
>>the
>> > > java side (set a cookie??).
>> > >
>> > > > Your contribution must match your need !)
>
>___
>__
>Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.

RE: connector status in tomcat 4

[GOMEZ Henri]

>In that case, what is the point of warp. Is it going to be 
>faster, more scalable or something? 

warp is a whole new developpement using 
very recent lib tools like APR.

>If not why was it created?

That's a good question and who has the answer ?

>Dave
>[EMAIL PROTECTED]
>
>
>>From: GOMEZ Henri <[EMAIL PROTECTED]>
>>Reply-To: [EMAIL PROTECTED]
>>To: [EMAIL PROTECTED]
>>Subject: RE: connector status in tomcat 4
>>Date: Mon, 28 May 2001 17:43:41 +0200
>>
>> >I thought the idea of warp/webapp was that it was to support
>> >servlet api 2.3
>> >and ajp/jk couldn't eaily be modified to support the new specs.
>>
>>What's the supposed features in 2.3 that ajp/jk couldn't support ?
>>At least there will be in ajp14/jk the autoconfig (ie list of
>>URL/URI handled ) =>
>>
>>/examples/servlet/*
>>/examples/*.jsp
>>/examples/*.xml
>>
>> >
>> >Dave
>> >[EMAIL PROTECTED]
>> >
>> >
>> >>From: kevin seguin <[EMAIL PROTECTED]>
>> >>Reply-To: [EMAIL PROTECTED]
>> >>To: [EMAIL PROTECTED]
>> >>Subject: Re: connector status in tomcat  4
>> >>Date: Mon, 28 May 2001 09:52:43 -0500
>> >>
>> >> >
>> >> > Ok, so which one would you say should has highest priority?
>> >> >
>> >>
>> >>that probably depends on who you ask ;-)
>> >>
>> >> > Having a quick look at the CVS repository I see
>> >>jakarta-tomcat-connectors,
>> >> > which contains the jk-park, and in jakarta-tomcat I see
>> >the warp/webapp.
>> >>Is
>> >> > this right? Won't ajp13/jk be included in tc4? Is it going to be
>> >>replaced by
>> >> > warp/webapp?
>> >> >
>> >>
>> >>jakarta-tomcat-connectors (jtc) is a new module where 
>connectors like
>> >>ajp, warp/webapp, etc. should live.  the idea is that the
>> >core parts of
>> >>connectors should be container-agnostic.  only the request/response
>> >>adapters should know about containers.
>> >>
>> >>ajp/jk will not be "included" in tc4, but it will support 
>tc4 -- there
>> >>will be (is) an ajp13 connector for tc 4 (it's is a work 
>in progress).
>> >>going forward, ajp connectors for tc 3, tc 4, and maybe other
>> >containers
>> >>will live in jtc.
>> >>
>> >>warp/webapp will not replace ajp/jk, but it will give you another
>> >>choice.  you'll be free to make the decision yourself as to what
>> >>connector you want to use.
>> >>
>> >> > // Erik
>> >> >
>> >> > > -Original Message-
>> >> > > From: kevin seguin [mailto:[EMAIL PROTECTED]]
>> >> > > Sent: Monday, May 28, 2001 3:05 PM
>> >> > > To: [EMAIL PROTECTED]
>> >> > > Subject: Re: connector status in tomcat 4
>> >> > >
>> >> > >
>> >> > > GOMEZ Henri wrote:
>> >> > > >
>> >> > > > >My question is what the status is on the apache 
>connector in
>> >> > > > >tomcat 4. I've
>> >> > > > >been testing Jakarta 4 in standalone mode and is 
>very pleased
>> >> > > > >with it, but
>> >> > > > >we can't run it like that once we release the 
>system for all
>> >> > > > >our students..
>> >> > > > >;)
>> >> > > >
>> >> > > > There is actually 2 connectors for Apache Tomcat 4.0 :
>> >> > > >
>> >> > > > - warp/webapp : Developped specifically for TC 4.0 have
>> >> > > >   autoconfig stuff but lack load-balancing or 
>IIS/NES support
>> >> > > >
>> >> > > > - ajp13/jk : Available since TC 3.2, works with TC 3.3 and
>> >> > > >   now with 4.0 (thanks to Kevin). Miss the autoconfig stuff
>> >> > > >   (will came in ajp14) but have load-balancing and IIS/NES
>> >> > > >   support.
>> >> > > >
>> >> > >
>> >> > > er...  the load-balancing doesn't work yet for tc 4 --
>> >the java side
>> >>of
>> >> > > it hasn't been done yet.  it shouldn't be too hard to do
>> >though :)  i
>> >> > > think it's just a matter of figuring out what to do with
>> >jvmRoute on
>> >>the
>> >> > > java side (set a cookie??).
>> >> > >
>> >> > > > Your contribution must match your need !)
>> >
>> >___
>> >__
>> >Get Your Private, Free E-mail from MSN Hotmail at
>>http://www.hotmail.com.
>
>___
>__
>Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.

RE: [PATCH] for mod_jk/ajp13 memory leaks.

[GOMEZ Henri]

>I found some more memory leaks in mod_jk.  The biggest one is 
>in mod_jk.c when there is a virtual host section in 
>httpd.conf.  Multiple conf structures are allocated, but only 
>one was being cleaned up.  Another leak was in 
>jk_ajp13_worker.c.  We were calling jk_open_pool on the 
>endpoint object and never calling jk_close_pool when the 
>endpoint was shut down.  The attached diff files are against 
>the latest tomcat_33 branch.  If anyone is interested, I'd be 
>happy to provide the same diffs for tomcat_32 and the 
>tomcat-jakarta-connectors project.  I'd also be happy to enter 
>a bug if necessary.

Thanks for these very important fixes. 
I'll commit then to TC 3.3 and JTC (which came from TC 3.3 CVS). 

I think Marc Saegesser will be interest in fixes for tomcat_32.

Regards

RE: connector status in tomcat 4

[GOMEZ Henri]

>Ok, another question then.

Please,

>What is it that the connector has to be able to do? Is it 
>sufficient if it
>simply can forward the HTTP request to tomcat or does it need 
>to play around
>with it? I guess it must do something or the disscusion on ajp13/jk and
>warp/webapp wouldn't be.

The web-server connector forward request to tomcat and add some 
information, like the SESSION-COOKIES. In return the tomcat add
a var, jvmroute, which is used in load-balancing config to be sure
that the same tomcat will serve the next queries for that session.

The connector use a simple protocol, ajp12/13/14, to forward the
request. You may imagine a web-connector forwarding the request 
using HTTP protocol, but this one is more complex to handle.
 
>// Erik
>
>> -Original Message-
>> From: kevin seguin [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, May 28, 2001 5:47 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: connector status in tomcat 4
>>
>> for example, in my case, currently all i care about is being able to
>> forward requests based on uri from iis and netscape to 
>tomcat.  so, for
>> me, ajp does what i need it to, while warp/webapp currently 
>does not (no
>> iis/netscape support yet).  hence, i would pick ajp.
>>
>> now, i'm not saying one is better than the other.  i'm just 
>saying that
>> one might be better than the other in certain circumstances, 
>and now you
>> have a choice.
>>
>

RE: connector status in tomcat 4

[GOMEZ Henri]

>GOMEZ Henri at [EMAIL PROTECTED] wrote:
>
>>> In that case, what is the point of warp. Is it going to be
>>> faster, more scalable or something?
>> 
>> warp is a whole new developpement using
>> very recent lib tools like APR.

>And a bunch of other features and improvements, but it seems 
>that no one
>ever listen to what I write - technically speaking :) :) :) :)

What's the technicals improvements apart of the use of APR,
technically speaking ?

>>> If not why was it created?
>> 
>> That's a good question and who has the answer ?
>
>I do, and the mailing list archive... Check out for subjects 
>like WARP :)

The first time we saw something about Warp is in the announcement
of Tomcat 4.0 m4.

I couldn't find any discussion on tomcat-dev (or tomcat-user) 
about starting a new connector (mod_webapp) instead adding 
features to ajp13 and using mod_jk ;(

Could help me find the initial thread on mod_webapp/warp ?)

Regards

=>

List: tomcat-dev
Subject:  Tomcat 4.0 Milestone 4
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Date: 2000-11-01 0:09:41
[Download message RAW]

Hey folks,

I'm planning on cutting a fourth milestone of Tomcat 4.0 tomorrow
(Wednesday) evening.  This milestone will reflect all of the changes
that occurred in the servlet 2.3 and JSP 1.2 specifications between
public draft and proposed final draft (and there were a *bunch* of
them), completion of the remaining new 2.3/1.2 functionality, and
several bug fixes.

This will be the last big push of spec-related functionality additions
for Tomcat 4.0.  Now, we can turn our attention more towards bug fixes
and performance tuning.  You can help in that process by downloading and
playing with the Tomcat 4.0 milestone.  I'd like to see us shake it out
enough to be production quality by Christmas time.

Besides bug fixing and tuning, I know of several pieces of functionality
yet to be added that are being worked on, including:

* Web connectors (using a new connector protocol
  called mod_warp that is aware of webapp configuration
  settings, so you will not have to configure things twice).

* JNDI context support (like that used in J2EE servers)
  for the  and  configuration
  parameters in the deployment descriptor.

If you are interested in contributing to Tomcat 4.0, there is a "wish
list" document in file "catalina/STATUS.html" in the jakarta-tomcat-4.0
source tree.  Feel free to propose new ideas, or to volunteer to work on
one of these.

Craig McClanahan

<=

RE: connector status in tomcat 4

[GOMEZ Henri]

>>
>Ok. Is there any written specification för the ajp protocol 
>adn where can I
>find it?

You could find both ajp13 and ajp14 protocol documentation in
at least :

jakarta-tomcat-connectors/jk/src/doc/ 

RE: compiling mod_jk in IRIX, bug+fix

[GOMEZ Henri]

Fixed in TC 3.3 CVS and JTC

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 30, 2001 1:19 PM
>To: [EMAIL PROTECTED]
>Subject: compiling mod_jk in IRIX, bug+fix
>
>
>Sorry if this is the wrong list and/or this is wellknown.
>
>If you want to compile mod_jk from tomcat.3.2.2 in IRIX 6.5.x, 
>then some
>smallish stuff needs to be changed:
>
>in dir jakarta-tomcat-3.2.2-src/src/native/jk
>
>edit the following files in the following way:
>
>jk_sockbuf.c.  replace //comment  with /*  comment */
>jk_util.c  replace //comment  with /*  comment */
>jjk_worker_list.h  add a newline at the eof.
>
>then compile and be happy!
>
>Regards,
>Christer Enkvist
>
>

RE: [ANNOUNCEMENT] Domino / Tomcat connecter available

[GOMEZ Henri]

We could add it to jakarta-tomcat-connector ?
 
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 30, 2001 1:05 PM
>To: Tomcat Dev
>Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available
>
>
>I've written a Tomcat for Lotus Domino in the spirit of the IIS and
>Netscape connectors making it possible to use Tomcat as 
>Domino's servlet
>container.
>
>It can be found at
>
>   http://free.tagish.net/domino-tomcat/index.jsp
>
>It's quite small and wouldn't look at all out of place in the Tomcat
>release ;-)
>
>-- 
>Andy Armstrong, Tagish
>

RE: [ANNOUNCEMENT] Domino / Tomcat connecter available

[GOMEZ Henri]

I'll take a look at it late and see how to include in
JTC !)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, May 31, 2001 10:28 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
>
>
>That would be super cool with me ;-)
>
>GOMEZ Henri wrote:
>> 
>> We could add it to jakarta-tomcat-connector ?
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>> >-Original Message-
>> >From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>> >Sent: Wednesday, May 30, 2001 1:05 PM
>> >To: Tomcat Dev
>> >Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available
>> >
>> >
>> >I've written a Tomcat for Lotus Domino in the spirit of the IIS and
>> >Netscape connectors making it possible to use Tomcat as
>> >Domino's servlet
>> >container.
>> >
>> >It can be found at
>> >
>> >   http://free.tagish.net/domino-tomcat/index.jsp
>> >
>> >It's quite small and wouldn't look at all out of place in the Tomcat
>> >release ;-)
>> >
>> >--
>> >Andy Armstrong, Tagish
>> >
>
>-- 
>Andy Armstrong, Tagish
>

RE: configure for jakarta-tomcat-connectors

[GOMEZ Henri]

>Hi,
>
>I have added support for static linking of mod_jk (for 
>Apache-1.3.x). I have
>used automake to reach it, it has side effects I would like to comment:
>- apxs cannot be used build mod_jk.so.
>- It needs autoconf/automake for prepare the *.in file. (Only 
>for develloppers).
>- It needs libtools.
>
>I am quite unhappy about not beeing able to use apxs to build 
>mod_jk.so, but I
>have not find a clean solution. Has someone an idea?
>

What about a dual strategy ?

DSO using current autoconf stuff and STATIC the new one ?

[VOTE] New Committer: Mike Anderson

[GOMEZ Henri]

I would like to propose Mike Anderson as a new committer.

He found many subtils bugs in mod_jk and since he's
working on Netware platforms, it will a great help 
to improve connectors on this OS.

Vote please

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: [ANNOUNCEMENT] Domino / Tomcat connecter available

[GOMEZ Henri]

>> We could add it to jakarta-tomcat-connector ?
>> 
>
>+1 -- so long as andy will help fix bugs in it when/if they come :)

I'll commit this works on current JTC. 

I'd like to see this connector supporting others protocol like
ajp13 and may be ajp14/warp.

It's important to have people working on others platforms for 
the connector project. We're not in the Java User Land and even
if APR will help us be independant from underlying OS, we'll still
need good OS specialists


>> >-Original Message-
>> >From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>> >Sent: Wednesday, May 30, 2001 1:05 PM
>> >To: Tomcat Dev
>> >Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available
>> >
>> >
>> >I've written a Tomcat for Lotus Domino in the spirit of the IIS and
>> >Netscape connectors making it possible to use Tomcat as
>> >Domino's servlet
>> >container.
>> >
>> >It can be found at
>> >
>> >   http://free.tagish.net/domino-tomcat/index.jsp
>> >
>> >It's quite small and wouldn't look at all out of place in the Tomcat
>> >release ;-)
>> >
>> >--
>> >Andy Armstrong, Tagish
>> >
>

web_app in JTC

[GOMEZ Henri]

Did you, Pier, agree to move the mod_webapp/warp stuff
in jakarta-tomcat-connector and use these CVS instead
the one from TC 4.0 ?

Having all the connector stuff in a common area will help
users (it's what we want), and could also allow us to have
a release rate different from the main servlet-engine rate
(TC 3.2/3.3/4.0). 

We could concentrate on common documentation, faq and so-on.

We migth even see people using others servlet-engine, like
jetty, using the jakarta-tomcat-connector to have a connector
for their prefered servlet-engine. 

Where could I find a description of warp protocol ?
As you know I started to work on ajp13 successor, ajp14
and like to see if we could merge the both.

Also do you consider adding to mod_webapp the support for
load-balancing and fault-tolerance ? 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: mod_jk for Apache 2.0 not building on Red Hat 6

[GOMEZ Henri]

Something I know well :)

Which version of Apache 2.0 have you ?
Up to the latest, the apxs was broken.

I recommand you take a look at Makefile.linux
in TC 3.3 :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jeffrey Altman [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 01, 2001 2:27 PM
>To: [EMAIL PROTECTED]
>Subject: mod_jk for Apache 2.0 not building on Red Hat 6
>
>
>I'm sorry if this is the wrong mailing list to request help for mod_jk
>for Apache 2.0.  If it is, please point me in the proper direction.
>
>I am attempting to build mod_jk for Apache 2.0 on Red Hat 6.0.  I'm
>using the build-unix.sh script.  Unfortunately, the command
>
>  $APXS -c -o mod_jk.so $INCLUDE $LIB $SRC
>
>does not produce an output file mod_jk.so and it does not indicate
>why.  The file .libs/libmod_jk.a is being produced.  Does anyone have
>any suggestions as to where I should look to determine why the .so
>file is not being produced?
>
>Thanks.
>
>
>
> Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha 
>available
> The Kermit Project @ Columbia University   includes Secure 
>Telnet and FTP
> http://www.kermit-project.org/ using Kerberos, SRP, and 
> [EMAIL PROTECTED]  OpenSSL.  SSH soon 
>to follow.
>

RE: mod_jk for Apache 2.0 not building on Red Hat 6

[GOMEZ Henri]

>> Something I know well :)
>> 
>> Which version of Apache 2.0 have you ?
>> Up to the latest, the apxs was broken.
>> 
>> I recommand you take a look at Makefile.linux
>> in TC 3.3 :)
>> 
>
>Thanks for your help.  The Apache version is 2.0.16
>
>I've looked at the Makefile.linux and that apparently has less luck
>than build_unix.sh.  It calls 
>
>  mod_jk.so:
>$(APXS) -I ${JK} ${JAVA_INCL} -c -o mod_jk.la mod_jk.c $(SRCS)
>mv .libs/mod_jk.so .

You got the Apache 2.0 with the buggy apxs. Please try Apache 2.0.18
or apply the attached path to Apache 2.0 apxs :)


Here is my dump (using jk in JTC) :>

/usr/sbin/apxs2 -DUSE_APACHE_MD5 -I ../common -I /opt/IBMJava2-13/include -I
/opt/IBMJava2-13/include/linux -c -o mod_jk.la mod_jk.c
../common/jk_ajp12_worker.c ../common/jk_connect.c ../common/jk_msg_buff.c
../common/jk_util.c ../common/jk_ajp13.c ../common/jk_jni_worker.c
../common/jk_pool.c ../common/jk_worker.c ../common/jk_ajp13_worker.c
../common/jk_lb_worker.c ../common/jk_sockbuf.c  ../common/jk_map.c
../common/jk_uri_worker_map.c ../common/jk_ajp14.c
../common/jk_ajp14_worker.c ../common/jk_md5.c ../common/jk_context.c 
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o mod_jk.lo mod_jk.c && touch mod_jk.slo
mod_jk.c: In function `ws_write':
mod_jk.c:272: warning: initialization discards `const' from pointer target
type
mod_jk.c: In function `init_ws_service':
mod_jk.c:418: warning: assignment discards `const' from pointer target type
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp12_worker.lo ../common/jk_ajp12_worker.c && touch
../common/jk_ajp12_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_connect.lo ../common/jk_connect.c && touch
../common/jk_connect.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_msg_buff.lo ../common/jk_msg_buff.c && touch
../common/jk_msg_buff.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_util.lo ../common/jk_util.c && touch
../common/jk_util.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp13.lo ../common/jk_ajp13.c && touch
../common/jk_ajp13.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_jni_worker.lo ../common/jk_jni_worker.c && touch
../common/jk_jni_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_pool.lo ../common/jk_pool.c && touch
../common/jk_pool.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_worker.lo ../common/jk_worker.c && touch
../common/jk_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp13_worker.lo ../common/jk_ajp13_worker.c && touch
../common/jk_ajp13_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_lb_worker.lo ../common/jk_lb_worker.c && touch
../common/jk_lb_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_sockbuf.lo ../common/jk_sockbuf.c && touch
../common/jk_sockbuf.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread

RE: mod_jk for Apache 2.0 not building on Red Hat 6

[GOMEZ Henri]

APR is Apache Portable Runtime (apr.apache.org)

Could you give us the libtool version ?
I've used Redhat 6.0 and many things were damaged.

May I recommand you try with a more recent distro, ie 6.2 
if you want best compatibility :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jeffrey Altman [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 01, 2001 4:06 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: mod_jk for Apache 2.0 not building on Red Hat 6
>
>
>> 
>> Other idea is a broken libtool... try with the one that is in APR.
>>  
>
>I'm sorry.  APR?
>
>
>
> Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha 
>available
> The Kermit Project @ Columbia University   includes Secure 
>Telnet and FTP
> http://www.kermit-project.org/ using Kerberos, SRP, and 
> [EMAIL PROTECTED]  OpenSSL.  SSH soon 
>to follow.
>

RE: mod_jk for Apache 2.0 not building on Red Hat 6

[GOMEZ Henri]

I used the following RPM

libtool-1.3.4-3 
autoconf-2.13-5
automake-1.4-6


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Jeffrey Altman [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 01, 2001 5:08 PM
>To: [EMAIL PROTECTED]
>Subject: RE: mod_jk for Apache 2.0 not building on Red Hat 6
>
>
>I applied the patch to APXS.  
>
>I replaced /usr/bin/libtool (version "1.3.4") with the one from the
>Apache 2.0 distribution (version "1.3.4-freebsd-ports").
>
>./build-unix.sh now completes successfully and produces 
>
>  [root@IAM40 apache2.0]# ls -l /usr/local/apache2/modules/
>  total 12
>  -rw-r--r--   1 root root10802 Jun  1 07:45 libmod_jk.a
>
>but no mod_jk.so file.  Anyway to convert from .a to .so?
>
>make -f Makefile.linux is still failing.  So I wonder, which version
>of libtool are you using?
>
>BEGIN
>make -f Makefile.linux
>./apxs -I ../common -I /opt/IBMJava2-13/include -I
>/opt/IBMJava2-13/include/linux -c -o mod_jk.la mod_jk.c 
>../common/jk_ajp12_worker.c
>../common/jk_connect.c ..
>/common/jk_msg_buff.c ../common/jk_util.c ../common/jk_ajp13.c
>../common/jk_jni_worker.c ../common/jk_pool.c ../common/jk_worker.c
>../common/jk_ajp13_worker.c .
>./common/jk_lb_worker.c ../common/jk_sockbuf.c  ../common/jk_map.c
>../common/jk_uri_worker_map.c
>libtool --mode=compile gcc -pthread -I/usr/local/apache2/include
>-I../common -I/
>opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux  -c mod_jk.c
>&& touch mod_jk.slo
>mkdir .libs
>gcc -pthread -I/usr/local/apache2/include -I../common
>-I/opt/IBMJava2-13/include
> -I/opt/IBMJava2-13/include/linux -c mod_jk.c  -fPIC -DPIC -o 
>.libs/mod_jk.lo
>gcc -pthread -I/usr/local/apache2/include -I../common 
>-I/opt/IBMJava2-13/include
> -I/opt/IBMJava2-13/include/linux -c mod_jk.c -o mod_jk.o 
>>/dev/null 2>&1
>mv -f .libs/mod_jk.lo mod_jk.lo
>libtool --mode=link gcc -pthread -o mod_jk.la -rpath
>/usr/local/apache2/modules
>-module -avoid-version mod_jk.lo
>rm -fr .libs/mod_jk.la .libs/mod_jk.* .libs/mod_jk.*
>gcc -shared  -Wl,--rpath -Wl,/usr/local/apache2/modules  mod_jk.lo
>-pthread -lc
>  -Wl,-soname -Wl,mod_jk.so -o .libs/mod_jk.so
>creating mod_jk.la
>(cd .libs && rm -f mod_jk.la && ln -s ../mod_jk.la mod_jk.la)
>libtool --mode=compile gcc -pthread -I/usr/local/apache2/include
>-I../common -I/ opt/IBMJava2-13/include 
>-I/opt/IBMJava2-13/include/linux  -c
>../common/jk_ajp12_worker.c && touch ../common/jk_ajp12_worker.slo
>rm -f .libs/jk_ajp12_worker.lo
>gcc -pthread -I/usr/local/apache2/include -I../common
>-I/opt/IBMJava2-13/include
> -I/opt/IBMJava2-13/include/linux -c ../common/jk_ajp12_worker.c
>-fPIC -DPIC -o  .libs/jk_ajp12_worker.lo
>gcc -pthread -I/usr/local/apache2/include -I../common
>-I/opt/IBMJava2-13/include
> -I/opt/IBMJava2-13/include/linux -c ../common/jk_ajp12_worker.c -o
>jk_ajp12_worker.o >/dev/null 2>&1
>mv -f .libs/jk_ajp12_worker.lo jk_ajp12_worker.lo
>libtool --mode=link gcc -pthread -o ../common/jk_ajp12_worker.la
>-rpath /usr/local/apache2/modules -module -avoid-version 
>../common/jk_ajp12_worker.lo
>rm -fr ../common/.libs/jk_ajp12_worker.la
>../common/.libs/jk_ajp12_worker.* ../common/.libs/jk_ajp12_worker.*
>(cd ../common && ln -s jk_ajp12_worker.lo jk_ajp12_worker.o)
>gcc -shared  -Wl,--rpath -Wl,/usr/local/apache2/modules
>../common/jk_ajp12_worker.lo  -pthread -lc  -Wl,-soname 
>-Wl,jk_ajp12_worker.so -o
>../common/.libs/jk_ajp12_worker.so
>gcc: ../common/jk_ajp12_worker.lo: No such file or directory
>apxs:Break: Command failed with rc=65536
>make: *** [mod_jk.so] Error 1
>###END
>
>
>
>
>
>
>
>
>
> Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha 
>available
> The Kermit Project @ Columbia University   includes Secure 
>Telnet and FTP
> http://www.kermit-project.org/ using Kerberos, SRP, and 
> [EMAIL PROTECTED]  OpenSSL.  SSH soon 
>to follow.
>

RE: A starting point for ajp13, ajp14/warp anyone?

[GOMEZ Henri]

jakarta-tomcat-connector is the safe place to put experimental
code, like Domino redirector.

Also we could hope this sub-project could be one day the 
reference of connectors between majors Web-Servers and
jakarta Servlet Engines :)

It's an arena where there we may speak more on native 
problems (OS, web-server, autoconf, libtool, apr) than
Java :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 01, 2001 9:58 PM
>To: [EMAIL PROTECTED]
>Subject: Re: A starting point for ajp13, ajp14/warp anyone?
>
>
>Thanks for that Kevin. Pardon my ignorance ;-)
>
>kevin seguin wrote:
>> 
>> tomcat 4 is not the right place to look for ajp13 examples.  ajp14 is
>> still in the early stages, so you're probably better off 
>starting with
>> ajp13.  jakarta-tomcat-connectors/jk is probably the best 
>place to look
>> for examples.  there are ajp13 connectors for apache, iis 
>and netscape.
>> you're domino connector is also there now, i think :)
>> 
>> Andy Armstrong wrote:
>> >
>> > Hi,
>> >
>> > This weekend I'm going to look at making the Domino connector we
>> > released this week use ajp13 or ajp14 or both. Can anyone give me a
>> > quick pointer to which source I should grab from where (or a meta
>> > pointer to something I can read to find out) to get 
>started. I had a
>> > quick look at the Tomcat 4 sources -- am I right in 
>thinking that the
>> > only ajp14 connector that exists at the moment is the Apache one?
>> >
>> > Sorry if this is an rtfm -- I've had a quick look round 
>the site but
>> > couldn't find much.
>> >
>> > --
>> > Andy Armstrong, Tagish
>
>-- 
>Andy Armstrong, Tagish
>

RE: [ANNOUNCEMENT] Domino / Tomcat connecter available

[GOMEZ Henri]

>GOMEZ Henri wrote:
>> 
>> >> We could add it to jakarta-tomcat-connector ?
>> >>
>> >
>> >+1 -- so long as andy will help fix bugs in it when/if they come :)
>> 
>> I'll commit this works on current JTC.
>> 
>> I'd like to see this connector supporting others protocol like
>> ajp13 and may be ajp14/warp.
>
>I've just been testing it against ajp13 and it seems fine -- did you
>think there might be a problem with it? Or was it just because 
>it wasn't
>tested?

i just wasn't tested and you're now our resident expert in Domino
and Tomcat connection. Welcome on-board...

RE: [Patch]jk_isapi_plugin.c, Virtual Server support for IIS

[GOMEZ Henri]

>Attached is a patch for jk_isapi_plugin.c and a example
>uriworkermap.properties file.
>This patch adds some syntax sugar to uriworkermap.properties 
>file format
>to allow fine grained control over redirection of tomcat 
>contexts to IIS
>virtual hosts, allowing a syntax like :
>
>/www.somevirtualhost.com/context/*.jsp=ajp13 

We have this ability under Apache 1.3 by defining the JkMount
in virtual server (thus lower cost since the scan will be done
only against this virtual server)

>in UWM.P file.. in addition to the old one of :
>
>/context/*.jsp=ajp13
>
>The old syntax comprises the mapping for the entire server, 
>that is this
>context are honored in all IIS virtual servers..
>
>Why i'm sending a patch and not committing it directly?
>
>I'm not sure if the patch ( mostly a hack ) has the merit to go to the
>repository,as it doubles the number of scans throught the map array, is
>one of the most wanted TC feature a critical piece, and the patch goes
>directly to his heart where performance is crucial ...i prefer to hear
>from people before commit..

What's the size of a standard map array ? Did you see a great loss of
performance in that case ?

You add the ability to handle the virtual host also in IIS and such
new feature may be needed by many users.

I'm +1

More on ajp14

[GOMEZ Henri]

Hi to all,

The work in still on progress on AJP14 and I've got new 
questions on ajp14.

1) AJP14 could be considered like an evolution of AJP13.
   
   Basically the same protocol but with added commands.

   AJP13 use the 'AB' chars in start of protocol, what about
   using something like 'DE' in the case of AJP14.

   It will help detect and fixes problem when trying to 
   use AJP14 on AJP13. Smarted servlet engine could even
   route the incorrect ajp protocol 

2) Servlet 2.3 (I can't get the Proposed Final Draft 2) 
   add as requirement cipher_suite and key_size.
   cipher_suite is allready present in current ajp13.

   I've added key_size to a test ajp13 but adding it 
   to current ajp13 may break compatibility since I'll add
   a command #11 in the ajp13 stream, something which will not 
   be understand by current ajp13 java implementation.

   So what to do now ? 

a) Freeze the ajp13 in all branches and add the key_size only in
ajp14 
b) add key_size to ajp13 in mod_jk (in jtc) and in all the java
implementations ?

I've done the b) case, and so I've adapated mod_jk (native) and
ajp13 
   (java for TC 4.0) on jakarta-tomcat-connector to recognize and use
the new command. 
   I attached the diff :)

Even if I've worked on the b) case, I think it will be more secure
to use a)
   and freeze ajp13 now Just to keep compatibility with TC 3.2.2
which are 
   now closed to new features an which didn't require the Servlet 2.3
compatibility.


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


 java.diff
 native.diff

FYI : JSR-000053 Proposed Final Draft 2 Unavailable

[GOMEZ Henri]

Servlet 2.3 API and JSP 1.2 are unavailable at :

http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html

Clicking on continue for 2.3 or 1.2 give you to :

http://java.sun.com/Download4

Any idea where we could find the latest Draft ?

RE: [VOTE] New Committer: Andy Armstrong

[GOMEZ Henri]

+1

Andy does a great job and open us the door of the 
Domino World. A big plkus for jakarta...

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Monday, June 04, 2001 4:53 PM
>To: [EMAIL PROTECTED]
>Subject: [VOTE] New Committer: Andy Armstrong
>
>
>i'd like to propose Andy Armstrong as a new committer.
>
>he has provided a connector for the lotus domino webserver
>(http://free.tagish.net/domino-tomcat/index.jsp) which has 
>recently been
>incorporated into jakarta-tomcat-connectors.
>
>please vote :)
>
>-kevin.
>

RE: More on ajp14

[GOMEZ Henri]

protocol negociation is present in ajp14 but didn't exist
in ajp13...

Adding new command to ajp13 in the protocol need to have
both native (web-server) and java (servlet-engine) to be
upgraded at the same time.

:!

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Monday, June 04, 2001 5:48 PM
>To: [EMAIL PROTECTED]
>Subject: Re: More on ajp14
>
>
>a couple quick thoughts (i haven't fully processed all of this yet
>:))...
>
>feels like the right thing to do is freeze ajp13, and only add 
>new stuff
>to ajp14.  perhaps code can be refactored so that common stuff in
>ajp13/14 can be pulled out of the ajp13 code and put into a 
>common place
>in org.apache.ajp.
>
>or...
>
>have one implementation on the java side that can determine 
>the protocol
>version (1.3, 1.4, X.x ...) and behave appropriately.  for example, the
>web server would send protocol version info, or maybe the packet header
>is enought (the 0x1234) for the java side to determine if the ssl key
>size is a valid attribute.
>
>i'm kind of in a hurry, so these thoughts are going straight from brain
>to keyboard with no processing in between ;-)
>
>-kevin.
>
>GOMEZ Henri wrote:
>> 
>> Hi to all,
>> 
>> The work in still on progress on AJP14 and I've got new
>> questions on ajp14.
>> 
>> 1) AJP14 could be considered like an evolution of AJP13.
>> 
>>Basically the same protocol but with added commands.
>> 
>>AJP13 use the 'AB' chars in start of protocol, what about
>>using something like 'DE' in the case of AJP14.
>> 
>>It will help detect and fixes problem when trying to
>>use AJP14 on AJP13. Smarted servlet engine could even
>>route the incorrect ajp protocol
>> 
>> 2) Servlet 2.3 (I can't get the Proposed Final Draft 2)
>>add as requirement cipher_suite and key_size.
>>cipher_suite is allready present in current ajp13.
>> 
>>I've added key_size to a test ajp13 but adding it
>>to current ajp13 may break compatibility since I'll add
>>a command #11 in the ajp13 stream, something which will not
>>be understand by current ajp13 java implementation.
>> 
>>So what to do now ?
>> 
>> a) Freeze the ajp13 in all branches and add the 
>key_size only in
>> ajp14
>> b) add key_size to ajp13 in mod_jk (in jtc) and in 
>all the java
>> implementations ?
>> 
>> I've done the b) case, and so I've adapated mod_jk 
>(native) and
>> ajp13
>>(java for TC 4.0) on jakarta-tomcat-connector to 
>recognize and use
>> the new command.
>>I attached the diff :)
>> 
>> Even if I've worked on the b) case, I think it will 
>be more secure
>> to use a)
>>and freeze ajp13 now Just to keep compatibility 
>with TC 3.2.2
>> which are
>>now closed to new features an which didn't require 
>the Servlet 2.3
>> compatibility.
>> 
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>>   
>---
>-
>> Name: java.diff
>>java.diffType: unspecified type (application/octet-stream)
>> Encoding: quoted-printable
>> 
>>   Name: native.diff
>>native.diffType: unspecified type (application/octet-stream)
>>   Encoding: quoted-printable
>

RE: More on ajp14

[GOMEZ Henri]

>I agree that even if you have option b) working, option a) is the
>correct way to go so that we don't break backwards compatibility.

The consensus seems to be in freezing ajp13 and adding new features
in ajp14 only. It will avoid conflict with servlet-engine using 
standard ajp13 protocol (TC 3.2/3.3).

The ajp13 protocol use an int header which is 0x1234 when 
packet in from web-server to servlet-engine and 'AB' in
servlet-engine to web-server.

ajp14 (which is ajp13++ ;) will use 0x1235 and 'AC'. It will
help people writting disector (protocol decoder) determine 
the rigth protocol.

I'll start to move some code from jk_ajp13.c to jk_ajp_common.c
and make ajp13/ajp14 use them via flags a protocol flag :)

Stay tuned.

>
>Mike Anderson
>Senior Software Engineer
>Platform Services Group
>[EMAIL PROTECTED]
>Novell, Inc., the leading provider of Net services software
>www.novell.com
>
 [EMAIL PROTECTED] 06/04/01 06:24AM >>>
>Hi to all,
>
>The work in still on progress on AJP14 and I've got new 
>questions on ajp14.
>
>1) AJP14 could be considered like an evolution of AJP13.
>   
>   Basically the same protocol but with added commands.
>
>   AJP13 use the 'AB' chars in start of protocol, what about
>   using something like 'DE' in the case of AJP14.
>   
>   It will help detect and fixes problem when trying to 
>   use AJP14 on AJP13. Smarted servlet engine could even
>   route the incorrect ajp protocol 
>
>2) Servlet 2.3 (I can't get the Proposed Final Draft 2) 
>   add as requirement cipher_suite and key_size.
>   cipher_suite is allready present in current ajp13.
>
>   I've added key_size to a test ajp13 but adding it 
>   to current ajp13 may break compatibility since I'll add
>   a command #11 in the ajp13 stream, something which will not 
>   be understand by current ajp13 java implementation.
>
>   So what to do now ? 
>
>   a) Freeze the ajp13 in all branches and add the key_size only in
>ajp14 
>   b) add key_size to ajp13 in mod_jk (in jtc) and in all the java
>implementations ?
>
>   I've done the b) case, and so I've adapated mod_jk (native) and
>ajp13 
>   (java for TC 4.0) on jakarta-tomcat-connector to 
>recognize and use
>the new command. 
>   I attached the diff :)
>   
>   Even if I've worked on the b) case, I think it will be 
>more secure
>to use a)
>   and freeze ajp13 now Just to keep compatibility 
>with TC 3.2.2
>which are 
>   now closed to new features an which didn't require the 
>Servlet 2.3
>compatibility.
>
>   
>-
>Henri Gomez ___[_]
>EMAIL : [EMAIL PROTECTED](. .) 
>PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>
>

RE: realms and authentication

[GOMEZ Henri]

>"Ignacio J. Ortega" wrote:
>> 
>> I do like your idea , this was something i was talking some time ago,
>> But better than for 3.2.2 ( that is on bug fix mode only , no new
>> features ), But I would prefer to apply your idea to share Realms
>> Implementatios between 3.3 and 4.0, a much more useful objetive..

What about a jakarta-tomcat-realms sub-project as we do we 
jakarta-tomcat-connector and jakarta-tomcat-jasper ?.

>I would like to see Tomcat taking the initiative and providing core
>support for JAAS given then pending inclusion of JAAS in the final
>release of JDK1.4.  I know this would limit tomcat to JDK1.3 and above
>but this should not be a problem for v4.  All the existing realm
>implementations can then be re-implemented as JAAS LoginModules.

Don't forget that 3.2/3.3 are given to works against standard JDK 1.1  :)

RE: RPM of 3.3m3 dependencies

[GOMEZ Henri]

xerces>
>I try to install on Mandrake 8.0,  tomcat-3.3-m3.1.noarch.rpm  
> and it has 
>a dependencie on Xerces-j. I found it at xml.apache.org, but 
>no rpm what DO 
>you have a solution ?
>ps: I then check with  tomcat-3.2.2-1.noarch.rpm   and 
>everything works 
>perfectly.

Apache rpms are allways available at :

ftp://ftp.falsehope.com/home/gomez/xerces-j/
ftp://ftp.falsehope.com/home/gomez/xalan-j/
ftp://ftp.falsehope.com/home/gomez/tomcat/

Warning if you use also xalan-j 2.1.0 since this
one will failed to use xerces.jar if you have jaxp.jar
and parser.jar in THE SAME DIRECTORY THAT xalan.jar.

I make a bug report on xalan list :)

RPM of 3.3m3 - XERCES-J instead of JAXP - Agree ?

[GOMEZ Henri]

Just to comment the RPM building :

In my TC 3.3-m3 RPM, I choose to use xerces-j >= 1.2
instead of the jaxp 1.1 present on TC 3.3

I add the RPM dependency and didn't install jaxp.jar
and parser.jar. At install time the RPM make a link
to xerces in common lib :

ln -s /usr/share/java/xerces.jar /var/tomcat/lib/common/xerces.jar

Do you (users) agree ?

In TC 3.2.2, I was installing a required jaxp.jar and parser.jar
but in some case you could just have xerces.jar installed :!

I'll modify the spec and will release an updated RPM ASAP.

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-----
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, June 05, 2001 12:58 PM
>To: [EMAIL PROTECTED]
>Subject: RE: RPM of 3.3m3 dependencies
>
>
>xerces>
>>I try to install on Mandrake 8.0,  tomcat-3.3-m3.1.noarch.rpm  
>> and it has 
>>a dependencie on Xerces-j. I found it at xml.apache.org, but 
>>no rpm what DO 
>>you have a solution ?
>>ps: I then check with  tomcat-3.2.2-1.noarch.rpm   and 
>>everything works 
>>perfectly.
>
>Apache rpms are allways available at :
>
>ftp://ftp.falsehope.com/home/gomez/xerces-j/
>ftp://ftp.falsehope.com/home/gomez/xalan-j/
>ftp://ftp.falsehope.com/home/gomez/tomcat/
>
>Warning if you use also xalan-j 2.1.0 since this
>one will failed to use xerces.jar if you have jaxp.jar
>and parser.jar in THE SAME DIRECTORY THAT xalan.jar.
>
>I make a bug report on xalan list :)
>

Initial on Java ajp14

[GOMEZ Henri]

Hi,

Find here a quick and dirty diff to start implementing ajp14 
on the java side :)

I'm sure Kevin will clean it up, and I'll use his works to 
add later the marshall/unmarshalling stuff in AJP14 :)
 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


 ajp14.diffs

RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le

[GOMEZ Henri]

That was asked many time before but .

What about creating a sub project jakarta-tomcat-realms 
 
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6


-Original Message-
From: Roytman, Alex [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 5:37 PM
To: 'GOMEZ Henri'; [EMAIL PROTECTED]
Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab
le


Hello Henri, 
Has Interceptor architecture changed in TC3.3? If not 3.2 version should
work just fine. 
In general I do not mind doing it however I did not see much interest from
apache developers and little from users so I am not making any effort to
make it truly open source - comments, documentation, etc.
If somebody from tomcat developers community could review it would express
some interest I will be glad to spend couple of days to its quality. 
Alex 



-Original Message- 
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, June 05, 2001 6:52 AM 
To: [EMAIL PROTECTED] 
Cc: [EMAIL PROTECTED] 
Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is 
availab le 


What about a port of LDAPRealm & JNDIReam  to TC 3.3 ? 
Thanks 


http://www.peacetech.com/java/files/apache/tomcat/default.htm 

Ajp14 / mod_jk update

[GOMEZ Henri]

A quick note to say that the secret key used in login phase
which was defined in mod_jk.conf (JkSecretKey/JkDefaultSecretKey)
is now set in workers.properties :

worker.ajp14.port=8011
worker.ajp14.host=localhost
worker.ajp14.type=ajp14
worker.ajp14.secretkey=myverysecretkey
worker.ajp14.lbfactor=1
worker.ajp14.cachesize=16

The secret-key is required.

The good point is that is will be less works for IIS/NES
adaptation since worker.properties is handled by the common
code :)

Regards

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, June 05, 2001 5:52 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Tomcat4.0 does not compile with jdk1.2.2
>
>
>Hi,
>
>I have noted that ProcessHelper.java and  CGIServlet.java use 
>jdk1.3.1 but this
>code cannot compile with jdk1.2.2...
>+++
>[javac]
>/home/jakarta/jakarta-tomcat-4.0/catalina/src/share/org/apache/
>catalina/servlets/CGIServlet.java:1567:
>Wrong number of arguments in method. 
>[javac] proc = rt.exec(cmdAndArgs.toString(),
>hashToStringArray(env),
>wd);   
>   
>[javac]   ^
> 
>[javac]
>/home/jakarta/jakarta-tomcat-4.0/catalina/src/share/org/apache/
>catalina/util/ProcessHelper.java:381:
>Wrong number of arguments in method.   
>[javac] proc = rt.exec(cmdAndArgs.toString(), 
>hashToStringArray(env),
>wd);   
>   
>[javac]   ^
> 
>[javac] Note: 13 files use or override a deprecated API.  
>Recompile with
>"-deprecation" for
>details.
>[javac] 2 errors, 1 warning
> 
>+++
>
>The 3d argument have been added in jdk1.3.1 - What should I do? -
>
>Cheers
>
>Jean-frederic
>

RE: AJP14 Suggestion

[GOMEZ Henri]

>I want to know how the developers think about adding a request 
>id to ajp14 
>requests, which is then presented back in the response phase.

ajp14 is in it's early stage and a uniq request id could be added
but how will you use it ?

>Background:
>
>We had serious trouble in diagnosing problems with tomcat 3.2 
>related to 
>bug 728 (SimplePool synchronization issue).
>
>The problem caused customers in an ecommerce application to receive 
>responses which belonged to other requests, i.e. were meant to 
>be seen by 
>some other customer. This bug is fixed now, but I wonder if 
>one could make 
>the whole request-response handling more robust by adding an id to the 
>request. This id should then be given back by te response, preferably 
>during a very late phase. The requesting component could then 
>check, if the 
>request and response ids are the same.

Very strange, but are you sure the web-server must trash incorrect
replies (ie without the matching id ?) 

>If furthermore the id would be part of the servlet 
>infrastructure, then 
>application developers could take the id and pass it on the 
>application 
>server etc.
>
>I know, that at the moment this is not contained in a standard 
>or existing 
>product, but in a situation where money is involved on the 
>customer side, 
>people implementing solutions with tomcat would poosibly like 
>very much 
>such checking possibilities.

That something I know well in my day job...

>Once again: we had a hard time and were missing such a 
>possibility a lot. 
>In Tomcat 3.2 you can easily produce stress test situations 
>where a request 
>gets as response body two valied bodies concatenated, one of 
>them belonging 
>to another request, or some other body, or no body at all, or 
>a corrupted 
>one. An id would at least make sure the response belongs to 
>the right request.
>
>In the apache 1.3 szenario, the id would have to be generated 
>by mod_jk!
>
>Any comments?

The request id could be easily added, ie a 32 bits incrementing
id but I'd like to know the others developpers opinion

RE: mod_jk pages

[GOMEZ Henri]

Everything works fine for me 

Bad alert :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, June 06, 2001 2:48 PM
>To: tomcat dev
>Subject: FW: mod_jk pages
>
>
>
>
>-- Forwarded Message
>From: Darrell Howard <[EMAIL PROTECTED]>
>Date: Sat, 02 Jun 2001 11:34:18 -0400
>To: [EMAIL PROTECTED]
>Subject: mod_jk pages
>
>I've been having problems accessing the mod_jk link
>http://jakarta.apache.org/tomcat/tomcat-3.2-doc/mod_jk-howto.html. I
>first attempted to do so on 5/28/01 then again on 6/2/01. I'm guessing
>this has simply not been brought to you attention, but if I'm 
>incorrect,
>could you please point me in the right direction?
>
>Thanks in advance for your help.
>
>Darrell Howard
>[EMAIL PROTECTED]
>
>-- End of Forwarded Message
>

RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le

[GOMEZ Henri]

>>What about creating a sub project jakarta-tomcat-realms? 

>Sure why not. Although I think TC4.0 has or will have some JNDI
authentication 

>I do not know how tomcat project works internally. I rely on tomcat
developers (committers) for guidance. 

>I love tomcat product and developed various extensions for it (context
aware JNDI Environment for 
>TC3.2 to make it somewhat J2EE compatible, Authentication, etc.) but I have
no 
> idea whether they are wanted (I know I can't develop without them) or not.
I rely on you 
>guys to provide guidance. If I got no response I assume it is not needed.

The discussion as started, on the tomcat-dev list :)

Thanks to send the code to the list (source and doc) 

Regards

RE: cvs commit: jakarta-tomcat-4.0/connectors/scandoc scandoc.pl template.pl

[GOMEZ Henri]

Thanks Pier :=)



-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, June 06, 2001 11:14 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat-4.0/connectors/scandoc scandoc.pl
>template.pl
>
>
>pier01/06/06 14:13:39
>
>  Removed: connectors .cvsignore LICENSE.txt Makedefs.in 
>Makefile.in
>README.txt WIN32.txt buildconf.sh configure.in
>   connectors/apache-1.3 .cvsignore Makefile.in 
>mod_webapp.c
>mod_webapp.dsp
>   connectors/docs apache-1.3.html connection.ai 
>connection.jpg
>logo.png packet.jpg warp.html
>   connectors/docs/api README.txt
>   connectors/include wa.h wa_config.h wa_main.h 
>wa_request.h
>   connectors/java WarpConnection.java
>WarpConnectionHandler.java WarpConnector.java
>WarpConstants.java WarpContext.java 
>WarpDebug.java
>WarpEngine.java WarpEngineMapper.java
>WarpHandler.java WarpHandlerTable.java
>WarpHost.java WarpInputStream.java
>WarpOutputStream.java WarpPacket.java
>WarpReader.java WarpRequest.java
>WarpRequestHandler.java WarpResponse.java
>WarpTable.java
>   connectors/lib .cvsignore Makefile.in pr_info.c 
>pr_warp.c
>wa_config.c wa_main.c wa_request.c
>   connectors/scandoc scandoc.pl template.pl
>  Log:
>  The WebApp module distribution has been moved in 
>jakarta-tomcat-connectors.
>

RE: cvs commit: jakarta-tomcat-4.0/connectors/scandoc scandoc.pl template.pl

[GOMEZ Henri]

Could we change the naming of webapp to 
make it matching jk...

ie :

webapp/src/native/apache-1.3
webapp/src/doc
webapp/src/native/include
webapp/src/java
webapp/src/native/lib
webapp/src/native/scandoc
webapp/src/native/webapplib

May be JF or Kevin :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, June 07, 2001 2:23 PM
>To: [EMAIL PROTECTED]
>Subject: Re: cvs commit: jakarta-tomcat-4.0/connectors/scandoc
>scandoc.pl template.pl
>
>
>GOMEZ Henri at [EMAIL PROTECTED] wrote:
>
>> Thanks Pier :=)
>
>I have a couple of major updates, but right now I'm fighting 
>with a major
>problem with the [EMAIL PROTECTED] mailing list :( :(...
>
>As soon as I'm done and I can check them, I'll be doing some updates...
>
>Pier
>

AJP14 - mod_jk - adventure continue

[GOMEZ Henri]

The ajp14 continue :

There will be a huge commit today since I've started
the ajp14 stuff (worker).

Notes :

I've updated Domino, Netscape, IIS, Apache 1.3/2.0 
since I add the uw_map to wc_open call.

AJP14 and it's autoconf feature will try to load the 
URI 2 worker maps...

On the Java Side I've started a quick patch on TC 3.3 
Ajp13.java & Ajp13Interceptor. I'll wait for TC 3.3 
java code import to commit the java code for Ajp14 :)

But here they are attached :

No login handling or Context Info forwarding yet, only
protocol modification :=)


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


 Ajp14.java
 Ajp14Interceptor.java

RE: cvs commit: jakarta-tomcat-4.0/connectors/scandoc scandoc.pl template.pl

[GOMEZ Henri]

>> ie :
>> 
>> webapp/src/native/apache-1.3
>> webapp/src/doc
>> webapp/src/native/include
>> webapp/src/java
>> webapp/src/native/lib
>> webapp/src/native/scandoc
>> webapp/src/native/webapplib
>> 
>> May be JF or Kevin :)
>
>If we share some macro files (m4 files) for configure, life  
>will be more easy
>if the relative pathes are the same. 
>
>But the src does not help in jk: all is under src!
>It brings nothing to have src/native src/doc src/java... And 
>what is src/doc?

>I would propose to remove the src level in jk...

No problem for me :)

>An other thing I am thinking about: the java sources of webapp 
>are in a flat
>structure (all in the java directory). In jk they are in 
>...org/apache/ajp. Does
>this make sense?

I'll follow Kevin there since he used the organization
found in tomcat. For webapp why not use org/apache/warp

AJP14 - autoconf

[GOMEZ Henri]

Hi JF,

Just test the latest configure stuff and autoconf failed
with :

autoconf: Undefined macros:
configure.in:23:AC_PROG_LD

I've got autoconf 2.13, libtool 1.3.4, automake 1.4 :)

The configure.in from yesterday (without AC_PROG_LD) 
worked fine...




-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

SSL - NES / DOMINO

[GOMEZ Henri]

Hi,

I take a look at NES and the SSL vars are not handled 
by this connector.

Idem for DOMINO where some vars are grabbed but not used.

Who know how to get the SSL vars (the following come from apache+mod_ssl) :

SSL_CLIENT_CERT => The client certificat (if user auth used)
SSL_CIPHER  => cipher used (ie RC4-MD5)
SSL_SESSION_ID  => SSL session ID, a big number unique big SSL
SESSION
SSL_CIPHER_USEKEYSIZE   => #bits used in clt<->srv exchange ie: 128

Here is was I got in TC 3.3-M3 (using initial AJP14), with attached
snoop.jsp against Apache 1.3.20/mod_ssl 2.8.4 

Request Information 

JSP Request Method: GET 
Request URI: /examples/jsp/snp/snoop.jsp 
Request Protocol: HTTP/1.0 
Servlet path: /jsp/snp/snoop.jsp 
Path info: null 
Path translated: null 
Query string: null 
Content length: -1 
Content type: null 
Server name: localhost 
Server port: 443 
Remote user: null 
Remote address: 127.0.0.1 
Remote host: localhost 
Authorization scheme: null 

SSL Client Certificate: null 
SSL Cypher Suite: RC4-MD5 
SSL Session Id:
9A9F153F57A505AA3FAB648223929413BC035ACE89FF2735138456F7B38B2CAB 
SSL Key Size: 128 

The browser you are using is Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) 


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


 snoop.jsp

RE: AJP14 - autoconf

[GOMEZ Henri]

Fixed, I didn't have do the ./buildconf.

In README.configure, just replace autoconf by ./buildconf.

I've got a system with Apache 1.3 and 2.0.
1.3 use /usr/sbin/apxs and 2.0 /usr/sbin/apxs2

What about adding a --with-apxs2 to help us use the
correct apxs ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

RE: AJP14 - autoconf

[GOMEZ Henri]

>> Oh, BTW, I don't want to see libtool used anywhere... The 
>would would be a
>> better place without that evil thing... (Doesn't run on OS/X)
>
>You mean it does not support OS/X yet or that is buggy?
>What about aplibtool?

I used to be a Mac Developpers (10 years ago) and allways like 
this platform even if I didn't have one no more ;(

libtool is used in major Unix project and discarding this tool 
for it's 'actual' OS/X incompatibility seems a bad idea.

It will help remove HUGE quantity of questions like

HOW TO BUILD XXX under HP-UX 10, AIX 4.2, SUN-OS 4.1, SOLARIS 8, LINUX 2.4, 

>I agree that libtool could be an evil thing.
>I will try to use LD and CC instead libtool or shlibtool when 
>it is possible.

When building shared libs, libtool will be our friend.

RE: AJP14 - autoconf

[GOMEZ Henri]

>> >> Oh, BTW, I don't want to see libtool used anywhere... The
>> >would would be a
>> >> better place without that evil thing... (Doesn't run on OS/X)
>> >
>> >You mean it does not support OS/X yet or that is buggy?
>> >What about aplibtool?
>> 
>> I used to be a Mac Developpers (10 years ago) and allways like
>> this platform even if I didn't have one no more ;(
>> 
>> libtool is used in major Unix project and discarding this tool
>> for it's 'actual' OS/X incompatibility seems a bad idea.
>
>I will try to get access to an OS/X machine to check libtool 
>there (I have
>already adapted libtool to the BS2000 mainframe, hopefully it 
>is more easy to
>fix libtool that not using it).

I've got a challenge for you. Port libtool to AS/400 :)

>> It will help remove HUGE quantity of questions like
>> 
>> HOW TO BUILD XXX under HP-UX 10, AIX 4.2, SUN-OS 4.1, 
>SOLARIS 8, LINUX 2.4,
>> 
>> >I agree that libtool could be an evil thing.
>> >I will try to use LD and CC instead libtool or shlibtool when
>> >it is possible.
>> 
>> When building shared libs, libtool will be our friend.
>
>I have just noted that apxs of Apache-2.0 calls libtool... 
>libtool has to be our
>friend!
>
>By the way my apxs (2.0) tries to build an excutable instead a 
>dynamic library,
>has someone seen a problem like that? (evil libtool or JF's 
>big fingers?:-( ).

I didn't have such problem here using Linux :)
And I use your apache 2.0 (or may be mine, what was the latest
of our 2 pacthes commit ?)

RE: AJP14 - autoconf

[GOMEZ Henri]

>>By the way my apxs (2.0) tries to build an excutable instead a 
>>dynamic library,
>>has someone seen a problem like that? (evil libtool or JF's 
>>big fingers?:-( ).
>
>I didn't have such problem here using Linux :)
>And I use your apache 2.0 (or may be mine, what was the latest
>of our 2 pacthes commit ?)

I mean the actual apxs (which was patched by JF or I to support
multiple source files)

:)

removing src level in jk for jtc

[GOMEZ Henri]

Who could do that ? 
Kevin/JF ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 3:57 AM
>To: [EMAIL PROTECTED]
>Subject: Re: cvs commit: jakarta-tomcat-4.0/connectors/scandoc
>scandoc.pl template.pl
>
>
>jean-frederic clere at [EMAIL PROTECTED] wrote:
>> 
>> I would propose to remove the src level in jk...
>
>I like this better :)
>
>Pier
>

RE: removing src level in jk for jtc

[GOMEZ Henri]

I've got some commit to do, could you wait 1 or 2 hours before ?


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 2:53 PM
>To: [EMAIL PROTECTED]
>Subject: Re: removing src level in jk for jtc
>
>
>i was just about to send a mail about that... i will do it :)  
>
>i planning on doing this directly in cvs (rather than doing cvs add or
>cvs import).  speak now if you have objections :)
>
>-kevin.
>
>GOMEZ Henri wrote:
>> 
>> Who could do that ?
>> Kevin/JF ?
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>> >-Original Message-
>> >From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>> >Sent: Friday, June 08, 2001 3:57 AM
>> >To: [EMAIL PROTECTED]
>> >Subject: Re: cvs commit: jakarta-tomcat-4.0/connectors/scandoc
>> >scandoc.pl template.pl
>> >
>> >
>> >jean-frederic clere at [EMAIL PROTECTED] wrote:
>> >>
>> >> I would propose to remove the src level in jk...
>> >
>> >I like this better :)
>> >
>> >Pier
>> >
>

RE: buffers in jakarta-tomcat-connectors

[GOMEZ Henri]

>Unless someone has reasons not to, I will start changing the build 
>process to use the buffers and low-level objects in j-t-c. Over
>the weekend I'll try to finish the move of all connector code 
>into j-t-c, where it belongs.

+1 for buffer stuff. 

RE: RPM of 3.3m3 - XERCES-J instead of JAXP - Agree ?

[GOMEZ Henri]

Could you give me info on how to rebuild crimson
from xml-commons, xml-crimson and xml-xalan ?

Thanks.

I'll package a RPM to falsehope.com :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, June 06, 2001 8:41 AM
>To: [EMAIL PROTECTED]
>Subject: Re: RPM of 3.3m3 - XERCES-J instead of JAXP - Agree ?
>
>
>
>What about using jaxp-1.1 ? You can now build the whole thing from 
>xml-commons, xml-crimson and xml-xalan. 
>
>Jaxp1.0 is quite old, we should upgrade ( many bugs were fixed  ).
>
>I personally prefer using crimson ( but I can live with 
>xerces1 ) - code
>size is the one reason ( I also worked much more with crimson 
>). Long term
>we'll use xerces2 of course. 
>
>Costin
>
>
>
>On Tue, 5 Jun 2001, GOMEZ Henri wrote:
>
>> Just to comment the RPM building :
>> 
>> In my TC 3.3-m3 RPM, I choose to use xerces-j >= 1.2
>> instead of the jaxp 1.1 present on TC 3.3
>> 
>> I add the RPM dependency and didn't install jaxp.jar
>> and parser.jar. At install time the RPM make a link
>> to xerces in common lib :
>> 
>> ln -s /usr/share/java/xerces.jar /var/tomcat/lib/common/xerces.jar
>> 
>> Do you (users) agree ?
>> 
>> In TC 3.2.2, I was installing a required jaxp.jar and parser.jar
>> but in some case you could just have xerces.jar installed :!
>> 
>> I'll modify the spec and will release an updated RPM ASAP.
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .) 
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>> 
>> 
>> 
>> >-Original Message-
>> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, June 05, 2001 12:58 PM
>> >To: [EMAIL PROTECTED]
>> >Subject: RE: RPM of 3.3m3 dependencies
>> >
>> >
>> >xerces>
>> >>I try to install on Mandrake 8.0,  tomcat-3.3-m3.1.noarch.rpm  
>> >> and it has 
>> >>a dependencie on Xerces-j. I found it at xml.apache.org, but 
>> >>no rpm what DO 
>> >>you have a solution ?
>> >>ps: I then check with  tomcat-3.2.2-1.noarch.rpm   and 
>> >>everything works 
>> >>perfectly.
>> >
>> >Apache rpms are allways available at :
>> >
>> >ftp://ftp.falsehope.com/home/gomez/xerces-j/
>> >ftp://ftp.falsehope.com/home/gomez/xalan-j/
>> >ftp://ftp.falsehope.com/home/gomez/tomcat/
>> >
>> >Warning if you use also xalan-j 2.1.0 since this
>> >one will failed to use xerces.jar if you have jaxp.jar
>> >and parser.jar in THE SAME DIRECTORY THAT xalan.jar.
>> >
>> >I make a bug report on xalan list :)
>> >
>> 
>

RE: [ANNOUNCE] Domino redirector 1.0.2

[GOMEZ Henri]

>Version 1.0.2 of the Lotus Domino redirector for Win32 and Linux is
>available now at
>
>  http://free.tagish.net/domino-tomcat/
>
>The main change is a fix to the SSL handling that means that SSL
>connections are now correctly reported to Tomcat.

Excellent !:)

Will you commit it ?

RE: [ANNOUNCE] Domino redirector 1.0.2

[GOMEZ Henri]

7 vote +1, no vote -1

You're now commiter:

Craig is a little busy with JavaOne but I'm sure
he will do the necessary next week.

I'll do the commit :)


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 3:36 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [ANNOUNCE] Domino redirector 1.0.2
>
>
>GOMEZ Henri wrote:
>> 
>> >Version 1.0.2 of the Lotus Domino redirector for Win32 and Linux is
>> >available now at
>> >
>> >  http://free.tagish.net/domino-tomcat/
>> >
>> >The main change is a fix to the SSL handling that means that SSL
>> >connections are now correctly reported to Tomcat.
>> 
>> Excellent !:)
>> 
>> Will you commit it ?
>
>I don't seem to have commit rights yet -- I didn't really hear much
>after the vote. Otherwise I would have ;-)
>
>-- 
>Andy Armstrong, Tagish
>

RE: removing src level in jk for jtc

[GOMEZ Henri]

I'll finish in half hour...

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 3:11 PM
>To: [EMAIL PROTECTED]
>Subject: Re: removing src level in jk for jtc
>
>
>i'll wait until around 12pm CDT -- that's about 4 hours from now :)
>
>GOMEZ Henri wrote:
>> 
>> I've got some commit to do, could you wait 1 or 2 hours before ?
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> 
>> >-Original Message-
>> >From: kevin seguin [mailto:[EMAIL PROTECTED]]
>> >Sent: Friday, June 08, 2001 2:53 PM
>> >To: [EMAIL PROTECTED]
>> >Subject: Re: removing src level in jk for jtc
>> >
>> >
>> >i was just about to send a mail about that... i will do it :)
>> >
>> >i planning on doing this directly in cvs (rather than doing 
>cvs add or
>> >cvs import).  speak now if you have objections :)
>> >
>> >-kevin.
>> >
>> >GOMEZ Henri wrote:
>> >>
>> >> Who could do that ?
>> >> Kevin/JF ?
>> >>
>> >> -
>> >> Henri Gomez ___[_]
>> >> EMAIL : [EMAIL PROTECTED](. .)
>> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>> >>
>> >> >-Original Message-
>> >> >From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>> >> >Sent: Friday, June 08, 2001 3:57 AM
>> >> >To: [EMAIL PROTECTED]
>> >> >Subject: Re: cvs commit: jakarta-tomcat-4.0/connectors/scandoc
>> >> >scandoc.pl template.pl
>> >> >
>> >> >
>> >> >jean-frederic clere at [EMAIL PROTECTED] wrote:
>> >> >>
>> >> >> I would propose to remove the src level in jk...
>> >> >
>> >> >I like this better :)
>> >> >
>> >> >Pier
>> >> >
>> >
>

RE: Help with Code in jk_nwmain.c.

[GOMEZ Henri]

Why did you compile Netware code on HP-UX ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 10:01 PM
>To: [EMAIL PROTECTED]
>Subject: Help with Code in jk_nwmain.c.
>
>
>
>
>
>
>I am trying to compile mod_jk in HPUX11.00 in 32 bit mode. I am using
>Tomcat3.2.1
>I am getting these error messages saying: 
>
>../jk/jk_nwmain.c line 62 -unexpected void
>../jk/jk_nwmain.c  line 64 TSR_THREAD undefined.
>
>
>What am I doing wrong???
>
>Thanks,
>
>Joyce
>
>
>Code from jk_nwmain.c
>==
>
>
>
>static void main();
>#ifdef NETWARE
>/*
> * NATIVE_MAIN
> */
>
>/*
> * INCLUDES
> */
>
>#include 
>#include 
>#include 
>
>NETDB_DEFINE_CONTEXT
>
>/*
> * main ()
> *
> * Main entry point -- don't do much more than I've provided
> *
> * Entry:
> *
> * Exit:
> *Nothing
> */
>
>void main ()
>{
>   ExitThread (TSR_THREAD, 0); 
>}
>
>#elif HPUX11
>/*
> * NATIVE_MAIN
> */
>
>  /*
>   * INCLUDES
>   */
>
>#include 
>#include 
>#include 
>
>NETDB_DEFINE_CONTEXT
>
>  /*  # Can I generate an error  --- yes if not remmed out */
>
>
>/*
> * main ()
> *
> * Main entry point -- don't do much more than I've provided
> *
> * Entry:
> *
> * Exit:
> *Nothing
> */
>
> void main()
> {
>ExitThread (TSR_THREAD, 0);
> }
>#endif
>

RE: [j-t-c] src level directories removed...

[GOMEZ Henri]

Could you also remove the unused apache1.3 and apache2.0.
We're using apache-1.3 and apache-2.0 now :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 10:02 PM
>To: [EMAIL PROTECTED]
>Subject: [j-t-c] src level directories removed...
>
>
>... in jtc/util and jtc/jk.
>

RE: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13Packet.java

[GOMEZ Henri]

>seguin  01/06/08 12:49:52
>
>  Modified:jk/java/org/apache/ajp Ajp13Packet.java
>  Log:
>  [bug fix] send right header to webserver.
>  now i'm glad i added a junit test ;-)
>  
>  Revision  ChangesPath
>  1.6   +2 -2  
>jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13Packet.java

Thanks, I'm guilty here, dan't copy/paste ;)


>  Index: Ajp13Packet.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp1
>3Packet.java,v
>  retrieving revision 1.5
>  retrieving revision 1.6
>  diff -u -r1.5 -r1.6
>  --- Ajp13Packet.java 2001/06/07 13:42:36 1.5
>  +++ Ajp13Packet.java 2001/06/08 19:49:51 1.6
>  @@ -198,8 +198,8 @@
>   public void reset() {
>   len = 4;
>   pos = 4;
>  -buff[0] = (byte)(AJP13_WS_HEADER >> 8);
>  -buff[1] = (byte)(AJP13_WS_HEADER & 0xFF);
>  +buff[0] = (byte)(AJP13_SW_HEADER >> 8);
>  +buff[1] = (byte)(AJP13_SW_HEADER & 0xFF);
>   }
>   
>   /**
>  
>  
>  
>

AJP14 - header

[GOMEZ Henri]

What about using the same header for both side in
AJP14 ?

In AJP13, we're using 0x1234 when web->servlet and 
'AB' when servlet->web.

Ajp14 use now 0x1235 in web->servlet side and 
'Ac' in servlet->web side.

What about using 0x1235 in both side (in Ajp14),
just to be consistent 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 11:47 PM
>To: [EMAIL PROTECTED]
>Subject: RE: cvs commit:
>jakarta-tomcat-connectors/jk/java/org/apache/ajp Ajp13Packet.java
>
>
>>seguin  01/06/08 12:49:52
>>
>>  Modified:jk/java/org/apache/ajp Ajp13Packet.java
>>  Log:
>>  [bug fix] send right header to webserver.
>>  now i'm glad i added a junit test ;-)
>>  
>>  Revision  ChangesPath
>>  1.6   +2 -2  
>>jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13Packet.java
>
>Thanks, I'm guilty here, dan't copy/paste ;)
>
>
>>  Index: Ajp13Packet.java
>>  ===
>>  RCS file: 
>>/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp1
>>3Packet.java,v
>>  retrieving revision 1.5
>>  retrieving revision 1.6
>>  diff -u -r1.5 -r1.6
>>  --- Ajp13Packet.java2001/06/07 13:42:36 1.5
>>  +++ Ajp13Packet.java2001/06/08 19:49:51 1.6
>>  @@ -198,8 +198,8 @@
>>   public void reset() {
>>   len = 4;
>>   pos = 4;
>>  -buff[0] = (byte)(AJP13_WS_HEADER >> 8);
>>  -buff[1] = (byte)(AJP13_WS_HEADER & 0xFF);
>>  +buff[0] = (byte)(AJP13_SW_HEADER >> 8);
>>  +buff[1] = (byte)(AJP13_SW_HEADER & 0xFF);
>>   }
>>  
>>   /**
>>  
>>  
>>  
>>
>

RE: AJP14 - autoconf (apxs 2.0 buggy?)

[GOMEZ Henri]

>> Strange,
>> 
>> I didn't have that, libtool use mod_jk.la :
>> 
>> make -f Makefile.linux
>> 
>> /usr/sbin/apxs2 -DUSE_APACHE_MD5 -I ../common -I 
>/opt/IBMJava2-13/include -I
>> /opt/IBMJava2-13/include/linux -c -o mod_jk.la mod_jk.c
>
>mod_jk.la that why I am complaining!
>Should not we able to use mod_jk.so directly?

Yes it seems there is something bad here.
I tried many things before using .la.

Do you see what to fix in apxs ?

>apxs of Apache-1.3 does it that way.

Yes, so we need to fix apxs ?

RE: AJP14 - autoconf (apxs 2.0 buggy?)

[GOMEZ Henri]

/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_uri_worker_map.lo ../common/jk_uri_worker_map.c && touch
../common/jk_uri_worker_map.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp14.lo ../common/jk_ajp14.c && touch
../common/jk_ajp14.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp14_worker.lo ../common/jk_ajp14_worker.c && touch
../common/jk_ajp14_worker.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_md5.lo ../common/jk_md5.c && touch ../common/jk_md5.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_context.lo ../common/jk_context.c && touch
../common/jk_context.slo
libtool --silent --mode=compile gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -I/usr/include/apache2 -I../common
-I/opt/IBMJava2-13/include -I/opt/IBMJava2-13/include/linux -DUSE_APACHE_MD5
-c -o ../common/jk_ajp_common.lo ../common/jk_ajp_common.c && touch
../common/jk_ajp_common.slo
libtool --silent --mode=link gcc -O2 -m486 -fno-strength-reduce  -pthread
-DNO_DBM_REWRITEMAP -o mod_jk.la -rpath /usr/lib/apache2 -module
-avoid-version  ../common/jk_ajp_common.lo ../common/jk_context.lo
../common/jk_md5.lo ../common/jk_ajp14_worker.lo ../common/jk_ajp14.lo
../common/jk_uri_worker_map.lo ../common/jk_map.lo ../common/jk_sockbuf.lo
../common/jk_lb_worker.lo ../common/jk_ajp13_worker.lo
../common/jk_worker.lo ../common/jk_pool.lo ../common/jk_jni_worker.lo
../common/jk_ajp13.lo ../common/jk_util.lo ../common/jk_msg_buff.lo
../common/jk_connect.lo ../common/jk_ajp12_worker.lo mod_jk.lo
mv .libs/mod_jk.so .

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: jean-frederic clere [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 08, 2001 1:08 PM
>To: [EMAIL PROTECTED]
>Cc: Martin Kraemer; [EMAIL PROTECTED]
>Subject: Re: AJP14 - autoconf (apxs 2.0 buggy?)
>
>
>GOMEZ Henri wrote:
>> 
>> >>By the way my apxs (2.0) tries to build an excutable instead a
>> >>dynamic library,
>> >>has someone seen a problem like that? (evil libtool or JF's
>> >>big fingers?:-( ).
>> >
>> >I didn't have such problem here using Linux :)
>> >And I use your apache 2.0 (or may be mine, what was the latest
>> >of our 2 pacthes commit ?)
>> 
>> I mean the actual apxs (which was patched by JF or I to support
>> multiple source files)
>> 
>> :)
>
>Martin committed your patch for apxs (some weeks ago)
>
>But a little more fixing is needed in apxs: It calls libtool 
>-o mod_jk.so
>instead -o mod_jk.la.
>+++
>Usage: apxs -g [-S =] -n
> 
>   apxs -q [-S =]  ...
> 
>   apxs -c [-S =] [-o ] [-D 
>[=]]
>   [-I ] [-L ] [-l ] 
>[-Wc,] 
>   [-Wl,]  ...   
> 
>   apxs -i [-S =] [-a] [-A] [-n ] 
> ...  
>   apxs -e [-S =] [-a] [-A] [-n ] 
> ...  
>+++
>The end user should not worry about *.la files if when he 
>tries to use apxs. Any
>objections?
>
>Cheers
>
>Jean-frederic
>

Apache 2.0.18 problem with mod_jk and

[GOMEZ Henri]

I've got some problems with Apache 2.0.18 and mod_jk
with Internet Explorer 5.5 and Mozilla 0.8.1.

Even if there is a network traffic (I attached the
ethereal logs (tcpdump compatible)), I couldn't get 
the Tomcat pages.

No problem with Netscape 4.77 ?

I've got no problem with static pages using NS/IE/MZ.

If some expert could take a look at this and give me pointer
on what is bad. (May be a flush missing somewhere since I didn't
remember having such problem with at leats Apache 2.0.15)

Regards

JK-80 is for traffic using Apache 1.3.20
JK-8092 is for traffic using Apache 2.0.18-alpha

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


 jk-8092
 jk-80

RE: [j-t-c] src level directories removed...

[GOMEZ Henri]

Yes please :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: kevin seguin [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, June 09, 2001 1:06 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [j-t-c] src level directories removed...
>
>
>GOMEZ Henri wrote:
>> 
>> Could you also remove the unused apache1.3 and apache2.0.
>> We're using apache-1.3 and apache-2.0 now :)
>> 
>
>they appear to have cvs rm'd, do you want them to be physically removed
>too?
>

RE: [JTC] Use of DOXYGEN instead of SCANDOC...

[GOMEZ Henri]

I just started to look at doxygen.

A nice tool but may require many 
extras stuff (qt-2.1.0), tetex 1.0...

The current RPM build of doxygen failed about
missing command moc (a qt devel tool).

Did you succeed build doxygen under MacOs X ?

We'll have to see if all commiters (I think here
at Mike Anderson and JF Clere) could use it on
their build hosts...


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, June 09, 2001 8:22 PM
>To: tomcat dev jakarta.apache.org
>Subject: [JTC] Use of DOXYGEN instead of SCANDOC...
>
>
>What do you think about DOXYGEN 
>?
>I'm thinking about changing from SCANDOC to DOXYGEN for the 
>automatically
>generated documentation from C code...
>
>Pier
>

RE: [JTC] Use of DOXYGEN instead of SCANDOC...

[GOMEZ Henri]

>Well I am not willing to change somethings that works!
>APR is using SCANDOC. SCANDOC uses PERL and does not mean 
>extra porting work for
>me.

Even on my Linux Redhat box, it's not an easy task to 
install doxygen. 

The RPM found around are against libstdc++ 2.96
and qt-devel 2.1 (+/- Redhat 7.1)

When I want to rebuild it under my Redhat 6.2 box,
I've got to install latext, and next go problems 
with a required ginstall (in doxygen 1.2.8.1).

May be just to complex for our use.

>Changing to DOXYGEN sounds bad for me because:
>- It is written C it have to will to port to the platfroms we 
>want to support.
>(And that work does not looks easy).
>- Why changing a tool that works fine?
>- Why using a different documentation tool in each ASF project?

+1

>I would more happy using a JAVA written tool than a C/C++ one.

++1

RE: Apache 2.0.18 problem with mod_jk and

[GOMEZ Henri]

I reverted to Apache 2.0.16 beta and I still have the problem.

lynx/ns 4.77 works well but IE5.5/MZ failed to get the dynamic
pages

The traffic is very similar :)

IE5.5 works when switching to HTTP 1.0

Any idea ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6