RE: First day - RE: PROPOSAL: Tomcat docs
>11. Load-balancing >that it can be done through mod_jserv and mod_jk> mod_jserv support fault-tolerant and load-balancing mode. original mod_jk support only load-balancing but a recent patch (found in J-T-C) allow you to configure mod_jk in fault-tolerant only. ie when you have a cluster of tomcat be sure that all requests will goes to primary tomcat (worker) and backup tc will be use only in case of failure of the primary. I'm very happy to see how people respond to documentations and all this preliminary organisation. Question what about having a more detailed coverage of Tomcat's architecture ? ie: How to write TC 3.3 Interceptors, write 4.0 filters, writing realms. Final question will be who will be ready to participate in jakarta-tomcat-documentation (J-T-D). What about creating the jakarta-tomcat-documentation cvs and then vote for commiters on that CVS (and maybe only on that CVS) ?
[J-T-C] uniq workers.properties file and virtual hosting
Hi to all, Costin proposed sometimes ago to have an uniq workers.properties file which will handle all the configuration directive and settings. What about the case of virtual hosting ? For example, in Apache 1.3/2.0, it's nice to be able to use a JkMount directive only in a virtual server. I use it extensivelly on my production servers where site A, B and C are hosted on the same Apache 1.3 boxes (using std and ssl). Site A std - only static/php pages Site B std - only static/php pages Site C std - only static/php pages Site A ssl - use contextA (ie /contextA/servlet/hello) Site B ssl - use contextB (ie /contextB/servlet/hello) Site C ssl - use contextC (ie /contextC/servlet/hello) We've got an easy to set configuration JkMount /contextA/servlet/* workerA JkMount /contextA/*.jsp workerA ... JkMount /contextB/servlet/* workerB JkMount /contextB/*.jsp workerB ... JkMount /contextC/servlet/* workerC JkMount /contextC/*.jsp workerC ... How could we set it in an uniq workers.properties files ? Case 1 (workerA only for mysiteA, workerB for mysiteB) worker.workerA.port=8009 worker.workerA.host=remoteA worker.workerA.type=ajp13 worker.workerA.lbfactor=1 worker.workerA.cachesize=8 worker.workerA.virtual=mysiteA worker.workerB.port=8009 worker.workerB.host=remoteB worker.workerB.type=ajp13 worker.workerB.lbfactor=1 worker.workerB.cachesize=8 worker.workerB.virtual=mysiteB Case 2 (workerA & B goes to the same remote) worker.workerA.port=8009 worker.workerA.host=commonremote worker.workerA.type=ajp13 worker.workerA.lbfactor=1 worker.workerA.cachesize=8 worker.workerA.virtual=mysiteA worker.workerB.port=8009 worker.workerB.host=commonremote worker.workerB.type=ajp13 worker.workerB.lbfactor=1 worker.workerB.cachesize=8 worker.workerB.virtual=mysiteB In that case how could we avoid that site A get access to context B and vice-versa ? Should it be restricted in server.xml ? Thanks for your lights here - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: libapr and --disable-shared?
"Pier P. Fumagalli" wrote: > > jean-frederic clere at [EMAIL PROTECTED] wrote: > > > >> DOH! So why do you keep saying that you're against using sources... > >> Since all those problems are simply fixed by using them > > > > No, I am not against using the APR sources, I was just thinking that the time > > needed to change mod_webapp could have been used to fix APR. (But it is more > > complicated that I excepted it). > > Do you think I didn't think about it? So, can you roll back that -1 so I can > commit some changes? Thanks :) Yes, please commit the changes. > > Pier
RE: TC 3.3 strange encoding
>Tc 3.3 now tries to autodetect ( and use ) Jikes where possible..,
>perhaps your tc33 copy is using some Jikes present on your system..,
>
>Only a wild thought Henri..
>
I've got jikes installed, and that may explains why I should have
rt.jar in tomcat.sh (yesterday cvs)
if [ -f ${JAVA_HOME}/jre/lib/rt.jar ] ; then
CLASSPATH=${CLASSPATH}:${JAVA_HOME}/jre/lib/rt.jar
fi
>
>
>> -Mensaje original-
>> De: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>> Enviado el: jueves 5 de julio de 2001 11:54
>> Para: [EMAIL PROTECTED]
>> Asunto: TC 3.3 strange encoding
>>
>>
>> Hi,
>>
>> I've got the following contents in a JSP :
>>
>>
>> -> target="main">Multi-marché
>>
>>
>>
>> Which give me on output :
>>
>> Multi-marché
>>
>> What's the problem :)
>>
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .)
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>>
>
RE: RPM of 3.3m3 dependencies
>What is *noarch*, exactly.. I installed this one because at >the time it was >the only RPM I could find but am I missing out? noarch indicate it's not native code (i386/sparc...) It's java code ...
RE: problems compling mod_jk for apache-1.3 on linux
What about using my RPM ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Donald Ball [mailto:[EMAIL PROTECTED]] >Sent: Thursday, July 05, 2001 10:18 PM >To: [EMAIL PROTECTED] >Subject: problems compling mod_jk for apache-1.3 on linux > > >i'm getting these errors with the latest cvs: > >[root@benjamin apache-1.3]# ./build-unix.sh >APACHE_HOME=/usr/local/apache >Compiling mod_jk >gcc -DLINUX=2 -DMOD_SSL=206106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT >-I../lib/expat-lite -fpic -DSHARED_CORE -DSHARED_MODULE >-I/usr/local/apache/include -I../common -I/usr/local/java/include >-I/usr/local/java/include/linux -c mod_jk.c >In file included from ../common/jk_global.h:68, > from mod_jk.c:94: >../common/jk_version.h:93: parse error before `<' >In file included from ../common/jk_global.h:92, > from mod_jk.c:94: >/usr/include/netinet/tcp.h:84: parse error before `:' >/usr/include/netinet/tcp.h:85: parse error before `:' >/usr/include/netinet/tcp.h:86: parse error before `:' >/usr/include/netinet/tcp.h:87: parse error before `:' >/usr/include/netinet/tcp.h:88: parse error before `:' >/usr/include/netinet/tcp.h:89: parse error before `:' >/usr/include/netinet/tcp.h:90: parse error before `:' >/usr/include/netinet/tcp.h:91: parse error before `:' >/usr/include/netinet/tcp.h:92: parse error before `:' >/usr/include/netinet/tcp.h:109: parse error before `}' >apxs:Break: Command failed with rc=65536 >Installing mod_jk.so into /usr/local/apache/libexec >cp: mod_jk.so: No such file or directory >Done. Install by running ./install-unix.sh > >the parse error in jk_global.h looks to be a problem in j-t-c >repository. >the parse error in tcp.h looks to be a problem with my glibc >installation, >although any clues are welcome as i've never had a problem compiling >anything that used tcp before. also, the build script is erroneously >trying to install mod_jk.so, which it shouldn't do even if the >build was >successful, but absolutely shouldn't do if the build is >unsuccessful. :) >finally, the ./install-unix.sh script doesn't exist. > >fwiw, i'm using glibc-2.1.3-21 on a linux-2.2.19 box with >apache-1.3.12. > >- donald >
cvs commit: jakarta-tomcat-connectors/jk/native/common Makefile.in
jfclere 01/07/06 03:23:02 Modified:jk/native/common Makefile.in Log: rm -f is better that -rm (ignored errors make me nervious). Revision ChangesPath 1.3 +1 -1 jakarta-tomcat-connectors/jk/native/common/Makefile.in Index: Makefile.in === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/Makefile.in,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Makefile.in 2001/06/14 14:38:14 1.2 +++ Makefile.in 2001/07/06 10:22:59 1.3 @@ -13,4 +13,4 @@ install: clean: - -rm *.o *.slo *.lo + rm -f *.o *.slo *.lo
TomCat TCP connector leaking
[This was posted on tomcat-user some weeks ago. As there was no response I am now trying it here.] Hi, we are using TC 3.2.2 in standalone mode on a medium frequented site. I am sure we never have more than 40-50 active, simultaneous connections. However, from time to time I see the message "thread pool exhausted" in jvm.stderr. I have raised the max_threads parameter in server.xml, lets see if this helps. However, I actually wonder how 100 threads can be used? Our application has some long running servlets in push mode, but definitely not that much. So I ask myself whether the thread pool of the TCP connector is leaking? My question is: How would I debug the TCP connector? How can I determine, which threads are actually busy, running which servlet and which are waiting? Thanks, Jochen
Re: First day - RE: PROPOSAL: Tomcat docs
Antony Bowesman wrote: > > Glenn Nielsen wrote: > > > > Antony Bowesman wrote: > > > > > > > 8. Security > > > > > > How about > > > 8.1 Concepts - Explanation of J2EE and Java 2 security models > > > 8.2 Authentication with Realms > > > 8.2.1 Simple realm > > > 8.2.2 JDBC Realm > > > 8.2.3 Custom realms > > > 8.3 Authorization > > > 8.3.1 J2EE role based > > > > > > In particular, it should try to explain in simpler terms than the API > > > spec how J2EE roles are designed to work, covering the mapping from > > > developer roles to deployment roles. > > > > > > 8.3.2 Java 2 security policy > > > > > > > I would break the above into two sections. > > > > Access Control (for all the Realm based access control) > > > > and > > > > Server Security (for configuring and using Tomcat with the Java > > SecurityManager) > > > > These really are two completely different topics. And use of > > Realms isn't "Security", it is "Access Control". > > Not sure I'd agree with your removal of Java Security Manager from a > chapter about access control. The first line of the JavaTM 2 Platform > Security Introduced: document at > > http://java.sun.com/j2se/1.3/docs/guide/security/index.html > > says > > * Policy-based, easily-configurable, fine-grained access control > > Access control is one element of securing a server, as is > authentication, encryption, non repudiation, SSL etc. > > Access control is performed by Java 2 security manager as well as J2EE > and they compliment each other. JAAS (JDK1.3 extension) which extends > the Java 2 model and which is now included in JDK1.4 extends the Java 2 > security model to provide principal based access control on top of code > source. So access control is firmly part of Java security. > > There should be additional sections on 'server security' that includes > configuring the server for use with SSL. > I have seen the general term 'security' used instead of a more descriptive term like SSL Encryption, SecurityManager, or Access Control. My point is that these are very different things, and the documentation should be constructed so that users use those terms rather than the general term "Security". Security Overview - types of security J2EE Security Model User Access Control (Realms & roles) Java SecurityManager SSL Data Encryption Yes, JAAS can be used to control access for executing code based on what role the user is in. At this point there is no support in Tomcat for JAAS. There are two ways I see JAAS being used within Tomcat sometime in the future. 1. Policy based JAAS access control to Tomcat's manager or admin servlet. 2. Some Policy configuration tool for webapps that supports normal Java SecurityManager configuration and JAAS policy based access control. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: First day - RE: PROPOSAL: Tomcat docs
Glenn, Glenn Nielsen wrote: > > Antony Bowesman wrote: > > > > Glenn Nielsen wrote: > > > > > > Antony Bowesman wrote: > > > > > > > > > 8. Security > > > > > > > > How about > > > > 8.1 Concepts - Explanation of J2EE and Java 2 security models > > > > 8.2 Authentication with Realms > > > > 8.2.1 Simple realm > > > > 8.2.2 JDBC Realm > > > > 8.2.3 Custom realms > > > > 8.3 Authorization > > > > 8.3.1 J2EE role based > > > > > > > > In particular, it should try to explain in simpler terms than the API > > > > spec how J2EE roles are designed to work, covering the mapping from > > > > developer roles to deployment roles. > > > > > > > > 8.3.2 Java 2 security policy > > > > > > > > > > I would break the above into two sections. > > > > > > Access Control (for all the Realm based access control) > > > > > > and > > > > > > Server Security (for configuring and using Tomcat with the Java > > > SecurityManager) > > > > > > These really are two completely different topics. And use of > > > Realms isn't "Security", it is "Access Control". > > > > Not sure I'd agree with your removal of Java Security Manager from a > > chapter about access control. The first line of the JavaTM 2 Platform > > Security Introduced: document at > > > > http://java.sun.com/j2se/1.3/docs/guide/security/index.html > > > > says > > > > * Policy-based, easily-configurable, fine-grained access control > > > > Access control is one element of securing a server, as is > > authentication, encryption, non repudiation, SSL etc. > > > > Access control is performed by Java 2 security manager as well as J2EE > > and they compliment each other. JAAS (JDK1.3 extension) which extends > > the Java 2 model and which is now included in JDK1.4 extends the Java 2 > > security model to provide principal based access control on top of code > > source. So access control is firmly part of Java security. > > > > There should be additional sections on 'server security' that includes > > configuring the server for use with SSL. > > > > I have seen the general term 'security' used instead of a more > descriptive term like SSL Encryption, SecurityManager, or Access > Control. My point is that these are very different things, and > the documentation should be constructed so that users use those > terms rather than the general term "Security". Yes, I agree there are different elements of security, I don't agree that access control is different to security manager. The difference is that java 2 security, i.e. security manager, is different to J2EE role based access control. > Security > Overview - types of security > J2EE Security Model > User Access Control (Realms & roles) > Java SecurityManager > SSL Data Encryption > > Yes, JAAS can be used to control access for executing code based > on what role the user is in. At this point there is no support > in Tomcat for JAAS. Not specifically, because the servlet API spec does not support it, however, JAAS is on the list for servlet API spec 2.4 (who knows when that might be!). However, I am currently using JAAS in Tomcat 3 and I know others have JAAS running with tomcat (e.g. Jboss/Tomcat integration) > There are two ways I see JAAS being used within Tomcat sometime in > the future. > > 1. Policy based JAAS access control to Tomcat's manager or admin > servlet. > > 2. Some Policy configuration tool for webapps that supports normal Java > SecurityManager configuration and JAAS policy based access control. I suspect that when the API spec supports JAAS there will be some kind of getUserSubject() method in the spec that gets the JAAS Subject and the getUserPrincipal() will be deprecated because JAAS supports more than a single Principal. However, as SecurityManager uses the Java 2 security Policy it effectively enable JAAS support as soon as JDK1.4 is released. Tomcat could therefore provide support for the JAAS Subject internally. However, I have seen other comments on this list that Tomcat is trying to support many early versions of JDK so requiring JDK1.4 support might be too difficult. Anyway, SUN are asking for feedback about how JAAS should be implemented in the servlet API spec, so send your comments there, I already have! Rgds Antony
AW: What will happen to BUG #2333
Hi Tom, > "Thomas Colin de Verdiere" wrote: > what's your problem in ajp12 the problem, using sendRedirect( very long URL ) should send a HTTP-Header to the client like : HTTP/1.1 302 FOUND Location: the new location the Result i got was something like HTTP/1.1 302 htp:// and a lot of more date somtimes whith newlines in it Date: some more header after empty line ... The result was: The client could not show the new page. In the file jk_ajp12_worker.c i found the reason. In function ajp12_handle_response() the call jk_sb_get( ,&line ) will fill the buffer line. After finding the word "Status" in this line the pointer reason will save the adress of the beginning of the reason in the line. "FOUND" in my case. Aditional calls to jk_sb_get() will fill the buffer line with new data. So the pointer reason becomes invalid and points to some undefined data. This data will be printed later as Reason after HTTP/1.1 302 I fixed this - in a patch i send to this list. Was that the right way ? Who will add this to the current source-tree ? Dirk
AW: What will happen to BUG #2333
Hi Andrej, > Von: Andrej Koelewijn [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 5. Juli 2001 16:05 > I think sending 'content-disposition: attachment' in the http > headers will > cause msie to save the file. But I'm not sure if it's > supported in 5.0... Sounds good - i will have a look at it thanks Dirk
RE: What will happen to BUG #2333
I'll check the patch but frankly ajp12 is pretty deprecated today switch to ajp13 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Roloff, Dirk [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 06, 2001 4:01 PM >To: '[EMAIL PROTECTED]' >Subject: AW: What will happen to BUG #2333 > > >Hi Andrej, > >> Von: Andrej Koelewijn [mailto:[EMAIL PROTECTED]] >> Gesendet: Donnerstag, 5. Juli 2001 16:05 >> I think sending 'content-disposition: attachment' in the http >> headers will >> cause msie to save the file. But I'm not sure if it's >> supported in 5.0... > >Sounds good - i will have a look at it > >thanks > >Dirk >
inquiry about load balancing
Hi folks I am working on load balancing(failover) on Apache-tomcat server. Can you guys send me the maximum possible details concerned with this. i have to work with java. thanks & regds Jayakrishnan __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: inquiry about load balancing
JAYAKRISHNAN.E.K koroth at [EMAIL PROTECTED] wrote: > Hi folks > > I am working on load balancing(failover) on > Apache-tomcat server. Can you guys send me the maximum > possible details concerned with this. i have to work > with java. My bad... I approved this by mistake instead of redirecting to users... Pier
RE: problems compling mod_jk for apache-1.3 on linux
On Fri, 6 Jul 2001, GOMEZ Henri wrote: > What about using my RPM ? i could do, but i wanted to try to get the latest cvs working. as it stands now, it doesn't build. is that to be expected? - donald
question about the thread pool of Tomcat
Hi, everyone, I am doing some performance testing with application running on Tomcat 3.2.1. Can you please tell me how I can tune Tomcat to affect the server performance, such as the thread pool, or any other configurable numbers? Many thanks in advance. Sincerely, Li
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
hgomez 01/07/06 08:27:17 Modified:jk/native/common jk_version.h Log: Invalid line split use (at least in gcc) Revision ChangesPath 1.2 +2 -3 jakarta-tomcat-connectors/jk/native/common/jk_version.h Index: jk_version.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jk_version.h 2001/06/29 11:09:54 1.1 +++ jk_version.h 2001/07/06 15:27:15 1.2 @@ -58,7 +58,7 @@ /*** * Description: Socket buffer header file * * Author: Jean-Frederic Clere <[EMAIL PROTECTED]> * - * Version: $Revision: 1.1 $ * + * Version: $Revision: 1.2 $ * ***/ #ifndef __JK_VERSION_H @@ -89,8 +89,7 @@ #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-beta-" JK_BETASTRING #endif -#define JK_MAKEVERSION(major, minor, fix, beta) \ - (((major) << 24) + ((minor) << 16) + ((fix) << 8) + (beta)) +#define JK_MAKEVERSION(major, minor, fix, beta) (((major) << 24) + ((minor) << 16) + ((fix) << 8) + (beta)) #define JK_VERSION JK_MAKEVERSION(JK_VERMAJOR, JK_VERMINOR, JK_VERFIX, JK_VERBETA)
RE: problems compling mod_jk for apache-1.3 on linux
I fixed version.h (bad / split line) and here is the steps : You should use : cd jakarta-tomcat-connectors/jk/native/ ./buildconf.sh ./configure --with-apxs=/usr/sbin/apxs --enable-jni --with-java-home=/opt/IBMJava2-13 --with-java-platform=2 cd apache-1.3/ make -f Makefile.apxs cp mod_jk.so /usr/lib/apache/ Enjoy :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Donald Ball [mailto:[EMAIL PROTECTED]] >Sent: Thursday, July 05, 2001 10:18 PM >To: [EMAIL PROTECTED] >Subject: problems compling mod_jk for apache-1.3 on linux > > >i'm getting these errors with the latest cvs: > >[root@benjamin apache-1.3]# ./build-unix.sh >APACHE_HOME=/usr/local/apache >Compiling mod_jk >gcc -DLINUX=2 -DMOD_SSL=206106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT >-I../lib/expat-lite -fpic -DSHARED_CORE -DSHARED_MODULE >-I/usr/local/apache/include -I../common -I/usr/local/java/include >-I/usr/local/java/include/linux -c mod_jk.c >In file included from ../common/jk_global.h:68, > from mod_jk.c:94: >../common/jk_version.h:93: parse error before `<' >In file included from ../common/jk_global.h:92, > from mod_jk.c:94: >/usr/include/netinet/tcp.h:84: parse error before `:' >/usr/include/netinet/tcp.h:85: parse error before `:' >/usr/include/netinet/tcp.h:86: parse error before `:' >/usr/include/netinet/tcp.h:87: parse error before `:' >/usr/include/netinet/tcp.h:88: parse error before `:' >/usr/include/netinet/tcp.h:89: parse error before `:' >/usr/include/netinet/tcp.h:90: parse error before `:' >/usr/include/netinet/tcp.h:91: parse error before `:' >/usr/include/netinet/tcp.h:92: parse error before `:' >/usr/include/netinet/tcp.h:109: parse error before `}' >apxs:Break: Command failed with rc=65536 >Installing mod_jk.so into /usr/local/apache/libexec >cp: mod_jk.so: No such file or directory >Done. Install by running ./install-unix.sh > >the parse error in jk_global.h looks to be a problem in j-t-c >repository. >the parse error in tcp.h looks to be a problem with my glibc >installation, >although any clues are welcome as i've never had a problem compiling >anything that used tcp before. also, the build script is erroneously >trying to install mod_jk.so, which it shouldn't do even if the >build was >successful, but absolutely shouldn't do if the build is >unsuccessful. :) >finally, the ./install-unix.sh script doesn't exist. > >fwiw, i'm using glibc-2.1.3-21 on a linux-2.2.19 box with >apache-1.3.12. > >- donald >
Re: First day - RE: PROPOSAL: Tomcat docs
> Question what about having a more detailed coverage of Tomcat's > architecture ? > > ie: How to write TC 3.3 Interceptors, write 4.0 filters, writing > realms. Yes, there needs to be a separate Developers' Guide. Here's my first pass at that. I'll be revising my whole TOC as soon as I get some coffee, so don't take this *too* seriously... :-) Part V: Tomcat Development Covers actually writing code for the Tomcat code base. 1. Tomcat 3.x vs 4.x 2. Overview of Tomcat code base 3. Downloading and Building the source code - Using CVS - Downloading - Building - Using Ant 4. Fixing Bugs 5. Developing Interceptors (Tomcat 3.x) 6. Developing Valves (Tomcat 4.x) 7. Developing Connectors - mod_jserv - mod_jk - mod_webapp 8. Using Tomcat Utility Classes > Final question will be who will be ready to participate > in jakarta-tomcat-documentation (J-T-D). What about creating > the jakarta-tomcat-documentation cvs and then vote for commiters > on that CVS (and maybe only on that CVS) ? I'm in. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
RE: First day - RE: PROPOSAL: Tomcat docs
I'll help for mod_jk connector :) Count me on - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Alex Chaffee [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 06, 2001 5:28 PM >To: [EMAIL PROTECTED] >Subject: Re: First day - RE: PROPOSAL: Tomcat docs > > > >> Question what about having a more detailed coverage of Tomcat's >> architecture ? >> >> ie: How to write TC 3.3 Interceptors, write 4.0 filters, writing >> realms. > > >Yes, there needs to be a separate Developers' Guide. Here's my first >pass at that. I'll be revising my whole TOC as soon as I get some >coffee, so don't take this *too* seriously... :-) > > >Part V: Tomcat Development > >Covers actually writing code for the Tomcat code base. > >1. Tomcat 3.x vs 4.x > >2. Overview of Tomcat code base > >3. Downloading and Building the source code > >- Using CVS >- Downloading >- Building >- Using Ant > >4. Fixing Bugs > >5. Developing Interceptors (Tomcat 3.x) > >6. Developing Valves (Tomcat 4.x) > >7. Developing Connectors > >- mod_jserv >- mod_jk >- mod_webapp > >8. Using Tomcat Utility Classes > > >> Final question will be who will be ready to participate >> in jakarta-tomcat-documentation (J-T-D). What about creating >> the jakarta-tomcat-documentation cvs and then vote for commiters >> on that CVS (and maybe only on that CVS) ? > > >I'm in. > > >-- >Alex Chaffee mailto:[EMAIL PROTECTED] >jGuru - Java News and FAQs http://www.jguru.com/alex/ >Creator of Gamelan http://www.gamelan.com/ >Founder of Purple Technology http://www.purpletech.com/ >Curator of Stinky Art Collective http://www.stinky.com/ >
Re: TC4 docs - can we end this? (ready to help...)
hey... u r right that the tomcat documentation needs to be improved i am ready to help. i can work with DocBook XML. it would be my pleasure to help.. thanx in advance.. hiten pandya _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Netware team
Hi; How can I find out who is involved in the tomcat build for Netware? I'd like to bring our project wiserlabz to the table, and promote the tomcat solution there. I noted a couple of problems with 3.2.2 as well. In any event, wiserlabz is a collaborative effort to promote Novell and Novell compatible solutions, which everyday seem more and more platform independent. Visit wiserlabz at http://www.wiserlabz.com, which is also running the tomcat 3.2.1 product. There is a sneek preview of our new "version" of the site, at http://www2.wisernet.com/cleibe/wiserlabz2. Thanks Todd http://www.wiserlabz.com mailto:[EMAIL PROTECTED] begin:vcard n:Tredeau;Todd tel;work:607-277-8336 x-mozilla-html:TRUE url:http://dubbau.com org:Computer Room adr:;;346 Pine Tree Road;Ithaca;NY;14850;US version:2.1 email;internet:[EMAIL PROTECTED] note;quoted-printable:Wisernet and Computer Room=0D=0A=0D=0A=0D=0Ahttp://dubbau.com The website formerly knows as W=0D=0Ahttp://www.croom.net Computer Room=0D=0Ahttp://www.wisernet.netWisernet =0D=0Ahttp://www.wisernotes.comWisernotes Band Hosting=0D=0Ahttp://www.wisermodels.com Modeling and Promotion=0D=0Ahttp://www.wiserlabz.com=0D=0Ahttp://www.thinkitsfree.com $=0D=0Ahttp://www.stuffnthings.com=0D=0Ahttp://www.powergridz.com=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A fn:Todd Tredeau end:vcard
RE: Netware team
Mike Anderson from novell.com is commiter on Tomcat and works on mod_jk for Netware and iPlanet :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-Original Message- >From: Todd Tredeau [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 06, 2001 5:22 PM >To: [EMAIL PROTECTED] >Subject: Netware team > > >Hi; >How can I find out who is involved in the tomcat build for Netware? >I'd like to bring our project wiserlabz to the table, and promote the >tomcat solution there. I noted a couple of problems with 3.2.2 as well. >In any event, wiserlabz is a collaborative effort to promote Novell and >Novell compatible solutions, which everyday seem more and more platform >independent. Visit wiserlabz at http://www.wiserlabz.com, which is also >running the tomcat 3.2.1 product. There is a sneek preview of our new >"version" of the site, at http://www2.wisernet.com/cleibe/wiserlabz2. > > >Thanks > >Todd >http://www.wiserlabz.com >mailto:[EMAIL PROTECTED] > > >
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp14_worker.c
jfclere 01/07/06 09:27:35 Modified:jk/native/common jk_ajp14_worker.c Log: Arrange C++ comment. Revision ChangesPath 1.10 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c Index: jk_ajp14_worker.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp14_worker.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jk_ajp14_worker.c 2001/07/02 21:17:07 1.9 +++ jk_ajp14_worker.c 2001/07/06 16:27:35 1.10 @@ -58,7 +58,7 @@ /*** * Description: AJP14 next generation Bi-directional protocol. * * Author: Henri Gomez <[EMAIL PROTECTED]> * - * Version: $Revision: 1.9 $ * + * Version: $Revision: 1.10 $ * ***/ #include "jk_context.h" @@ -406,7 +406,7 @@ memset(aw->login, 0, sizeof(jk_login_service_t)); aw->login->negociation = (AJP14_CONTEXT_INFO_NEG | AJP14_PROTO_SUPPORT_AJP14_NEG); - aw->login->web_server_name = NULL; // must be set in init + aw->login->web_server_name = NULL; /* must be set in init */ aw->ep_cache_sz= 0; aw->ep_cache = NULL;
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 Makefile.in
jfclere 01/07/06 09:39:17
Modified:jk/native configure.in
jk/native/apache-2.0 Makefile.in
Added: common/build os_apache.m4
Log:
Add support for static linked mod_jk with httpd-2.0.
Arrange install of dynamic linked for httpd-2.0.
Revision ChangesPath
1.1 jakarta-tomcat-connectors/common/build/os_apache.m4
Index: os_apache.m4
===
dnl copied from httpd-2.0/os/config.m4
dnl OS changed to OS_APACHE and OS_DIR to OS_APACHE_DIR
AC_MSG_CHECKING(for target platform)
#PLATFORM=`${CONFIG_SHELL-/bin/sh} $ac_config_guess`
PLATFORM=$host
case "$PLATFORM" in
*beos*)
OS_APACHE="beos"
OS_APACHE_DIR=$OS_APACHE
;;
*pc-os2_emx*)
OS_APACHE="os2"
OS_APACHE_DIR=$OS_APACHE
;;
bs2000*)
OS_APACHE="unix"
OS_APACHE_DIR=bs2000 # only the OS_APACHE_DIR is platform specific.
;;
*)
OS_APACHE="unix"
OS_APACHE_DIR=$OS_APACHE;;
esac
AC_MSG_RESULT($OS_APACHE)
1.9 +19 -1 jakarta-tomcat-connectors/jk/native/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- configure.in 2001/07/02 09:46:12 1.8
+++ configure.in 2001/07/06 16:39:16 1.9
@@ -1,7 +1,7 @@
dnl
dnl Process this file with autoconf to produce a configure script
dnl
-AC_REVISION($Id: configure.in,v 1.8 2001/07/02 09:46:12 jfclere Exp $)dnl
+AC_REVISION($Id: configure.in,v 1.9 2001/07/06 16:39:16 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
@@ -104,6 +104,10 @@
AC_MSG_RESULT(no apxs given)
])
+dnl Apache-2.0 needs the os subdirectory to include os.h
+dnl this include is copy from os/config.m4
+sinclude(../../common/build/os_apache.m4)
+
dnl it is copied from the configure of JServ ;=)
dnl and adapted.
@@ -154,6 +158,7 @@
WEBSERVER="apache-2.0"
apache_dir=${withval}
apache_dir_is_src="true"
+ apache_include="-I${withval}/include -I${withval}/srclib/apr/include
-I${withval}/os/${OS_APACHE_DIR} -I${withval}/srclib/apr-util/include"
AC_MSG_RESULT(${apache_dir})
fi
fi
@@ -407,6 +412,19 @@
AC_SUBST(WEBSERVER)
AM_CONDITIONAL(MAKE_DYNAMIC_APACHE, ${TEST} "${apache_dir_is_src}" = "false")
+
+if ${TEST} "${apache_dir_is_src}" = "false" ; then
+ APACHE20_OEXT=.c
+ LIB_JK_TYPE=mod_jk.so
+ INSTALL_TYPE=install_dynamic
+else
+ APACHE20_OEXT=.lo
+ LIB_JK_TYPE=lib_jk.la
+ INSTALL_TYPE=install_static
+fi
+AC_SUBST(APACHE20_OEXT)
+AC_SUBST(LIB_JK_TYPE)
+AC_SUBST(INSTALL_TYPE)
dnl automake needs the path it does not work with $WEBSERVER
dnl that why useless Makefiles are build.
1.6 +44 -16jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Makefile.in 2001/06/07 13:54:09 1.5
+++ Makefile.in 2001/07/06 16:39:17 1.6
@@ -3,28 +3,56 @@
APXS=@APXS@
OS=@OS@
JAVA_HOME=@JAVA_HOME@
+CP=@CP@
+APACHE_DIR=@APACHE_DIR@
+MKDIR=@MKDIR@
+LIBTOOL=libtool
+
JK=../common
JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
+CFLAGS=@apache_include@ @CFLAGS@ ${JK_INCL}
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
+
+include ../common/list.mk.in
+include ../scripts/build/rules.mk
+
+OEXT=@APACHE20_OEXT@
+
+
+all: @LIB_JK_TYPE@
+install: @INSTALL_TYPE@
-SRCS=${JK}/jk_ajp12_worker.c ${JK}/jk_connect.c ${JK}/jk_msg_buff.c ${JK}/jk_util.c
${JK}/jk_ajp13.c \
- ${JK}/jk_jni_worker.c ${JK}/jk_pool.c ${JK}/jk_worker.c
${JK}/jk_ajp13_worker.c ${JK}/jk_lb_worker.c \
- ${JK}/jk_sockbuf.c ${JK}/jk_map.c ${JK}/jk_uri_worker_map.c ${JK}/jk_ajp14.c
${JK}/jk_ajp14_worker.c \
- ${JK}/jk_md5.c ${JK}/jk_context.c ${JK}/jk_ajp_common.c
-
-LSRCS=jk_ajp12_worker.c jk_connect.c jk_msg_buff.c jk_util.c jk_ajp13.c \
- jk_jni_worker.c jk_pool.c jk_worker.c jk_ajp13_worker.c jk_lb_worker.c \
- jk_sockbuf.c jk_map.c jk_uri_worker_map.c jk_ajp14.c jk_ajp14_worker.c \
- jk_md5.c jk_context.c jk_ajp_common.c
-
-all: mod_jk.so
-
-mod_jk.so:
- $(APXS) ${JK_INCL} ${JAVA_INCL} -c -o mod_jk.la mod_jk.c $(SRCS)
- mv .libs/mod_jk.so .
+lib_jk.la: mod_jk.lo
+ $(LIBTOOL) --mode=link $(CC) -o lib_jk.la -static -rpath
${APACH
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 config.m4
jfclere 01/07/06 09:43:38 Added: jk/native/apache-2.0 config.m4 Log: m4 file needed for configure --with-mod_jk=static (httpd-2.0). Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native/apache-2.0/config.m4 Index: config.m4 === AC_MSG_CHECKING(for mod_jk module) AC_ARG_WITH(mod_jk, [ --with-mod_jk Include the mod_jk (static).], [ modpath_current=modules/jk module=jk libname=lib_jk.la BUILTIN_LIBS="$BUILTIN_LIBS $modpath_current/$libname" cat >>$modpath_current/modules.mk<
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 Makefile.in
Hi,
I have added the feature to link mod_jk staticly with httpd-2.0. Fell free to
test it.
BTW, I have just noted that the name of the installed library is libjk.* in
Apache-1.3 and lib_jk.* in Apache-2.0.
I will correct Apache-2.0 to use libjk.* (On Monday, it does not prevent the
things to work it is just not very coherent).
Cheers
Jean-frederic
[EMAIL PROTECTED] wrote:
>
> jfclere 01/07/06 09:39:17
>
> Modified:jk/native configure.in
>jk/native/apache-2.0 Makefile.in
> Added: common/build os_apache.m4
> Log:
> Add support for static linked mod_jk with httpd-2.0.
> Arrange install of dynamic linked for httpd-2.0.
>
> Revision ChangesPath
> 1.1 jakarta-tomcat-connectors/common/build/os_apache.m4
>
> Index: os_apache.m4
> ===
> dnl copied from httpd-2.0/os/config.m4
> dnl OS changed to OS_APACHE and OS_DIR to OS_APACHE_DIR
>
> AC_MSG_CHECKING(for target platform)
>
> #PLATFORM=`${CONFIG_SHELL-/bin/sh} $ac_config_guess`
> PLATFORM=$host
>
> case "$PLATFORM" in
> *beos*)
> OS_APACHE="beos"
> OS_APACHE_DIR=$OS_APACHE
> ;;
> *pc-os2_emx*)
> OS_APACHE="os2"
> OS_APACHE_DIR=$OS_APACHE
> ;;
> bs2000*)
> OS_APACHE="unix"
> OS_APACHE_DIR=bs2000 # only the OS_APACHE_DIR is platform specific.
> ;;
> *)
> OS_APACHE="unix"
> OS_APACHE_DIR=$OS_APACHE;;
> esac
>
> AC_MSG_RESULT($OS_APACHE)
>
>
>
> 1.9 +19 -1 jakarta-tomcat-connectors/jk/native/configure.in
>
> Index: configure.in
> ===
> RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
> retrieving revision 1.8
> retrieving revision 1.9
> diff -u -r1.8 -r1.9
> --- configure.in 2001/07/02 09:46:12 1.8
> +++ configure.in 2001/07/06 16:39:16 1.9
> @@ -1,7 +1,7 @@
>dnl
>dnl Process this file with autoconf to produce a configure script
>dnl
> -AC_REVISION($Id: configure.in,v 1.8 2001/07/02 09:46:12 jfclere Exp $)dnl
> +AC_REVISION($Id: configure.in,v 1.9 2001/07/06 16:39:16 jfclere Exp $)dnl
>
>AC_PREREQ(2.13)
>AC_INIT(common/jk_ajp13.h)
> @@ -104,6 +104,10 @@
> AC_MSG_RESULT(no apxs given)
>])
>
> +dnl Apache-2.0 needs the os subdirectory to include os.h
> +dnl this include is copy from os/config.m4
> +sinclude(../../common/build/os_apache.m4)
> +
>dnl it is copied from the configure of JServ ;=)
>dnl and adapted.
>
> @@ -154,6 +158,7 @@
> WEBSERVER="apache-2.0"
> apache_dir=${withval}
> apache_dir_is_src="true"
> + apache_include="-I${withval}/include
>-I${withval}/srclib/apr/include -I${withval}/os/${OS_APACHE_DIR}
>-I${withval}/srclib/apr-util/include"
> AC_MSG_RESULT(${apache_dir})
> fi
>fi
> @@ -407,6 +412,19 @@
>AC_SUBST(WEBSERVER)
>
>AM_CONDITIONAL(MAKE_DYNAMIC_APACHE, ${TEST} "${apache_dir_is_src}" = "false")
> +
> +if ${TEST} "${apache_dir_is_src}" = "false" ; then
> + APACHE20_OEXT=.c
> + LIB_JK_TYPE=mod_jk.so
> + INSTALL_TYPE=install_dynamic
> +else
> + APACHE20_OEXT=.lo
> + LIB_JK_TYPE=lib_jk.la
> + INSTALL_TYPE=install_static
> +fi
> +AC_SUBST(APACHE20_OEXT)
> +AC_SUBST(LIB_JK_TYPE)
> +AC_SUBST(INSTALL_TYPE)
>
>dnl automake needs the path it does not work with $WEBSERVER
>dnl that why useless Makefiles are build.
>
>
>
> 1.6 +44 -16jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in
>
> Index: Makefile.in
> ===
> RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/Makefile.in,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- Makefile.in 2001/06/07 13:54:09 1.5
> +++ Makefile.in 2001/07/06 16:39:17 1.6
> @@ -3,28 +3,56 @@
>APXS=@APXS@
>OS=@OS@
>JAVA_HOME=@JAVA_HOME@
> +CP=@CP@
> +APACHE_DIR=@APACHE_DIR@
> +MKDIR=@MKDIR@
>
> +LIBTOOL=libtool
> +
>JK=../common
>JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
> +CFLAGS=@apache_include@ @CFLAGS@ ${JK_INCL}
>JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
>JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L
>${JAVA_HOME}/lib/${ARCH}/native_threads
> +
> +include ../common/list.mk.in
> +include ../scripts/build/rules.mk
> +
> +OEXT=@APACHE20_OEXT@
> +
> +
> +all: @LIB_JK_TYPE@
> +install: @INSTALL_TYPE@
>
> -SRCS=${JK}/jk_ajp12_worker.c ${JK}/jk_connect.c ${JK}/jk_msg_buff.c
>${JK}/jk_util.c ${JK}/jk_ajp13.c \
> - ${JK}/jk_jni_worker.c ${JK}/jk_pool.c ${JK}/jk_worker.c
>${JK}/jk_ajp13_worker.c ${JK}/jk_lb_worker.c \
> - ${JK}/jk_sockbuf.c ${JK}/jk_map.c ${JK}/jk_uri_worker_map.c
>${JK}/jk_ajp14.
DOC: Table of Contents
Here's my current Table of Contents. As I said in an earlier message, > I'd like to organize this TOC as a little more abstract than a simple table of contents. Each section should be organized to contain not just our original documents, but also a list of other resources on that topic. This will be a good way to get a useful set of docs up and running quickly. In fact, I imagine that many of the chapters will remain unwritten for a while, since there may be existing documents, or articles, or FAQ entries that cover the topic (even if not exclusively). > In short, I propose that writing a TOC is a very important first step, and that this TOC should live a life of its own as a standalone document, containing links to other docs, and meta-information like links to other docs as well. I used emacs outline mode, which uses * to represent header level, so we don't have to renumber all the chapters all the time. * = part ** = chapter *** = section For the Security chapter, I took the outline Antony wrote. I trust the current discussion thread will improve upon it. Since there's a lot of detail in here, here's the outline to one level of headers only: * Part I: Installation Guide ** Overview ** Pre-Installation ** Installation Standalone ** Server lifecycle management ** Secure Server (SSL) ** Virtual Hosts ** Installing Jasper (JSP) ** Logging ** Load Balancing * Part II: Installation Behind A Web Server ** Installation Behind a Web Server Overview ** Behind Apache ** Behind IIS ** Behind iPlanet * Part III: Deploying Web Applications in Tomcat ** Web Application Primer ** The Web application directory structure ** Deploying your Web applications ** Reloading ** Aliasing and redirecting ** Security ** Developing with Jasper (JSP) * Part IV: Performance ** Performance Tuning Web Applications ** Tuning the server ** Load Balancing * Part V: Tomcat Development ** Tomcat 3.x vs 4.x ** Overview of Tomcat code base ** Downloading the source code ** Building the source code ** Bugs ** Developing Interceptors (Tomcat 3.x) ** Developing Valves (Tomcat 4.x) ** Developing Connectors ** Using Tomcat Utility Classes * Appendices ** server.xml documentation ** web.xml documentation ** Glossary ** Resources A note on copyright: I'm claiming copyright for this document, since I may use parts of it to write articles or books, and I haven't done the research on what it means to post text (as opposed to code) into an Apache project. I'd contribute it explicitly as open source if I were sure I'd keep my rights to use it too. If anyone can enlighten me on this topic, please respond with a separate subject line (like "Copyrights") so we can keep discussions of copyright separate from discussions of the table of contents itself. The copyright will not prevent other Apache contributors from using or editing it or adding it to the code base -- that is, I want to preserve *my* right to use it in a non-Apache context, but also to grant Apache the right to use it too. If that's even possible. I'm confused. Anyway, here it is :-) Next steps: comments & revisions ad infinitum flag each section as applicable to 3.x, 4.x, or both add links to existing documents volunteer authors to write chapters/sections -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ This document Copyright (C) 2001 by Alex Chaffee. All rights reserved. Permission is granted for the Apache project to incorporate it in whole or in part into their documentation. * Editorial Notes The "installation" unit is the most crucial. I think there should be a chapter or series of chapters on installing Tomcat standalone, that covers *everything* or almost everything start-to-finish. Then we also need separate chapters for installing behind each Web server. Then come chapters on administration and advanced configuration issues. We should make it clear that it is *HIGHLY* recommended to install standalone first. This will help the users debug their setups. It will also help us organize the docs. Each "behind" chapter will assume you've read the "standalone" chapter(s). http://jakarta.apache.org/tomcat/tomcat-3.3-doc/appdev/deployment.html is very well organized and would be great as a "Web Application Developer's Guide" * Part I: Installation Guide Covers installing Tomcat. Separate instructions (sidebars?) for Windows 9x, Windows NT, Linux, Solaris, Other Unixes, Mac OS. Separate instructions for standalone vs. plug-in. Separate instructions for Tomcat 3.x vs 4.x. ** Overview Big picture, 30,000 foot view. *** Diagram of all the parts of Tomcat Servlet Container * Directories * Config files * Web apps * Connectors *** Basic terms servlet web a
Re: DOC: Table of Contents
Alex Chaffee at [EMAIL PROTECTED] wrote: > > A note on copyright: I'm claiming copyright for this document, since I > may use parts of it to write articles or books, and I haven't done the > research on what it means to post text (as opposed to code) into an > Apache project. I'd contribute it explicitly as open source if I were > sure I'd keep my rights to use it too. If anyone can enlighten me on > this topic, please respond with a separate subject line (like > "Copyrights") so we can keep discussions of copyright separate from > discussions of the table of contents itself. The copyright will not > prevent other Apache contributors from using or editing it or adding it > to the code base -- that is, I want to preserve *my* right to use it in > a non-Apache context, but also to grant Apache the right to use it too. > If that's even possible. I'm confused. Nice question :) And I believe this should be addressed by the members... Our license clearly states that the sentence "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)" must be included in derivate works, but, when thinking about documentation, and so text instead of code, I don't know whether that should be included or not. Our license, in fact, is called "Apache Software License" and covers that part, and I don't know how that could apply to things related to software, such as logos and documentation. For logos, what usually happens is that the board specifically grants the right to use our logo somewhere, and this could also happen for docs, but I think we should address this problem once for all... It's not a problem of Copyright, IMVHO, but a problem related to licensing the use and publication of our documentation. Pier (CCing members@apache to see what others think...)
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/context DefaultCMSetter.java
larryi 01/07/06 11:36:18
Modified:src/share/org/apache/tomcat/context Tag: tomcat_32
DefaultCMSetter.java
Log:
Add all default handlers to the context even though they may not be
used by default due to an web.xml error mapping. The default handler
may be needed if there is a problem with the web.xml error mapping.
Revision ChangesPath
No revision
No revision
1.45.2.11 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/context/Attic/DefaultCMSetter.java
Index: DefaultCMSetter.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/context/Attic/DefaultCMSetter.java,v
retrieving revision 1.45.2.10
retrieving revision 1.45.2.11
diff -u -r1.45.2.10 -r1.45.2.11
--- DefaultCMSetter.java 2001/03/17 20:52:49 1.45.2.10
+++ DefaultCMSetter.java 2001/07/06 18:36:16 1.45.2.11
@@ -94,12 +94,12 @@
// Default status handlers. If already set ( error-page in web.xml )
// do nothing
+ctx.addServlet( new RedirectHandler());
if( null==ctx.getErrorPage( "302" )) {
- ctx.addServlet( new RedirectHandler());
ctx.addErrorPage( "302", "tomcat.redirectHandler");
}
+ctx.addServlet( new NotFoundHandler());
if( null==ctx.getErrorPage( "404" )) {
- ctx.addServlet( new NotFoundHandler());
ctx.addErrorPage( "404", "tomcat.notFoundHandler");
}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
larryi 01/07/06 11:40:08
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
Log:
Fix recursive error handling if web.xml maps error code 404 to a non-existent
JSP page. With this fix, no response will be sent if status handler is called
recursively. You will need to examine the log output to see the error.
If web.xml maps error code 404 to a non-existent html, use default "not found"
handler instead of default "status" handler.
Revision ChangesPath
No revision
No revision
1.100.2.24 +22 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.100.2.23
retrieving revision 1.100.2.24
diff -u -r1.100.2.23 -r1.100.2.24
--- ContextManager.java 2001/04/25 16:50:12 1.100.2.23
+++ ContextManager.java 2001/07/06 18:40:05 1.100.2.24
@@ -1047,8 +1047,16 @@
if( debug>0 )
ctx.log( "Handler " + errorServlet + " " + errorPath);
- if( errorServlet==null )
- errorServlet=ctx.getServletByName( "tomcat.statusHandler");
+if ( statusLoop( ctx, req ) ){
+log( "Error loop for " + req + " error code " + code);
+return;
+}
+if( errorServlet==null ) {
+if( code == 404 )
+errorServlet=ctx.getServletByName( "tomcat.notFoundHandler");
+else
+errorServlet=ctx.getServletByName( "tomcat.statusHandler");
+}
req.setAttribute("javax.servlet.error.status_code",new Integer( code));
@@ -1194,6 +1202,18 @@
return true;
}
return false;
+}
+
+/** Handle the case of status handler generating an error
+ */
+private boolean statusLoop( Context ctx, Request req ) {
+if ( req.getAttribute("javax.servlet.error.status_code") != null ) {
+if( ctx.getDebug() > 0 )
+ctx.log( "Error: nested error inside status servlet " +
+req.getAttribute("javax.servlet.error.status_code"));
+return true;
+}
+return false;
}
/**
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
larryi 01/07/06 11:41:02
Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
Log:
Fix recursive error handling if web.xml maps error code 404 to a non-existent
JSP page. With this fix, no response will be sent if status handler is called
recursively. You will need to examine the log output to see the error.
If web.xml maps error code 404 to a non-existent html, use default "not found"
handler instead of default "status" handler.
Revision ChangesPath
1.14 +19 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ErrorHandler.java 2001/07/05 20:40:45 1.13
+++ ErrorHandler.java 2001/07/06 18:41:00 1.14
@@ -191,8 +191,15 @@
}
boolean isDefaultHandler = false;
+if ( statusLoop( ctx, req ) ){
+log( "Error loop for " + req + " error code " + code);
+return;
+}
if( errorServlet==null ) {
- errorServlet=ctx.getServletByName( "tomcat.statusHandler");
+if( code == 404 )
+errorServlet=ctx.getServletByName( "tomcat.notFoundHandler");
+else
+errorServlet=ctx.getServletByName( "tomcat.statusHandler");
isDefaultHandler = true;
}
@@ -389,9 +396,18 @@
}
return false;
}
-
-
+/** Handle the case of status handler generating an error
+ */
+private boolean statusLoop( Context ctx, Request req ) {
+if ( req.getAttribute("javax.servlet.error.status_code") != null ) {
+if( ctx.getDebug() > 0 )
+ctx.log( "Error: nested error inside status servlet " +
+req.getAttribute("javax.servlet.error.status_code"));
+return true;
+}
+return false;
+}
}
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
Hi Larry,
Please, ignore my last message. With this change, it fixed the problem.
Thanks a lot !!
Renato.
[EMAIL PROTECTED] wrote:
larryi 01/07/06 11:40:08Modified: src/share/org/apache/tomcat/core Tag: tomcat_32ContextManager.javaLog:Fix recursive error handling if web.xml maps error code 404 to a non-existentJSP page. With this fix, no response will be sent if status handler is calledrecursively. You will need to examine the log output to see the error.If web.xml maps error code 404 to a non-existent html, use default "not found"handler instead of default "status" handler.Revision Changes PathNo revisionNo revision1.100.2.24 +22 -2 jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.javaIndex: ContextManager.java===RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,vretrieving revision 1.100.2.23retrieving revision 1.100.2.24diff -u -r1.100.2.23 -r1.100.2.24--- ContextManager.java 2001/04/25 16:50:12 1.100.2.23+++ ContextManager.java 2001/07/06 18:40:05 1.100.2.24@@ -1047,8 +1047,16 @@if( debug>0 )ctx.log( "Handler " + errorServlet + " " + errorPath);- if( errorServlet==null )- errorServlet=ctx.getServletByName( "tomcat.statusHandler");+ if ( statusLoop( ctx, req ) ){+ log( "Error loop for " + req + " error code " + code);+ return;+ }+ if( errorServlet==null ) {+ if( code == 404 )+ errorServlet=ctx.getServletByName( "tomcat.notFoundHandler");+ else+ errorServlet=ctx.getServletByName( "tomcat.statusHandler");+ }req.setAttribute("javax.servlet.error.status_code",new Integer( code));@@ -1194,6 +1202,18 @@return true;}return false;+ }++ /** Handle the case of status handler generating an error+ */+ private boolean statusLoop( Context ctx, Request req ) {+ if ( req.getAttribute("javax.servlet.error.status_code") != null ) {+ if( ctx.getDebug() > 0 )+ ctx.log( "Error: nested error inside status servlet " ++ req.getAttribute("javax.servlet.error.status_code"));+ return true;+ }+ return false;}/**Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!http://personal.mail.yahoo.com/
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request JDBCRealm.java
nacho 01/07/06 13:59:35
Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
JDBCRealm.java
Log:
Bug# 2149 , 727 ( possibly others )
JDBCRealm did not close all the prepared staments opened,
when trying to reconnect when found a broken DBConnection,
I'ts a problem specillay surfaced when using MySQL..
Reported By :
mark.shotton at micromass.co.uk
andre.gommlich at netkom.de
edwin at finalist.com
kaneda at dedaletechnology.com
Revision ChangesPath
No revision
No revision
1.9.2.10 +47 -56
jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/JDBCRealm.java,v
retrieving revision 1.9.2.9
retrieving revision 1.9.2.10
diff -u -r1.9.2.9 -r1.9.2.10
--- JDBCRealm.java2001/04/17 10:43:43 1.9.2.9
+++ JDBCRealm.java2001/07/06 20:59:34 1.9.2.10
@@ -318,30 +318,14 @@
log(sm.getString("jdbcRealm.authenticateSQLException",
username));
log("SQLException: " + ex);
+close();
-// Clean up the JDBC objects so that they get recreated next time
-if (preparedAuthenticate != null) {
-try {
-preparedAuthenticate.close();
-} catch (Throwable t) {
-;
-}
-preparedAuthenticate = null;
-}
-if (dbConnection != null) {
-try {
-dbConnection.close();
-} catch (Throwable t) {
-;
-}
-dbConnection = null;
-}
-
// Return "not authenticated" for this request
return false;
}
}
+
public synchronized String[] getUserRoles(String username) {
try {
if( !checkConnection()) {
@@ -380,30 +364,15 @@
log(sm.getString("jdbcRealm.getUserRolesSQLException",
username));
log("SQLException: " + ex);
-if (preparedRoles != null) {
-try {
-preparedRoles.close();
-} catch (Throwable t) {
-;
-}
-preparedRoles = null;
-}
-if (dbConnection != null) {
-try {
-dbConnection.close();
-} catch (Throwable t) {
-;
-}
-dbConnection = null;
-}
+close();
}
- return null;
+return null;
}
public void contextInit(Context ctx)
throws org.apache.tomcat.core.TomcatException {
- // Validate and update our current component state
+// Validate and update our current component state
if (!started && checkConnection() ) {
started = true;
log(sm.getString("jdbcRealm.started"));
@@ -415,14 +384,7 @@
// Validate and update our current component state
if (started) {
started=false;
-if( dbConnection != null ) {
- try {
-dbConnection.close();
- }
- catch( SQLException ex ) {
-log("dbConnection.close Exception!!!");
- }
- }
+close();
}
}
@@ -448,8 +410,8 @@
// This realm will use only username and password callbacks
String user=(String)cred.get("username");
String password=(String)cred.get("password");
-
- if( user !=null && password !=null ){
+
+if( user !=null && password !=null ){
if ( authenticate( user, password ) ) {
if( debug > 0 ) log( "Auth ok, user=" + user );
req.setRemoteUser( user );
@@ -458,8 +420,8 @@
if (ctx != null)
req.setAuthType(ctx.getAuthMethod());
}
- }
- return 0;
+}
+return 0;
}
public int authorize( Request req, Response response, String roles[] )
@@ -473,16 +435,16 @@
String userRoles[]=null;
- String user=req.getRemoteUser();
- if( user==null )
+String user=req.getRemoteUser();
+if( user==null )
return 401; //HttpServletResponse.SC_UNAUTHORIZED
-
- if( debug > 0 )
+
+if( debug > 0 )
log( "Controled access for " + user + " " + req + " "
+ req.getContainer() );
-
- userRoles = getUserRoles( us
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request LocalStrings.properties
nacho 01/07/06 14:02:32 Modified:src/share/org/apache/tomcat/request Tag: tomcat_32 LocalStrings.properties Log: Adding a Lost ( or forget ) String for JDBCRealm Revision ChangesPath No revision No revision 1.1.2.3 +3 -3 jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/LocalStrings.properties Index: LocalStrings.properties === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/LocalStrings.properties,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- LocalStrings.properties 2001/02/23 22:02:50 1.1.2.2 +++ LocalStrings.properties 2001/07/06 21:02:30 1.1.2.3 @@ -6,6 +6,6 @@ jdbcRealm.notStarted=This Realm has not yet been started jdbcRealm.checkConnectionDBClosed=The database connection is null or was found to be closed. Trying to re-open it. jdbcRealm.checkConnectionDBReOpenFail=The re-open on the database failed. The database could be down. -jdbcRealm.starting=Starting JDBCRealm, trying to acquire JDBC Driver class and DB Connection -jdbcRealm.started=JDBCRealm has been started succesfully - +jdbcRealm.starting=Starting JDBCRealm, trying to acquire JDBC Driver class and DB Connection +jdbcRealm.started=JDBCRealm has been started succesfully +jdbcRealm.checkConnectionSQLException=There was an SQLException while in checkConnection
[PATCH] Case sensitive attributes in ApacheConfig's javadoc
The javadoc in ApacheConfig lists the attributes as all lowercase. Some parts of these attributes need to be capitalized. For example, the attribute modjk actually needs to be modJk. Index: ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v retrieving revision 1.15 diff -u -r1.15 ApacheConfig.java --- ApacheConfig.java 2001/07/04 05:09:56 1.15 +++ ApacheConfig.java 2001/07/06 20:52:07 @@ -86,21 +86,21 @@ where options can include any of the following attributes: - confighome - default parent directory for the following paths. + configHome - default parent directory for the following paths. If not set, this defaults to TOMCAT_HOME. Ignored whenever any of the following paths is absolute. - jkconfig - path to write apacke mod_jk conf file to. If + jkConfig - path to write apacke mod_jk conf file to. If not set, defaults to "conf/jk/mod_jk.conf". - workersconfig - path to workers.properties file used by + workersConfig - path to workers.properties file used by mod_jk. If not set, defaults to "conf/jk/workers.properties". - modjk - path to Apache mod_jk plugin file. If not set, + modJk - path to Apache mod_jk plugin file. If not set, defaults to "modules/mod_jk.dll" on windows, "modules/mod_jk.nlm" on netware, and "libexec/mod_jk.so" everywhere else. - jklog - path to log file to be used by mod_jk. + jkLog - path to log file to be used by mod_jk. @author Costin Manolache
Re: tomcat 3.3 proposals cleanup - next step ?
On Tue, 26 Jun 2001, GOMEZ Henri wrote: > Larry does a cleanup on Tomcat 3.3 project > and remove many dirs in proposal but > > I removed all the proposal subdir from my > local CVS and got all the proposal subdir > trees at the next checkout. > In the Unix and CYGWIN versions of CVS (at least), you can do your updates like this: cvs update -d -P and you won't have these directories present on your disk -- although there will still be some time spent scanning the server-side versions. > All it used not less than 1.5Mb. What about > removing (rm) also the directories in CVS dir to > avoid grabbing 1.5Mb of subdirs :> > Doing this would violate a basic premise of source code control systems -- that you can *always* go back to a previous version (with a specific tag, or as of a specific date). It may be that a "proposals" directory doesn't really qualify for being concerned about this (since the code wasn't ever included in a production release), but it's appropriate to think very seriously before doing such a thing. > Henri Gomez ___[_] Craig
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]
On Mon, 2 Jul 2001, Jon Stevens wrote: > on 7/2/01 5:58 PM, "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote: > > > Excellent :) Anakia is a tool written by Jon to translate XML into HTML > > (correct me if I'm wrong) based on the same language that WebMacro uses... > > It generates http://jakarta.apache.org/, so, it must be somehow good :) > > > > Pier > > No. It is based on Velocity which is similar but different than WebMacro. > > In order to use Jakarta-Site2 you don't need to know how to understand the > stylesheet though because it is already done for you. All you need to > understand is the syntax to use in the XML files. > It would sure be nice to have a little HOWTO on what tags (like and ) Anakia recognizes, and what they do :-). The same, of course, goes for the XSLT stylesheets, including stylebook, that are used in various projects. > -jon > > Craig
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocumentation Redactors To Hire]
On Mon, 2 Jul 2001, Rob S. wrote: > This seems to be one of the questions that comes up and never gets answered > (re: docs, not Jon's behavior ;) I'm not sure what magical solution will > get people to read docs. Frankly, I'd just like to get started. Anakia > works for Jakarta, Yep, thanks to Jon's hard work setting up jakarta-site2, a large majority of the Jakarta web site is generated using Anakia. > it works for Struts Technically, it's not actually *used* by Struts -- Struts uses the Ant
RE: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocumentation Redactors To Hire]
On Mon, 2 Jul 2001, Rob S. wrote: > > We've started writing some new docs in XML (catalina/docs/dev/xdocs). The > > HTML generation is done with XSL, but the DTD should be the same > > as the one > > used by Anakia. > > I noticed the xdocs directory, but I didn't see anything in there. I sent > Craig an email about it a week ago, but haven't heard back from him. Just got back from vacation last night. If I'd read your email a week ago, I'd have been in ***big*** trouble with my wife :-). > Am I > doing something wrong? (re: CVS, not emailing Craig =) > There are currently eight XML files in the "catalina/docs/dev/xdocs" directory. They aren't transformed by the standard build process, because the current use of
Re: Somebody get me off this List PLEASE!!!!!!!!!!!!!!!!
On Thu, 5 Jul 2001, Justin Erenkrantz wrote: > On Thu, Jul 05, 2001 at 06:10:42PM +0100, Andy Armstrong wrote: > > "Swart, James (Jim) ** CTR **" wrote: > > > > > > why is it everyone has such a hard time getting off this list? Someone put > > > me in charge of getting people off the jarkata maillists, I'll make sure > > > it's done to ensure these floods of "get me off here" is done... Sound good? > > > > Can't it be automated? What are the lists running on? > > Apache.org is using ezmlm. The problem is when users don't confirm the > unsubscription or send it from the wrong address. It is automated, but > it isn't idiot-proof. > Even in the "wrong address" case, the reply that you get tells you what's wrong and how to fix it. Of course, even here nobody reads the documentation ... :-). I tried to remove the original complainer, but there's no current subscription under the email address he sent this message from. That means either someone beat me to it, or he's getting messages forwarded to him from somebody else. > It'd be nice to have a human moderator who reads tomcat-dev and can > manually take people off the list when they start to complain on-list. There are (Pier and me). Among other things, we have to approve any post from non-subscribers, and you'd be amazed at how much crap we shield this list from :-). But it's not anywhere close to the highest priority task for either of us. > -- justin > > Craig
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Fri, Jul 06, 2001 at 10:06:21PM -0700, Craig R. McClanahan wrote: > * Tomcat docs for a particular version should be delivered as one or more > web apps (not necessarily the root webapp as is current practice). That > way, the corresponding WAR files could be dropped into *any* container, > or opened up and read directly from the filesystem. > > * At least two documentation webapps (developer-oriented and > user-oriented) would seem to be appropriate. Having more than two > will make it difficult to create reliable hyperlinks (since you don't > have any control over the context path that someone uses to deploy). Although I find the rest of your comments on this topic both clear and refreshing, I'd like to point out a possible fallacy here: Providing Tomcat documentation in a WAR file is a little like providing a VHS tape on how to setup your VCR. It may seem really elegant to have on-the-fly style-generating documentation, and I may be alone on this, but I think that the majority of the user-oriented documentation should just be plain text. (By 'user-oriented documentation' I specifically mean build instructions and deployment configuration docs). Just my 2c, -aaron
Re: Tomcat Documentation Project
On Tue, 3 Jul 2001, Alex Chaffee wrote: > Leaving aside the issue of file format for just one second... > > Are we agreed on the following? > > 1. Tomcat documentation sucks :-) > > 2. There needs to be a new CVS project called jakarta-tomcat-doc. > > My reasoning is that we want to avoid the fragmentation of documentation > into different trees for 3.2, 3.3, and 4.0. Why? Because a lot of > documentation would apply equally to all versions. > This is not at *all* clear to me. For developer-oriented docs, the overlap would seem to be zero -- the architectures of all three environments are radically different. For user docs, there are *similarities* between the versions, but they are by no means identical -- for example, IMHO it would be very confusing to have a single document about JDBCRealm (just to pick an example) with three different ways to configure it, based on which Tomcat version you are using. To say nothing about the fact that the various versions of JDBCRealm are *not* identical in their functionality or implementation. And, many of the concepts you want to talk about in configuration docs are *radically* different between versions. +1 for separate doc trees per version (with a possible exception identified in the next paragraph). > Looking at it in reverse, the fact that someone is using an old version > of Tomcat shouldn't mean they're forced to use an old version of the > documentation. Instead, a chapter on, say, web application deployment > may need to have a sidebar describing changes between 3.x and 4.x, but > assuming 4.x isn't *radically* different, they can both use the same > core text. (In cases where 4.x *is* radically different, it would just > have a separate document/chapter, with the 4.x specificity clearly > labelled in the title.) > The "Application Developer's Guide" is pretty much the only existing doc that is 99.9% portable across 3.2/3.3/4.0. That's courtesy of the fact that it talks about web apps as defined in the servlet spec, and touches only very lightly on anything that is Tomcat-version-specific. There is probably 50% overlap if you talk about something like mod_jk (i.e. the stuff about configuring httpd.conf). At that point, IMHO, it's still better to have separate docs from a readability point of view. But the killer issue is that the various versions are created by different groups of developers, with different release schedules. Nobody is going to be willing to wait for the omnibus documentation to be updated, or care about shipping docs covering the "other" versions -- so you can count on anything about the 3.3 version to be out-of-date in the 4.0 release (for example), and vice versa. Note that none of the above is influenced much by whether docs are stored in a separate jakarta-tomcat-doc CVS repository or not (my preference is "not" but that's a minor detail). But, even if it's all in the same repository, in practice it's going to end up being separate subdirectories, maintained and released indepently, anyway. > I know the 4.x crew have begun the process of creating a separate > documentation set, including xdocs, and this is great. If it's too much > work to integrate 3.x and 4.x then maybe they should remain separate CVS > projects too, but it may still be desirable to have a separate CVS > project anyway. > The more work you make it for developers to write docs along with code, the less docs are going to get written (by those developers). If the docs are written by others it's not that big a deal -- but I personally like the docs I write in the same CVS repository as the code that the docs describe. > 3. There needs to be a better index/TOC for the documentation we do > have, and a reorganization of the redundant / outdated / wrong parts of > the existing docs (the Apache config stuff comes to mind). > > 4. Someone or some small group of people should take responsibility for > making this happen (before we "run out of steam"), regularly submitting > proposals and keeping the rest of the group apprised of developments and > decisions, but retaining some authority. Let's call this person/people > the Documentation Czar. I'm not proposing he/they have any real > authority over the content, but just over organizing it, deciding where > to place it, and forming "to do" lists for documents/chapters that need > to be written or proofed or tech edited or revised. > > If we agree on the above, then there's a good chance I'd volunteer to be > the Doc Czar, even though I think it's a lot of work. I've been managing > the jGuru Tomcat FAQ for a year, and the Servlets FAQ for longer, so I > at least have some idea of the scope of this kind of organizational > task. (Note that I'm not suggesting I actually *write* all this new > documentation... :-) > I'd be happy to see Alex take this task on. > Maybe a better term would be "Doc Editor" or "Editorial Board". And > maybe I'm being too anal in propos
Re: JDBC Realm Questions Tomcat 3.2.2
On Tue, 3 Jul 2001, Jonathan Pierce wrote:
> This may be a stupid question but I've found hundreds of messages from confused
> users on the subject of JDBC Realms and Tomcat and no good explanation or
> example. There is a documentation file JDBCRealm.howto but it doesn't describe
> how to instantiate the datasource with a code example or what additional
> property files need to be included to configure jndi properties.
>
> Like lots of other people, I'm trying to use the release Tomcat 3.2.2, configure
> multiple jdbc datasources in the server.xml file, and reference it in my
> servlet. I am only interested in using a shared database ID to connect to the
> database for all users of my servlet. The database connect info needs to be in
> Tomcat conf files since the passwords need to be reconfigured at deployment time
> outside my war file.
>
> 1. Is this behavior supported by Tomcat 3.2.2? How do I configure multiple
> database datasources and instantiate them in my code?
>
IIRC, Tomcat 3.2.2 only supports a single realm of usernames and passwords
for all of the webapps running in a single JVM. That is not the case with
4.0.
> 2. Assuming I setup the datasources like below, what properties do I use to
> assign a name to the datasource so I can reference it?
>
> className="org.apache.tomcat.request.JDBCRealm"
> debug="99"
> driverName="oracle.jdbc.driver.OracleDriver"
> connectionURL="jdbc:oracle:thin:@ntserver:1521:ORCL"
> connectionName="scott"
> connectionPassword="tiger"
> />
>
> className="org.apache.tomcat.request.JDBCRealm"
> debug="99"
> driverName="oracle.jdbc.driver.OracleDriver"
> connectionURL="jdbc:oracle:thin:@ntserver2:1521:ORCL"
> connectionName="scott"
> connectionPassword="tiger"
> />
>
>
> 3. What do I need to add to a config file in order to access the initial context
> so I can retrieve the datasource?
>
> import javax.servlet.*;
> import javax.servlet.http.*;
> import javax.naming.*;
> import javax.sql.*;
>
> String theDataSourceName = "???";
> String theNamingProviderURL = "???";
> String theInitialContextNamingFactory = "???";
> Properties theProperties = new Properties ();
> theProperties.put("java.naming.provider.url", theNamingProviderURL);
> theProperties.put("java.naming.factory.initial",theInitialContextNamingFactory);
>
> Context theInitialContext = new InitialContext(theProperties);
> DataSource theDataSource = (DataSource) theInitialContext.lookup
> (theDatasourceName);
>
You might be confusing realms with datasources :-)
The purpose of JDBCRealm is to allow you to store the usernames,
passwords, and roles required for container-managed security (as described
in the servlet spec) in a database accessed via JDBC. When used in this
manner, only Tomcat talks to the database that you configure with
JDBCRealm -- not your application.
If you want to use a datasource for your own application data, you don't
need JDBCRealm at all. Instead, you've got a couple choices:
* Use one of the existing datasource implementations, following the
configuration documentation included with that datasource.
* Use a J2EE application server, where you can declare a
in the web.xml file, and use your app server's
deployment tools to connect that to an actual database.
* Use Tomcat 4.0, which lets you do the same thing -- the connection
to a particular database is done in the "conf/server.xml" file.
Craig McClanahan
Re: TC4 docs - can we end this?
On Wed, 4 Jul 2001, Andy Armstrong wrote: > "Rob S." wrote: > > > > > Anyway +1 million on getting some decent docs written. Personally I'd > > > find it useful if someone who is reasonably clueful on the state of TC > > > documentation at the moment could summarise what's out there. The TC > > > book project for example; where's that at? > > > > I think that falls under my personal category of "too involved to garner > > much continual support". That's just my thought tho' =) If we had a solid > > bank of docs and had proven to ourselves that we could even do that 'simple' > > task, then I'd be all for a book. Lets get some docs out there first ;) > > Completely agree -- I'm just trying to get a feel for what's been done > so far on the assumption that there may be useful documentation lying > around out there. > Everything that is included in the Tomcat distribution is sitting there already in CVS :-). Of course, there's quite a bit of user-written "unofficial" documentation on Tomcat that could be drawn from as well -- I'll bet a little research on the TOMCAT-USER archives would give us lots of pointers (plus lots of ideas on topics to be covered). > -- > Andy Armstrong, Tagish > Craig
RE: TC4 docs - can we end this?
On Wed, 4 Jul 2001, Rob S. wrote: > It'll already take a tremendous amount of time to get the user's side up and > going, which is what I think the grand majority of people will benefit the > most from. I'm not saying the dev design docs aren't extremely important, > I'm just saying that I want to spend my time where it will have the greated > effect =) > I think it makes *lots* of sense to focus on the user docs first. After all, there's a lot more of them trying to understand this stuff than there are developers :-). Also, developers should be "strongly" :-) encouraged to write their own docs about architecture and so on -- and yes, I'm definitely pointing my finger at myself as well. > - r > Craig
Re: Poor Tomcat 3.2.2 performance on Win32 with class reloadingenabled
On Wed, 4 Jul 2001, Stuart Roebuck wrote:
> I've been hitting against getCanonicalPath myself recently in the context
> of Cocoon 2 and Tomcat 4 under Mac OS X.
>
> I've taken a look through some of the code of Tomcat and it appears that
> there are opportunities to cut down on calls to getCanonicalPath, but I'm
> conscious that I really am not at all familiar with the code and the
> possible underlying issues.
>
One thing to be *very* cautious about here is security. You have to make
absolutely sure, for example, that resource references are case sensitive
(even on case insensitive platforms), and that malicious users can't use
things like "../../../../../other/place" to access things outside of the
web app.
> Here are some examples of bits of code in the current Tomcat source which
> appear open to optimization, perhaps you could comment on whether such
> optimizations would work:
>
> StandardContext.java:
>
> > if (directory.exists() && directory.canRead() &&
> > directory.isDirectory()) {
> > String filenames[] = directory.list();
> > for (int i = 0; i < filenames.length; i++) {
> > if (!filenames[i].endsWith(".jar"))
> > continue;
> > File file = new File(directory, filenames[i]);
> > try {
> > URL url = new URL("file", null, file.getCanonicalPath(
> > ));
> > newLoader.addRepository(url.toString());
> > } catch (IOException e) {
> > throw new IllegalArgumentException(e.toString());
> > }
> > }
> > }
>
> Couldn't we get the Canonical path of the directory and then assume that
> the absolute path of the filenames returned would be Canonical too,
> thereby taking getCanonicalPath out of the loop?
>
Depends on where the list of filenames comes from. In this case, it might
be feasible (since they come from the operating system and not the web
app), but a thorough security review would be important first.
> > // Create this directory if necessary
> > File dir = new File(workDir);
> > if (!dir.isAbsolute()) {
> > File catalinaHome = new
> > File(System.getProperty("catalina.home"));
> > String catalinaHomePath = null;
> > try {
> > catalinaHomePath = catalinaHome.getCanonicalPath();
> > dir = new File(catalinaHomePath, workDir);
> > } catch (IOException e) {
> > }
> > }
>
> Isn't getAbsolutePath sufficient here?
>
IIRC, getAbsolutePath caused problems here on Windows but worked
correctly on Solaris and Linux. Such is life when you've got to be
portable across multiple JVMs.
> Similar issues exist in Bootstrap.java.
>
> HostConfig:
>
> > // Deploy the application in this directory
> > if (debug >= 1)
> > log(sm.getString("hostConfig.deployDir", files[i]));
> > try {
> > URL url = new URL("file", null, dir.getCanonicalPath(
> > ));
> > ((Deployer) host).install(contextPath, url);
> > } catch (Throwable t) {
> > log(sm.getString("hostConfig.deployDir.error", files[
> > i]),
> > t);
> > }
>
> dir is derived using the list method on the appBase variable (not shown on
> listing) which is canonical. Do we need to use getCanonicalPath here or
> can we just use getAbsolutePath?
>
> Finally, how about having some form of cached getCanonicalPath method
> which returns results from cache for requests for the same file path? I
> tried replacing the actual getCanonicalPath method in the main Java
> classes with a simple unlimited hashTable and the performance improvements
> running Tomcat and Cocoon were very visible. Clearly the hash table would
> need to be time and size limited, but are there any other fundamental
> issues with this idea?
>
The cases you've described above all happen only once (at startup
time). Assuming that we could safely optimize these cases, would it
really make a significant difference?
To influence the performance of Cocoon, we'd want to look at the Resources
implementation. It's been worked on, but I would certainly not say we've
really optimized it yet. And reducing the number of calls to
getCanonicalPath() sounds like a good strategy -- as long as it can be
done safely.
> Stuart.
>
Craig
RE: PROPOSAL: Tomcat docs
On Wed, 4 Jul 2001, Robert Slifka wrote: > More refinements... if i didn't quote it, I agree with it =) BTW, what > does "AW" in a subject line mean? I see it all the time... > > 0) Introduction to the TC4 container > ADD > - Requirements (JDK versions, extra libs?, etc.) > > 1) "User's Guide" (or "Administrator's") > > - Tomcat and different JDK Versions > Moved this up to (0) > > > 2) "" Can't think of a title =) > > ^ > > Tomcat Webdeveloper Guide > > I think we do need to separate out the fact that there are a group of people > who will developing/embedding/extending Tomcat, and a group of people that > will be developing web applications for Tomcat. As a web developer, I don't > care a lot of about Tomcat's internals ;) > That's why I called the current document "Application Developer's Guide" instead, because it fit better in a User Documentation suite. :-) Tomcat internals should be documented in the overall Developer Documentation suite. > 3) "Tomcat Upgrade Guide" > > I think this would equate to a lot of feature mapping from one container to > another. The Admin's guide should suffice. REALLY all you need to do is > drop a .WAR file in and change the port to get the container running > standalone. > Alas, it's not always that simple. If you did *anything* inside server.xml for version X, you're going to have to know how to do the same thing for version Y when you upgrade. > > 4) "Appendix" > > Suggest that we move this all up into (0). I'd like people to know these > things asap =) With the history of doc reading, I dunno anyone would make > it this far! > > - r > Craig
Re: First day - RE: PROPOSAL: Tomcat docs
On Wed, 4 Jul 2001, Rob S. wrote: > 2) Web Application Developers' Guide > >- Things to know while developing with Tomcat. The web dev > doesn't have to be an admin pro! > One decision to be made when actually *writing* this thing is whether you consider the servlet spec to be a "required reading" prerequisite or not. I'd certainly vote for that, but you'll find that the current App Developer's Guide does cover quite a bit (but not all) of the material from the spec. Another decision is how Tomcat-specific you want to be here. Everything about creating a WAR should be (in theory) portable to *any* server, and we've also covered the admin stuff (i.e. changes to server.xml) in the previous section. Craig
Re: Poor Tomcat 3.2.2 performance on Win32 with class reloading enabled
> The cases you've described above all happen only once (at startup > time). Assuming that we could safely optimize these cases, would it > really make a significant difference? It wouldn't. While you were away, I did some profiling of the startup (since people complained), and it turns out that the time is mostly spent in : - Crimson, because it's used in validating mode - introspecting and doing various things in the XML mapper (no surprise) > To influence the performance of Cocoon, we'd want to look at the Resources > implementation. It's been worked on, but I would certainly not say we've > really optimized it yet. And reducing the number of calls to > getCanonicalPath() sounds like a good strategy -- as long as it can be > done safely. getCanonicalPath is called only under Windows (for case sensitivity checking). More profiling showed that the resources were fast enough. Remy
