Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote:
jean-frederic clere wrote:
Hi,
I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
I have VERISRELEASE to mark that it is a developement version, I am not sure we
need the beta number. I would prefer to do it like httpd.
But will this be ok?
mod_jk/1.2.0-beta-01 (for the first beta)
mod_jk/1.2.0 (for the release version).
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
What about:
#ifdef RELEASE
#define JK_VERSION JK_MKVER(1, 2, 0, 99)
#else
#define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA)
Hex is a copy + paste from Linux sources. Dec is more easy? - No problem - But I
like to write 0x010200 and 0x110200 it is easy to see than 10200 and 110200.
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun include file named
version.h. (On Monday!).
Of course we will to have to document our internal API so that for each version
of mod_jk the connectors could know the parameters and the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal --acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module. FILE is the optional
pathname to the apxs tool; defaults to finding
apxs in
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: Decimal fields might be more appropriate to the ranges of numbers expected, and I think Henri suggested an additional field for alpha, beta etc. I have VERISRELEASE to mark that it is a developement version, I am not sure we need the beta number. I would prefer to do it like httpd. But will this be ok? mod_jk/1.2.0-beta-01 (for the first beta) mod_jk/1.2.0 (for the release version). How about #define JK_DEV 0 #define JK_ALPHA1 #define JK_BETA 2 #define JK_RELEASE 99 #define JK_MKVER(major, minor, sequence, type) \ ((major) * 100 + (minor) * 1 + (sequence) * 100 + (type)) #define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV) What about: #ifdef RELEASE #define JK_VERSION JK_MKVER(1, 2, 0, 99) #else #define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA) Hex is a copy + paste from Linux sources. Dec is more easy? - No problem - But I like to write 0x010200 and 0x110200 it is easy to see than 10200 and 110200. Fine, +1 ;-) -- Andy Armstrong, Tagish
RE: [J-T-C] Ajp14 Autoconf features
In JkMount you'll need to indicate ALL the URL handled under the given context, ie /myapp/servlet/* /myapp/*.jsp. With JkAutoMount if you provide the base context, the servlet-engine will give them to web-servlet. Imagine you install cocoon on myapp, it's will handle also the .xml. servlet-engine is allready aware that it should handle the .xml, so just let him inform the web-server. (less works) Ok: JkAutoMount workername cocoon /cocoon Is a least: JkMount /cocoon workername JkMount /*.xml workername Correct? You find in web.xml for cocoon 1.8.2 = ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app servlet servlet-name org.apache.cocoon.Cocoon /servlet-name servlet-class org.apache.cocoon.Cocoon /servlet-class init-param param-name properties /param-name param-value /WEB-INF/conf/cocoon.properties /param-value /init-param /servlet servlet-mapping servlet-name org.apache.cocoon.Cocoon /servlet-name url-pattern *.xml /url-pattern /servlet-mapping /web-app = mod_jk needed JkMount /cocoon/servlet/* workername JkMount /cocoon/*.jsp workername JkMount /cocoon/*.xml workername ie: JkAutoMount workername examples /examples which will make the servlet-engine respond : /examples/servlet/* /examples/*.jsp A way to keep autoconf features but under the web-server admin staff Then you could have JkAutoMount directives in all your virtual hosts part of your web-server : VirtualHost myaltside:80 JkAutoMount myworker examples /examples /VirtualHost VirtualHost myaltside:443 JkAutoMount myworker admin /admin /VirtualHost I prefer this one, it is more like the WebAppDeploy of mod_webapp. WebAppDeploy examples warpConnection /examples JkMount /examples examples JkAutoMount examples examples /examples Confusing no? No more confusion if we use : mod_jk today : JkMount /examples ajpworkername mod_jk could use also now : JkAutoMount examples ajpworkername /examples What about ? Well I was just thinking we could use the same order. WebAppDeploy /examples warpConnection examples JkMount /examples ajpworkername JkAutoMount /examples ajpworkername examples Ok for me, let stay with : JkAutoMount /examples ajpworkername examples May be later I could use a wildcard like : JkAutoMount * ajpworkername * Which will told mod_jk to GET ALL THE URL handled by the worker ajpworkername. In that case if the worker is a load-balancing worker, WE MUST BE SURE TO HAVE ALL the servlet-engine in the cluster WITH EXACTLY THE SAME CONFIG Regards
RE: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
Hi, Does anyone have any objection to my deleting the following folders from the jakarta-tomcat head: proposals/jasper34 proposals/tomcat-4.0 proposals/web-connector src/jasper34 They all have projects elsewhere and, as Henri noted earlier, would make a noticeable reduction in the size of the source file. Yes please :) +111
RE: [J-T-C] 1 second for crash (core)
Just some ideas, since I saw that kind of problems while playing with mod_php using ct_lib/mysql and mod_xslt and mod_gzip - Did httpd was linked against pthread ? When you use Apache with a some requiring libpthread YOU SHOULD REALLY rebuild apache with -lpthread - Also take a look to see if there is no duplicate symbol in webapp and all the others modules Good luck - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: #define JK_VERSION in j-t-c (doesn't exist)
I have prepared a patch for configure.in to generate
JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
I have VERISRELEASE to mark that it is a developement version,
I am not sure we
need the beta number. I would prefer to do it like httpd.
But will this be ok?
mod_jk/1.2.0-beta-01 (for the first beta)
mod_jk/1.2.0 (for the release version).
+1
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
What about:
#ifdef RELEASE
#define JK_VERSION JK_MKVER(1, 2, 0, 99)
#else
#define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA)
Hex is a copy + paste from Linux sources. Dec is more easy? -
No problem - But I
like to write 0x010200 and 0x110200 it is easy to see than
10200 and 110200.
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything
protocol specific
into the Domino connector, but the interface to the
protocol code is
changing over time -- extra fields are being added
and so on. I want the
Domino code to work with both the current jk stuff
and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm
talking about. Here's a
bit of code that handles parsing the SSL keysize and
passing it to the
jk stuff. The field ssl_key_size wasn't available
until recently so the
I have to cope with that case too. Surely that isn't
too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable:
we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun
include file named
version.h. (On Monday!).
Of course we will to have to document our internal API
so that for each version
of mod_jk the connectors could know the parameters and
the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new
connector to
start with the source of an existing one -- I certainly
did -- that
pretty much documents everything you need to know.
Perhaps it would be
enough to nominate one connector (mod_jk I guess) as
'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
---
-
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13
jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal
--acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module.
FILE is the optional
pathname to the apxs tool;
defaults to finding
apxs in your PATH.],
[
case
Re: RPM for tomcat 3.2.2-1 : any problems reported?
GOMEZ Henri wrote: Just a quick recall of build of rpms. There are built under Redhat 6.2 / Redhat 7.1 (validation) - using latest jikes 1.14 - using latest IBM SDK 1.3 (javadoc) - with latest ant 1.3, xerces-j 1.4, xalan-j 2.1.0 I encounter rare problems when building with jikes, at least one with a previous release of TC 4.0 Also my RPM, install the current jaxp.jar and parser.jar. May be fine to switch now to jaxp/crimson or xerces-j ? I've asked sometimes ago on how to build a crimson RPM (ie where to get the latest sources) but I still wait for replies. Thanks for the reponse. I just installed the RPM, and saw that it *didn't* seem to exhibit the same problems on my machine as it did on the user's that report the problem. I may revisit. It was a very wierd problem - Velocity seemed to work fine when the user was loading templates from files using our 'FileResourceLoader', but when the user switch to loading templates from a jar placed in WEB-INF/lib using the 'ClasspathResourceLoader', which just uses getResourceAsStream() it stopped working. And as I said, the user installed the tgz distro of 3.2.2, moved his webapp over (not rebuild - move), and restarted tomcat, and it worked... I don't know if it was some kind of classpath issue. I have a few comments from the RPM : - would it be possible to add the basic startup/shutdown scripts in a bin/ under /var/tomcat ? The reason I ask is that it might be convenient for people to have available the same scripts uses by other tomcat users, so if someone provides instructions to do something, they can be followed exactly to the letter, which can be important for new or unconfident users. - it automatically overrides things like JAVA_HOME with a new value. I know that it's noted on when the rpm is installed, but its a little presumptive. Thanks for the reply. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ You have a genius for suggesting things I've come a cropper with!
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ApacheConfig.java
larryi 01/06/21 06:04:19
Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
Log:
Add space following j_security_check to avoid syntax error.
Updated to detect Ajp13Interceptor from jakarta-tomcat-connectors.
Added jkProtocol property so Ajp12 or Ajp13 can be set explicitly.
Revision ChangesPath
1.11 +43 -11
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ApacheConfig.java 2001/05/27 23:11:07 1.10
+++ ApacheConfig.java 2001/06/21 13:04:19 1.11
@@ -1,4 +1,4 @@
-/* $Id: ApacheConfig.java,v 1.10 2001/05/27 23:11:07 costin Exp $
+/* $Id: ApacheConfig.java,v 1.11 2001/06/21 13:04:19 larryi Exp $
*
*
* The Apache Software License, Version 1.1
@@ -112,7 +112,7 @@
p
@author Costin Manolache
@author Mel Martinez
- @version $Revision: 1.10 $ $Date: 2001/05/27 23:11:07 $
+ @version $Revision: 1.11 $ $Date: 2001/06/21 13:04:19 $
*/
public class ApacheConfig extends BaseInterceptor {
@@ -148,6 +148,8 @@
public static final int AJP12 = 0;
public static final int AJP13 = 1;
public static final String AJPV12 = ajpv12;
+public static final String JTC_AJP13_INTERCEPTOR =
+org.apache.ajp.tomcat33.Ajp13Interceptor;
private File configHome = null;
@@ -158,6 +160,7 @@
private File modJk = null;
private File jkLog = null;
+private int jkProtocol = -1;
public ApacheConfig() {
@@ -204,6 +207,7 @@
if(name.equals(modjserv)) setModJserv(value);
if(name.equals(modjk)) setModJk(value);
if(name.equals(jklog)) setJkLog(value);
+if(name.equals(jkprotocol)) setJkProtocol(value);
}
/**
@@ -432,7 +436,7 @@
public void setModJserv(File path){
modJserv=path;
}
-
+
/**
returns the path to the apache module mod_jserv.
If the path set with setModJserv() was relative, this method
@@ -544,8 +548,31 @@
return logF;
}
+/**
+set the Ajp protocal
+@param bprotocal/b String protocol, ajp12 or ajp13
+ */
+public void setJkProtocol(String protocol){
+jkProtocol = -1;
+for( int i=0; i JkMount.length; i++ ) {
+if( JkMount[i].equalsIgnoreCase(protocol) ) {
+jkProtocol = i;
+break;
+}
+}
+}
-
+/**
+get the Ajp protocol
+@return a String for the Ajp protocol
+ */
+public String getJkProtocol(){
+if( jkProtocol 0 || jkProtocol = JkMount.length )
+return JkMount[0];
+else
+return JkMount[jkProtocol];
+}
+
/**
executes the ApacheConfig interceptor. This method generates apache
configuration files for use with mod_jserv or mod_jk. If not
@@ -565,7 +592,8 @@
//String apacheHome = findApache();
int jkConnector = AJP12;
-
+ if( jkProtocol = 0 jkProtocol JkMount.length)
+ jkConnector = jkProtocol;
PrintWriter pw=new PrintWriter(new FileWriter(getJservConfig()));
log(Generating apache mod_jserv config = +getJservConfig() );
@@ -620,17 +648,21 @@
// Find Ajp1? connectors
int portInt=8007;
BaseInterceptor ci[]=cm.getContainer().getInterceptors();
+ // try to get jakarta-tomcat-connectors Ajp13 Interceptor class
+ Class jtcAjp13 = null;
+ try {
+ jtcAjp13 = Class.forName(JTC_AJP13_INTERCEPTOR);
+ } catch ( ClassNotFoundException e ) { }
for( int i=0; ici.length; i++ ) {
Object con=ci[i];
-/* if( con instanceof Ajp12ConnectionHandler ) {
- PoolTcpConnector tcpCon=(PoolTcpConnector) con;
- portInt=tcpCon.getPort();
- }*/
if( con instanceof Ajp12Interceptor ) {
Ajp12Interceptor tcpCon=(Ajp12Interceptor) con;
portInt=tcpCon.getPort();
}
- if( con instanceof Ajp13Interceptor ) {
+// if jkProtocol not specified and Ajp13 Interceptor found, use
Ajp13
+if( jkProtocol 0
+( con instanceof Ajp13Interceptor ||
+( jtcAjp13 != null
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
larryi 01/06/21 06:04:43
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Update for Milestone 4
Revision ChangesPath
1.181 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.180
retrieving revision 1.181
diff -u -r1.180 -r1.181
--- ContextManager.java 2001/06/09 03:20:52 1.180
+++ ContextManager.java 2001/06/21 13:04:43 1.181
@@ -148,7 +148,7 @@
public final class ContextManager {
/** Official name and version
*/
-public static final String TOMCAT_VERSION = 3.3 Milestone 3;
+public static final String TOMCAT_VERSION = 3.3 Milestone 4;
public static final String TOMCAT_NAME = Tomcat Web Server;
/** System property used to set the base directory ( tomcat home ).
RE: RPM for tomcat 3.2.2-1 : any problems reported?
Just a quick recall of build of rpms. There are built under Redhat 6.2 / Redhat 7.1 (validation) - using latest jikes 1.14 - using latest IBM SDK 1.3 (javadoc) - with latest ant 1.3, xerces-j 1.4, xalan-j 2.1.0 I encounter rare problems when building with jikes, at least one with a previous release of TC 4.0 One of the guys here came across a problem using jikes 1.13-1 Doing an intern on two strings and checking for equality failed in cases where it should have worked. jr
cvs commit: jakarta-tomcat-connectors/jk/native/common version.h.in jk_global.h
jfclere 01/06/21 07:48:11
Modified:jk/native configure.in
jk/native/common jk_global.h
Added: jk/native/common version.h.in
Log:
Add JK_VERSION - Note the logic is configure.in, not in version.h -
Revision ChangesPath
1.6 +30 -4 jakarta-tomcat-connectors/jk/native/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- configure.in 2001/06/14 14:38:13 1.5
+++ configure.in 2001/06/21 14:47:59 1.6
@@ -1,17 +1,24 @@
dnl
dnl Process this file with autoconf to produce a configure script
dnl
-AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
+AC_REVISION($Id: configure.in,v 1.6 2001/06/21 14:47:59 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
+AM_CONFIG_HEADER(common/version.h)
+dnl package and version.
PACKAGE=mod_jk
-VERSION=0.0.0
-AC_SUBST(PACKAGE)
-AC_SUBST(VERSION)
+VERMAJOR=1
+VERMINOR=2
+VERFIX=0
+VERBETA=1
+dnl set VERISRELEASE to 1 when release (do not forget to commit!)
+VERISRELEASE=0
+VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
+
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
@@ -42,6 +49,25 @@
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
+
+dnl prepare the string and value for mod_jk version logic
+JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
+if ${TEST} ${VERISRELEASE} -eq 0 ; then
+JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-beta-${VERBETA}
+else
+VERBETA=255
+fi
+
+AC_SUBST(PACKAGE)
+AC_SUBST(VERSION)
+
+#
+# Adds in version.h
+#
+AC_DEFINE_UNQUOTED(JK_EXPOSED_VERSION,$JK_EXPOSED_VERSION,
+ [ Printable string for version ] )
+AC_DEFINE_UNQUOTED(JK_VERSION,((($VERMAJOR) 24) + (($VERMINOR) 16) +
(($VERFIX) 8) + ($VERBETA)),
+ [ Version in hex :like 010200ff for release 01020001 for beta 1. ] )
WEBSERVER=
apache_dir=
1.4 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_global.h
Index: jk_global.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_global.h 2001/06/18 14:15:40 1.3
+++ jk_global.h 2001/06/21 14:48:05 1.4
@@ -59,13 +59,13 @@
* Description: Global definitions and include files that should exist *
* anywhere *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.4 $ *
***/
#ifndef JK_GLOBAL_H
#define JK_GLOBAL_H
-#define JK_EXPOSED_VERSION (mod_jk/1.1a1)
+#include version.h
#include stdio.h
#include stdlib.h
1.1 jakarta-tomcat-connectors/jk/native/common/version.h.in
Index: version.h.in
===
#undef JK_EXPOSED_VERSION
#undef JK_VERSION
Tomcat with multiple JVMs
Hello all! We configure the Tomcat 3.2.1 (mod_jserv) to run multiples JVMs on a one Web Server Apache, but when i make the request to the second JVM the tomcat response with the last JVM that i started (set as default in tomcat-apache.conf the last JVMS). and ignore the other. How can i configure my tomcat for run OK with multiples JVMs regards!
Re: FORM-based authentication idea
The best way to think about form-based login is like this: * The login page is (in essence) part of the container, not the application. Therefore, ... * The login page should *never* be referenced directly by any other application page, and ... * The login page should *never* be requested directly by the user. How do you enforce that a particular URL should never be asked for by a user? Shouldn't the responsibility to handle that case rest with the JSP container and not the user? Isn't that kind of like designing a user interface where a button shouldn't be clicked when the program is in a certain state and instead of making the button invisible or disabled when in that state, you simply say well, the user shouldn't click that button when the program is in that state Using form-based login pages in any other manner is just going to cause you grief, unless and until the servlet spec were changed to mandate a behavior like what you propose. NOTE: A primary reason that form-based login was designed the way it is was to emulate the user experience of how BASIC login works. With BASIC, you never reference the login page directly, right? It just pops up whenever you try to access a protected resource for the first time -- then, you are transparently returned to the resource you originally requested. Using form-based login lets you manage the look-and-feel of the login page, but it should *not* be part of your application's normal flow. Any thoughts? -Mike Craig McClanahan
Re: 3.3: nightly, updating the parser, options
+1 Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 06/21/01 02:18AM Hi, I'm working on restoring the nightly buildtest, probably this evening we'll have them ( I was close last night ). Few issues, need feedback: - I would like to update to the latest jaxp, we are still building with jaxp1.0 ( it's about the default build, of course you can build/use whatever you want ). - There are few module options that are set for backward compatibility right now, but it would be very usefull otherwise. One is the autodeploy ( detect when the .WAR file changes, and redeploy and reload the context - same as if a .class file changes ). The other is the vhost-based layout for the webapps dir ( use webapps/virtual.host.com/context, with DEFAULT as keyword for the main host ). That would allow easier auto-configuration for virtual hosts. ( as you should know, the location of webapp and it's behavior can be easily controlled in server.xml, it's just a matter of setting the default). In the configurations, I would also like to change the log options in examples to go to the default logger ( instead of examples.log ). I am going to fix some modules to use the context logger for all the messages where a context is available ( so a context log file will have all the informations related with a context, and the main logger will be used only for bad requests and server-wide events. ). I think this is the correct behavior, but that would mean people will no longer see the /examples logs in the console window. Costin
RE: 3.3: nightly, updating the parser, options
Hi Larry, Those options are already implemented - it's just a matter of turning them on or off, and I wasn't targeting M4. There are few issues building in JDK1.1, but I think we are ok with building M4 this night ( with the final tommorow ). Regarding jasper34, it passes all watchdog/sanity checks - but it should be your choice to include it or not. Given your vacation, I would vote for not defaulting to jasper34 ( I am confident the refactoring was safe enough so far , the extra testing would be nice but not a necesity. ) ( let me know if there is any problem with M4, this should be the biggest priority for today/tommorow ) Costin On Thu, 21 Jun 2001, Larry Isaacs wrote: Hi Costin, I'm fine with including these if you are confident that they don't contain any show stoppers and can be done quickly. I go on vacation this Saturday for a week. As a result, I can't wait too long before putting Milestone 4 together. I'm was hoping to get the bulk of the files there tonight so I can fix mistakes on Friday, if needed. Are we still go for enabling Jasper34 by default? I have been working on other small problems and haven't actually tried Jasper34 yet. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, probably this evening we'll have them ( I was close last night ). Few issues, need feedback: - I would like to update to the latest jaxp, we are still building with jaxp1.0 ( it's about the default build, of course you can build/use whatever you want ). - There are few module options that are set for backward compatibility right now, but it would be very usefull otherwise. One is the autodeploy ( detect when the .WAR file changes, and redeploy and reload the context - same as if a .class file changes ). The other is the vhost-based layout for the webapps dir ( use webapps/virtual.host.com/context, with DEFAULT as keyword for the main host ). That would allow easier auto-configuration for virtual hosts. ( as you should know, the location of webapp and it's behavior can be easily controlled in server.xml, it's just a matter of setting the default). In the configurations, I would also like to change the log options in examples to go to the default logger ( instead of examples.log ). I am going to fix some modules to use the context logger for all the messages where a context is available ( so a context log file will have all the informations related with a context, and the main logger will be used only for bad requests and server-wide events. ). I think this is the correct behavior, but that would mean people will no longer see the /examples logs in the console window. Costin
RE: 3.3: nightly, updating the parser, options
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 21 de junio de 2001 10:19 Para: [EMAIL PROTECTED] Asunto: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, probably this evening we'll have them ( I was close last night ). Few issues, need feedback: - I would like to update to the latest jaxp, we are still building with jaxp1.0 ( it's about the default build, of course you can build/use whatever you want ). - There are few module options that are set for backward compatibility right now, but it would be very usefull otherwise. One is the autodeploy ( detect when the .WAR file changes, and redeploy and reload the context - same as if a .class file changes ). The other is the vhost-based layout for the webapps dir ( use webapps/virtual.host.com/context, with DEFAULT as keyword for the main host ). That would allow easier auto-configuration for virtual hosts. ( as you should know, the location of webapp and it's behavior can be easily controlled in server.xml, it's just a matter of setting the default). In the configurations, I would also like to change the log options in examples to go to the default logger ( instead of examples.log ). I am going to fix some modules to use the context logger for all the messages where a context is available ( so a context log file will have all the informations related with a context, and the main logger will be used only for bad requests and server-wide events. ). I think this is the correct behavior, but that would mean people will no longer see the /examples logs in the console window. Costin
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java
larryi 01/06/21 12:31:06 Modified:src/share/org/apache/tomcat/modules/generators StaticInterceptor.java Log: Fix display of the file size. Revision ChangesPath 1.14 +2 -2 jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java Index: StaticInterceptor.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/StaticInterceptor.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- StaticInterceptor.java2001/05/26 17:54:23 1.13 +++ StaticInterceptor.java2001/06/21 19:31:04 1.14 @@ -631,9 +631,9 @@ // To avoid 0.0 for non-zero file, we bump to 0.1 if (leftside == 0 rightside == 0 filesize != 0) rightside = 1; - buf.write(leftside); + buf.write(String.valueOf(leftside)); buf.write(.); - buf.write(rightside); + buf.write(String.valueOf(rightside)); buf.write( KB); } }
RE: 3.3: nightly, updating the parser, options
Costin, I'm fine with saving these changes until after Milestone 4. I'll add a note to the readme about the availability of Jasper34 and how to enable it. It would help if you could take a quick look at an NPE that is occurring when Tomcat 3.3 is connected to Apache with mod_jserv. The problem is in org.apache.tomcat.modules.mappers.DecodeInterceptor's postReadRequest() method. Unlike mod_jk and directly hitting Tomcat, mod_jserv creates pathMB as a String. If the request contains a '%', such as HelloWorld%2Ejsp, the handling is trigger that results in pathMB.resetStringValue() being called. The next pathMB.indexOf() will NPE. If you could find a quick fix, I would appreciate it. If there isn't one, let me know and I'll proceed with Milestone 4. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 12:59 PM To: '[EMAIL PROTECTED]' Subject: RE: 3.3: nightly, updating the parser, options Hi Larry, Those options are already implemented - it's just a matter of turning them on or off, and I wasn't targeting M4. There are few issues building in JDK1.1, but I think we are ok with building M4 this night ( with the final tommorow ). Regarding jasper34, it passes all watchdog/sanity checks - but it should be your choice to include it or not. Given your vacation, I would vote for not defaulting to jasper34 ( I am confident the refactoring was safe enough so far , the extra testing would be nice but not a necesity. ) ( let me know if there is any problem with M4, this should be the biggest priority for today/tommorow ) Costin On Thu, 21 Jun 2001, Larry Isaacs wrote: Hi Costin, I'm fine with including these if you are confident that they don't contain any show stoppers and can be done quickly. I go on vacation this Saturday for a week. As a result, I can't wait too long before putting Milestone 4 together. I'm was hoping to get the bulk of the files there tonight so I can fix mistakes on Friday, if needed. Are we still go for enabling Jasper34 by default? I have been working on other small problems and haven't actually tried Jasper34 yet. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: 3.3: nightly, updating the parser, options Hi, I'm working on restoring the nightly buildtest, probably this evening we'll have them ( I was close last night ). Few issues, need feedback: - I would like to update to the latest jaxp, we are still building with jaxp1.0 ( it's about the default build, of course you can build/use whatever you want ). - There are few module options that are set for backward compatibility right now, but it would be very usefull otherwise. One is the autodeploy ( detect when the .WAR file changes, and redeploy and reload the context - same as if a .class file changes ). The other is the vhost-based layout for the webapps dir ( use webapps/virtual.host.com/context, with DEFAULT as keyword for the main host ). That would allow easier auto-configuration for virtual hosts. ( as you should know, the location of webapp and it's behavior can be easily controlled in server.xml, it's just a matter of setting the default). In the configurations, I would also like to change the log options in examples to go to the default logger ( instead of examples.log ). I am going to fix some modules to use the context logger for all the messages where a context is available ( so a context log file will have all the informations related with a context, and the main logger will be used only for bad requests and server-wide events. ). I think this is the correct behavior, but that would mean people will no longer see the /examples logs in the console window. Costin
Re: FORM-based authentication idea
Why is the button there at all? There should be zero linkages to the login page from *anywhere* in your user interface. That's true. The point I was trying to make is that there is nothing to stop an end-user from bookmarking a login page or typing it in directly, even if you have no linkages to the login page in your user interface. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Michael Jennings wrote: That's true. The point I was trying to make is that there is nothing to stop an end-user from bookmarking a login page or typing it in directly, even if you have no linkages to the login page in your user interface. It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Not quite true. In most cases the login page will not be in the same directory with the page that needs authentication. If the container does not send a redirect, but internally displays the login page, all the relative URLs will be treated by the browser as relatvie to the authenticated page, not the login page. Since the spec doesn't mention that the login pages are not allowed to have relative URLs - I'm not sure it's that easy to implement the form login without a redirection. And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. Costin
Re: FORM-based authentication idea
It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Right now I've got a web app set up with tomcat 3.2.2 using form-based authentication, when I request /WWAT2/user/welcome.jsp I get redirected to /WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked it, logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my original request) I logged out, then went to my bookmarked /WWAT2/login.jsp So it looks like I do see the login URL. (I have absolutely no links to the /WWAT2/login.jsp anywhere) So what you are saying is that if a user doesn't see the login URL, there are no links to it in the web-app, the chances of them requesting JUST the login page of a web-app are so few and far between that handling that special case should just be ignored? Is there something wrong with my tomcat configuration? The form-based authentication works like a dream except for showing me the URL of the login page. The behaviour is fine. -Mike And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike Craig
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf MessageBytes.java
costin 01/06/21 14:22:12
Modified:util/java/org/apache/tomcat/util/buf MessageBytes.java
Log:
Fix for the mod_jserv bug, reported by Larry.
The reset in MessageBytes will clean the cached String value only if
the string value is indeed a cached value, not the primary value.
The MessageBytes can be used as a holder for byte[], char[] and Strings,
with delayed conversion from byte[] to String ( to allow the container to
detect the encoding - it can happen very late, especially in 2.3 ). It is
possible that toString() has been called before ( for example in parameters
we need to detect jsp_precompile - that will happen before the right
encoding is known ).
Revision ChangesPath
1.5 +6 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java
Index: MessageBytes.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/MessageBytes.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- MessageBytes.java 2001/06/16 21:40:59 1.4
+++ MessageBytes.java 2001/06/21 21:22:09 1.5
@@ -165,8 +165,12 @@
byte[] or after the encoding is changed
*/
public void resetStringValue() {
- hasStrValue=false;
- strValue=null;
+ if( type != T_STR ) {
+ // If this was cread as a byte[] or char[], we remove
+ // the old string value
+ hasStrValue=false;
+ strValue=null;
+ }
}
public void setString( String s ) {
Re: FORM-based authentication idea
Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp So the redirection thing is just how it is implemented right now. Stupid me. -Mike - Original Message - From: Michael Jennings [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 2:21 PM Subject: Re: FORM-based authentication idea It's kinda hard for them to bookmark the login page when they don't know the URL. Keep in mind that, as far as the browser is concerned, the URL in the location is still the page that was originally requested. Therefore, a bookmark for the login form will actually be to the real page (which might again trigger authentication if they have exited and restarted before following the bookmark). Right now I've got a web app set up with tomcat 3.2.2 using form-based authentication, when I request /WWAT2/user/welcome.jsp I get redirected to /WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked it, logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my original request) I logged out, then went to my bookmarked /WWAT2/login.jsp So it looks like I do see the login URL. (I have absolutely no links to the /WWAT2/login.jsp anywhere) So what you are saying is that if a user doesn't see the login URL, there are no links to it in the web-app, the chances of them requesting JUST the login page of a web-app are so few and far between that handling that special case should just be ignored? Is there something wrong with my tomcat configuration? The form-based authentication works like a dream except for showing me the URL of the login page. The behaviour is fine. -Mike And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the container is supposed to redirect to the originally requested page after authentication is completed. The net effect of this is that the URL of the login page is never visible to the user, unless you have deliberately linked to it in your user interface. That's one of the reasons such links should not exist. NOTE: If you don't like the philosophy of form-based login, the appropriate forum is the feedback address for the servlet spec ([EMAIL PROTECTED]), because that is where the requirements for how Tomcat works are defined. Craig Thanks! I'll forward my suggestion on to them. -Mike Craig
cvs commit: jakarta-tomcat/src/share/org/apache/jasper Constants.java
costin 01/06/21 14:40:24
Modified:src/share/org/apache/jasper Constants.java
Log:
Rollback, we'll use watchdog with 32 tag.
Revision ChangesPath
1.24 +1 -4 jakarta-tomcat/src/share/org/apache/jasper/Constants.java
Index: Constants.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Constants.java2001/06/21 20:49:22 1.23
+++ Constants.java2001/06/21 21:40:22 1.24
@@ -100,10 +100,7 @@
public static final String[] STANDARD_IMPORTS = {
javax.servlet.*,
javax.servlet.http.*,
- javax.servlet.jsp.*,
- // WRONG, the spec says only the above 3 should be included, but
- // watchdog has a different opinion
- javax.servlet.jsp.tagext.*
+ javax.servlet.jsp.*
};
/**
Any reason why...
...these two lines at around 1110 in jk_ajp_common.c int port = jk_get_worker_port(props, p-name, port); char *host = jk_get_worker_host(props, p-name, host); use unitialised values for port and host. Anyone mind if I change them to int port = jk_get_worker_port(props, p-name, -1); char *host = jk_get_worker_host(props, p-name, NULL); ? -- Andy Armstrong, Tagish
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Michael Jennings wrote: Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp That would be nice - if possible. I spent quite a bit of time finding workarounds that would allow such a behavior. If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. So the redirection thing is just how it is implemented right now. Stupid me. Probably it's me the one - since everyone seems to know how to implement such a thing except me. Costin
DCOM/JNI/TOMCAT
Hi All, Tomcat craches when trying to access remote DCOM server while local access works fine. Default security is used, thus no CoInitializeSecurity is called neither from client or server part. Tomcat runs as win2000 service with my users login profil. Default system login does not enable remote access to DCOM server. Any suggestions There seem to be a permission issue. Cheers
cvs commit: jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/core Constants.java
larryi 01/06/21 15:33:57
Modified:jasper34/generator/org/apache/jasper34/core Constants.java
Log:
Cleaned up default imports.
Note: For the time being, you will need the tomcat_32 branch of
jakarta-watchdog testing. The head of jakarta-watchdog hasn't been
updated to avoid a dependency on javax.servlet.jsp.tagext.*
Revision ChangesPath
1.7 +1 -15
jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/core/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper34/generator/org/apache/jasper34/core/Constants.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Constants.java2001/06/17 20:22:27 1.6
+++ Constants.java2001/06/21 22:33:56 1.7
@@ -98,26 +98,12 @@
/**
* These classes/packages are automatically imported by the
* generated code.
- *
- * FIXME: Need to trim this to what is there in PR2 and verify
- *with all our generators -akv.
*/
public static final String[] STANDARD_IMPORTS = {
javax.servlet.*,
javax.servlet.http.*,
- javax.servlet.jsp.*,
- // This one is not in spec, but a lot of tests depend on it.
- // The code is fixed to use explicit deps, when we test
- // the watchdog tests we can remove this
- javax.servlet.jsp.tagext.*
+ javax.servlet.jsp.*
};
-
-// javax.servlet.jsp.tagext.*,
-// java.io.PrintWriter, java.io.IOException, java.io.FileInputStream,
-// java.io.ObjectInputStream, java.util.Vector,
-// org.apache.jasper.runtime.*, java.beans.*,
-// org.apache.jasper.JasperException
-// };
/**
* ServletContext attribute for classpath. This is tomcat specific.
Re: FORM-based authentication idea
On Thu, 21 Jun 2001 [EMAIL PROTECTED] wrote: On Thu, 21 Jun 2001, Michael Jennings wrote: Okay, I was being stupid. I understand now, with form-based authentication when you request /mywebapp/private/somefile.jsp what you get back should just be generated from the login page, then when you submit your credentials, it returns whatever is generated from /mywebapp/private/somefile.jsp That would be nice - if possible. I spent quite a bit of time finding workarounds that would allow such a behavior. If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. So the redirection thing is just how it is implemented right now. Stupid me. Probably it's me the one - since everyone seems to know how to implement such a thing except me. Costin Craig
cvs commit: jakarta-tomcat/src/doc readme
larryi 01/06/21 15:35:33 Modified:src/doc readme Log: Mention that Jasper34 is available in the build Revision ChangesPath 1.15 +9 -1 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- readme2001/06/21 04:52:45 1.14 +++ readme2001/06/21 22:35:32 1.15 @@ -1,4 +1,4 @@ -$Id: readme,v 1.14 2001/06/21 04:52:45 larryi Exp $ +$Id: readme,v 1.15 2001/06/21 22:35:32 larryi Exp $ Release Notes for: @@ -190,6 +190,14 @@ /Context See conf/server.xml for more information. + +- The jakarta-tomcat-jasper project has been created to support refactoring + and other improvements for Jasper, called as Jasper34. As a separate + project, this development can occur independent of Tomcat 3.x and 4.x. + Some preliminary work has been completed and the result is included in the + Tomcat 3.3 build and binary distributions. If you wish to give Jasper34 + a try, change JspInterceptor ... to JspInterceptor34 ... in your + server.xml file. - (more to be added)
Re: FORM-based authentication idea
On Thu, 21 Jun 2001, Craig R. McClanahan wrote: If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. Should != must. AFAIK there is no restriction on what is allowed in a login page - except the use of special name for the action and variables. That mean a page using relative URLs is legal, and the container must deal with it. ( I don't know too many pages using the base tag anyway, and relative URLs are prefered in many cases - I would say they are far more frequent than server-relative URLs ). Costin
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/20/01 9:14 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Lol. I thought it was really weird at first, then I added some traces, then I finally figured out something was hardcoded somewhere in the mapper. Still nothing in the work directory. I really don't understand how this has worked for you at all and isn't working for me. Are you actually testing your code before checking it in? -jon
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/20/01 9:14 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Lol. I thought it was really weird at first, then I added some traces, then I finally figured out something was hardcoded somewhere in the mapper. Still nothing in the work directory. I really don't understand how this has worked for you at all and isn't working for me. Are you actually testing your code before checking it in? Lol. If you think the bug isn't fixed fast enough, you can either : - send new logs instead of just saying it still doesn't work - it's oss, so you can fix it youself :) - keep on using the old CL, which works ok in most cases Remy
[t4] classloader doesn't work
#1. Remy, for the life of me, I can't use your new classloader. It just isn't happening. It doesn't start up at all because the settings in the file still seem to be ignored. I'm also having problems with the StandardClassLoader which is what seems to be used regardless of what I have in my server.xml file. #2. The new problem is that now, when I force a classloader reload by touching some files in scarab/WEB-INF/classes, I get this exception below. This causes Catalina to essentially crash and it leaves around a work/localhost/scarab/SESSION.ser file. If I restart Catalina, I cannot get Scarab to work again until I remove that file because it causes an exception like the one below to happen no matter what... So, something that you have done recently really messed up the class reloading to the point of not working at all. thanks, -jon java.lang.NoClassDefFoundError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at org.apache.turbine.services.intake.TurbineIntakeService.initializeBeanProp(T urbineIntakeService.java:224) at org.apache.turbine.services.intake.TurbineIntakeService.getFieldGetter(Turbi neIntakeService.java:581) at org.apache.turbine.services.intake.TurbineIntake.getFieldGetter(TurbineIntak e.java:235) at org.apache.turbine.services.intake.model.Field.init(Field.java:180) at org.apache.turbine.services.intake.model.BooleanField.init(BooleanField.ja va:73) at org.apache.turbine.services.intake.model.FieldFactory$2.getInstance(FieldFac tory.java:90) at org.apache.turbine.services.intake.model.FieldFactory.getInstance(FieldFacto ry.java:154) at org.apache.turbine.services.intake.model.Group.init(Group.java:154) at org.apache.turbine.services.intake.TurbineIntakeService.getGroup(TurbineInta keService.java:363) at org.apache.turbine.services.intake.TurbineIntake.getGroup(TurbineIntake.java :85) at org.apache.turbine.services.intake.IntakeTool.init(IntakeTool.java:131) at org.apache.turbine.services.pull.TurbinePullService.populateWithRequestTools (TurbinePullService.java:463) at org.apache.turbine.services.pull.TurbinePullService.populateContext(TurbineP ullService.java:391) at org.apache.turbine.services.pull.TurbinePull.populateContext(TurbinePull.jav a:145) at org.apache.turbine.services.velocity.TurbineVelocityService.getContext(Turbi neVelocityService.java:221) at org.apache.turbine.services.velocity.TurbineVelocity.getContext(TurbineVeloc ity.java:140) at org.apache.turbine.modules.pages.VelocityPage.doBuildBeforeAction(VelocityPa ge.java:84) at org.tigris.scarab.pages.ScarabPage.doBuildBeforeAction(ScarabPage.java:74) at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:137) at org.apache.turbine.modules.Page.build(Page.java:90) at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123) at org.apache.turbine.Turbine.doGet(Turbine.java:502) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:255) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:219) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:472) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2253) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at
Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/21/01 5:45 PM, Remy Maucherat [EMAIL PROTECTED] wrote: If you think the bug isn't fixed fast enough, you can either : I never said or even implied such a thing. Speed isn't the issue. - send new logs instead of just saying it still doesn't work The log files are the same as before. You haven't changed the logging aspects. - it's oss, so you can fix it youself :) I see your point, but I'm just hoping that Sun is not depending on the OSS community to fix their primary RI servlet container. - keep on using the old CL, which works ok in most cases See my last posting. It is broken as well. -jon
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
remm01/06/21 19:03:00
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
- Remove the StandardLoader classname from the comments.
Revision ChangesPath
1.26 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Catalina.java 2001/06/21 04:18:50 1.25
+++ Catalina.java 2001/06/22 02:02:59 1.26
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.25 2001/06/21 04:18:50 remm Exp $
- * $Revision: 1.25 $
- * $Date: 2001/06/21 04:18:50 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.26 2001/06/22 02:02:59 remm Exp $
+ * $Revision: 1.26 $
+ * $Date: 2001/06/22 02:02:59 $
*
*
*
@@ -98,7 +98,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.25 $ $Date: 2001/06/21 04:18:50 $
+ * @version $Revision: 1.26 $ $Date: 2001/06/22 02:02:59 $
*/
public class Catalina {
@@ -855,7 +855,7 @@
/**
- * Class that creates a new StandardLoader instance, with the parent class
+ * Class that creates a new loader instance, with the parent class
* loader associated with the top object on the stack (which must be a
* Container), and pushes it on to the stack.
*/
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Embedded.java
remm01/06/21 19:03:44
Modified:catalina/src/share/org/apache/catalina/startup Embedded.java
Log:
- Embedded createLoader method will now create instances of
WebappLoader, instead of StandardLoader.
Revision ChangesPath
1.8 +6 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java
Index: Embedded.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Embedded.java 2000/12/19 03:23:12 1.7
+++ Embedded.java 2001/06/22 02:03:43 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
1.7 2000/12/19 03:23:12 craigmcc Exp $
- * $Revision: 1.7 $
- * $Date: 2000/12/19 03:23:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
1.8 2001/06/22 02:03:43 remm Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/06/22 02:03:43 $
*
*
*
@@ -86,7 +86,7 @@
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.core.StandardEngine;
import org.apache.catalina.core.StandardHost;
-import org.apache.catalina.loader.StandardLoader;
+import org.apache.catalina.loader.WebappLoader;
import org.apache.catalina.logger.FileLogger;
import org.apache.catalina.logger.SystemOutLogger;
import org.apache.catalina.net.SSLServerSocketFactory;
@@ -148,7 +148,7 @@
* /pre
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2000/12/19 03:23:12 $
+ * @version $Revision: 1.8 $ $Date: 2001/06/22 02:03:43 $
*/
public class Embedded implements Lifecycle {
@@ -639,7 +639,7 @@
logger.log(Creating Loader with parent class loader ' +
parent + ');
-StandardLoader loader = new StandardLoader(parent);
+WebappLoader loader = new WebappLoader(parent);
return (loader);
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader Reloader.java StandardClassLoader.java
remm01/06/21 19:04:12
Modified:catalina/src/share/org/apache/catalina/loader Reloader.java
StandardClassLoader.java
Log:
- Remove the StandardLoader classname from the comments.
Revision ChangesPath
1.4 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/Reloader.java
Index: Reloader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/Reloader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Reloader.java 2001/01/23 22:12:32 1.3
+++ Reloader.java 2001/06/22 02:04:09 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/Reloader.java,v
1.3 2001/01/23 22:12:32 glenn Exp $
- * $Revision: 1.3 $
- * $Date: 2001/01/23 22:12:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/Reloader.java,v
1.4 2001/06/22 02:04:09 remm Exp $
+ * $Revision: 1.4 $
+ * $Date: 2001/06/22 02:04:09 $
*
*
*
@@ -68,10 +68,10 @@
/**
* Internal interface that codeClassLoader/code implementations may
* optionally implement to support the auto-reload functionality of
- * codeStandardLoader/code.
+ * the classloader associated with the context.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.3 $ $Date: 2001/01/23 22:12:32 $
+ * @version $Revision: 1.4 $ $Date: 2001/06/22 02:04:09 $
*/
public interface Reloader {
1.20 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
Index: StandardClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- StandardClassLoader.java 2001/06/12 03:53:26 1.19
+++ StandardClassLoader.java 2001/06/22 02:04:11 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.19 2001/06/12 03:53:26 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/06/12 03:53:26 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.20 2001/06/22 02:04:11 remm Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/06/22 02:04:11 $
*
*
*
@@ -93,7 +93,7 @@
* Subclass implementation of bjava.net.URLClassLoader/b that knows how
* to load classes from disk directories, as well as local and remote JAR
* files. It also implements the codeReloader/code interface, to provide
- * automatic reloading support to codeStandardLoader/code.
+ * automatic reloading support to the associated loader.
* p
* In all cases, URLs must conform to the contract specified by
* codeURLClassLoader/code - any URL that ends with a / character is
@@ -110,7 +110,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.19 $ $Date: 2001/06/12 03:53:26 $
+ * @version $Revision: 1.20 $ $Date: 2001/06/22 02:04:11 $
*/
public class StandardClassLoader
Re: Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/21/01 5:45 PM, Remy Maucherat [EMAIL PROTECTED] wrote: If you think the bug isn't fixed fast enough, you can either : I never said or even implied such a thing. Speed isn't the issue. - send new logs instead of just saying it still doesn't work The log files are the same as before. You haven't changed the logging aspects. Well, looking at your logs that's true, the logs are unchanged. The important changes were in the startup/Catalina class, which I assume you picked up. I have to fix a few other places where the CL classname was hardcoded to StandardLoader, but that definitely shouldn't have affected you. - it's oss, so you can fix it youself :) I see your point, but I'm just hoping that Sun is not depending on the OSS community to fix their primary RI servlet container. As far as *I* am concerned, that is not true. Sun only needs a good servlet container. There's a lot of improvements over what Sun provides which have to be contributed by the community for Tomcat to be a great product, and the main one IMO is real world testing, as many bugfixes as possible (since it saves a lot of time trying to reproduce the bug, which is also generally very hard to do). I hope you don't think Tomcat 4 is developed like closed source software. If I thought that was the case, I would be out of here already. - keep on using the old CL, which works ok in most cases See my last posting. It is broken as well. According to the logs, you're somehow still using it : From scarab_log : 2001-06-21 18:20:58 StandardLoader[/scarab]: Reloading checks are enabled for this Context I have removed the StandardLoader class from my checked out CVS tree without any problems. I'm leaving it in the TC CVS at the moment, as a backup. If you update and do a grep for StandardLoader in your Catalina source, you'll see that it now only occurs in the messages strings, and in the StandardLoader class source itself. So I don't see any logical reason why you would end up with it being your loader. If you're paranoid, you can do as I did and delete StandardLoader from your tree. Remy
cvs commit: jakarta-tomcat/src/jasper34/org/apache/jasper34/utils Cache.java CacheDefaults.java Expirable.java JspMangler.java JspManglerImpl.java JspRecursiveModificationChecker.java MapCache.java ModificationChecker.java PeriodicJspRecursiveModificationChecker.java PeriodicModChecker.java SimpleModificationChecker.java TableCache.java
larryi 01/06/21 19:32:03 Removed: src/jasper34/org/apache/jasper34/utils Cache.java CacheDefaults.java Expirable.java JspMangler.java JspManglerImpl.java JspRecursiveModificationChecker.java MapCache.java ModificationChecker.java PeriodicJspRecursiveModificationChecker.java PeriodicModChecker.java SimpleModificationChecker.java TableCache.java Log: Removal of some of the Jasper34 files that now live in jakarta-tomcat-jasper
cvs commit: jakarta-tomcat/proposals/tomcat-4.0 source-proposal.html jasper-proposal.html catalina-proposal.html
larryi 01/06/21 19:33:42 Removed: proposals/tomcat-4.0 source-proposal.html jasper-proposal.html catalina-proposal.html Log: Removing old Tomcat 4.0 proposals
cvs commit: jakarta-tomcat/proposals/jasper34/runtime12/org/apache/jasper34/runtime12 BodyContentImpl.java Constants.java HttpJspBase.java JasperException.java JspFactoryImpl.java JspRuntimeLibrary.java JspWriterImpl.java PageContextImpl.java ServletResponseWrapperInclude.java
larryi 01/06/21 19:43:13 Removed: proposals/jasper34 JasperToolkit.html build.xml proposals/jasper34/generator/org/apache/jasper34/core JasperException.java JspCompilationContext.java Options.java TagLibraries.java proposals/jasper34/generator/org/apache/jasper34/generator11 CompileException.java Constants.java Generator.java GeneratorBase.java JspParseEventListener.java ServletWriter.java TagLibraryInfoImpl.java proposals/jasper34/generator/org/apache/jasper34/generator11/generators BeanEndGenerator.java BeanGenerator.java CharDataGenerator.java CommentGenerator.java DeclarationGenerator.java ExpressionGenerator.java ForwardGenerator.java GetPropertyGenerator.java IncludeGenerator.java InfoGenerator.java JakartaCommentGenerator.java MappedCharDataGenerator.java PluginGenerator.java ScriptletGenerator.java SetPropertyGenerator.java StoredCharDataGenerator.java TagBeginGenerator.java TagEndGenerator.java TagGeneratorBase.java TagPoolGenerator.java TagPoolManagerGenerator.java proposals/jasper34/generator/org/apache/jasper34/generator11/phase ClassDeclarationPhase.java DestroyMethodPhase.java FileDeclarationPhase.java InitMethodPhase.java ServiceMethodPhase.java StaticInitializerPhase.java proposals/jasper34/generator/org/apache/jasper34/generator11/util BeanRepository.java JspRuntimeLibrary.java JspUtil.java TagCache.java proposals/jasper34/generator/org/apache/jasper34/parser11 CoreElement.java DelegatingListener.java JspParseUtil.java JspReader.java Mark.java ParseEventListener.java ParseException.java Parser.java proposals/jasper34/model/model-tree false.gif model.tree true.gif tv-class.gif tv-interface.gif tv-physical-package.gif tv-pkg-diagram.gif proposals/jasper34/model/org/apache/jasper34 jasper34.cl.html package-frame.html package-summary.html package-tree.html package-use.html proposals/jasper34/model/org/apache/jasper34/doc-files jasper34.cl.gif jasper34.cl.html proposals/jasper34/model/org/apache/jasper34/resources package-frame.html package-summary.html package-tree.html package-use.html resources.cl.html proposals/jasper34/model/org/apache/jasper34/resources/doc-files resources.cl.gif resources.cl.html proposals/jasper34/model/org/apache/jasper34/servlet JspServlet.html JspServletLoader.html JspServletPageHandler.html JspServletRequestHandler.html JspServletToolkit.html package-frame.html package-summary.html package-tree.html package-use.html servlet.cl.html proposals/jasper34/model/org/apache/jasper34/servlet/class-use JspServlet.html JspServletLoader.html JspServletPageHandler.html JspServletRequestHandler.html JspServletToolkit.html proposals/jasper34/model/org/apache/jasper34/servlet/doc-files servlet.cl.gif servlet.cl.html proposals/jasper34/model/org/apache/jasper34/toolkit JasperToolkit.html JavaCompiler.html JspCompiler.html JspPageHandler.html JspRequestHandler.html package-frame.html package-summary.html package-tree.html package-use.html toolkit.cl.html proposals/jasper34/model/org/apache/jasper34/toolkit/class-use JasperToolkit.html JavaCompiler.html JspCompiler.html JspPageHandler.html JspRequestHandler.html proposals/jasper34/model/org/apache/jasper34/toolkit/doc-files toolkit.cl.gif toolkit.cl.html proposals/jasper34/model/org/apache/jasper34/utils Cache.html CacheDefaults.html Expirable.html JspMangler.html JspManglerImpl.html
cvs commit: jakarta-tomcat/proposals/web-connector/native/nt_service jk_nt_service.c nt_service.dsp
larryi 01/06/21 19:48:04 Removed: proposals/web-connector/doc AJPv13.html Tomcat-Workers-HowTo.html mod_jk-howto.html tomcat-apache-howto.html tomcat-iis-howto.html tomcat-netscape-howto.html tomcat-ssl-howto.html proposals/web-connector/native README proposals/web-connector/native/apache1.3 Makefile.freebsd Makefile.linux Makefile.nw README.hpux README.solaris build-hpux-cc.sh build-hpux.sh build-solaris.sh build-unix.sh install-unix.sh mod_jk.c mod_jk.dsp proposals/web-connector/native/apache2.0 Makefile.linux build-unix.sh install-unix.sh mod_jk.c mod_jk.dsp proposals/web-connector/native/common jk_ajp12_worker.c jk_ajp12_worker.h jk_ajp13.c jk_ajp13.h jk_ajp13_worker.c jk_ajp13_worker.h jk_connect.c jk_connect.h jk_global.h jk_jni_worker.c jk_jni_worker.h jk_lb_worker.c jk_lb_worker.h jk_map.c jk_map.h jk_msg_buff.c jk_msg_buff.h jk_mt.h jk_nwmain.c jk_pool.c jk_pool.h jk_service.h jk_sockbuf.c jk_sockbuf.h jk_uri_worker_map.c jk_uri_worker_map.h jk_util.c jk_util.h jk_worker.c jk_worker.h jk_worker_list.h proposals/web-connector/native/iis isapi.def isapi.dsp isapi.dsw jk_isapi_plugin.c proposals/web-connector/native/jni Makefile.nw Makefile.solaris jk_jnicb.c jk_jnicb.exp jk_jnicb.h jni_connect.dsp jni_connect.dsw proposals/web-connector/native/netscape Makefile.nw Makefile.solaris jk_nsapi_plugin.c nsapi.dsp nsapi.dsw proposals/web-connector/native/nt_service jk_nt_service.c nt_service.dsp Log: Removing the web-connector proposal which now lives in jakarta-tomcat-connectors
Historical question about BufferedServletOutputStream.java
Ever since version 1.1, BufferedServletOutputStream.flush() checks to see if if the response is using an PrintWriter and if it is it ignores the flush request. The question is why? My guess is that it had something to do with the fact that the PrintWriter itself has a buffer because it uses an OutputStreamWriter internally, but that still doesn't make any sense. The net result is that if a servlet author calls flush on the PrintWriter returned from response.getWriter() nothing *appears* to happen. Internally what happens is that the bytes from the PrintWriter's OutputStreamWriter are flushed into the BufferedServletOutputStream's buffer, but they aren't sent to the client. This is not the behaviour that most servlet authors would expect and I don't see any reason in the spec that would mandate it. Does anyone remember or know why BufferedServletOutputStream.flush() does nothing when a PrintWriter is in use? There's bug posted against this behaviour and I don't see any reason why the buffer shouldn't be sent to the client when a PrintWriter is in use, but before I make a change to something that's been around for so long I thought I'd see if anyone remembers why it was done this way to start with.
Re: FORM-based authentication idea
FWIW, I ran into this problem with users bookmarking the login page and returning to it without trying to access a protected resource. In the current implementation in 3.2.2, I don't think you can prevent that, can you? After being authenticated, the user was being dropped into the directory that contained my login.jsp. I found the easiest solution was to have my login.jsp in it's own directory with an index.jsp that simply redirects to the appropriate page inside my protected resource. Took me about a minute to implement and it works well. Craig, from your previous posts I am under the impression that the current implementation for form-based logins uses a sendRedirect() -- which is why you can see and bookmark the URL for your login.jsp page (3.2.2). Is this correct? Is that going to change to use RequestDispatcher.forward() in the future? If so, that should solve the bookmarking problem. Thanks, --jeff P.S. -- I always use server-relative links, but I'm a programmer! :o) My designers using Dreamweaver always send me files with relative links... - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 4:48 PM Subject: Re: FORM-based authentication idea On Thu, 21 Jun 2001, Craig R. McClanahan wrote: If the login page would be displayed all the a href= / or img in the login page will be treated by the browser as relative to /mywebapp/private, while the login page can be somewhere else. The form login page should use server-relative URLs, or a base tag in the head section. That way, the initial display of the login page will work correctly even on a container that does (what amounts to) a RequestDispatcher.forward() to the login page. Should != must. AFAIK there is no restriction on what is allowed in a login page - except the use of special name for the action and variables. That mean a page using relative URLs is legal, and the container must deal with it. ( I don't know too many pages using the base tag anyway, and relative URLs are prefered in many cases - I would say they are far more frequent than server-relative URLs ). Costin
Re: Historical question about BufferedServletOutputStream.java
What I remember - it was there, and I never understood very well why :-) That's one of the reasons I put a lot of time into OutputBuffer and refactoring the output system. My best guess was that it is related with higher level code ( Writer, JspWriter most likely ) that needs to empty it's internal buffers - but without trigering a real write. For example if a jsp includes a servlet, it must empty the JspWriter buffers to prevent out-of-order output. Until recently jasper used flush() to do that ( it has been fixed with a cast to JspWriterImpl ). It may be possible to have the servlet included by the jsp forward to another page - a valid sequence that will not work if the flush commits the answer, so the flush had to be avoided. Working with streams can be extremely confusing, especially in situations like this. If you want to fix this - the jasper side was fixed wrt. flush() ( at least in 3.3), but you need to be carefull. Costin On Thu, 21 Jun 2001, Marc Saegesser wrote: Ever since version 1.1, BufferedServletOutputStream.flush() checks to see if if the response is using an PrintWriter and if it is it ignores the flush request. The question is why? My guess is that it had something to do with the fact that the PrintWriter itself has a buffer because it uses an OutputStreamWriter internally, but that still doesn't make any sense. The net result is that if a servlet author calls flush on the PrintWriter returned from response.getWriter() nothing *appears* to happen. Internally what happens is that the bytes from the PrintWriter's OutputStreamWriter are flushed into the BufferedServletOutputStream's buffer, but they aren't sent to the client. This is not the behaviour that most servlet authors would expect and I don't see any reason in the spec that would mandate it. Does anyone remember or know why BufferedServletOutputStream.flush() does nothing when a PrintWriter is in use? There's bug posted against this behaviour and I don't see any reason why the buffer shouldn't be sent to the client when a PrintWriter is in use, but before I make a change to something that's been around for so long I thought I'd see if anyone remembers why it was done this way to start with.
cvs commit: jakarta-tomcat KEYS
larryi 01/06/21 22:07:58 Added: .KEYS Log: Adding KEYS file from Tomcat 3.2.2 and adding my own key. Revision ChangesPath 1.2 +59 -0 jakarta-tomcat/KEYS
cvs commit: jakarta-tomcat build.xml
larryi 01/06/21 22:26:58
Modified:.build.xml
Log:
Include KEYS file in build
Revision ChangesPath
1.136 +1 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- build.xml 2001/06/19 00:34:37 1.135
+++ build.xml 2001/06/22 05:26:56 1.136
@@ -138,6 +138,7 @@
fileset dir=src/native/
/copy
copy tofile=${tomcat.build}/LICENSE file=LICENSE/
+copy tofile=${tomcat.build}/KEYS file=KEYS/
!-- include ant, it is used for testing and will be used for
configuration and few other tasks
