Re: Poor Tomcat 3.2.2 performance on Win32 with class reloading enabled
Remy Craig, Thanks for your responses... On Saturday, July 7, 2001, at 07:28 am, Remy Maucherat wrote: 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) The examples I gave were just some examples of getCanonicalPath that I located in the source - I acknowledge that I had been unable to identify which ones were taking up significant resources, though all the ones I listed were at least in loops. I have had problems profiling Tomcat and Cocoon, but in those threads I have been able to profile under Mac OS X, getCanonicalPath (i.e. native UnixFileSystem.canonicalize) calls whilst running Tomcat 4 and Cocoon II constitute a *very* significant proportion of runtime. I know that others have noted that this is also true under Windows, so this does not appear to be specific to Mac OS X, though the 'cost' of getCanonicalPath under Mac OS X may be proportionally higher than on other operating systems due to certain underlying filesystem issues. 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 Remy - could you explain what you mean here. getCanonicalPath calls within Tomcat are not, as far as I can see, conditional upon runtime Operating System. Both Windows filing systems and HFS / HFS+ (Under Mac OS / Mac OS X) are case insensitive, the latter being BSD Unix derivative. I would have thought that calls to getCanonicalPath would be required, not just for case sensitivity reasons, but also to deal with the assortment of equivalent path descriptors, e.g. the use of .., ., ~user and the effects of filesystem softlinks, hardlinks, aliases, shortcuts, or whathaveyou. If getCanonicalPath is being used as a case insensitive string comparitor, then I am sure there are less costly alternatives. When you say that profiling indicated that resources were fast enough, do you mean that getCanonicalPath is not a significant bottleneck on any platform? I'm not doubting this with respect to Tomcat 4, as the main issues I have run across may be largely Cocoon II specific, unfortunately currently profiling problems mean that I'm going round the houses a little to pin this one down. However, as I indicated in my earlier email, I have tested substituting th java.io.File.getCanonicalPath() method with a caching version and found a very visible speedup which confirms that getCanonicalPath is an issue somewhere in this Tomcat 4 / Cocoon II combination. Stuart. - Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS http://www.adolos.com/
I'd like to retract my earlier request
Hello, my name is Victor Wynnytsky I had sent you a very long message earlier today (July 8) asking for a means of setting the default directory on a per-webapp basis. Then as an after thought I also asked that my message be sent to the XML team to see if maybe Xalan could be told to pickup xsl:imports from a folder other then the default directory. I then researched Xalan furthur and learned about it's URIResolver interface and my problem is pretty muched solved there. Thanks for listening though. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
cvs commit: jakarta-tomcat-connectors/webapp configure.in
jfclere 01/07/09 07:09:19 Modified:webapp configure.in Log: Arrange LOCAL_FILTEREXEC because ret is not set correctly. Revision ChangesPath 1.10 +3 -1 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- configure.in 2001/07/08 23:11:38 1.9 +++ configure.in 2001/07/09 14:09:16 1.10 @@ -58,7 +58,7 @@ dnl -- dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED] dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED] -dnl Version $Id: configure.in,v 1.9 2001/07/08 23:11:38 pier Exp $ +dnl Version $Id: configure.in,v 1.10 2001/07/09 14:09:16 jfclere Exp $ dnl -- dnl -- @@ -98,7 +98,9 @@ done unset first unset line +exit $ret } + ret=$? ]) dnl --
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Hmm If you do an exit $ret, it'll kill the whole ./configure process with some bourne shells... Will check it... Pier [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: jfclere 01/07/09 07:09:19 Modified:webapp configure.in Log: Arrange LOCAL_FILTEREXEC because ret is not set correctly. Revision ChangesPath 1.10 +3 -1 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- configure.in2001/07/08 23:11:381.9 +++ configure.in2001/07/09 14:09:161.10 @@ -58,7 +58,7 @@ dnl -- dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED] dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED] -dnl Version $Id: configure.in,v 1.9 2001/07/08 23:11:38 pier Exp $ +dnl Version $Id: configure.in,v 1.10 2001/07/09 14:09:16 jfclere Exp $ dnl -- dnl -- @@ -98,7 +98,9 @@ done unset first unset line +exit $ret } + ret=$? ]) dnl --
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Pier P. Fumagalli wrote: Hmm If you do an exit $ret, it'll kill the whole ./configure process with some bourne shells... Will check it... Oop, I have just found one, on BS2000! Pier [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: jfclere 01/07/09 07:09:19 Modified:webapp configure.in Log: Arrange LOCAL_FILTEREXEC because ret is not set correctly. Revision ChangesPath 1.10 +3 -1 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- configure.in2001/07/08 23:11:381.9 +++ configure.in2001/07/09 14:09:161.10 @@ -58,7 +58,7 @@ dnl -- dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED] dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED] -dnl Version $Id: configure.in,v 1.9 2001/07/08 23:11:38 pier Exp $ +dnl Version $Id: configure.in,v 1.10 2001/07/09 14:09:16 jfclere Exp $ dnl -- dnl -- @@ -98,7 +98,9 @@ done unset first unset line +exit $ret } + ret=$? ]) dnl --
hello everyone (regarding documentation)
hi everyone, i am planning to start my own documentation project for Tomcat 3.3 and 4.0. The different thing about this project is that, i am going to port all of the tomcat documentation to XML Docbook format. Though i am not very good at docbook but i think i can cope. Once the documentation is complete, I will submit it to the main tomcat development team. I dont really know if this is the rite approach for writing documentation, but i am open for suggestions. It will be a funtime for my summer holidays as well. Hiten Pandya United Kingdom. If anyone would like to help me write the documentation, please submit the sections u will be working on to me at [EMAIL PROTECTED] But first i am waiting for enough good votes and bad votes about the starting of this project. Put [SUGGESTIONS] in the subject header so it is easier for me to fetch them out of my mailbox. Thanks in advance. The following are the details. Document Language: XML Format: DocBook 4.x(stable) Binary Formats: - Portable Document Format (PDF) - HTML - Latex - PostScript - Etc... - Windows Help Format. (text formats) - ASCII - Thanks in advance hiten pandya 15 [EMAIL PROTECTED] united Kingdom. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
I have some more problems because printf does not like \133. (Why \133 and not ]?). I have some remarks: - Why using \033\13301m, \033\13300m etc but not bold=\033\13301m, offbold=\033\13300m, red=...? - \133 is not ] but $ on my EBCDIC platform. - Why not using bold=`tput smso` offbold=`tput rmso`? Does someone know how to ask for red and offred? Jean-frederic Pier P. Fumagalli wrote: Hmm If you do an exit $ret, it'll kill the whole ./configure process with some bourne shells... Will check it... Pier [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: jfclere 01/07/09 07:09:19 Modified:webapp configure.in Log: Arrange LOCAL_FILTEREXEC because ret is not set correctly. Revision ChangesPath 1.10 +3 -1 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- configure.in2001/07/08 23:11:381.9 +++ configure.in2001/07/09 14:09:161.10 @@ -58,7 +58,7 @@ dnl -- dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED] dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED] -dnl Version $Id: configure.in,v 1.9 2001/07/08 23:11:38 pier Exp $ +dnl Version $Id: configure.in,v 1.10 2001/07/09 14:09:16 jfclere Exp $ dnl -- dnl -- @@ -98,7 +98,9 @@ done unset first unset line +exit $ret } + ret=$? ]) dnl --
RE: cvs commit: jakarta-tomcat-connectors/webapp configure.in
May be you could use what Ralf used for mod_ssl :)
...
# some optional terminal sequences
case $TERM in
xterm|xterm*|vt220|vt220*)
T_MD=`echo dummy | awk '{ printf(%c%c%c%c, 27, 91, 49, 109); }'`
T_ME=`echo dummy | awk '{ printf(%c%c%c, 27, 91, 109); }'`
;;
vt100|vt100*)
T_MD=`echo dummy | awk '{ printf(%c%c%c%c%c%c, 27, 91, 49, 109, 0,
0); }'`
T_ME=`echo dummy | awk '{ printf(%c%c%c%c%c, 27, 91, 109, 0, 0);
}'`
;;
default)
T_MD=''
T_ME=''
;;
esac
echo ${T_MD}INITIALIZATION${T_ME}
...
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting jean-frederic clere [EMAIL PROTECTED]: Pier P. Fumagalli wrote: Hmm If you do an exit $ret, it'll kill the whole ./configure process with some bourne shells... Will check it... Oop, I have just found one, on BS2000! And OS/X... It seems to me that the only case in which that would work is when the script is executed by BASH, that forks the second part of the pipe into another process, but if it's interactive, we're screwed :) Pier
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting jean-frederic clere [EMAIL PROTECTED]: I have some more problems because printf does not like \133. (Why \133 and not ]?). Bacause [ and ] are the string delimiters in M4... If you change that and try to run AutoConf, it'll complain... I have some remarks: - Why using \033\13301m, \033\13300m etc but not bold=\033\13301m, offbold=\033\13300m, red=...? - \133 is not ] but $ on my EBCDIC platform. - Why not using bold=`tput smso` offbold=`tput rmso`? Does someone know how to ask for red and offred? Why don't we simply remove all the colourization? It's kinda fancy and neat, but we don't seriously _need_ that... I got that code from Ralf's some project, and looked cool on my terminal, but we seriously don't depend on having colours in the script :) Pier BTW, for US citizens, s/colour/color/g (getting the accent and more over here)
webapp classloader ProtectionDomain (running secured tomcat)
Hi there, I've posted the message below to tomcat-user but it didn't get much attention. Is any work being done to address this? Thanks, --V. Hi all, It seems that webapp classloader puts all classes loaded from a webapp directory into the same ProtectionDomain regardless of the location where the class was loaded from (like classes dir or a jar file). It means that any security grant entry granting permssions to a webapp codesource effectively grants the same set of permissions to each and every class in web application. This is probably fine in most cases but leaves no possibility to fine tune security within web-application. My particular problem is that I'm trying to use JAAS to enable access control with custom JAAS policy implementation. CodeSOurce partitioning that Sun suggests requires that the code sensitive to user-based operations shoud be put into separate ProtectionDomain for JAAS mechanisms to work. The only way to do this with Tomcat is to put classes someplace out of webapp directory, so they don't inherit any permissions assigned to webapp ProtectionDomain. I think that webapp class loader should put classes loaded from class directory and every jar file into diffrent protection domains, like class loaders that load classes from the system classpath in Java. Well, if all that makes any sense to you may be there's something I'm missing here? Just wanted to get other people's opinions... --Vlad. *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ***
Re: hello everyone (regarding documentation)
Quoting hiten pandya [EMAIL PROTECTED]: hi everyone, i am planning to start my own documentation project for Tomcat 3.3 and 4.0. The different thing about this project is that, i am going to port all of the tomcat documentation to XML Docbook format. Though i am not very good at docbook but i think i can cope. Once the documentation is complete, I will submit it to the main tomcat development team. I dont really know if this is the rite approach for writing documentation, but i am open for suggestions. It will be a funtime for my summer holidays as well. Hiten Pandya United Kingdom. If anyone would like to help me write the documentation, please submit the sections u will be working on to me at [EMAIL PROTECTED] But first i am waiting for enough good votes and bad votes about the starting of this project. Put [SUGGESTIONS] in the subject header so it is easier for me to fetch them out of my mailbox. Thanks in advance. A nice way to duplicate the job, indeed... Why not joining Alex et. al and write the documentation with them? Just because you want to do it with the DocBook DTD? A ridiculous excuse, as with a very simple XSLT stylesheet you can convert the Anakia DTD in DocBook with no fuzz... Pier
RE: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting GOMEZ Henri [EMAIL PROTECTED]: May be you could use what Ralf used for mod_ssl :) Version 2.0 of the code I stole :) Why don't we remove colours and that's it? :) Pier
RE: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Hi, Was talking about mod_ssl for 1.3.x and only bold used there... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:31 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-tomcat-connectors/webapp configure.in Quoting GOMEZ Henri [EMAIL PROTECTED]: May be you could use what Ralf used for mod_ssl :) Version 2.0 of the code I stole :) Why don't we remove colours and that's it? :) Pier
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Pier Fumagalli wrote: Quoting jean-frederic clere [EMAIL PROTECTED]: Pier P. Fumagalli wrote: Hmm If you do an exit $ret, it'll kill the whole ./configure process with some bourne shells... Will check it... Oop, I have just found one, on BS2000! And OS/X... It seems to me that the only case in which that would work is when the script is executed by BASH, that forks the second part of the pipe into another process, but if it's interactive, we're screwed :) What about this: +++ Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.10 diff -u -r1.10 configure.in --- configure.in2001/07/09 14:09:16 1.10 +++ configure.in2001/07/09 15:38:33 @@ -98,9 +98,9 @@ done unset first unset line -exit $ret +echo $ret retfile } - ret=$? + ret=`cat retfile` ]) dnl -- +++ Pier
cvs commit: jakarta-tomcat-connectors/webapp configure.in
pier01/07/09 08:46:00
Modified:webapp configure.in
Log:
Removed color grief once for all (nifty but useless and unportable).
Fixed the exit $ret bug introduced by JFC.
Revision ChangesPath
1.11 +8 -8 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- configure.in 2001/07/09 14:09:16 1.10
+++ configure.in 2001/07/09 15:45:57 1.11
@@ -58,7 +58,7 @@
dnl --
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.10 2001/07/09 14:09:16 jfclere Exp $
+dnl Version $Id: configure.in,v 1.11 2001/07/09 15:45:57 pier Exp $
dnl --
dnl --
@@ -67,15 +67,16 @@
AC_DEFUN(LOCAL_INIT,[
AC_PATH_PROG(test,test,${PATH})
AC_PATH_PROG(true,true,${PATH})
- AC_PATH_PROG(printf,printf,${PATH})
+ AC_PATH_PROG(echo,echo,${PATH})
])
AC_DEFUN(LOCAL_HEADER,[
- ${printf} \n\033\13301;31m%s\033\13300m\n $1 12
+ ${echo}
+ ${echo} $1 12
])
AC_DEFUN(LOCAL_FILTEREXEC,[
- ${printf} \033\13301mInvoking\033\13300m: %s\n $1
+ ${echo} Invoking: $1
{
$1
echo retvalue $?
@@ -92,13 +93,12 @@
then
ret=${line}
else
- ${printf} \033\13301m%s\033\13300m: %s\n $2 ${first} ${line}
+ ${echo} $2: ${first} ${line}
fi
fi
done
unset first
unset line
-exit $ret
}
ret=$?
])
@@ -217,7 +217,7 @@
cd ${APRDIR}
LOCAL_HEADER([Building APR configure script])
-LOCAL_FILTEREXEC([./buildconf],[ APR buildconf])
+LOCAL_FILTEREXEC([./buildconf],[APR buildconf])
if ${test} ${ret} -ne 0
then
AC_MSG_ERROR([APR buildconf terminated with error code ${ret}])
@@ -225,7 +225,7 @@
LOCAL_HEADER([Configuring APR])
LOCAL_FILTEREXEC([./configure --enable-static --disable-shared --disable-threads],
- [ APR configure])
+ [APR configure])
if ${test} ${ret} -ne 0
then
AC_MSG_ERROR([APR configure script terminated with error code ${ret}])
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting jean-frederic clere [EMAIL PROTECTED]: What about this: -exit $ret +echo $ret retfile } - ret=$? + ret=`cat retfile` ]) AAARRRGGGHHH! :) I found out why you're trying to do that :) (Me dork!) Pier
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Pier Fumagalli wrote: Quoting jean-frederic clere [EMAIL PROTECTED]: I have some more problems because printf does not like \133. (Why \133 and not ]?). Bacause [ and ] are the string delimiters in M4... If you change that and try to run AutoConf, it'll complain... Yep, it does. I have some remarks: - Why using \033\13301m, \033\13300m etc but not bold=\033\13301m, offbold=\033\13300m, red=...? - \133 is not ] but $ on my EBCDIC platform. - Why not using bold=`tput smso` offbold=`tput rmso`? Does someone know how to ask for red and offred? Why don't we simply remove all the colourization? It's kinda fancy and neat, but we don't seriously _need_ that... I got that code from Ralf's some project, and looked cool on my terminal, but we seriously don't depend on having colours in the script :) Agreed, all cursors and colours are useless when doing nohup nice_shell_that_build_world. Pier BTW, for US citizens, s/colour/color/g (getting the accent and more over here)
cvs commit: jakarta-tomcat-connectors/webapp configure.in
pier01/07/09 08:57:59
Modified:webapp configure.in
Log:
Fixed bug I introduced 5 seconds ago. Now the return value of LOCAL_FILTEREXEC
should be correctly returned to the parent. (try to modify the last line of
APR buildconf to exit with a non-zero value and execute configure, it should
report an error)
Revision ChangesPath
1.12 +2 -2 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- configure.in 2001/07/09 15:45:57 1.11
+++ configure.in 2001/07/09 15:57:56 1.12
@@ -58,7 +58,7 @@
dnl --
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.11 2001/07/09 15:45:57 pier Exp $
+dnl Version $Id: configure.in,v 1.12 2001/07/09 15:57:56 pier Exp $
dnl --
dnl --
@@ -100,7 +100,7 @@
unset first
unset line
}
- ret=$?
+ ${echo} Execution of $1 returned $ret
])
dnl --
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting jean-frederic clere [EMAIL PROTECTED]: Agreed, all cursors and colours are useless when doing nohup nice_shell_that_build_world. Fixed in CVS :) Pier
Copyright issues (was Re: DOC: Table of Contents)
Hi Alex! Alex Chaffee 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. On www.gnu.org you can read the following: --- Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Updated: $Date: 2001/06/29 17:42:09 $ $Author: rms $ --- For all I know, (c) in software is not essentially different from (c) issues in text. Of course, the concept has been borrowed from there, otherwise we would use patents. In fact, you can copyleft a book, or BSD-like-license an essay. But I don't know much anyway. Perhaps the following link would be useful: http://www.gnu.org/philosophy/nonsoftware-copyleft.html Un saludo, Alex.
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Quoting [EMAIL PROTECTED]: Fixed bug I introduced 5 seconds ago. Now the return value of LOCAL_FILTEREXEC should be correctly returned to the parent. (try to modify the last line of APR buildconf to exit with a non-zero value and execute configure, it should report an error) Jean Frederic, can you check if it works for you now? Thanks Pier
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
Pier Fumagalli wrote:
Quoting [EMAIL PROTECTED]:
Fixed bug I introduced 5 seconds ago. Now the return value of
LOCAL_FILTEREXEC should be correctly returned to the parent.
(try to modify the last line of APR buildconf to exit with a non-zero
value and execute configure, it should report an error)
Jean Frederic, can you check if it works for you now? Thanks
No, it does not, because the shell forks and ret is not set in father but in the
son process (after the |).
Look to the output:
+++
APR configure: creating include/arch/unix/apr_private.h
Execution of ./configure --enable-static --disable-shared --disable-threads
returned
/usr/bin/test: integer expression expected before -ne
+++
The only work-around I see is to write the ret in a file and read it.
+++
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.12
diff -u -r1.12 configure.in
--- configure.in2001/07/09 15:57:56 1.12
+++ configure.in2001/07/09 16:59:22
@@ -99,7 +99,9 @@
done
unset first
unset line
+echo ${ret} retfile
}
+ ret=`cat retfile`
${echo} Execution of $1 returned $ret
])
+++
Pier
Re: webapp classloader ProtectionDomain (running secured tomcat)
This is true form tomcat 3.x, but not for Tomcat 4. Tomcat 4 allows setting of different policies for different locations within a webapp. Regards, Glenn Vladimir Grishchenko wrote: Hi there, I've posted the message below to tomcat-user but it didn't get much attention. Is any work being done to address this? Thanks, --V. Hi all, It seems that webapp classloader puts all classes loaded from a webapp directory into the same ProtectionDomain regardless of the location where the class was loaded from (like classes dir or a jar file). It means that any security grant entry granting permssions to a webapp codesource effectively grants the same set of permissions to each and every class in web application. This is probably fine in most cases but leaves no possibility to fine tune security within web-application. My particular problem is that I'm trying to use JAAS to enable access control with custom JAAS policy implementation. CodeSOurce partitioning that Sun suggests requires that the code sensitive to user-based operations shoud be put into separate ProtectionDomain for JAAS mechanisms to work. The only way to do this with Tomcat is to put classes someplace out of webapp directory, so they don't inherit any permissions assigned to webapp ProtectionDomain. I think that webapp class loader should put classes loaded from class directory and every jar file into diffrent protection domains, like class loaders that load classes from the system classpath in Java. Well, if all that makes any sense to you may be there's something I'm missing here? Just wanted to get other people's opinions... --Vlad. *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. *** -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
InstanceListener syntax?
Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. -Thom
RE: webapp classloader ProtectionDomain (running secured tomcat)
I have a feeling that it's a general problem with servlet containers. It's not in the spec (well, I don't remember exatctly...) so every container implementation can choose what to do. What it means is that there's no way to create a container neutral application if one wants to use Java security mechanisms. --V. -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 10:13 AM To: [EMAIL PROTECTED] Subject: Re: webapp classloader ProtectionDomain (running secured tomcat) This is true form tomcat 3.x, but not for Tomcat 4. Tomcat 4 allows setting of different policies for different locations within a webapp. Regards, Glenn Vladimir Grishchenko wrote: Hi there, I've posted the message below to tomcat-user but it didn't get much attention. Is any work being done to address this? Thanks, --V. Hi all, It seems that webapp classloader puts all classes loaded from a webapp directory into the same ProtectionDomain regardless of the location where the class was loaded from (like classes dir or a jar file). It means that any security grant entry granting permssions to a webapp codesource effectively grants the same set of permissions to each and every class in web application. This is probably fine in most cases but leaves no possibility to fine tune security within web-application. My particular problem is that I'm trying to use JAAS to enable access control with custom JAAS policy implementation. CodeSOurce partitioning that Sun suggests requires that the code sensitive to user-based operations shoud be put into separate ProtectionDomain for JAAS mechanisms to work. The only way to do this with Tomcat is to put classes someplace out of webapp directory, so they don't inherit any permissions assigned to webapp ProtectionDomain. I think that webapp class loader should put classes loaded from class directory and every jar file into diffrent protection domains, like class loaders that load classes from the system classpath in Java. Well, if all that makes any sense to you may be there's something I'm missing here? Just wanted to get other people's opinions... --Vlad. *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. *** -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
cvs commit: jakarta-tomcat-connectors/webapp configure.in
pier01/07/09 10:59:51
Modified:webapp configure.in
Log:
Committed JFC's patch for returning the right return value out of LOCAL_FILTEREXEC
Revision ChangesPath
1.13 +5 -1 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- configure.in 2001/07/09 15:57:56 1.12
+++ configure.in 2001/07/09 17:59:48 1.13
@@ -58,7 +58,7 @@
dnl --
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.12 2001/07/09 15:57:56 pier Exp $
+dnl Version $Id: configure.in,v 1.13 2001/07/09 17:59:48 pier Exp $
dnl --
dnl --
@@ -68,6 +68,7 @@
AC_PATH_PROG(test,test,${PATH})
AC_PATH_PROG(true,true,${PATH})
AC_PATH_PROG(echo,echo,${PATH})
+ AC_PATH_PROG(rm,rm,${PATH})
])
AC_DEFUN(LOCAL_HEADER,[
@@ -99,7 +100,10 @@
done
unset first
unset line
+echo ${ret} retvalue.tmp
}
+ ret=`cat retvalue.tmp`
+ ${rm} retvalue.tmp
${echo} Execution of $1 returned $ret
])
Re: cvs commit: jakarta-tomcat-connectors/webapp configure.in
jean-frederic clere at [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: Quoting [EMAIL PROTECTED]: Fixed bug I introduced 5 seconds ago. Now the return value of LOCAL_FILTEREXEC should be correctly returned to the parent. (try to modify the last line of APR buildconf to exit with a non-zero value and execute configure, it should report an error) Jean Frederic, can you check if it works for you now? Thanks No, it does not, because the shell forks and ret is not set in father but in the son process (after the |). Ok... Patched... Check it out :) Pier
Re: Vote on oustanding doc issues?
I was out of town for the holiday, so I have just read almost all of this ex post facto. It looks like there are quite a few people, myself included, willing to devote an appreciable amount of time to an informal new group of doc wrangers. When I originally jumped into this thread early on, I had no idea that there were so many people ready to help out. That the Tomcat list has so many people truly interested in providing users with extensive and well-organized documentation only speaks to the quality of the Tomcat developer community. Hell, most OSS projects would be arguing over whether there would be enough internal effort to even warrant a separate docs sub-project. The fact that this is a foregone conclusion with Tomcat, and that we are actually debating whether or not it makes logical sense, is really quite impressive when you stop and think about it. Anyway, I agree with Rob. I would like to see a committer bring at least #1 to a vote at this point. That way we can at least get the directories in place, where we can then start shuffling all existing docs into an organized location (or locations) and go from there. Alex has graciously agreed to be the current Czar, and based on his work at jGuru, I think we should *definitely* take him up on that. He and Rob seem to have a sensible Master Plan(tm) with the TOC. With #1 out of the way, at least people can start sending in whatever is out there. Once our fearless Czar consolidates that, we'll can get a good idea of where we stand. The rest (doc format, to webapp or not to webapp, fine tuning the TOC, etc.) can follow later. I think that once we have something tangible (the repositories), everything else will start to take shape quite nicely. A vote on #1 will also, through the resulting +1's vs. +0's, give us an idea of exactly how many contributors this new cabal will have. The more people who answer the roll call, the fancier and more extensive we can get when dicussing the TOC. Regards, Christopher Rob S. wrote: Not to be pushy or anything, but I'd like to get these settled quickly so we can get down to writing some docs =) Does a committer want to call a vote on these two things? Are we ready to do that yet? 1) Tomcat documentation per-project or in a single repository? 2) What is the format (XML, *Book, HTML, etc.) of the documentation source? If XML, what DTD? Okay, you can't really vote on the second I one I guess =) Hmm... what to do? Personally I'd like to use something XML-like, but close to HTML. It would require less documentation (re: tags) and less work than HTML to author docs, meaning hopefully more people would do it, more often. If that's Anakia, whatever. If it's XML with some other DTD, whatever. Once we know these two things, we can get to work. Of course there will be discussion on these points, but I'd like to bring them to a close sooner than later, so we can keep moving on with things like the TOC. - r
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
on 7/6/01 9:53 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: It would sure be nice to have a little HOWTO on what tags (like document and section) Anakia recognizes, and what they do :-). Anakia recognizes *any* tags. It is the Jakarta-Site2 module's stylesheet which is the key. Needless to say, I have now documented it: http://jakarta.apache.org/site/jakarta-site-tags.html Happy now? One more nail in this discussion's coffin. The same, of course, goes for the XSLT stylesheets, including stylebook, that are used in various projects. Yup. -jon
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocumentation Redactors To Hire]
on 7/7/01 9:33 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: FWIW, I'm fine with Anakia, XSLT, Cocoon, Stylebook, Docbook, or whatever ... but IF AND ONLY IF the tags for use by the document authors are well documented, and the page generation procedure is amenable to Ant scripting (not a difficult problem in most cases). Jakarta-Site tags are now documented. http://jakarta.apache.org/site/jakarta-site-tags.html Also, please quit grouping Anakia into Anakia tags need to be documented. It is the Jakarta-Site2 project's tags which need to be documented (and have been). Anakia itself doesn't give a shit what tags you use. :-) -jon
RE: tomcat docs mailinglists..
I created a few mailinglist on my server tomcatdocs.isallineed.org , to send notes for tomcat documentation to. This is just to gather all the notes on a specific subject to make documentation from. -1. They should have been created on an apache.org server. I thought : make stuff available to make the docs gathering process easier, especially for things that are just notes and not really docs and as I said : it is not replacement for the apache.org mailinglist, if it is ever gonna be there. Question : the -1 is for what actually? Or is it a +1 to let me setup this stuff on an apache server (I'll be happy to do that too..) Another question : when is who gonna create these mailinglists and how are they gonna manage it? Any ideas on the format of the messages, so there is a parsing possibility? Mvgr, Martin
Re: tomcat docs mailinglists..
on 7/9/01 12:34 PM, Martin van den Bemt [EMAIL PROTECTED] wrote: Question : the -1 is for what actually? Using your lists. I'm not going to subscribe. Another question : when is who gonna create these mailinglists and how are they gonna manage it? Mailing list creation is dictated by the active developers on a project. Once there has been a vote and the list has been decided to be created, email is sent to the appropriate address (craig knows the one) and the list is created by the people with the right permissions. Once the list has been created, someone needs to go and update the jakarta-site2/xdocs/site/mail2.xml file (which is generated with Anakia)...:-) -jon
[PATCH] Ajp13 wrong Response
This fixes the problem reported by Angel Aray in thread 23795. The diff is against TC3.3 M4. What was happening is that the user hitting the stop button in the browser was invoking the re-try broken connection logic. This totally freaks out the proxy server who now thinks that the re-sent page is actually the page for a different request. jk_ajp13_worker.diff
RE: tomcat docs mailinglists..
Question : the -1 is for what actually? Using your lists. I'm not going to subscribe. Me neither.. It's just for gathering notes.. You can subscribe if you want to, but the intention is to just request (or parse if possible) the messages to construct docs from in a later stage. So once a month (or whenever) I collect the information in the lists and try to incorporate it into the created docs on tomccat-docs (or whatever its name is gonna be). So not subscribing is intended use ;-). BTW where can I find Anakia (not that I looked heavily for it though..).. But maby I can integrate some stuff in my qmail manager (writing that in java btw.. and is still a work in progress..) Mvgr, Martin
Probably a simple problem with an equally simple solution...
I was trying to develop my own valve to plug into Catalina, but running into some problems. I wrote up a little class that implements Valve and has empty code for getInfo() and invoke(). I put it in its own package called valvetest, compiled it just fine, put that folder with the class in it in Catalina's startup classpath, and added a valve element to my server.xml. Catalina could find the class when it started, but would give me an IllegalArgumentException - argument type mismatch for the valve. Finally I decided to stick the classes into catalina.jar, and it worked. The odd thing here is that before I jarred it, Catalina found the class just fine, and even _ran its constructor_. Though I have one solution for this now (jarring it into catalina.jar), I'm not terribly satisfied with that. I wanted to know if there's a more convenient way of adding my custom components without modifying catalina.jar. Thanks, in advance. -KSH
Re: tomcat docs mailinglists..
on 7/9/01 12:55 PM, Martin van den Bemt [EMAIL PROTECTED] wrote: BTW where can I find Anakia (not that I looked heavily for it though..).. http://jakarta.apache.org/velocity/anakia.html But maby I can integrate some stuff in my qmail manager (writing that in java btw.. and is still a work in progress..) Check out... http://anzu.tigris.org/ The website isn't real up to date, but the source code is and I'm sure that collaboration is better than working alone. We use it within our CollabNet SourceCast application. -jon
Re: Probably a simple problem with an equally simple solution...
Quoting Kedar Hirve [EMAIL PROTECTED]: I was trying to develop my own valve to plug into Catalina, but running into some problems. I wrote up a little class that implements Valve and has empty code for getInfo() and invoke(). I put it in its own package called valvetest, compiled it just fine, put that folder with the class in it in Catalina's startup classpath, and added a valve element to my server.xml. Catalina could find the class when it started, but would give me an IllegalArgumentException - argument type mismatch for the valve. Finally I decided to stick the classes into catalina.jar, and it worked. The odd thing here is that before I jarred it, Catalina found the class just fine, and even _ran its constructor_. Though I have one solution for this now (jarring it into catalina.jar), I'm not terribly satisfied with that. I wanted to know if there's a more convenient way of adding my custom components without modifying catalina.jar. It doesn't work even if you put the valve class in server/classes (common/classes should work too) ? Remy
Re: tomcat docs mailinglists..
on 7/9/01 1:20 PM, Jon Stevens [EMAIL PROTECTED] wrote: BTW where can I find Anakia (not that I looked heavily for it though..).. http://jakarta.apache.org/velocity/anakia.html Oh yea... http://www.google.com/search?q=anakia First response...imagine that... -jon
RE: tomcat docs mailinglists..
BTW where can I find Anakia (not that I looked heavily for it though..).. http://jakarta.apache.org/velocity/anakia.html But maby I can integrate some stuff in my qmail manager (writing that in java btw.. and is still a work in progress..) Check out... http://anzu.tigris.org/ The website isn't real up to date, but the source code is and I'm sure that collaboration is better than working alone. If your interested : Yep.. probably.. The problem is the different approach.. They are focused on the ezmlm and I'm focused on actually managing the qmail server, integration with dns, sanity checks etc, and that all in java.. They also use perl stuff to make their life a little bit easier.. If I have to use natives, so it be, but still not necessary ;-). So I'm writing a qmail manager which other people can extend to. It is also a experiment project for myself, so it has some use to do it alone, but for the sake of it : I'll drop them a mail. If something comes out of it, I'll drop you a mail.. We use it within our CollabNet SourceCast application. -jon
My small, simple problem continued... (null container for my valve)
Oh, WOW. It did work, and I didn't even have to modify Catalina's startup classpath. I had tried putting the class under common\lib and server\lib, but I didn't know that common\classes would work. But now I've got another problem... Again, I have this barebones valve class I wrote, and I've gotten it to load up without exception in Catalina. Now, oddly enough, I find that my valve has a null container, even though its nested in a context in my server.xml: Context className=org.apache.catalina.core.StandardContext path=/ debug=0 docBase=/ reloadable=true Logger className=org.apache.catalina.logger.FileLogger verbosity=1 directory=/logs/kedlog prefix=valvetest timestamp=true / Valve className=org.apache.catalina.valvetest.KedValve / /Context Is there some initialization I need to do, or am I forgetting some tags in my server.xml? Thanks again, -KSH
Re: My small, simple problem continued... (null container for my valve)
Oh, WOW. It did work, and I didn't even have to modify Catalina's startup classpath. I had tried putting the class under common\lib and server\lib, but I didn't know that common\classes would work. But now I've got another problem... In the lib folders, you can only put jars. Un-jarred classes should be in the classes folders. That's mentioned in the CL docs. The best place to put your valve here is in server/classes/ Again, I have this barebones valve class I wrote, and I've gotten it to load up without exception in Catalina. Now, oddly enough, I find that my valve has a null container, even though its nested in a context in my server.xml: Context className=org.apache.catalina.core.StandardContext path=/ debug=0 docBase=/ reloadable=true Logger className=org.apache.catalina.logger.FileLogger verbosity=1 directory=/logs/kedlog prefix=valvetest timestamp=true / Valve className=org.apache.catalina.valvetest.KedValve / /Context Is there some initialization I need to do, or am I forgetting some tags in my server.xml? Does your valve extend ValveBase or implement Contained ? Remy
Re: InstanceListener syntax?
Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. Glenn, would the default context help here ? Remy
cvs commit: jakarta-tomcat-connectors/webapp/apache-1.3 Makefile.in mod_webapp.c
pier01/07/09 15:00:28
Modified:webapp/apache-1.3 Makefile.in mod_webapp.c
Log:
Function renamed for clarity...
Revision ChangesPath
1.4 +2 -2 jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Makefile.in 2001/07/08 23:11:42 1.3
+++ Makefile.in 2001/07/09 22:00:23 1.4
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.3 2001/07/08 23:11:42 pier Exp $
+# @version $Id: Makefile.in,v 1.4 2001/07/09 22:00:23 pier Exp $
include @SRCDIR@/Makedefs
@@ -84,7 +84,7 @@
-I$(APXS_INCLUDEDIR) $(CPPFLAGS) $(EXTRA_CPPFLAGS) \
-c $ -o $@
-mod_webapp.so: mod_webapp.lo
+mod_webapp.so: mod_webapp.lo @SRCDIR@/lib/libwebapp.la @APRDIR@/libapr.la
@echo Linking Apache 1.3 WebApp Module
@$(SHELL) $(LIBTOOL) $(LTFLAGS) --mode=link \
$(APXS_LD_SHLIB) $(APXS_LDFLAGS_SHLIB) \
1.17 +9 -9 jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c
Index: mod_webapp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- mod_webapp.c 2001/05/12 02:31:47 1.16
+++ mod_webapp.c 2001/07/09 22:00:24 1.17
@@ -57,7 +57,7 @@
/**
* @author Pier Fumagalli mailto:[EMAIL PROTECTED]
- * @version $Id: mod_webapp.c,v 1.16 2001/05/12 02:31:47 jon Exp $
+ * @version $Id: mod_webapp.c,v 1.17 2001/07/09 22:00:24 pier Exp $
*/
#include httpd.h
@@ -84,26 +84,26 @@
/* MODULE AND LIBRARY INITIALIZATION AND DESTRUCTION */
/* * */
-/* Destroy the module and the WebApp Library */
-static void wam_destroy(void *nil) {
-if (!wam_initialized) return;
-wa_destroy();
-wam_initialized=FALSE;
-}
-
/* Startup the module and the WebApp Library */
static void wam_startup(server_rec *s, pool *p) {
if (!wam_initialized) return;
wa_startup();
}
+/* Destroy the module and the WebApp Library */
+static void wam_shutdown(void *nil) {
+if (!wam_initialized) return;
+wa_shutdown();
+wam_initialized=FALSE;
+}
+
/* Initialize the module and the WebApp Library */
static const char *wam_init(pool *p) {
const char *ret=NULL;
if(wam_initialized) return(NULL);
if ((ret=wa_init())!=NULL) return(ret);
-ap_register_cleanup(p,NULL,wam_destroy,NULL);
+ap_register_cleanup(p,NULL,wam_shutdown,NULL);
wam_initialized=TRUE;
return(NULL);
}
cvs commit: jakarta-tomcat-connectors/webapp/include wa_main.h
pier01/07/09 15:00:54 Modified:webapp/include wa_main.h Log: Functions renamed for clarity. Revision ChangesPath 1.5 +4 -14 jakarta-tomcat-connectors/webapp/include/wa_main.h Index: wa_main.h === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/include/wa_main.h,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- wa_main.h 2001/05/10 21:15:00 1.4 +++ wa_main.h 2001/07/09 22:00:51 1.5 @@ -58,7 +58,7 @@ /** * @package Main * @author Pier Fumagalli mailto:[EMAIL PROTECTED] - * @version $Id: wa_main.h,v 1.4 2001/05/10 21:15:00 pier Exp $ + * @version $Id: wa_main.h,v 1.5 2001/07/09 22:00:51 pier Exp $ */ #ifndef _WA_MAIN_H_ #define _WA_MAIN_H_ @@ -109,9 +109,9 @@ * Cleans up all resources allocated by the provider. * br * The provider is notified that no further requests will be handled, and - * the WebApp library is being destroyed. + * the WebApp library is being shut down. */ -void (*destroy)(void); +void (*shutdown)(void); /** * Configure a connection with the parameter from the web server @@ -186,7 +186,7 @@ * to any other WebApp Library function after this function has been invoked * will result in impredictable results. */ -void wa_destroy(void); +void wa_shutdown(void); /** * Deploy a web-application. @@ -212,16 +212,6 @@ * @param others The parameters to the format string. */ void wa_debug(const char *f, const int l, const char *fmt, ...); - -/** - * Log an error message. - * - * @param f The file where this function was called. - * @param l The line number where this function was called. - * @param fmt The format string of the debug message (printf style). - * @param others The parameters to the format string. - */ -void wa_log(const char *f, const int l, const char *fmt, ...); /** * The WebApp library memory pool.
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_info.c wa_main.c wa_request.c
pier01/07/09 15:02:13
Modified:webapp/lib pr_info.c wa_main.c wa_request.c
Log:
Minor fixes.
Revision ChangesPath
1.2 +21 -21jakarta-tomcat-connectors/webapp/lib/pr_info.c
Index: pr_info.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_info.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- pr_info.c 2001/05/10 15:53:49 1.1
+++ pr_info.c 2001/07/09 22:02:08 1.2
@@ -55,7 +55,7 @@
* *
* = */
-/* @version $Id: pr_info.c,v 1.1 2001/05/10 15:53:49 pier Exp $ */
+/* @version $Id: pr_info.c,v 1.2 2001/07/09 22:02:08 pier Exp $ */
#include wa.h
/* Counter for requests */
@@ -73,8 +73,8 @@
}
/* Cleans up all resources allocated by this provider. */
-static void info_destroy(void) {
-wa_debug(WA_MARK,INFO provider destroyed);
+static void info_shutdown(void) {
+wa_debug(WA_MARK,INFO provider shut down);
}
/* Configure a connection with the parameter from the web server
@@ -219,7 +219,7 @@
static int info_handle_hdrname(void *d, const char *n, const char *v) {
wa_request *r=(wa_request *)d;
-wa_rprintf(r, %sbr\n,n);
+wa_rprintf(r, nobr%s/nobrbr\n,n);
return(TRUE);
}
@@ -232,7 +232,7 @@
b=apr_pstrndup(r-pool,b,64);
b=apr_pstrcat(r-pool,b, ,NULL);
}
-wa_rprintf(r, bquot;%squot;/bbr\n,b);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,b);
return(TRUE);
}
@@ -346,21 +346,21 @@
wa_rprintf(r, /font\n);
wa_rprintf(r,/td\n);
wa_rprintf(r,td width=\90%%\ valign=\top\ align=\left\\n);
-wa_rprintf(r, font size=\-1\\n);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-serv-host);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-serv-addr);
-wa_rprintf(r, bquot;%dquot;/bbr\n,r-serv-port);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-clnt-host);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-clnt-addr);
-wa_rprintf(r, bquot;%dquot;/bbr\n,r-clnt-port);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-meth);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-ruri);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-args);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-prot);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-schm);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-user);
-wa_rprintf(r, bquot;%squot;/bbr\n,r-auth);
-wa_rprintf(r, bquot;%dquot;/b\n,r-clen);
+wa_rprintf(r, font size=\-1\nobr\n);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-serv-host);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-serv-addr);
+wa_rprintf(r, bnobrquot;%dquot;/nobr/bbr\n,r-serv-port);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-clnt-host);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-clnt-addr);
+wa_rprintf(r, bnobrquot;%dquot;/nobr/bbr\n,r-clnt-port);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-meth);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-ruri);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-args);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-prot);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-schm);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-user);
+wa_rprintf(r, bnobrquot;%squot;/nobr/bbr\n,r-auth);
+wa_rprintf(r, bnobrquot;%dquot;/nobr/b\n,r-clen);
wa_rprintf(r, /font\n);
wa_rprintf(r,/td\n);
@@ -439,7 +439,7 @@
info,
info_init,
info_startup,
-info_destroy,
+info_shutdown,
info_connect,
info_deploy,
info_conninfo,
1.7 +12 -23jakarta-tomcat-connectors/webapp/lib/wa_main.c
Index: wa_main.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/wa_main.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wa_main.c 2001/06/07 09:40:33 1.6
+++ wa_main.c 2001/07/09 22:02:09 1.7
@@ -55,9 +55,13 @@
* *
* = */
-/* @version $Id: wa_main.c,v 1.6 2001/06/07 09:40:33 jfclere Exp $ */
+/* @version $Id: wa_main.c,v 1.7 2001/07/09 22:02:09 pier Exp $ */
#include wa.h
+#ifndef DEBUG
+#define DEBUG
+#endif
+
/* The current APR memory pool. */
apr_pool_t *wa_pool=NULL;
/* The list of all deployed applications. */
@@ -88,7 +92,7 @@
while(wa_providers[x]!=NULL) {
const char
RE: My small, simple problem continued... (null container for my valve)
It extends ValveBase, which should implicitly make it implement Contained, I think? I just tried explicitly Contained as well, but it didn't make any difference. It still has a null container. I'm on Win 2000, running Tomcat standalone, by the way. -KSH -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: My small, simple problem continued... (null container for my valve) Does your valve extend ValveBase or implement Contained ? Remy
DOC: Re: Vote on oustanding doc issues?
On the topic of a new mailing list: I think we can do the next steps inside the tomcat-dev list or on our own. (BTW, let's use DOC: as a prefix so it's easier to scan for new messages.) I want to do this in full view of the rest of the community, mostly so they can see what's going on and volunteer to contribute. (Martin's notes-gathering list is a good idea, but I think a bit premature, given issues like what the topics are and what format they need to be in. I definitely don't want substantive discussion to happen on his lists (see prior para.)) Rob S. wrote: Not to be pushy or anything, but I'd like to get these settled quickly so we can get down to writing some docs =) Does a committer want to call a vote on these two things? Are we ready to do that yet? I don't want to rush it. 1) Tomcat documentation per-project or in a single repository? This is actually three separate questions, and I don't think any are quite ready for a vote yet: 1a) Should Tomcat 3.2 documentation be rolled in together with Tomcat 3.3 documentation for a single, up-to-date, source base, whose release cycle will be independent of the release cycle of Tomcat? 1b) Should Tomcat 3.x documentation be rolled together with Tomcat 4.x documentation? 1c) Should there be a separate CVS repository for Tomcat Documentation that is separate from jakarta-tomcat and jakarta-tomcat-4.0? (Currently, there's a src/doc subdirectory in the jakarta-tomcat repository that would work just fine (especially if the answer to 1b is no.) OTOH, it might be nice to get a fresh slate, our own build.xml, etc.) (Personally, I'm leaning towards yes on all 3, but I'm not quite sure.) 2) What is the format (XML, *Book, HTML, etc.) of the documentation source? If XML, what DTD? I propose that we do *NOT* try to answer this yet, or maybe ever. Instead, I propose anarchy: that the Table Of Contents be maintained in a convenient text-editable format. It will contain links to doc files (sections or guides or chapters) that are files in whatever format they're in. I imagine that it will eventually be most convenient to use Anakia, but for now, it means that we don't have to worry about rewriting useful docs that are already in HTML. Organizing the TOC and and assigning volunteer authors to write parts is much more important than file format right now. Once we know these two things, we can get to work. Of course there will be discussion on these points, but I'd like to bring them to a close sooner than later, so we can keep moving on with things like the TOC. We can work on the TOC independently of resolving those other issues. -- 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/
cvs commit: jakarta-tomcat-connectors/webapp/lib .cvsignore
pier01/07/09 15:07:05 Modified:webapp/apache-1.3 .cvsignore webapp/lib .cvsignore Added: webapp/include .cvsignore webapp/java .cvsignore Log: Added ignores for MacOS/X resource storage. Revision ChangesPath 1.3 +1 -0 jakarta-tomcat-connectors/webapp/apache-1.3/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- .cvsignore2001/07/08 23:11:41 1.2 +++ .cvsignore2001/07/09 22:06:56 1.3 @@ -1,4 +1,5 @@ .libs +.DS_Store Makefile mod_webapp.lo mod_webapp.o 1.1 jakarta-tomcat-connectors/webapp/include/.cvsignore Index: .cvsignore === .DS_Store 1.1 jakarta-tomcat-connectors/webapp/java/.cvsignore Index: .cvsignore === .DS_Store 1.3 +1 -0 jakarta-tomcat-connectors/webapp/lib/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- .cvsignore2001/07/08 23:11:44 1.2 +++ .cvsignore2001/07/09 22:07:03 1.3 @@ -1,4 +1,5 @@ .libs +.DS_Store Makefile libwebapp.la libwebapp.a
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp.c
pier01/07/09 15:11:23
Modified:webapp/lib pr_warp.c
Log:
Disabling WARP functionality until a couple of bugs have been fixed. (Just
in case someone relies on CVS checkouts)
Revision ChangesPath
1.4 +5 -512jakarta-tomcat-connectors/webapp/lib/pr_warp.c
Index: pr_warp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- pr_warp.c 2001/06/07 09:40:32 1.3
+++ pr_warp.c 2001/07/09 22:11:21 1.4
@@ -55,45 +55,10 @@
* *
* = */
-/* @version $Id: pr_warp.c,v 1.3 2001/06/07 09:40:32 jfclere Exp $ */
+/* @version $Id: pr_warp.c,v 1.4 2001/07/09 22:11:21 pier Exp $ */
#include wa.h
/* * */
-/* WARP CONSTANTS */
-/* * */
-
-/* Look in WarpConstants.java for a description of these definitions. */
-#define RID_CONNECTION 0x0
-#define RID_DISCONNECT 0x0
-
-#define TYP_CONINIT_HST 0x0
-#define TYP_CONINIT_HID 0x1
-#define TYP_CONINIT_APP 0x2
-#define TYP_CONINIT_AID 0x3
-#define TYP_CONINIT_REQ 0x4
-#define TYP_CONINIT_RID 0x5
-#define TYP_CONINIT_ERR 0xF
-
-#define TYP_REQINIT_MET 0x00010
-#define TYP_REQINIT_URI 0x00011
-#define TYP_REQINIT_ARG 0x00012
-#define TYP_REQINIT_PRO 0x00013
-#define TYP_REQINIT_HDR 0x00014
-#define TYP_REQINIT_VAR 0x00015
-#define TYP_REQINIT_RUN 0x0001D
-#define TYP_REQINIT_ERR 0x0001E
-#define TYP_REQINIT_ACK 0x0001F
-
-#define TYP_REQUEST_STA 0x00020
-#define TYP_REQUEST_HDR 0x00021
-#define TYP_REQUEST_CMT 0x00022
-#define TYP_REQUEST_DAT 0x00023
-#define TYP_REQUEST_ERR 0x0002E
-#define TYP_REQUEST_ACK 0x0002F
-
-#define MAXPAYLOAD 65536
-
-/* * */
/* STRUCTURES AND FUNCTIONS DECLARATION */
/* * */
@@ -111,79 +76,12 @@
wa_boolean depl;
} warp_aconfig;
-typedef struct warp_packet {
-apr_pool_t *pool; /* The APR memory pool where this packet is allocated */
-int type; /* The packet type signature */
-int size; /* The size of the buffer (used by read) */
-int bpos; /* The current position in the buffer */
-char *buff; /* The payload buffer */
-} warp_packet;
-
/* The list of all configured connections */
static wa_chain *warp_connections=NULL;
/* This provider */
wa_provider wa_provider_warp;
/* * */
-/* WARP PACKET FUNCTIONS */
-/* * */
-static void p_reset(warp_packet *pack) {
-pack-type=0;
-pack-bpos=0;
-pack-size=0;
-}
-
-static warp_packet *p_create(apr_pool_t *pool) {
-warp_packet *pack=apr_palloc(pool,sizeof(warp_packet));
-pack-buff=apr_palloc(pool,MAXPAYLOAD*sizeof(char));
-pack-pool=pool;
-p_reset(pack);
-return(pack);
-}
-
-static wa_boolean p_wshort(warp_packet *p, int k) {
-if ((p-bpos+2)MAXPAYLOAD) return(FALSE);
-p-buff[p-bpos++]=(char)((k8)0x0ff);
-p-buff[p-bpos++]=(char)(k0x0ff);
-return(TRUE);
-}
-
-static wa_boolean p_wstring(warp_packet *p, char *s) {
-int l=0;
-int x=0;
-
-if (s==NULL) return(p_wshort(p,0));
-
-/* Evaluate string length */
-l=strlen(s);
-/* Store string length */
-if (!p_wshort(p,strlen(s))) return(FALSE);
-/* Check if we have room in the buffer and copy the string */
-if ((p-bpos+l)MAXPAYLOAD) return(FALSE);
-for(x=0; xl; x++) p-buff[p-bpos++]=s[x];
-return(TRUE);
-}
-
-static int p_rshort(warp_packet *p) {
-int k=0;
-int x=0;
-
-/* Store the two bytes */
-x=p-bpos;
-k=((p-buff[p-bpos++]8)0x0ff00);
-k=((k|(p-buff[p-bpos++]0x0ff))0x0);
-return(k);
-}
-
-static char *p_rstring(warp_packet *p) {
-int k=p_rshort(p);
-char *ret=apr_pstrndup(p-pool,p-buff+p-bpos,k);
-p-bpos+=k;
-return(ret);
-}
-
-
-/* * */
/* NETWORK FUNCTIONS */
/* * */
@@
cvs commit: jakarta-tomcat-connectors/webapp configure.in
pier01/07/09 15:20:13
Modified:webapp configure.in
Log:
Fix from JFC @ home.
Revision ChangesPath
1.14 +2 -1 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- configure.in 2001/07/09 17:59:48 1.13
+++ configure.in 2001/07/09 22:20:12 1.14
@@ -58,7 +58,7 @@
dnl --
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.13 2001/07/09 17:59:48 pier Exp $
+dnl Version $Id: configure.in,v 1.14 2001/07/09 22:20:12 pier Exp $
dnl --
dnl --
@@ -78,6 +78,7 @@
AC_DEFUN(LOCAL_FILTEREXEC,[
${echo} Invoking: $1
+ ${echo} -1 retvalue.tmp
{
$1
echo retvalue $?
DOC: Re: Vote on oustanding doc issues?
On the topic of a new mailing list: I think we can do the next steps inside the tomcat-dev list or on our own. (BTW, let's use DOC: as a prefix so it's easier to scan for new messages.) I want to do this in full view of the rest of the community, mostly so they can see what's going on and volunteer to contribute. I prefer [DOC] btw.. replying to a doc issue with DOC: removes the DOC: entry. (at least in outlook). (Martin's notes-gathering list is a good idea, but I think a bit premature, given issues like what the topics are and what format they need to be in. I definitely don't want substantive discussion to happen on his lists (see prior para.)) The lists are not for discussion and especially not these discussions.. They should contain notes! Good idea, a hey, mail to one of the lists (you don't have to be a member). The format needs to be discussed indeed. My proposal on that wasn't really usefull and too complicated. on these two things? Are we ready to do that yet? I don't want to rush it. Better do it correct the first time. 1) Tomcat documentation per-project or in a single repository? (Personally, I'm leaning towards yes on all 3, but I'm not quite sure.) I agree completely. Don't think we must start this in a current cvs root. 2) What is the format (XML, *Book, HTML, etc.) of the documentation source? If XML, what DTD? I propose that we do *NOT* try to answer this yet, or maybe ever. Instead, I propose anarchy: that the Table Of Contents be maintained in a convenient text-editable format. It will contain links to doc files (sections or guides or chapters) that are files in whatever format they're in. I imagine that it will eventually be most convenient to use Anakia, but for now, it means that we don't have to worry about rewriting useful docs that are already in HTML. The main parts and main chapters in seperate subdirs at first? Generating a default output at a certain point is not too bad though. But we have to be open enough for people who want to convert this to eg man pages or a nice pdf. Organizing the TOC and and assigning volunteer authors to write parts is much more important than file format right now. I already volunteerd for the gathering notes ;) Once we know these two things, we can get to work. Of course there will be discussion on these points, but I'd like to bring them to a close sooner than later, so we can keep moving on with things like the TOC. We can work on the TOC independently of resolving those other issues. As long everything is stays flexible enough, we don't want to spend 80% of our time in generating docs in whatever format. In the beginning we probably will only be complementry to current documentation until we are grown up enough to be the source for documentation on tomcat releases. This leaves room for experimenting with what works best. A vote on a seperate mailinglist for discussing doc issues would be appreciated though. It's getting a lot of discussion already and this will grow in the near future I think (and hope..). This way we don't miss any of the important non-docs specific stuff. Mvgr, Martin
RE: Re: Vote on oustanding doc issues?
Preamble: grumble grumble =) I don't want to rush it. Agreed, but at the same time, I'd like to decide sooner than later. I'm on co-op until August 24th, then I start full-time school again. 4 courses doesn't leave a lot of room for TC docs. Judging by the amount of progress we've made recently (pretty much *zero* in over 10 days), I'll be graduated by the time we figure out if Tomcat documentation needs a separate repository. 1a) Should Tomcat 3.2 documentation be rolled in together with Tomcat 3.3 documentation for a single, up-to-date, source base, whose release cycle will be independent of the release cycle of Tomcat? Bundle the 3.2.x docs with 3.2.x and only have the 3.3 docs online (latest Tomcat release). If you want the 3.2.x docs, get them with the binary or whatever. I certainly don't think we should keep old versions of documentation updated. I mean, why would updated 3.0 or 3.1 docs be useful? Too much work, too little people wanting to do it. I don't think anyone would expect even a product company to update their documentation on old versions. The version of docs I, as a user, would expect to see 'shipping' with 3.2.2 (if i want to download an older version of the container) is how the docs looked at 3.2.2 ship time. 1b) Should Tomcat 3.x documentation be rolled together with Tomcat 4.x documentation? 1c) Should there be a separate CVS repository for Tomcat Documentation that is separate from jakarta-tomcat and jakarta-tomcat-4.0? Depends on if there is something that should be factored out from the documentation. From what we've seen so far, aside from Craig's dev guide, the answer is not much. I propose that we do *NOT* try to answer this yet, or maybe ever. Instead, I propose anarchy: that the Table Of Contents be maintained in a convenient text-editable format. It will contain links to doc files (sections or guides or chapters) that are files in whatever format they're in. I imagine that it will eventually be most convenient to use Anakia, but for now, it means that we don't have to worry about rewriting useful docs that are already in HTML. I don't imagine anyone will want to take the task on of converting the anarchical doc repository into the format is decided upon, or how we'll generate anything useful for people to evaluate during that time. So someone writes in HTML, someone writes in DocBook, etc. If I want to help on different docs I have to figure out the viewing/editing mechanism for each one? Ugh... Organizing the TOC and and assigning volunteer authors to write parts is much more important than file format right now. Agreed, but the decision needs to be made. I don't want to start discussing something the moment we need it. We can work on the TOC independently of resolving those other issues. They're not being resolved, different questions are just asked over and over again. grumble grumble =) - r
Re: mod_jk.so-eapi vs mod_jk.so-noeapi
Hi Vinay, EAPI means extended API. You'll need to use mod_jk.so-eapi if you are using Apache with mod_ssl for SSL (https) support. If you are not using mod_ssl, you can use the mod_jk.so-noeapi. Thanks, --jeff - Original Message - From: Vinay Menon [EMAIL PROTECTED] To: Tomcat Dev [EMAIL PROTECTED]; Tomcat User [EMAIL PROTECTED] Sent: Monday, July 09, 2001 2:27 PM Subject: mod_jk.so-eapi vs mod_jk.so-noeapi What exactly are these 2 so's? Why 2 of them and which one should one use? Would appreciate if somebody could let me know! Thanks Vinay
Re: mod_jk.so-eapi vs mod_jk.so-noeapi
Sorry, I didn't notice the original message was cross-posted to the dev and user lists. Didn't mean to post it here... Thanks, --jeff - Original Message - From: Jeff Kilbride [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 09, 2001 4:39 PM Subject: Re: mod_jk.so-eapi vs mod_jk.so-noeapi Hi Vinay, EAPI means extended API. You'll need to use mod_jk.so-eapi if you are using Apache with mod_ssl for SSL (https) support. If you are not using mod_ssl, you can use the mod_jk.so-noeapi. Thanks, --jeff - Original Message - From: Vinay Menon [EMAIL PROTECTED] To: Tomcat Dev [EMAIL PROTECTED]; Tomcat User [EMAIL PROTECTED] Sent: Monday, July 09, 2001 2:27 PM Subject: mod_jk.so-eapi vs mod_jk.so-noeapi What exactly are these 2 so's? Why 2 of them and which one should one use? Would appreciate if somebody could let me know! Thanks Vinay
Re: [DOC]: Vote on oustanding doc issues?
Martin van den Bemt wrote: On the topic of a new mailing list: I think we can do the next steps inside the tomcat-dev list or on our own. (BTW, let's use DOC: as a prefix so it's easier to scan for new messages.) I want to do this in full view of the rest of the community, mostly so they can see what's going on and volunteer to contribute. I prefer [DOC] btw.. replying to a doc issue with DOC: removes the DOC: entry. (at least in outlook). OK. (See subject of this message.) 2) What is the format (XML, *Book, HTML, etc.) of the documentation source? If XML, what DTD? I propose that we do *NOT* try to answer this yet, or maybe ever. Instead, I propose anarchy: that the Table Of Contents be maintained in a convenient text-editable format. It will contain links to doc files (sections or guides or chapters) that are files in whatever format they're in. I imagine that it will eventually be most convenient to use Anakia, but for now, it means that we don't have to worry about rewriting useful docs that are already in HTML. Generating a default output at a certain point is not too bad though. But we have to be open enough for people who want to convert this to eg man pages or a nice pdf. Yeah, I guess anarchy will be a little too... anarchic :-) (Rob S. made the point more strongly in his latest message.) Even if a few documents are unavoidably in wacky PDF or Word, having the majority in a single base format would be desirable. I'm leaning towards Anakia, since it's basically HTML with a few wrapper tags, for the chapters (content). We can define a subset of HTML to be the approved tags, and encourage people to use minimal formatting (e.g. use H1 instead of FONT SIZE=+3B) but I'm pretty sure it's got the right characteristics. See http://jakarta.apache.org/site/jakarta-site-tags.html If someone is scared of XML, they can submit it to us in text format and we can go add tags (as time permits), but we're all developers here, so I don't think that's an issue. The main parts and main chapters in seperate subdirs at first? Let's see. The current TOC (still no comments on it, btw -- I must have scared everyone off ;-) has six parts. I think these translate nicely into separate documents or Guides: I. Standalone Installation Guide II. Installation Behind a Web Server Guide III. Deploying and Configuring, or Tomcat Administrator's Guide IV. Performance Tuning Guide V. Tomcat Developer's Guide (writing code for Tomcat itself) I and II may merge, as may III and IV, but I think we're looking at at least three major parts. Seems natural that they'd be in separate subdirectories. But... I'm a big fan of the throw everything into one package until it gets so big you need to refactor school of organization -- I *hate* wading through an infinite number of empty subdirectories that someone thought would be filled up some day -- so I'd be happy keeping the file tree one level deep for now. That frees us up to reorganize at the drop of a hat without painful CVS grooming. A vote on a seperate mailinglist for discussing doc issues would be appreciated though. It's getting a lot of discussion already and this will grow in the near future I think (and hope..). This way we don't miss any of the important non-docs specific stuff. My vote is -1 for a separate mailing list at this point, at least until we prove that we're not going to peter out like every other documentation effort so far. :-) -- 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: Table of Contents
Alex, Please see my comment below: 1) The details of the TOC looks better than my version. 2) How about moving Developing Interceptors, Valves and Connectors, and Using Tomcat Utility Classes to a seperate Developer Guide? They are only useful for real hackers. 3) How about putting all the installation and configuration of Tomcat standalone first, and then followed by some chapters (advanced topics) about Running Tomcat behind web servers? 4) Overall, I prefer to have all the basics chapters comes first, and then some advanced topices listed in the later chapter. This is what I found from most of user manuals in my bookshelf. 5) About Copyright and Authorship. It is fine for you to hold the copyright. But if somebody modified your TOC and send back to you, and you accepted these changes. How about identity of authorship of this document? Punky - Original Message - From: Alex Chaffee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, July 07, 2001 1:02 AM Subject: 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. *
Re: [DOC] Vote on oustanding doc issues?
Rob S. wrote: Preamble: grumble grumble =) I don't want to rush it. Agreed, but at the same time, I'd like to decide sooner than later. I'm on co-op until August 24th, then I start full-time school again. 4 courses doesn't leave a lot of room for TC docs. Judging by the amount of progress we've made recently (pretty much *zero* in over 10 days), I'll be graduated by the time we figure out if Tomcat documentation needs a separate repository. Things To Do before we decide on format or CVS: * Look at the latest TOC and make comments * Pick a section or subsection and start writing :-) * Look at http://tomcatbook.sourceforge.net/ and http://groups.yahoo.com/group/tcbook and see if there's anyone there to recruit, or if effort is being duplicated 1a) Should Tomcat 3.2 documentation be rolled in together with Tomcat 3.3 documentation for a single, up-to-date, source base, whose release cycle will be independent of the release cycle of Tomcat? Bundle the 3.2.x docs with 3.2.x and only have the 3.3 docs online (latest Tomcat release). If you want the 3.2.x docs, get them with the binary or whatever. I certainly don't think we should keep old versions of documentation updated. I mean, why would updated 3.0 or 3.1 docs be useful? Too much work, too little people wanting to do it. I don't think anyone would expect even a product company to update their documentation on old versions. The version of docs I, as a user, would expect to see 'shipping' with 3.2.2 (if i want to download an older version of the container) is how the docs looked at 3.2.2 ship time. I like this compromise. I will propose that we get rid of the 3.2 docs on the site -- once I'm convinced they're similar enough. There's still that old 3.3 is a rogue release sentiment floating around, and people might not appreciate giving 3.3 implied legitimacy by making it the official documentation... I don't imagine anyone will want to take the task on of converting the anarchical doc repository into the format is decided upon, or how we'll generate anything useful for people to evaluate during that time. So someone writes in HTML, someone writes in DocBook, etc. If I want to help on different docs I have to figure out the viewing/editing mechanism for each one? Ugh... Good point. I'm for Anakia plus a stylebook saying which HTML tags and tricks are approved (like, stay away from JavaScript :-) We can work on the TOC independently of resolving those other issues. They're not being resolved, different questions are just asked over and over again. grumble grumble =) No, I think we're making progress. -- 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/
[DOC] Table of Contents
OK, at Craig's request, here's the current Table of Contents for Tomcat docs. (I wrote a program to convert *** to 1.2.3. format so it's easier to read.) It just occured to me that maybe the TOC will be applicable to both versions (3 vs 4), even though the content of each chapter will be completely different. I think there's actually value in synchronizing the TOCs of two different books, though maybe I'm just being weird :-) -- 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. Part 0: 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 Should we actually organize Part I and Part II as parts of a larger Installation Guide, as in 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. 1. Overview Big picture, 30,000 foot view. 1.1. Diagram of all the parts of Tomcat 1.1.1. Servlet Container 1.1.1.1. Directories 1.1.1.2. Config files 1.1.1.3. Web apps 1.1.1.4. Connectors 1.2. Basic terms 1.2.1. servlet 1.2.2. web app 1.2.3. see glossary [in fact, maybe this whole section should be removed in favor of the appendix] 2. Pre-Installation Covers what to do before you actually install Tomcat. 2.1. DIAGRAM: Flowchart of installation steps 2.1.1. Choose OS 2.1.2. Install Java 2.1.3. Download Tomcat 2.1.4. etc. 2.2. HIGHLY recommended to install standalone first 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). 2.3. Choosing an OS Religious rants here :-) 2.4. Installing Java How to install a JDK or JRE on your target platform. It might make sense to break this out into separate chapters per platform, if it turns out a lot of the information is different. 2.4.1. Downloading JDK 2.4.2. Setting environment variables 2.4.3. Setting class path (see Tomcat Classpath section) 2.4.4. OS Issues 2.5. Choosing a Tomcat Version 2.5.1. 3.x vs. 4.x [ see also Development:3.x vs 4.x chapter ] 2.5.2. 3.1 vs 3.2 vs 3.3 2.5.3. 4.0 status 2.6. Downloading Tomcat 2.6.1. Binary distribution 2.6.2. Source distribution 2.6.3. CVS (see developing section) 3. Installation Standalone This section covers the basic steps of installing Tomcat as a standalone application. It is the core of the Installation Guide. Everyone who reads the later chapters is expected to have read these, and to have a working standalone install before going and installing behind the Web server. 3.1. HIGHLY recommended to install standalone first 3.2. Basic procedure 3.3. Windows Issues 3.3.1. Where to place TOMCAT_HOME? 3.3.2. Port 80 3.3.3. Admin user 3.3.4. Running as a service 3.4. Unix Issues 3.4.1. Where to place TOMCAT_HOME? 3.4.2. Port 80 3.4.3. Redirector 3.4.4. root user 3.4.5. Running as a daemon 3.5. Testing your basic standalone installation 3.5.1. The Example Context (Webapp) 3.5.2. telnet from same machine 3.5.3. web browser 4. Server lifecycle management Maybe this should go in a later Admin guide, but it's important to get the users comfortable with the use of the scripts and stuff early on. Maybe here we just cover starting and stopping, and have a more thorough chapter later on. 4.1. Starting Tomcat 4.2. Stopping Tomcat 4.3. Checking if Tomcat is running 4.4. Automatically restarting [=reloading?] 4.5. [Log rotation? See logging chapter] 4.6. The Admin Context (Costin?) 4.7. The Tomcat Manager Application (Craig?) 5. Secure Server (SSL) Covers how to get Tomcat up and running with SSL. Since this is in an Installation guide, it does not cover other aspects of security (but refers to the
Re: Table of Contents
Punky Tse wrote: Alex, Please see my comment below: 1) The details of the TOC looks better than my version. Thanks :) 2) How about moving Developing Interceptors, Valves and Connectors, and Using Tomcat Utility Classes to a seperate Developer Guide? They are only useful for real hackers. I think just having them at then end of the single developer's guide works fine. Especially when you consider that they will be separate documents anyway (separate authors, separate cvs logs, etc.). 3) How about putting all the installation and configuration of Tomcat standalone first, and then followed by some chapters (advanced topics) about Running Tomcat behind web servers? It's already organized that way. See the first paragraph of the editorial notes: 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. I have a feeling you may have missed the attachment. See the post I just made for the latest one (in much detail). 5) About Copyright and Authorship. It is fine for you to hold the copyright. But if somebody modified your TOC and send back to you, and you accepted these changes. How about identity of authorship of this document? Yes, this is a big can of worms. I'm actually afraid the Apache license is too restrictive for our purposes. I want to make sure that both original authors and later contributors have the right the use their work -- even in part -- in other contexts. But I also want to make sure that someone else can't plagiarize it, so just making it public domain wouldn't work either. I haven't done enough research yet though. - A
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java ActionHook.java OutputBuffer.java Request.java Response.java AdapterEventCode.java AdapterListener.java Note.java
remm01/07/09 19:55:05
Modified:coyote/src/java/org/apache/coyote OutputBuffer.java
Request.java Response.java
Added: coyote/src/java/org/apache/coyote ActionCode.java
ActionHook.java
Removed: coyote/src/java/org/apache/coyote AdapterEventCode.java
AdapterListener.java Note.java
Log:
- Various updates to the Coyote API.
Note: The API can't be considered frozen until the port of at least one
connector is complete.
- Status update : I have started porting the Java HTTP/1.1 connector.
I will patially rewrite it for more memory efficiency and a few additional
features.
- On the adapter side, I'll write a simple adapter which will output the full
request information back to the client, and then I'll write an adapter
for Catalina.
Revision ChangesPath
1.2 +0 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/OutputBuffer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- OutputBuffer.java 2001/06/14 01:07:57 1.1
+++ OutputBuffer.java 2001/07/10 02:55:01 1.2
@@ -73,10 +73,4 @@
throws IOException;
-public void reset();
-
-
-public void close();
-
-
}
1.2 +3 -8
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Request.java 2001/06/14 01:07:57 1.1
+++ Request.java 2001/07/10 02:55:02 1.2
@@ -153,7 +153,7 @@
/**
* Notes.
*/
-protected Note notes[] = new Note[Constants.MAX_NOTES];
+protected Object notes[] = new Object[Constants.MAX_NOTES];
/**
@@ -349,12 +349,12 @@
// Per-Request notes
-public final void setNote(int pos, Note value) {
+public final void setNote(int pos, Object value) {
notes[pos] = value;
}
-public final Note getNote(int pos) {
+public final Object getNote(int pos) {
return notes[pos];
}
@@ -378,11 +378,6 @@
serverPort=-1;
scookies.recycle();
-
-for (int i=0; i Constants.MAX_NOTES; i++) {
-if (notes[i] != null)
-notes[i].recycle();
-}
unparsedURIMB.recycle();
uriMB.recycle();
1.2 +21 -23
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Response.java 2001/06/14 01:07:57 1.1
+++ Response.java 2001/07/10 02:55:02 1.2
@@ -111,7 +111,7 @@
/**
* Notes.
*/
-protected Note notes[] = new Note[Constants.MAX_NOTES];
+protected Object notes[] = new Object[Constants.MAX_NOTES];
/**
@@ -136,9 +136,9 @@
/**
- * Adapter listener.
+ * Action hook.
*/
-public AdapterListener listener;
+public ActionHook hook;
// - Properties
@@ -159,35 +159,35 @@
}
-public AdapterListener getListener() {
-return listener;
+public ActionHook getHook() {
+return hook;
}
-public void setAdapterListener(AdapterListener listener) {
-this.listener = listener;
+public void setHook(ActionHook hook) {
+this.hook = hook;
}
// Per-Response notes
-public final void setNote(int pos, Note value) {
+public final void setNote(int pos, Object value) {
notes[pos] = value;
}
-public final Note getNote(int pos) {
+public final Object getNote(int pos) {
return notes[pos];
}
-// Events
+// Actions
-public void sendEvent(AdapterEventCode eventCode, Object param) {
-if (listener != null) {
-listener.event(eventCode, param);
+public void action(ActionCode actionCode, Object param) {
+if (hook != null) {
+
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java
jon 01/07/09 20:19:00
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
itty bitty patch that will cause the stack trace of the
NotSerializableException to be logged so that it is more easily possible
to track down why an object in the session is not being unserialized
properly with the writeObject() method in StandardSession
this is turning up some weird weird crap in Turbine...like classes that i
would have never imagined needing to be serializable needing it...
Revision ChangesPath
1.21 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- StandardSession.java 2001/05/21 19:54:01 1.20
+++ StandardSession.java 2001/07/10 03:18:57 1.21
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
1.20 2001/05/21 19:54:01 craigmcc Exp $
- * $Revision: 1.20 $
- * $Date: 2001/05/21 19:54:01 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
1.21 2001/07/10 03:18:57 jon Exp $
+ * $Revision: 1.21 $
+ * $Date: 2001/07/10 03:18:57 $
*
*
*
@@ -111,7 +111,7 @@
* @author Craig R. McClanahan
* @author Sean Legassick
* @author a href=mailto:[EMAIL PROTECTED];Jon S. Stevens/a
- * @version $Revision: 1.20 $ $Date: 2001/05/21 19:54:01 $
+ * @version $Revision: 1.21 $ $Date: 2001/07/10 03:18:57 $
*/
class StandardSession
@@ -1218,7 +1218,7 @@
' with value ' + saveValues.get(i) + ');
} catch (NotSerializableException e) {
log(sm.getString(standardSession.notSerializable,
- saveNames.get(i), id));
+ saveNames.get(i), id), e);
stream.writeObject(NOT_SERIALIZED);
if (debug = 2)
log( storing attribute ' + saveNames.get(i) +
mail changed to egcs12md@yahoo.com.cn !
mail changed to [EMAIL PROTECTED]!
t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. I'm not asking for a timeline, just a status report. -jon
[t4] StandardSession.readObject()
Shouldn't it call setAttribute(name, value) instead of:
synchronized (attributes) {
attributes.put(name, value);
}
?
-jon
setAttribute
I am looking at
setAttribute implementation of Standard Session. Tomcat seems to be differing
from what spec says. Is this intentional?
As per
spec:
Both name and value of setAttribute should be not null. I assumed when either of
parameters is null servlet container throws
IllegalArguementException.
But tomcat allows setAttribute(null, null);
If session.setAttribute("someKey", null) is used tomcat removes previous object
in session with key "someKey".
More interesting example:
session.setAttribute(null, "KeyValueisNotNULL");
(String)session.getAttribute(null) returns
"KeyValueisNotNULL"
I believe this is a
wrong behaviour.
Any
comments?
Kumar.
Re: t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently Did you hear about Sun's shutdown last week ? ;-) Just before the shutdown, I rewrote the CL, and then waited to see if people would get back at me with problems. Nobody did, so I assume there's no problem. As far as I (the I here means that this concerns the parts of Catalina I'm working on : almost everything when Catalina is run standalone) am concerned, TC 4.0 is done, and is in bugfix / tweaking mode. At the moment, I'm working on an improved HTTP/1.1 connector, which is in late design / early implementation phase. It's unlikely it will be included in the 4.0 release, because we wouldn't have enough time to test it. and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. Adaptor means web server connector here ? I'm not asking for a timeline, just a status report. Remy
