Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
Justin Erenkrantz wrote: On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote: I'll grab the latest CVS and see how that works. The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal and autoconf. Cygwin includes all of these except libtool. I built it and installed it into /usr/local/bin and bad things happened. I put it into /usr/bin and things ran fine. Ah, that's jk-specific. It might be a good idea to try to remove the automake dependency if at all possible as we don't require it for httpd. That is possible - But that means to commit some automake generated files or to duplicate these files - All of the others are required for Apache 2.0. Pier has a good build system with 2.0 for mod_webapp. =) -- justin
DO NOT REPLY [Bug 3936] New: - getResources does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3936. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3936 getResources does not work Summary: getResources does not work Product: Tomcat 4 Version: 4.0 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] WebappClassLoader does not seem to implement getResources properly. There is an implementation for getResource that does things properly, but findResources simply delegates to super(). For example, this means that if I have multiple JAR files in WEB-INF/lib each of which contains a file foo.txt, and I want to get URL's to all of those files, I cannot use getResources(foo.txt) as I should be able to.
ClassCastException
this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) 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.java:215) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) 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:2366) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) 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:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement
How about naming it common instead of shared, to match Tomcat 3.3? --Jeff On Tue, Oct 02, 2001 at 04:54:54PM -0700, Craig R. McClanahan wrote: I'd like to propose a small change in the binary distribution layout for the next version of Tomcat (4.1). It's probably not a good idea to introduce this in a 4.0.1 maintenance update, though. Currently, the Shared class loader is set up based on unpacked classes in the $CATALINA_HOME/classes directory plus JAR files in the $CATALINA_HOME/lib directory. I would like to suggest that we change this to $CATALINA_HOME/shared/classes and $CATALINA_HOME/shared/lib instead, to have the directory names be more consistent with the class loader names. Anybody have any comments or thoughts on this? Craig
Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement
Jeff Turner wrote: How about naming it common instead of shared, to match Tomcat 3.3? There is already a common/lib in TC4.0 --Jeff On Tue, Oct 02, 2001 at 04:54:54PM -0700, Craig R. McClanahan wrote: I'd like to propose a small change in the binary distribution layout for the next version of Tomcat (4.1). It's probably not a good idea to introduce this in a 4.0.1 maintenance update, though. Currently, the Shared class loader is set up based on unpacked classes in the $CATALINA_HOME/classes directory plus JAR files in the $CATALINA_HOME/lib directory. I would like to suggest that we change this to $CATALINA_HOME/shared/classes and $CATALINA_HOME/shared/lib instead, to have the directory names be more consistent with the class loader names. Anybody have any comments or thoughts on this? Craig
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884
SingleThreadModel servlets not pooled results in low performance
--- Additional Comments From [EMAIL PROTECTED] 2001-10-03 04:59 ---
First, let me clarify that my arguments are mainly
for the servlet SingleThreadModel interface, the JSP
'isThreadSafe=false' declaration I can do without.
It seems like you have two major arguments,
1: many users don't understand how STM works and
2: it doesn't solve any real problems.
The first one is a documentation and education problem imho.
(Maybe removing the JSP 'isThreadSafe=false' declaration
partially solves this problem. No doubt naming it 'isThreadSafe'
has contributed to the confusion.)
Note also that the assumption that there exists only one instance
of a (non-STM) servlet is broken anyway in any real world
installation using more than one web server and servlet engine.
For the second one, we have a servlet library providing different
kinds of functionality for JSPs using our product. The servlet
library is a small tree of classes. The functionality provided
consists of both methods and members. The JSPs extends a servlet
to import the wanted functionality.
SingleThreadModel is used to make this scheme work when
a servlet implements members with request specific data.
These members can be replaced with access methods, but for
all but the most trivial cases the access method now
needs to store the computed information in the request scope
instead (this is just an optimization for read-only data,
but absolutely necessary for read-write data).
Storing the data in members simplifies the code internally
but the main reason we use it is that it provides a simpler API
for our clients (implementing JSPs). Adding members adds
implicit objects that can be used directly in the JSP just as the
default implicit objects ('request', 'response', 'out' etc).
This is a much more seamless extension of a standard JSP than
possible with access methods.
cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 Makefile.in
jfclere 01/10/03 05:35:14
Modified:webapp Makefile.in configure.in
webapp/apache-2.0 Makefile.in
Log:
mod_webapp build cleanups
Submitted by: Justin Erenkrantz [EMAIL PROTECTED]
Revision ChangesPath
1.21 +7 -1 jakarta-tomcat-connectors/webapp/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Makefile.in 2001/09/17 05:06:27 1.20
+++ Makefile.in 2001/10/03 12:35:14 1.21
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.20 2001/09/17 05:06:27 pier Exp $
+# @version $Id: Makefile.in,v 1.21 2001/10/03 12:35:14 jfclere Exp $
include @TGTDIR@/Makedefs
@@ -106,6 +106,12 @@
apache-1.3-clean:
@$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-1.3 MTGT=clean
+
+apache-2.0-build:
+ @$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-2.0 MTGT=build
+
+apache-2.0-clean:
+ @$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-2.0 MTGT=clean
template:
@ { \
1.40 +9 -9 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- configure.in 2001/09/17 05:07:01 1.39
+++ configure.in 2001/10/03 12:35:14 1.40
@@ -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.39 2001/09/17 05:07:01 pier Exp $
+dnl Version $Id: configure.in,v 1.40 2001/10/03 12:35:14 jfclere Exp $
dnl --
dnl --
@@ -177,7 +177,7 @@
dnl Upd vars: N/A
dnl -
AC_ARG_WITH(tomcat,
- [ --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
+ [ --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
to \/usr/local/tomcat\). Not required and ignored
when the --enable-java option is not specified.],
[
@@ -241,7 +241,7 @@
AC_MSG_CHECKING([for C API documentation])
AC_ARG_ENABLE(apidocs-c,
[ --enable-apidocs-c[=PERL]
- enbale generation of C API documentation using
+ enable generation of C API documentation using
ScanDoc (PERL is the name of the Perl interpreter
used to run ScanDoc. If not specified this is
looked up in your current path).],
@@ -302,7 +302,7 @@
AC_MSG_CHECKING([for Java API documentation])
AC_ARG_ENABLE(apidocs-java,
[ --enable-apidocs-java[=JAVADOC]
- enbale generation of Java API documentation using
+ enable generation of Java API documentation using
JavaDoc (If JAVADOC is not set its value will be
discovered by \--enable-java\).],
[
@@ -347,10 +347,10 @@
dnl Upd vars: APR_SRCDIR
dnl --
AC_ARG_WITH(apr,
- [ --with-apr[=DIR]path of an APR (Apache Portable Runtime) source
+ [ --with-apr[=DIR] path of an APR (Apache Portable Runtime) source
distribution or CVS snapshot. (DIR defaults to
- \./apr\). Not required and ignored when the
- --with-apxs2 option is specified.],
+ \./apr\). Not required and ignored when an
+ Apache 2.0 apxs is specified (--with-apxs).],
[
case ${withval} in
|yes|YES|true|TRUE)
@@ -382,7 +382,7 @@
dnl --
AC_MSG_CHECKING([for Apache apxs])
AC_ARG_WITH(apxs,
- [ --with-apxs[=FILE] build a shared Apache module. If FILE was not
+ [ --with-apxs[=FILE]build a shared Apache module. If FILE was not
specified, then APXS will be searched within the
current PATH. The Apache server version (1.3 or 2.0)
will be automatically detected.],
Re: ClassCastException
Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) 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.java:215) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) 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:2366) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) 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:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
welcome files being forwarded to rather than redirected to?
A while ago I sent a message about the behaviour of welcome files going against the recommendations at http://www.w3.org/Provider/Style/URI; at the time the servlet spec was in PFD and was fairly explicit that sending a redirect wasn't acceptable. Looking at the final spec, it appears that they've toned down their language a little - nevertheless, this kind of behaviour (avoiding redirects) seems preferable. Unfortunately, the latest stable tomcat/catalina (congrats on this, by the way!) still behaves in the old way. I know I can explicitly map any URIs to particular JSPs or html files; however, I'd like to avoid having to do that (the convenience of welcome files is completely lost). Is this set in stone? Cheers, jan PS. original message here: http://w4.metronet.com/~wjm/tomcat/2001/Apr/msg00234.html - in a nutshell: if I request http://foo.bar/webapp/ I'd like to see the contents of .../webapp/index.html, but _not_ see a redirect to http://foo.bar/webapp/index.html -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] ( echo ouroboros; cat ) /dev/fd/0 # it's like talking to yourself sometimes
cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c
jfclere 01/10/03 06:42:57 Modified:webapp/apache-2.0 mod_webapp.c Log: Fix the port (the direct was not working). Revision ChangesPath 1.4 +3 -3 jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c Index: mod_webapp.c === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- mod_webapp.c 2001/09/12 16:29:05 1.3 +++ mod_webapp.c 2001/10/03 13:42:57 1.4 @@ -57,7 +57,7 @@ /** * @author Pier Fumagalli mailto:[EMAIL PROTECTED] - * @version $Id: mod_webapp.c,v 1.3 2001/09/12 16:29:05 pier Exp $ + * @version $Id: mod_webapp.c,v 1.4 2001/10/03 13:42:57 jfclere Exp $ */ #include httpd.h @@ -459,9 +459,9 @@ req-serv-addr=apr_pstrdup(req-pool,con-local_ip); req-clnt-addr=apr_pstrdup(req-pool,con-remote_ip); apr_sockaddr_port_get(port, con-local_addr); -req-serv-port=ntohs(port); +req-serv-port= (int) port; apr_sockaddr_port_get(port, con-remote_addr); -req-clnt-port=ntohs(port); +req-clnt-port= (int) port; /* Set up all other members of the request structure */ req-meth=apr_pstrdup(req-pool,(char *)r-method);
Re: [PATCH] mod_webapp build cleanups...
Justin Erenkrantz wrote:
I finally got a chance to build mod_webapp from j-t-c with Apache 2.0.
Looks good and is quite easy to do. Only problem is that we aren't
handling directories properly. If you do the examples webapp, you
see a link to:
http://localhost:8080/examples/servlets/
Going there results in a bad response (actually nothing returned!),
but
http://localhost:8080/examples/servlets/index.html
works. I'm not terribly sure if httpd or Tomcat should be handling
this case (i.e. redirecting or handling DirectoryIndex-type semantics).
Somebody isn't handling it and that's not good.
I have fixed it (The port handling was wrong).
You will find attached a patch that cleans up some of the build
process in j-t-c so that it works with Apache 2.0 cleanly and
fixes some tpyos and formatting quirks.
I have committed the patch (it builds better with it ;-)).
The only questionable thing is that lib/libwebapp.a isn't built by
libtool. The simple straightforward ar and ranlib should work fine,
but it may not work on all systems. When linking mod_webapp.lo with
libwebapp.a, libtool emits a warning. It may be worth it to try and
use APR's libtool to compile and link all of the files in lib (this
would produce lib/libwebapp.la).
Enjoy. Oh, and Pier, thanks for dinner. =-) This is my
payback... -- justin
Index: webapp/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.20
diff -u -r1.20 Makefile.in
--- webapp/Makefile.in 2001/09/17 05:06:27 1.20
+++ webapp/Makefile.in 2001/10/01 06:39:24
@@ -107,6 +107,12 @@
apache-1.3-clean:
@$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-1.3 MTGT=clean
+apache-2.0-build:
+ @$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-2.0 MTGT=build
+
+apache-2.0-clean:
+ @$(MAKE) template MFLG=$(MAKEFLAGS) MDIR=apache-2.0 MTGT=clean
+
template:
@ { \
$(ECHO) ; \
Index: webapp/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.39
diff -u -r1.39 configure.in
--- webapp/configure.in 2001/09/17 05:07:01 1.39
+++ webapp/configure.in 2001/10/01 06:39:24
@@ -177,7 +177,7 @@
dnl Upd vars: N/A
dnl -
AC_ARG_WITH(tomcat,
- [ --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
+ [ --with-tomcat[=DIR] path of a Tomcat 4.0 distribution. (DIR defaults
to \/usr/local/tomcat\). Not required and ignored
when the --enable-java option is not specified.],
[
@@ -241,7 +241,7 @@
AC_MSG_CHECKING([for C API documentation])
AC_ARG_ENABLE(apidocs-c,
[ --enable-apidocs-c[=PERL]
- enbale generation of C API documentation using
+ enable generation of C API documentation using
ScanDoc (PERL is the name of the Perl interpreter
used to run ScanDoc. If not specified this is
looked up in your current path).],
@@ -302,7 +302,7 @@
AC_MSG_CHECKING([for Java API documentation])
AC_ARG_ENABLE(apidocs-java,
[ --enable-apidocs-java[=JAVADOC]
- enbale generation of Java API documentation using
+ enable generation of Java API documentation using
JavaDoc (If JAVADOC is not set its value will be
discovered by \--enable-java\).],
[
@@ -347,10 +347,10 @@
dnl Upd vars: APR_SRCDIR
dnl --
AC_ARG_WITH(apr,
- [ --with-apr[=DIR]path of an APR (Apache Portable Runtime) source
+ [ --with-apr[=DIR] path of an APR (Apache Portable Runtime) source
distribution or CVS snapshot. (DIR defaults to
- \./apr\). Not required and ignored when the
- --with-apxs2 option is specified.],
+ \./apr\). Not required and ignored when an
+ Apache 2.0 apxs is specified (--with-apxs).],
[
case ${withval} in
|yes|YES|true|TRUE)
@@ -382,7 +382,7 @@
dnl --
AC_MSG_CHECKING([for Apache apxs])
AC_ARG_WITH(apxs,
- [ --with-apxs[=FILE] build a shared Apache module. If FILE was not
+ [ --with-apxs[=FILE]build a shared Apache module. If FILE was not
specified, then APXS will be searched within the
current PATH. The Apache server version (1.3 or 2.0)
RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
It probably isn't a big deal now. I've got the .dsp file working now. Once I'm satisfied everything is OK I'll commit the changes and also export a Windows makefile so that I can build without using the damned IDE. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Wednesday, October 03, 2001 3:30 AM To: [EMAIL PROTECTED] Subject: Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows Justin Erenkrantz wrote: On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote: I'll grab the latest CVS and see how that works. The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal and autoconf. Cygwin includes all of these except libtool. I built it and installed it into /usr/local/bin and bad things happened. I put it into /usr/bin and things ran fine. Ah, that's jk-specific. It might be a good idea to try to remove the automake dependency if at all possible as we don't require it for httpd. That is possible - But that means to commit some automake generated files or to duplicate these files - All of the others are required for Apache 2.0. Pier has a good build system with 2.0 for mod_webapp. =) -- justin
Re: ClassCastException
sure :) WEB.XML ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app resource-ref res-ref-namejdbc/domus/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app # SERVER.XML ##à Context path=/domus docBase=domus debug=0 reloadable=true Resource name=jdbc/domus auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/domus parameter nameuser/name valueuser/value /parameter parameter namepassword/name valuepassword/value /parameter parameter namedriverClassName/name valueweblogic.jdbc.mssqlserver4.Driver/value /parameter parameter namedriverName/name valuejdbc:weblogic:mssqlserver4:domus@localhost:1433/value /parameter /ResourceParams /Context ## i tink that this part is correct ?? - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) 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:243) 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:215) 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.StandardContext.invoke(StandardContext.java:2366) 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:462) 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 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098 ) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
DO NOT REPLY [Bug 3939] New: - HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3939. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3939 HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat Summary: HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My application managed security sends a HttpServletResponse.SC_UNAUTHORIZED error to trigger the browser to ask for details from the user. However, Tomcat traps this error and redirects to an error page instead of passing the HTTP 401 error on to the browser. I cannot find a workaround, hence my application is unusable. Broken in Mozilla and IE, strangely works in Netscape 4.7x
Re: ClassCastException
hehehe if i use this class: tyrex.jdbc.xa.EnabledDataSource instead javax.sql.DataSource the program works fine the problem is that EnableDataSource implements javax.sql.DataSource but i can't cast javax.sql.DataSource. why ??? Alessandro - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) 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:243) 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:215) 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.StandardContext.invoke(StandardContext.java:2366) 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:462) 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 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098 ) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
DO NOT REPLY [Bug 3941] New: - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941
PrinWriter.flush() HttpServletResponse.flushBuffer() do not work
Summary: PrinWriter.flush() HttpServletResponse.flushBuffer() do
not work
Product: Tomcat 4
Version: 4.0 Release Candidate 2
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Flushing of buffered output from a servlet to a client does not work as shown in
the following Servlet code and Clinet code. This problem only occured in Tomcat
4 where the output only occures after closing the PrintWriter. The flushing
works fine with Tomcat 3.2.3 for both the Prinwriter and the
HttpServletResponse.
HERE IS THE SERVLET TEST CODE:
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Enumeration;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public final class Server extends HttpServlet {
/**
* Respond to a GET request for the content produced by
* this servlet.
*
* @param request The servlet request we are processing
* @param response The servlet response we are producing
*
* @exception IOException if an input/output error occurs
* @exception ServletException if a servlet error occurs
*/
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType(text/xml);
PrintWriter writer = response.getWriter();
writer.println(buffersize: + response.getBufferSize());
writer.println(\nTest:);
writer.println(initial isCommited: + response.isCommitted());
writer.println(\nresponse);
writer.flush();
writer.println(after writer.flush() isCommited: +
response.isCommitted());
writer.println(\nParameters);
response.flushBuffer();
writer.println(after response.flushBuffer() isCommited: +
response.isCommitted());
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
writer.println(name + : + request.getParameter(name));
writer.println(Waiting 2secs\n);
//THESE ARE THE 2 PROBLEMATIC LINES -NONE OF THEM WORKS WITH TOMCAT 4
writer.flush();
response.flushBuffer();
try {
Thread.sleep(2000);
}
catch (InterruptedException e){
}
}
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
doGet(request, response);
}
}
AND HERE IS THE CLIENT CODE:
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.URL;
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.net.URLConnection;
public class Client {
public static void main(String[] args) {
String query =
http://localhost:8080/Server1/Server1?banana=yellowsnow=whitesea=blue;;
try {
URL url = new URL(query);
BufferedReader in = new BufferedReader(new
InputStreamReader(url.openStream()));
String line;
while ((line = in.readLine()) != null)
System.out.println(line);
} catch(IOException e) {
System.out.println(Error + e);
}
}
}
Re: ClassCastException
I believe you have the various jar's in the wrong locations. They're wrong because, even though all the classes you need are there, they end up in incompatible class loaders. Make sure that: * tyrex jar, jta jar, and jdbc optional jar are in common/lib. * your JDBC driver jar is in common/lib, and *not* also in WEB-INF/lib Possibly other setups will work correctly -- the stuff above works for us. I know definitely that mislocating jar's -- like putting drivers in server/lib -- results in the exact CCE that you list below. - Fernando Alessandro Pizzolotto To: [EMAIL PROTECTED] ale@extraweb. cc: (bcc: Fernando Salazar/CAM/Lotus) it Subject: Re: ClassCastException 10/03/2001 11:10 AM Please respond to tomcat-dev hehehe if i use this class: tyrex.jdbc.xa.EnabledDataSource instead javax.sql.DataSource the program works fine the problem is that EnableDataSource implements javax.sql.DataSource but i can't cast javax.sql.DataSource. why ??? Alessandro - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) 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:243) 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:215) 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.StandardContext.invoke(StandardContext.java:2366) 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:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at
Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement
On Wed, 3 Oct 2001, Jeff Turner wrote: Date: Wed, 3 Oct 2001 19:41:47 +1000 From: Jeff Turner [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Tomcat 4.1] Proposed Slight Binary Distribution Rearrangement How about naming it common instead of shared, to match Tomcat 3.3? There is already a common directory, whose common/classes and common/lib subdirectories are added to the Common class loader. In fact, it is *this* pattern that I want shared to match :-). --Jeff Craig
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 09:09 --- If you (or anyone else) would like STM pooling support added, please submit a patch to make it so.
DO NOT REPLY [Bug 3944] New: - request.getRemoteAddr() always returning 127.0.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3944. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3944 request.getRemoteAddr() always returning 127.0.0.1 Summary: request.getRemoteAddr() always returning 127.0.0.1 Product: Tomcat 3 Version: 3.3 Release Candidate 1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I recently upgraded to tomcat 3.3rc1 and I'm not able any more to detect address of people connecting to my web site since I always get 127.0.0.1 as RemoteAddress and always localhost as RemoteHost. Is it a know issue and is there any work around? I need it also because I do some computation/statistics on network addresses. Thanks for the help and keep up the great work, Alex
Re: welcome files being forwarded to rather than redirected to?
On Wed, 3 Oct 2001, Jan Grant wrote: Date: Wed, 3 Oct 2001 13:59:10 +0100 (BST) From: Jan Grant [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: tomcat-dev [EMAIL PROTECTED] Subject: welcome files being forwarded to rather than redirected to? A while ago I sent a message about the behaviour of welcome files going against the recommendations at http://www.w3.org/Provider/Style/URI; at the time the servlet spec was in PFD and was fairly explicit that sending a redirect wasn't acceptable. Looking at the final spec, it appears that they've toned down their language a little - nevertheless, this kind of behaviour (avoiding redirects) seems preferable. Unfortunately, the latest stable tomcat/catalina (congrats on this, by the way!) still behaves in the old way. I know I can explicitly map any URIs to particular JSPs or html files; however, I'd like to avoid having to do that (the convenience of welcome files is completely lost). Is this set in stone? It's not at all clear that the Persistent URI article you referenced has anything to do with whether a redirect is used for a welcome file or not (the original persistent URI that the *human* used is still the same, no matter what technology is used on the server end) ... but there is a practical reason for the current behavior as well. Originally (back in the pre-3.2-final days), Tomcat did the equivalent of a RequestDispatcher.forward() to display welcome pages. This caused massive problems for people who didn't understand the difference between: http://foo.bar/webapp and http://foo.bar/webapp/ In the former case, any relative urls on the real welcome page are broken. This caused bug reports about welcome files not working (never mind that using a base element in your welcome page would have fixed it), which led to the current behavior. Cheers, jan Craig PS. original message here: http://w4.metronet.com/~wjm/tomcat/2001/Apr/msg00234.html - in a nutshell: if I request http://foo.bar/webapp/ I'd like to see the contents of .../webapp/index.html, but _not_ see a redirect to http://foo.bar/webapp/index.html -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] ( echo ouroboros; cat ) /dev/fd/0 # it's like talking to yourself sometimes
Re: ClassCastException
On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote: Date: Wed, 3 Oct 2001 17:10:37 +0200 From: Alessandro Pizzolotto [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ClassCastException hehehe if i use this class: tyrex.jdbc.xa.EnabledDataSource instead javax.sql.DataSource the program works fine the problem is that EnableDataSource implements javax.sql.DataSource but i can't cast javax.sql.DataSource. why ??? Would you happen to have a copy of jdbc2_0-stdext.jar in your system extensions directory ($JAVA_HOME/jre/lib/ext)? That would cause problems like this -- the same sort of problem that causes Class foo is not a servlet errors if you have servlet.jar there. Alessandro Craig McClanahan - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) 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:243) 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:215) 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.StandardContext.invoke(StandardContext.java:2366) 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:462) 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 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098 ) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
Issues regarding class loading in tomcat3.2.1
Hi, I am facing a problem regarding loading some of my classes at runtime. The scene is as follows. I download a jar and instantiate a class form it using my own class loader. This class extends another class which is present in the webapps/MYFOLDER/web-inf/classes folder. Now tomcat is unable to instantiate the class from the jar saying that the class from which it extends is not found. This problem is resolved if i make a jar of my classes in webapps/MYFOLDER/web-inf/classes folder and put it in the lib directory of tomcat. Can u please suggest me a better solution? and also let me know wht the problem is occuring. pls ASAP. Thanks in advance, Subhadeep.
Re: ClassCastException
now is ok i am delete 2 .jar from WEB-INF/lib the jdbc extension tanks :) Alkessandro - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 6:19 PM Subject: Re: ClassCastException On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote: Date: Wed, 3 Oct 2001 17:10:37 +0200 From: Alessandro Pizzolotto [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ClassCastException hehehe if i use this class: tyrex.jdbc.xa.EnabledDataSource instead javax.sql.DataSource the program works fine the problem is that EnableDataSource implements javax.sql.DataSource but i can't cast javax.sql.DataSource. why ??? Would you happen to have a copy of jdbc2_0-stdext.jar in your system extensions directory ($JAVA_HOME/jre/lib/ext)? That would cause problems like this -- the same sort of problem that causes Class foo is not a servlet errors if you have servlet.jar there. Alessandro Craig McClanahan - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) 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:243) 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:215) 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.StandardContext.invoke(StandardContext.java:2366) 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:462) 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 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1098 ) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
RE: ClassCastException
I had exactly this problem; but I had jdbc2_0-stdext.jar not in the jre/lib/ext but in my webapp/web-inf/lib directory. Putting jdbc2_0-stdext.jar in common/lib along with the tyrex files solved the problem (classloaders, you gotta love 'em) Kevin Jones Developmentor www.develop.com -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: 03 October 2001 17:20 To: [EMAIL PROTECTED] Subject: Re: ClassCastException On Wed, 3 Oct 2001, Alessandro Pizzolotto wrote: Date: Wed, 3 Oct 2001 17:10:37 +0200 From: Alessandro Pizzolotto [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ClassCastException hehehe if i use this class: tyrex.jdbc.xa.EnabledDataSource instead javax.sql.DataSource the program works fine the problem is that EnableDataSource implements javax.sql.DataSource but i can't cast javax.sql.DataSource. why ??? Would you happen to have a copy of jdbc2_0-stdext.jar in your system extensions directory ($JAVA_HOME/jre/lib/ext)? That would cause problems like this -- the same sort of problem that causes Class foo is not a servlet errors if you have servlet.jar there. Alessandro Craig McClanahan - Original Message - From: Will Stranathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 3:04 PM Subject: Re: ClassCastException Can we see the appropriate parts of server.xml and web.xml? Will Stranathan Alessandro Pizzolotto wrote: this code javax.naming.Context ctx = new javax.naming.InitialContext(); javax.naming.Context cto = (javax.naming.Context)ctx.lookup(java:/comp/env); javax.sql.DataSource ds = (javax.sql.DataSource)cto.lookup(jdbc/domus); produce this error java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource at org.apache.jsp.ricerca3$jsp._jspService(ricerca3$jsp.java:74) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Jsp Servlet.ja va:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A pplication FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati onFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp erValve.ja va:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel ine.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(StandardConte xtValve.ja va:215) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel ine.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.StandardContext.invoke(StandardContext.java:2366) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv e.java:164 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel ine.java:5 66) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel ine.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(StandardEngine Valve.java :163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipel ine.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.connector.http.HttpProcessor.process(HttpProce ssor.java: 1005) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor .java:1098 ) at java.lang.Thread.run(Thread.java:484) the code not get the cast in DataSource why ? tanks Alessadro
DO NOT REPLY [Bug 3939] - HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3939. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3939 HttpServletResponse.SC_UNAUTHORIZED incorrectly trapped by Tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 10:45 --- It looks extremely likely this problem would be caused by bug 3823 (your auth challenge would get cleared). Note that in the servlet model, the auth layer is supposed to be handled by the container. *** This bug has been marked as a duplicate of 3823 ***
DO NOT REPLY [Bug 3823] - sendError and setStatus clear headers already set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3823 sendError and setStatus clear headers already set [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 10:45 --- *** Bug 3939 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 3941] - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941 PrinWriter.flush() HttpServletResponse.flushBuffer() do not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 10:56 --- This works for me (HEAD branch + hacked HelloWorld servlet + IE). Both writer.flush() and response.flushBuffer() work properly.
DO NOT REPLY [Bug 3941] - PrinWriter.flush() HttpServletResponse.flushBuffer() do not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3941 PrinWriter.flush() HttpServletResponse.flushBuffer() do not work --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 11:03 --- Works for me as well. I would also add that your testing methodology is suspect, because the *client* is buffering things (inside the buffered reader) as well. To accurately test this servlet, you should connect with a browser (but change the content type to text/plain so the browser does not buffer things), or connect directly to Tomcat with a Telnet connection.
DO NOT REPLY [Bug 3839] - Problem bookmarking login page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 11:15 --- It is not valid to bookmark the form-based login page. You should consider that page to be part of the *container*, not part of the *application*. Users should be trained to bookmark the page they really want to see -- exactly as if you were using BASIC authentication instead. The login page will be presented by the container if necessary (i.e. if the user is not currently authenticated). Even if you figure out a way to do this that works in one servlet container, it is pretty much guaranteed not to be portable to any other.
Re: Rebinding Resolved Objects
The nightly build is based on the HEAD branch, correct? Doing a lookup on the same element produces different hashCode() results. Also, does the JDBC driver have to support something specific in order for Tyrex to pool it correctly? Even when I get the same DataSource every time, it still creates new connections on every single request. Thanks, Will Stranathan On Tue, 2 Oct 2001 11:44:32 -0700 Remy Maucherat [EMAIL PROTECTED] wrote: The HEAD branch should now rebind. Remy
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler Parser.java
kinman 01/10/03 12:26:47
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch Parser.java
Log:
PR: Bugzilla 3845
Revision ChangesPath
No revision
No revision
1.13.2.2 +8 -8
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.13.2.1
retrieving revision 1.13.2.2
diff -u -r1.13.2.1 -r1.13.2.2
--- Parser.java 2001/09/20 21:50:58 1.13.2.1
+++ Parser.java 2001/10/03 19:26:47 1.13.2.2
@@ -834,20 +834,16 @@
- if (reader.matches(CLOSE_1)
- || bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) {
- if (reader.matches(CLOSE_1))
- reader.advance(CLOSE_1.length());
- else
- throw new ParseException(start, Body is supposed to be empty for
+tag);
-
- listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
+ if (reader.matches(CLOSE_1)) {
+ reader.advance(CLOSE_1.length());
+ listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
listener.handleTagBegin(start, reader.mark(), attrs, prefix,
shortTagName, tli, ti, true);
listener.handleTagEnd(start, reader.mark(), prefix,
shortTagName, attrs, tli, ti, true);
} else {
// Body can be either
+ // - empty
// - JSP tags
// - tag dependent stuff
if (reader.matches(CLOSE)) {
@@ -861,12 +857,16 @@
if (bodyStop != null) {
String bodyString = new String(reader.getChars(bodyStart,
bodyStop));
hasBody = (bodyString.length() 0);
+ if (hasBody
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY))
+ throw new ParseException(start,
+ Body is supposed to be empty for +tag);
}
reader.reset(bodyStart);
listener.handleTagBegin(start, bodyStart, attrs, prefix,
shortTagName, tli, ti, hasBody);
if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT) ||
+ bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY) ||
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_JSP))
{
// Parse until the end of the tag body.
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler Parser.java
kinman 01/10/03 12:29:28
Modified:jasper/src/share/org/apache/jasper/compiler Parser.java
Log:
PR: Bugzilla 3845
Revision ChangesPath
1.15 +8 -8
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Parser.java 2001/09/20 21:47:32 1.14
+++ Parser.java 2001/10/03 19:29:28 1.15
@@ -834,20 +834,16 @@
- if (reader.matches(CLOSE_1)
- || bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) {
- if (reader.matches(CLOSE_1))
- reader.advance(CLOSE_1.length());
- else
- throw new ParseException(start, Body is supposed to be empty for
+tag);
-
- listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
+ if (reader.matches(CLOSE_1)) {
+ reader.advance(CLOSE_1.length());
+ listener.setTemplateInfo(parser.tmplStart, parser.tmplStop);
listener.handleTagBegin(start, reader.mark(), attrs, prefix,
shortTagName, tli, ti, true);
listener.handleTagEnd(start, reader.mark(), prefix,
shortTagName, attrs, tli, ti, true);
} else {
// Body can be either
+ // - empty
// - JSP tags
// - tag dependent stuff
if (reader.matches(CLOSE)) {
@@ -861,12 +857,16 @@
if (bodyStop != null) {
String bodyString = new String(reader.getChars(bodyStart,
bodyStop));
hasBody = (bodyString.length() 0);
+ if (hasBody
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY))
+ throw new ParseException(start,
+ Body is supposed to be empty for +tag);
}
reader.reset(bodyStart);
listener.handleTagBegin(start, bodyStart, attrs, prefix,
shortTagName, tli, ti, hasBody);
if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT) ||
+ bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY) ||
bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_JSP))
{
// Parse until the end of the tag body.
DO NOT REPLY [Bug 3845] - Body content is supposed to be empty
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3845 Body content is supposed to be empty [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 12:32 --- Fixed in nightly build 20011003
DO NOT REPLY [Bug 3949] New: - Document with content-length of 0 results in resend headers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3949 Document with content-length of 0 results in resend headers Summary: Document with content-length of 0 results in resend headers Product: Tomcat 4 Version: 4.0 Release Candidate 2 Platform: Sun OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] When Tomcat reaches the idle timeout on a persistent connection it seems to return an additional HTTP response just prior to closing the connection. Observed with telnet :- % telnet tomcat 8080 Trying 10.5.21.109... Connected to tomcat. Escape character is '^]'. GET /JAXPREP/familytree.dtd HTTP/1.1 HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 0 Date: Mon, 01 Oct 2001 12:07:13 GMT Server: Apache Tomcat/4.0-rc2 (HTTP/1.1 Connector) Last-Modified: Thu, 20 Sep 2001 23:02:56 GMT ETag: 0-1001026976000 delay for 60 seconds HTTP/1.1 200 OK Content-Length: 0 Date: Mon, 01 Oct 2001 12:08:13 GMT Server: Apache Tomcat/4.0-rc2 (HTTP/1.1 Connector) Connection closed by foreign host.
cvs commit: jakarta-tomcat-4.0/tester build.xml
craigmcc01/10/03 14:39:12
Modified:.build.xml
catalina build.xml
catalina/src/share/org/apache/catalina/startup
Bootstrap.java BootstrapService.java
jasper build.xml
tester build.xml
Log:
Update the build processes (and initial class loader setup):
* Old $CATALINA_HOME/classes is now $CATALINA_HOME/shared/classes
* Old $CATALINA_HOME/lib is now $CATALINA_HOME/shared/lib
Revision ChangesPath
1.44 +24 -11jakarta-tomcat-4.0/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- build.xml 2001/10/02 23:48:24 1.43
+++ build.xml 2001/10/03 21:39:11 1.44
@@ -94,16 +94,16 @@
target name=dist-prepare
mkdir dir=${tomcat.dist}/
mkdir dir=${tomcat.dist}/bin/
-mkdir dir=${tomcat.dist}/classes/
mkdir dir=${tomcat.dist}/common/
mkdir dir=${tomcat.dist}/common/classes/
mkdir dir=${tomcat.dist}/common/lib/
mkdir dir=${tomcat.dist}/conf/
-mkdir dir=${tomcat.dist}/lib/
mkdir dir=${tomcat.dist}/logs/
mkdir dir=${tomcat.dist}/server/
mkdir dir=${tomcat.dist}/server/classes/
mkdir dir=${tomcat.dist}/server/lib/
+mkdir dir=${tomcat.dist}/shared/classes/
+mkdir dir=${tomcat.dist}/shared/lib/
mkdir dir=${tomcat.dist}/webapps/
mkdir dir=${tomcat.dist}/work/
/target
@@ -112,6 +112,7 @@
!-- == DIST: Copy Static Files = --
target name=dist-static depends=dist-prepare
+!-- Copy the top-level documentation files --
copy todir=${tomcat.dist}
fileset dir=.
include name=LICENSE/
@@ -123,24 +124,39 @@
/fileset
/copy
+!-- Copy the contents of each build directory --
copy todir=${tomcat.dist}/bin
fileset dir=${tomcat.build}/bin /
/copy
-copy todir=${tomcat.dist}/conf
- fileset dir=${tomcat.build}/conf /
+copy todir=${tomcat.dist}/common/classes
+ fileset dir=${tomcat.build}/common/classes /
/copy
copy todir=${tomcat.dist}/common/lib
fileset dir=${tomcat.build}/common/lib /
/copy
-copy todir=${tomcat.dist}/lib
- fileset dir=${tomcat.build}/lib /
+copy todir=${tomcat.dist}/conf
+ fileset dir=${tomcat.build}/conf /
/copy
+copy todir=${tomcat.dist}/server/classes
+ fileset dir=${tomcat.build}/server/classes /
+/copy
copy todir=${tomcat.dist}/server/lib
fileset dir=${tomcat.build}/server/lib /
+/copy
+copy todir=${tomcat.dist}/shared/classes
+ fileset dir=${tomcat.build}/shared/classes /
+/copy
+copy todir=${tomcat.dist}/shared/lib
+ fileset dir=${tomcat.build}/shared/lib /
/copy
-fixcrlf srcdir=${tomcat.dist}/bin includes=*.sh eol=lf/
+copy todir=${tomcat.dist}/webapps
+ fileset dir=${tomcat.build}/webapps /
+/copy
+
+!-- Correct permissions and line endings on bin scripts --
+fixcrlf srcdir=${tomcat.dist}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${tomcat.dist}/bin includes=*.bat eol=crlf/
-chmod dir=${tomcat.dist}/bin includes=*.sh perm=+x/
+chmod dir=${tomcat.dist}/bin includes=*.sh perm=+x/
/target
@@ -179,9 +195,6 @@
!-- == DIST: Create Archives === --
target name=dist depends=deploy,dist-static,dist-javadoc
description=Create binary distribution
-copy todir=${tomcat.dist}/webapps
- fileset dir=${tomcat.build}/webapps /
-/copy
/target
1.73 +59 -39jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- build.xml 2001/10/02 23:20:43 1.72
+++ build.xml 2001/10/03 21:39:11 1.73
@@ -35,7 +35,7 @@
pathelement location=${servlet.jar}/
pathelement location=${tyrex.jar}/
pathelement location=${xerces.jar}/
-pathelement location=${catalina.build}/classes/
+pathelement location=${catalina.build}/server/classes/
/path
!-- Construct unit tests classpath --
@@ -55,7 +55,7 @@
pathelement location=${servlet.jar}/
pathelement location=${tyrex.jar}/
pathelement location=${xerces.jar}/
-pathelement location=${catalina.build}/classes/
+pathelement location=${catalina.build}/server/classes/
pathelement location=${catalina.build}/tests/
/path
@@ -377,15 +377,15 @@
mkdir
DO NOT REPLY [Bug 3944] - request.getRemoteAddr() always returning 127.0.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3944. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3944 request.getRemoteAddr() always returning 127.0.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources messages.properties messages_ja.properties
kinman 01/10/03 14:48:31
Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
jasper/src/share/org/apache/jasper/servlet JspServlet.java
jasper/src/share/org/apache/jasper/resources
messages.properties messages_ja.properties
Added: jasper/src/share/org/apache/jasper JasperError.java
Log:
PR: 3667, 3669
All messages from all validators in tag libraries are now displayed,
without throwing an exception that causes the stack trace to be printed.
Revision ChangesPath
1.1
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java
Index: JasperError.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper;
/**
* Errors generated by the JSP engine. It differs from JasperException in
* that it does not print stack trace.
*
* @author Kin-man Chung
*/
public class JasperError extends org.apache.jasper.JasperException {
public JasperError(String reason) {
super(reason);
}
}
1.34 +21 -10
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JspParseEventListener.java2001/07/25 01:08:13 1.33
+++ JspParseEventListener.java2001/10/03 21:48:30 1.34
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.33 2001/07/25 01:08:13 craigmcc Exp $
- * $Revision: 1.33 $
- * $Date: 2001/07/25 01:08:13 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.34 2001/10/03 21:48:30 kinman Exp $
+ * $Revision: 1.34 $
+ * $Date: 2001/10/03 21:48:30 $
*
*
*
@@ -78,10 +78,10 @@
import
DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884 SingleThreadModel servlets not pooled results in low performance --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 14:55 --- I'll just add a bit of text from JSDK 2.0 (a.k.a. Servlet API 2.0) in regards to SingleThreadModel: -- In essence, if the servlet implements this interface, the servlet will be thread safe. -- I have started at around that time with JServ and life was wonderful. All I needed to do was to implement SingleThreadModel and not worry about anything else ever again. Right? That's where the whole thing with SingleThreadModel is actually wrong. It gives people a false promise of something that is far more complicated than implementing one interface. Java already has threading support, no need to reinvent. After thinking about all the implications that people mentioned related to SingleThreadModel, I agree with Jon - it was a bad idea in the first place (although I didn't get it for some time Jon :-) As for pool support, let me quote JSDK 2.0 again: -- This guarantee is ensured by maintaining a pool of servlet instances for each such servlet, and dispatching each service call to a free servlet. -- And compare that to Servlet API 2.2: -- The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet. -- I think someone out there realized that the pool thing does not solve the actual problem of thread safety, complicates the code and increases the memory usage of the container, so they said: let's make it simple. It does seem like someone was sending a message to container providers, doesn't it? My point here is: I also have code relying on SingleThreadModel, and I'll have to rewrite. But I think it's time well spent.
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
kinman 01/10/03 15:00:35
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch JspParseEventListener.java
jasper/src/share/org/apache/jasper/resources Tag:
tomcat_40_branch messages.properties
messages_ja.properties
jasper/src/share/org/apache/jasper/servlet Tag:
tomcat_40_branch JspServlet.java
Added: jasper/src/share/org/apache/jasper Tag: tomcat_40_branch
JasperError.java
Log:
PR: 3667, 3669
All messages from all validators in tag libraries are now displayed,
without throwing an exception that causes the stack trace to be printed.
Revision ChangesPath
No revision
No revision
1.1.2.1 +0 -0
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java
Index: JasperError.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JasperError.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
No revision
No revision
1.33.2.1 +21 -10
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.33
retrieving revision 1.33.2.1
diff -u -r1.33 -r1.33.2.1
--- JspParseEventListener.java2001/07/25 01:08:13 1.33
+++ JspParseEventListener.java2001/10/03 22:00:33 1.33.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.33 2001/07/25 01:08:13 craigmcc Exp $
- * $Revision: 1.33 $
- * $Date: 2001/07/25 01:08:13 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.33.2.1 2001/10/03 22:00:33 kinman Exp $
+ * $Revision: 1.33.2.1 $
+ * $Date: 2001/10/03 22:00:33 $
*
*
*
@@ -78,10 +78,10 @@
import javax.servlet.jsp.tagext.TagLibraryInfo;
import javax.servlet.jsp.tagext.ValidationMessage;
+import org.apache.jasper.JasperError;
import org.apache.jasper.JasperException;
import org.apache.jasper.Constants;
import org.apache.jasper.JspCompilationContext;
-
import org.apache.jasper.logging.Logger;
import org.xml.sax.Attributes;
@@ -1114,7 +1114,9 @@
* libraries used by the document.
*/
public void validate() throws JasperException {
+ StringBuffer errMessage = new StringBuffer();
Enumeration enum = libraries.getTagLibInfos();
+boolean hasErrors = false;
while (enum.hasMoreElements()) {
TagLibraryInfo tli = (TagLibraryInfo)enum.nextElement();
//@@@ remove cast when TagLibraryInfo is fixed in spec
@@ -1122,14 +1124,23 @@
ValidationMessage[] errors =
((TagLibraryInfoImpl)tli).validate(xo.getPageData());
if ((errors != null) (errors.length != 0)) {
- // for now just report the first error!
- String msg = errors[0].getMessage();
-throw new JasperException(
- Constants.getString(
-jsp.error.taglibraryvalidator.invalidpage,
- new Object[]{tli.getShortName(), msg}));
+hasErrors = true;
+errMessage.append(h3);
+errMessage.append(Constants.getString(
+ jsp.error.taglibraryvalidator.invalidpage,
+ new Object[]{tli.getShortName()}));
+errMessage.append(/h3);
+for (int i = 0; i errors.length; i++) {
+errMessage.append(p);
+errMessage.append(errors[i].getId());
+errMessage.append(: );
+errMessage.append(errors[i].getMessage());
+errMessage.append(/p);
+}
}
}
+ if (hasErrors)
+throw new JasperError(errMessage.toString());
}
/**
No revision
No revision
1.20.2.1 +2 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
DO NOT REPLY [Bug 3953] New: - If context is listed in server.xml then webapp servlets are loaded twice....
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953 If context is listed in server.xml then webapp servlets are loaded twice Summary: If context is listed in server.xml then webapp servlets are loaded twice Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems that if a context is listed in server.xml Example: Context path= docBase=rewards debug=0 reloadable=true/ Then my servlets that get loaded on startup as defined in the web.xml for the webapp get loaded twice. Thanks for looking into this. -Mike
DO NOT REPLY [Bug 3669] - Improve Jasper error reporting (stack traces)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3669 Improve Jasper error reporting (stack traces) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:05 --- Fixed with nightly build 20011003
DO NOT REPLY [Bug 3667] - Only one ValidationMessage processed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3667 Only one ValidationMessage processed [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:07 --- Fixed with nightly build 20011003
DO NOT REPLY [Bug 3839] - Problem bookmarking login page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 14:11 --- ohh, come on, you are saying the solution is to fix the people who use your web application. What am I supposed to do, put in the login page something like this:Do not bookmark this page, consider it a part of the *container*, not part of the *application* Some of the users don't even know there is such thing as a container, and I don't see a reason why they should know.I don't see why the users should be instructed at all.Well, that really does not make it transparent for the users. I used to use weblogic and they had the same problem. They did change it to go to the default page in the web application after we contacted support.Plus the page IS part of the application, it has to be placed inside the war file, it is different for every web application, it has to be specified inside web.xml which is part of the standard. Exactly what part of the servlet standard is broken by fixing this?What good is the default page for the web application if it doesn't get shown by default?
DO NOT REPLY [Bug 3953] - If context is listed in server.xml then webapp servlets are loaded twice....
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953 If context is listed in server.xml then webapp servlets are loaded twice --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:14 --- Can you provide a web app that illustrates this? The reason I ask is that the examples web app included with Tomcat is set up exactly this way, but the load-on-startup servlets are executed only once.
DO NOT REPLY [Bug 3892] - Can't compile 2092.jsp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3892. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3892 Can't compile 2092.jsp [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Component|Unknown |Jasper
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java
mmanders01/10/03 15:13:45
Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
Log:
Fix Bug #3944 request.getRemoteAddr() alays returning 127.0.0.1
Bug report from Alessandro Polverini
Since the base Request object set remoteAddr and remoteHost to defaults,
the checks around setting them off of the real request always succeed so the
real values are never used. Added calls to recycle these in the constructor.
This still allows for delayed setting, since the calls to set the values can be
expensive.
Revision ChangesPath
1.26 +4 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
Index: Http10Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Http10Interceptor.java2001/09/22 22:05:31 1.25
+++ Http10Interceptor.java2001/10/03 22:13:45 1.26
@@ -209,6 +209,10 @@
public HttpRequest() {
super();
+
+// recycle these to remove the defaults
+remoteAddrMB.recycle();
+remoteHostMB.recycle();
}
public Object getAttribute(String name) {
if (name.equals(javax.servlet.request.X509Certificate)) {
DO NOT REPLY [Bug 3839] - Problem bookmarking login page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:23 --- The fact that you hd the same problems under WebLogic also should have given you a hint that you might be mis-using this functionality :-). Although the form login page (and form error page) are physically contained in your web application archive, they should not be hyperlinked to by any of your app's pages. Most particularly, it should *not* be your welcome page. If you (temporarily) switch your app to use BASIC authentication instead, it should still work correctly - and there is no possibility to bookmark the login page because there is no such thing. If your app doesn't work in this scenario, then you should modify it so that it can. If you don't, then you're going to be dependent on non-portable behavior of whatever container vendor happens to allow this technique to work - the spec doesn't require it.
cvs commit: jakarta-tomcat-4.0/catalina build.xml
craigmcc01/10/03 15:59:43
Modified:catalina build.xml
Log:
Do not copy the server classes twice (once unpacked and once packed).
Revision ChangesPath
1.74 +0 -9 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.73
retrieving revision 1.74
diff -u -r1.73 -r1.74
--- build.xml 2001/10/03 21:39:11 1.73
+++ build.xml 2001/10/03 22:59:43 1.74
@@ -631,9 +631,6 @@
chmod perm=+x file=${catalina.deploy}/bin/shutdown.sh/
!-- Common Extensions --
-copy todir=${catalina.deploy}/common/classes
- fileset dir=${catalina.build}/common/classes /
-/copy
copy todir=${catalina.deploy}/common/lib
fileset dir=${catalina.build}/common/lib /
/copy
@@ -644,17 +641,11 @@
/copy
!-- Server Components --
-copy todir=${catalina.deploy}/server/classes
- fileset dir=${catalina.build}/server/classes /
-/copy
copy todir=${catalina.deploy}/server/lib
fileset dir=${catalina.build}/server/lib /
/copy
!-- Shared Extensions --
-copy todir=${catalina.deploy}/shared/classes
- fileset dir=${catalina.build}/shared/classes /
-/copy
copy todir=${catalina.deploy}/shared/lib
fileset dir=${catalina.build}/shared/lib /
/copy
cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.1.txt
remm01/10/03 16:05:01 Added: .Tag: tomcat_40_branch RELEASE-PLAN-4.0.1.txt Log: - Add release plan for Tomcat 4.0.1. - Note: I don't think release plans are needed for maintenance releases, and it will be mainly used to keep track of must-fix issues. There will be a lazy vote for the beta, and a vote for the release. I'll act as the release manager for this release (unless someone disagrees). - Comments welcome. Revision ChangesPath No revision No revision 1.1.2.1 +99 -0 jakarta-tomcat-4.0/Attic/RELEASE-PLAN-4.0.1.txt
cvs commit: jakarta-tomcat-site/xdocs index.xml
craigmcc01/10/03 16:15:43 Modified:docs index.html xdocsindex.xml Log: Tweak the wording slightly to reflect the actual reality. Revision ChangesPath 1.10 +3 -1 jakarta-tomcat-site/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- index.html2001/09/18 03:01:51 1.9 +++ index.html2001/10/03 23:15:43 1.10 @@ -107,7 +107,9 @@ /td/tr trtd blockquote -pTomcat is the official Reference Implementation for the a href=http://java.sun.com/products/servlets;Java Servlet/a and a href=http://java.sun.com/products/jsp;JavaServer Pages/a technologies. +pTomcat is the servlet container that is used in the official +Reference Implementation for the +a href=http://java.sun.com/products/servlets;Java Servlet/a and a href=http://java.sun.com/products/jsp;JavaServer Pages/a technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the a href=http://java.sun.com/aboutJava/communityprocess/;Java Community Process/a. /p 1.9 +3 -2 jakarta-tomcat-site/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 2001/09/18 03:01:51 1.8 +++ index.xml 2001/10/03 23:15:43 1.9 @@ -10,8 +10,9 @@ section name=Jakarta Tomcat -pTomcat is the official Reference Implementation for the a -href=http://java.sun.com/products/servlets;Java Servlet/a and a +pTomcat is the servlet container that is used in the official +Reference Implementation for the +a href=http://java.sun.com/products/servlets;Java Servlet/a and a href=http://java.sun.com/products/jsp;JavaServer Pages/a technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the a href=http://java.sun.com/aboutJava/communityprocess/;Java
RE: Bug 3888/Class Loader Stopped
I noticed there were comments saying that it's hard to replicate. I get it pretty regularly, but the trick seems to be that it only occurs for me once I reload a context. Then pretty much my first servlet request generates this error. I couldn't figure out how to add a note to a bug in Bugzilla, so I figured I would post it here. HTH, -Mike
Re: Bug 3888/Class Loader Stopped
I noticed there were comments saying that it's hard to replicate. I get it pretty regularly, but the trick seems to be that it only occurs for me once I reload a context. Then pretty much my first servlet request generates this error. I couldn't figure out how to add a note to a bug in Bugzilla, so I figured I would post it here. And do you have a test case ? It never happened to me using the 'examples' context (which I use for testing). Remy
DO NOT REPLY [Bug 3953] - If context is listed in server.xml then webapp servlets are loaded twice....
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3953 If context is listed in server.xml then webapp servlets are loaded twice --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 16:25 --- Well, it's rather large, but the webapp that's displaying this that I'm using is the expresso4ea application. http://www.jcorporate.com/components/internal/projframe.jsp?category=65 Is where it can be downloaded. [Although the good news is that if you modify the server.xml file after you download things you'll get the results I'm talking about right away :-) ] I'm afraid I don't really develop outside this framework, so I don't really have any independent examples. Also the weird thing on my end is that if I set debugger breakpoints corresponding to the messages I see scrolling through the console, things only stop at the breakpoints once. [Even though I see the appropriate message twice]. BUT if I stop at the breakpoint, continue on, and wait until I see all the initialization messages and then pause the debugger I can be stepping through the code that I expect to be hitting twice. [I'm using Jbuilder 4 Pro, Jdk 1.3.0] HTH, -Mike
THANKS
I've been working with TC4.0, installing and configuring, for the past week, and I just want to say to the active developers on this list: THANK YOU This is a beautifully functional, beautifully documented, really slick piece of work. Y'all are GREAT.
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java
kinman 01/10/03 16:43:22
Modified:jasper/src/share/org/apache/jasper/compiler JspCompiler.java
Log:
PR: Bugzilla 3892
If the name of the .jsp file does not start with a legal Java identifier
letter, prepend the generated class name with a '$' to make it a legal
Java id name.
Revision ChangesPath
1.8 +5 -0
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
Index: JspCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JspCompiler.java 2001/09/07 22:51:26 1.7
+++ JspCompiler.java 2001/10/03 23:43:22 1.8
@@ -132,6 +132,11 @@
int iSep = jsp.lastIndexOf('/') + 1;
int iEnd = jsp.length();
StringBuffer modifiedClassName = new StringBuffer(jsp.length() - iSep);
+ if (!Character.isJavaIdentifierStart(jsp.charAt(iSep))) {
+ // If the first char is not a legal Java letter or digit,
+ // prepend a '$'.
+ modifiedClassName.append('$');
+ }
for (int i = iSep; i iEnd; i++) {
char ch = jsp.charAt(i);
if (Character.isLetterOrDigit(ch))
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java
kinman 01/10/03 16:45:02
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch JspCompiler.java
Log:
PR: Bugzilla 3892
If the name of a .jsp file does not start with a legal Java identifier
letter, prepend the generated class name with a '$' to make it a legal
Java id name.
Revision ChangesPath
No revision
No revision
1.7.2.1 +5 -0
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
Index: JspCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- JspCompiler.java 2001/09/07 22:51:26 1.7
+++ JspCompiler.java 2001/10/03 23:45:02 1.7.2.1
@@ -132,6 +132,11 @@
int iSep = jsp.lastIndexOf('/') + 1;
int iEnd = jsp.length();
StringBuffer modifiedClassName = new StringBuffer(jsp.length() - iSep);
+ if (!Character.isJavaIdentifierStart(jsp.charAt(iSep))) {
+ // If the first char is not a legal Java letter or digit,
+ // prepend a '$'.
+ modifiedClassName.append('$');
+ }
for (int i = iSep; i iEnd; i++) {
char ch = jsp.charAt(i);
if (Character.isLetterOrDigit(ch))
[half-off-topic] Java Compilers
Hi, First, I'm sorry for being off-topic, but I have no idea where it would be on-topic, so I write it here. Besides, at least some of you will be interested. I'm starting another project - run-time compiled java, which I would like to develop into stable beta and then donate to ASF. There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. I'm sure you see the similarity to .JSP now. While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. Greetings, deacon Marcus p.s. Is it ok for me to use org.apache.jjc (or org.apache. whatever) before I officialy donate it, assuming I won't be distributing it before donating anyway?
Re: [half-off-topic] Java Compilers
Hi, On Thu, 4 Oct 2001, Deacon Marcus wrote: There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. so you're talking about generating java source code, and compiling it on the fly? I'm sure you see the similarity to .JSP now. if my interpretation is correct, yes (o: While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. Short of searching google, which I'm sure you're already doing I cant help you there. What I can suggest though, is for source code generation, a project called Jenesis (http://www.inxar.org) which provides a nice API based on the Java Language spec. cheers dim
DO NOT REPLY [Bug 3822] - Drive letter causes a NumberFormatException when JSP compiler parses errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3822 Drive letter causes a NumberFormatException when JSP compiler parses errors [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 18:16 --- Can you attach a test case that causes this problem? I am not quite sure what you meant by the extra colon. Are you referring to the colon after the drive (such as D:)? That was being taken care of. All my tests ran as expected.
RE: [half-off-topic] Java Compilers
Hi, From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 2:35 AM To: [EMAIL PROTECTED] Subject: Re: [half-off-topic] Java Compilers Hi, On Thu, 4 Oct 2001, Deacon Marcus wrote: There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. so you're talking about generating java source code, and compiling it on the fly? Exactly. I'm coding it right now - looks like CompileContext is enough - I'll post when I finish of course. I'm sure you see the similarity to .JSP now. if my interpretation is correct, yes (o: While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. Short of searching google, which I'm sure you're already doing I cant help you there. What I can suggest though, is for source code generation, a project called Jenesis (http://www.inxar.org) which provides a nice API based on the Java Language spec. Generating source is out of scope of this project. I need it mainly for the complicated configs etc - no point in generating structure out of xml which is then analyzed everytime when you can compile it into bytecode. I'm sure it's possible to do xml-config to java-source transformation in xsl, but I don't like it personally, so I'll leave it to someone else. cheers dim Greetings, deacon Marcus ~ HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting, please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
tools.jar, javac and JDK 1.4b2
Hi, Are there any actions taken to convince Sun to leave tools.jar and javac as they were in JDK 1.4b1 and before? JDK 1.4 is still beta 2, so it's not too late for that, right? Greetings, deacon Marcus ~ HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting, please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
Train the user not to do that is a cop out. If an application doesn't work the way users expect, it's a problem with the application, not the user. That's usability 101. If the user shouldn't bookmark the login page, they shouldn't ever be exposed to the URI for the login page. That makes it impossible to bookmark. The only URI that the user should see is the URI for the protected resource. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 6:23 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 3839] - Problem bookmarking login page DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:23 --- The fact that you hd the same problems under WebLogic also should have given you a hint that you might be mis-using this functionality :-). Although the form login page (and form error page) are physically contained in your web application archive, they should not be hyperlinked to by any of your app's pages. Most particularly, it should *not* be your welcome page. If you (temporarily) switch your app to use BASIC authentication instead, it should still work correctly - and there is no possibility to bookmark the login page because there is no such thing. If your app doesn't work in this scenario, then you should modify it so that it can. If you don't, then you're going to be dependent on non-portable behavior of whatever container vendor happens to allow this technique to work - the spec doesn't require it. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: [half-off-topic] Java Compilers
If you haven't seen it already, there's an article on the Swing Connection on creating dynamic event listeners or some such which seems to have been the basis for the Dynamic Proxy support in JDK 1.3. It has source code for generating classes on the fly that implement arbitrary interfaces, including some generic routines for writing useful bits of bytecode. If your goals are limited enough in scope, you may want to skip the source code and just spew out bytecode directly based on the XML file you're reading. Also, I have JDK 1.2 implementation of Dynamic Proxies that you're welcome to look at, based on the aforementioned article. Aaron On Thu, 4 Oct 2001, Deacon Marcus wrote: Hi, From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 2:35 AM To: [EMAIL PROTECTED] Subject: Re: [half-off-topic] Java Compilers Hi, On Thu, 4 Oct 2001, Deacon Marcus wrote: There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. so you're talking about generating java source code, and compiling it on the fly? Exactly. I'm coding it right now - looks like CompileContext is enough - I'll post when I finish of course. I'm sure you see the similarity to .JSP now. if my interpretation is correct, yes (o: While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. Short of searching google, which I'm sure you're already doing I cant help you there. What I can suggest though, is for source code generation, a project called Jenesis (http://www.inxar.org) which provides a nice API based on the Java Language spec. Generating source is out of scope of this project. I need it mainly for the complicated configs etc - no point in generating structure out of xml which is then analyzed everytime when you can compile it into bytecode. I'm sure it's possible to do xml-config to java-source transformation in xsl, but I don't like it personally, so I'll leave it to someone else. cheers dim Greetings, deacon Marcus ~ HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting, please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form based authentication: Pages: /login/login.vm -- login page /login/error.vm -- error page /login/index.vm -- default index page If someone goes to /login/login.vm directly and gets authenticated, the page /login/index.vm gets displayed, which can then do whatever it wants (ie. redirect somewhere else, display error, content etc.) The pages I use are Velocity pages, but I don't think that JSP would be any different. Bojan Steve Downey wrote: Train the user not to do that is a cop out. If an application doesn't work the way users expect, it's a problem with the application, not the user. That's usability 101. If the user shouldn't bookmark the login page, they shouldn't ever be exposed to the URI for the login page. That makes it impossible to bookmark. The only URI that the user should see is the URI for the protected resource.
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
billbarker01/10/03 19:20:04
Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
Log:
Remove validity checks from where the spec doesn't require them.
This fixes Bug #3920 submitted by Alessandro Polverini [EMAIL PROTECTED]
Revision ChangesPath
1.17 +0 -3
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
Index: HttpSessionFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- HttpSessionFacade.java2001/09/23 00:24:52 1.16
+++ HttpSessionFacade.java2001/10/04 02:20:04 1.17
@@ -113,7 +113,6 @@
// public facade
public String getId() {
- checkValid();
return realSession.getId().toString();
}
@@ -140,7 +139,6 @@
}
public long getLastAccessedTime() {
- checkValid();
return realSession.getTimeStamp().getLastAccessedTime();
}
@@ -295,7 +293,6 @@
}
public int getMaxInactiveInterval() {
- checkValid();
// We use long because it's better to do /1000 here than
// every time the internal code does expire
return (int)realSession.getTimeStamp().getMaxInactiveInterval()/1000;
DO NOT REPLY [Bug 3920] - HttpSessionBindingListener partially working for session expiration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3920. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3920 HttpSessionBindingListener partially working for session expiration [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 19:24 --- This is now fixed in the latest CVS. Note that the session is still invalid, so get/setAttribute will still fail. However getId will work.
Re: tools.jar, javac and JDK 1.4b2
On Thu, 4 Oct 2001, Deacon Marcus wrote: Date: Thu, 4 Oct 2001 03:43:35 +0200 From: Deacon Marcus [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: tools.jar, javac and JDK 1.4b2 Hi, Are there any actions taken to convince Sun to leave tools.jar and javac as they were in JDK 1.4b1 and before? JDK 1.4 is still beta 2, so it's not too late for that, right? The original plan (of the J2SE folks) was to remove the old entry point. This has been changed - the current plan is to deprecate the old entry point (you get a warning message if you use it) but still leave it in for 1.4 final. Greetings, deacon Marcus Craig
Re: [half-off-topic] Java Compilers
On Thu, 4 Oct 2001, Deacon Marcus wrote: Date: Thu, 4 Oct 2001 01:50:53 +0200 From: Deacon Marcus [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [half-off-topic] Java Compilers Hi, First, I'm sorry for being off-topic, but I have no idea where it would be on-topic, so I write it here. Besides, at least some of you will be interested. I'm starting another project - run-time compiled java, which I would like to develop into stable beta and then donate to ASF. There would be two classes, CompileUnit and CompileContext. First, you create a CompileContext, initialize it with working dir and classpath, then you create CompileUnit, initialize it with CompileContext and a .java file. Then, you can call .prepare() or .compile() to compile the file, and .newInstance() to create an instance or .getClass() to get Class. Or you could use Class.forName(), since in most cases CompileContext's classpath would be active classpath. I'm sure you see the similarity to .JSP now. While it may seem basic, having API for this wouldn't hurt. Possible scenario: Supponse, there's some kind of mail server with *extremely* complicated rule-set in form of 200kb+ xml. Why not take it, convert it into .java implementing some interface, convert it to java source with hundreds if not more ifs and cases, and load it as compiled code. What I need: since JDK 1.4b2, tools.jar just isn't what it used to be... so I need some kind of 100% java java compiler. And, I have no idea where to search for one. Of course, there's dozens, but it must be both stable and compatible with JDK 1.1 - 1.4. A conversation on a semi-related topic is currently running on the [EMAIL PROTECTED] list, about the potential contribution of the bcel library to Jakarta. It would be quite interesting if BCEL and/or your code could be used to create the generated classes for JSP pages without going through a Java compiler. Greetings, deacon Marcus p.s. Is it ok for me to use org.apache.jjc (or org.apache. whatever) before I officialy donate it, assuming I won't be distributing it before donating anyway? It would *not* be wise to use org.apache under false pretenses. Even though you don't *intend* to distribute, it's difficult to move forward on an idea like this without showing it to some people. Also, there's no guarantee that Apache will accept it anyway -- especially if there is not already a development community built up around it. Craig
Re: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
Bojan Smojver wrote: I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form based authentication: Just to clarify here, 'my own' means in my own app, not something I've coded separately from TC. Bojan
RE: [half-off-topic] Java Compilers
Hi,
From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 3:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [half-off-topic] Java Compilers
If you haven't seen it already, there's an article on the Swing
Connection on creating dynamic event listeners or some such which seems to
Could you give me url please?
have been the basis for the Dynamic Proxy support in JDK 1.3. It has
If I'm thinking about the same thing, that's what I'm scared of - I want to
staticize things, not to make them more dynamic.
Consider the following example:
Program - let's assume it's HTTP server. The server calls cache for
RuleProcessor object, which has a single method like boolean
clientAllowed(RequestData rd). Then, Cache checks the file rules.xml - if
it was modified recently (or not read before), it's loaded, converted from
xml to source implementing the interface specifing method clientAllowed,
then compiled. Finally Server gets RuleProcessor compiled from xml file
(possibly using xsl transformation, but that's not my area). The point is,
rules.xml is interpreted, and then compiled, only after changes are
detected, then Server gets object running extremely fast compared even to
most optimized data structures.
Then again, maybe the savings aren't that much? Correct me if I'm wrong?
For example:
access-rules
access-rule
uri-mask/localonly/*/uri-mask
allow-ip1.2.3.4/allow-ip
allow-ip1.2.3.5/allow-ip
deny-all/
/access-rule
access-rule
uri-mask/*/uri-mask
deny-host*.crackers.net/deny-host
allow-all/
/access-rule
/access-rules
Could be compiled into:
public class Xxx implements RuleProcessor
{
public boolean clientAllowed(RequestData rd)
{
if( rd.getUri().startsWith(/localonly/)
{
if( rd.getIp().equals(1.2.3.4) )
{
return true;
}
//...
return false;
}
else if( rd.getUri().startsWith(/)
{
if( rd.getHost().endsWith(.crackers.net) )
{
return false;
}
return true;
}
else
{
return false;
}
}
}
I'm attaching minimalistic proof-of-concept implementation.
source code for generating classes on the fly that implement arbitrary
interfaces, including some generic routines for writing useful bits of
bytecode. If your goals are limited enough in scope, you may want to skip
the source code and just spew out bytecode directly based on the XML file
you're reading.
Also, I have JDK 1.2 implementation of Dynamic Proxies that you're
welcome to look at, based on the aforementioned article.
Aaron
Greetings, deacon Marcus
~
HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
=
On Thu, 4 Oct 2001, Deacon Marcus wrote:
Hi,
From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 2:35 AM
To: [EMAIL PROTECTED]
Subject: Re: [half-off-topic] Java Compilers
Hi,
On Thu, 4 Oct 2001, Deacon Marcus wrote:
There would be two classes, CompileUnit and CompileContext.
First, you create a CompileContext, initialize it with
working dir and
classpath, then you create CompileUnit, initialize it with
CompileContext
and a .java file. Then, you can call .prepare() or .compile()
to compile the
file, and .newInstance() to create an instance or .getClass()
to get Class.
Or you could use Class.forName(), since in most cases
CompileContext's
classpath would be active classpath.
so you're talking about generating java source code, and
compiling it on
the fly?
Exactly.
I'm coding it right now - looks like CompileContext is enough -
I'll post
when I finish of course.
I'm sure you see the similarity to .JSP now.
if my interpretation is correct, yes (o:
While it may seem basic, having API for this wouldn't hurt.
Possible scenario:
Supponse, there's some kind of mail server with *extremely*
complicated
rule-set in form of 200kb+ xml. Why not take it, convert it
into .java
implementing some interface, convert it to java source with
hundreds if not
more ifs and cases, and load it as compiled code.
What I need: since JDK 1.4b2, tools.jar just isn't what it used
to be... so
I need some kind of 100% java java compiler. And, I have no
idea where to
search for one. Of course, there's dozens, but it must be both
stable and
compatible with JDK 1.1 - 1.4.
Short of searching google, which I'm sure you're already
doing I cant help
you there. What I can suggest though, is for source code
generation, a
project called Jenesis (http://www.inxar.org) which provides
a nice API
based on the Java Language spec.
Generating source is out of scope of this project.
I need it mainly for the complicated configs etc - no point in
generating
structure out of xml which is then
RE: [half-off-topic] Java Compilers
Hi, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Craig R. McClanahan Sent: Thursday, October 04, 2001 4:42 AM To: [EMAIL PROTECTED] Subject: Re: [half-off-topic] Java Compilers [...] A conversation on a semi-related topic is currently running on the [EMAIL PROTECTED] list, about the potential contribution of the bcel library to Jakarta. Thanks, I'll take a look. It would be quite interesting if BCEL and/or your code could be used to create the generated classes for JSP pages without going through a Java compiler. Greetings, deacon Marcus p.s. Is it ok for me to use org.apache.jjc (or org.apache. whatever) before I officialy donate it, assuming I won't be distributing it before donating anyway? It would *not* be wise to use org.apache under false pretenses. Even though you don't *intend* to distribute, it's difficult to move forward on an idea like this without showing it to some people. Too bad I just did... don't sue me please :/ I'll change it next version. Also, there's no guarantee that Apache will accept it anyway -- especially if there is not already a development community built up around it. Craig Greetings, deacon Marcus
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java
remm01/10/03 20:36:50
Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
Log:
- Remove dead code.
Revision ChangesPath
1.39 +4 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
Index: HttpResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- HttpResponseBase.java 2001/09/27 00:58:38 1.38
+++ HttpResponseBase.java 2001/10/04 03:36:49 1.39
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.38 2001/09/27 00:58:38 remm Exp $
- * $Revision: 1.38 $
- * $Date: 2001/09/27 00:58:38 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.39 2001/10/04 03:36:49 remm Exp $
+ * $Revision: 1.39 $
+ * $Date: 2001/10/04 03:36:49 $
*
*
*
@@ -101,7 +101,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.38 $ $Date: 2001/09/27 00:58:38 $
+ * @version $Revision: 1.39 $ $Date: 2001/10/04 03:36:49 $
*/
public class HttpResponseBase
@@ -319,14 +319,6 @@
return (this.status);
-}
-
-
-/**
- * Recycle the facade object.
- */
-public void recycleFacade() {
-facade = new HttpResponseFacade(this);
}
[PATCH] 4 jakarta-tomcat-4.0 build.xml files
Hello,
Can someone review and commit the following 4 patches to the HEAD branch of
jakarta-tomcat-4.0?
catalina/build.xml
jasper/build.xml
tester/build.xml
webapps/build.xml
These 4 patches correct a problem when invoking ant within any of the above 4
directories. Prior to these patches, ant would create build and dist
directories in a different place than if ant was invoked in the
jakarta-tomcat-4.0 topmost directory. As a result, ant would create strange
extraneous directories like the following in the distribution:
webapps/build/examples/build/examples/build/examples
Thanks,
Patrick
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.74
diff -u -r1.74 build.xml
--- build.xml 2001/10/03 22:59:43 1.74
+++ build.xml 2001/10/04 04:39:06
@@ -11,9 +11,9 @@
!-- Build Defaults --
property name=build.compilervalue=classic/
- property name=catalina.buildvalue=build/
- property name=catalina.deploy value=../build/
- property name=catalina.dist value=dist/
+ property name=catalina.buildvalue=${basedir}/build/
+ property name=catalina.deploy value=${basedir}/../build/
+ property name=catalina.dist value=${basedir}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
property name=test.webapp value=../webapps/build/examples/
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/jasper/build.xml,v
retrieving revision 1.25
diff -u -r1.25 build.xml
--- build.xml 2001/10/03 21:39:12 1.25
+++ build.xml 2001/10/04 04:39:27
@@ -11,9 +11,9 @@
!-- Build Defaults --
property name=build.compilervalue=classic/
- property name=jasper.build value=build/
- property name=jasper.deploy value=../build/
- property name=jasper.dist value=dist/
+ property name=jasper.build value=${basedir}/build/
+ property name=jasper.deploy value=${basedir}/../build/
+ property name=jasper.dist value=${basedir}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
property name=tools.jar value=${java.home}/lib/tools.jar/
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/tester/build.xml,v
retrieving revision 1.15
diff -u -r1.15 build.xml
--- build.xml 2001/10/03 21:39:12 1.15
+++ build.xml 2001/10/04 04:41:31
@@ -9,9 +9,9 @@
property name=build.compiler value=classic/
property name=servletapi.home value=../../jakarta-servletapi-4/dist/
- property name=tester.buildvalue=build/
- property name=tester.deploy value=../build/
- property name=tester.dist value=dist/
+ property name=tester.buildvalue=${basedir}/build/
+ property name=tester.deploy value=${basedir}/../build/
+ property name=tester.dist value=${basedir}/dist/
!-- == Derived Property Values = --
property name=ant.jar value=${ant.home}/lib/ant.jar/
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/build.xml,v
retrieving revision 1.17
diff -u -r1.17 build.xml
--- build.xml 2001/09/16 04:58:28 1.17
+++ build.xml 2001/10/04 04:40:08
@@ -10,9 +10,9 @@
property file=${user.home}/build.properties/
property name=build.compiler value=classic/
- property name=webapps.build value=build/
- property name=webapps.deploy value=../build/
- property name=webapps.distvalue=dist/
+ property name=webapps.build value=${basedir}/build/
+ property name=webapps.deploy value=${basedir}/../build/
+ property name=webapps.distvalue=${basedir}/dist/
!-- === BUILD: Create Directories == --
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Bojan Smojver wrote: [EMAIL PROTECTED] wrote: I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). - Test. I'm one of those overly brave and too stupid that put CVS versions of software in production environment. Promise to give it a bashing within my applications. My first tests show that today's version of both Tomcat 3.3 and mod_jk that comes with it are fine on this issue. Hurray! Bojan PS. OK, let's move this baby to production server... ;-)
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpResponseStream.java
remm01/10/03 22:43:20
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpResponseStream.java
Log:
- Use setHeader to avoid setting duplicate headers.
Revision ChangesPath
1.9 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java
Index: HttpResponseStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- HttpResponseStream.java 2001/09/28 23:34:02 1.8
+++ HttpResponseStream.java 2001/10/04 05:43:20 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.8 2001/09/28 23:34:02 remm Exp $
- * $Revision: 1.8 $
- * $Date: 2001/09/28 23:34:02 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.9 2001/10/04 05:43:20 remm Exp $
+ * $Revision: 1.9 $
+ * $Date: 2001/10/04 05:43:20 $
*
*
*
@@ -218,14 +218,14 @@
if (!response.isChunkingAllowed() useChunking) {
// If we should chunk, but chunking is forbidden by the connector,
// we close the connection
-response.addHeader(Connection, close);
+response.setHeader(Connection, close);
} else {
response.removeHeader(Connection, close);
}
// Don't chunk is the connection will be closed
useChunking = (useChunking !response.isCloseConnection());
if (useChunking)
-response.addHeader(Transfer-Encoding, chunked);
+response.setHeader(Transfer-Encoding, chunked);
else
response.removeHeader(Transfer-Encoding, chunked);
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
remm01/10/03 22:44:43
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
Log:
- Add a flag to indicate that we'll finish the response. We don't if the problem
is an EOFException while parsing the request header.
Fixes bug 3949.
Revision ChangesPath
1.37 +16 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
Index: HttpProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- HttpProcessor.java2001/09/05 00:31:50 1.36
+++ HttpProcessor.java2001/10/04 05:44:43 1.37
@@ -1,6 +1,6 @@
-/* * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.36 2001/09/05 00:31:50 craigmcc Exp $
- * $Revision: 1.36 $
- * $Date: 2001/09/05 00:31:50 $
+/* * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
1.37 2001/10/04 05:44:43 remm Exp $
+ * $Revision: 1.37 $
+ * $Date: 2001/10/04 05:44:43 $
*
*
*
@@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.36 $ $Date: 2001/09/05 00:31:50 $
+ * @version $Revision: 1.37 $ $Date: 2001/10/04 05:44:43 $
*/
final class HttpProcessor
@@ -919,6 +919,7 @@
private void process(Socket socket) {
boolean ok = true;
+boolean finishResponse = true;
SocketInputStream input = null;
OutputStream output = null;
@@ -935,6 +936,8 @@
while (!stopped ok keepAlive) {
+finishResponse = true;
+
try {
request.setStream(input);
request.setResponse(response);
@@ -966,7 +969,10 @@
}
}
} catch (EOFException e) {
+// It's very likely to be a socket disconnect on either the
+// client or the server
ok = false;
+finishResponse = false;
} catch (ServletException e) {
ok = false;
try {
@@ -1028,10 +1034,12 @@
// Finish up the handling of the request
try {
-response.finishResponse();
-request.finishRequest();
-if (output != null)
-output.flush();
+if (finishResponse) {
+response.finishResponse();
+request.finishRequest();
+if (output != null)
+output.flush();
+}
} catch (IOException e) {
ok = false;
}
DO NOT REPLY [Bug 3949] - Document with content-length of 0 results in resend headers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3949 Document with content-length of 0 results in resend headers [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 22:48 --- Fixed in the 10/04/2001 nightly.
cvs commit: jakarta-tomcat-4.0/catalina build.xml
remm01/10/03 22:51:03
Modified:catalina build.xml
Log:
- Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
Revision ChangesPath
1.75 +3 -3 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- build.xml 2001/10/03 22:59:43 1.74
+++ build.xml 2001/10/04 05:51:03 1.75
@@ -11,9 +11,9 @@
!-- Build Defaults --
property name=build.compilervalue=classic/
- property name=catalina.buildvalue=build/
- property name=catalina.deploy value=../build/
- property name=catalina.dist value=dist/
+ property name=catalina.buildvalue=${basedir}/build/
+ property name=catalina.deploy value=${basedir}/../build/
+ property name=catalina.dist value=${basedir}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
property name=test.webapp value=../webapps/build/examples/
cvs commit: jakarta-tomcat-4.0/jasper build.xml
remm01/10/03 22:51:12
Modified:jasper build.xml
Log:
- Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
Revision ChangesPath
1.26 +3 -3 jakarta-tomcat-4.0/jasper/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/build.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- build.xml 2001/10/03 21:39:12 1.25
+++ build.xml 2001/10/04 05:51:12 1.26
@@ -11,9 +11,9 @@
!-- Build Defaults --
property name=build.compilervalue=classic/
- property name=jasper.build value=build/
- property name=jasper.deploy value=../build/
- property name=jasper.dist value=dist/
+ property name=jasper.build value=${basedir}/build/
+ property name=jasper.deploy value=${basedir}/../build/
+ property name=jasper.dist value=${basedir}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
property name=tools.jar value=${java.home}/lib/tools.jar/
cvs commit: jakarta-tomcat-4.0/tester build.xml
remm01/10/03 22:51:22
Modified:tester build.xml
Log:
- Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
Revision ChangesPath
1.16 +3 -3 jakarta-tomcat-4.0/tester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/build.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- build.xml 2001/10/03 21:39:12 1.15
+++ build.xml 2001/10/04 05:51:22 1.16
@@ -9,9 +9,9 @@
property name=build.compiler value=classic/
property name=servletapi.home value=../../jakarta-servletapi-4/dist/
- property name=tester.buildvalue=build/
- property name=tester.deploy value=../build/
- property name=tester.dist value=dist/
+ property name=tester.buildvalue=${basedir}/build/
+ property name=tester.deploy value=${basedir}/../build/
+ property name=tester.dist value=${basedir}/dist/
!-- == Derived Property Values = --
property name=ant.jar value=${ant.home}/lib/ant.jar/
cvs commit: jakarta-tomcat-4.0/webapps build.xml
remm01/10/03 22:51:38
Modified:webapps build.xml
Log:
- Fix some problems with handling of the base directory path. The output
directory could apparently be wrong when invoking Ant in one of the
subprojects (although I never experienced the problem).
Patch submitted by Patrick Luby (Patrick.Luby at sun.com).
Revision ChangesPath
1.18 +3 -3 jakarta-tomcat-4.0/webapps/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/build.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- build.xml 2001/09/16 04:58:28 1.17
+++ build.xml 2001/10/04 05:51:38 1.18
@@ -10,9 +10,9 @@
property file=${user.home}/build.properties/
property name=build.compiler value=classic/
- property name=webapps.build value=build/
- property name=webapps.deploy value=../build/
- property name=webapps.distvalue=dist/
+ property name=webapps.build value=${basedir}/build/
+ property name=webapps.deploy value=${basedir}/../build/
+ property name=webapps.distvalue=${basedir}/dist/
!-- === BUILD: Create Directories == --
