Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
[EMAIL PROTECTED] wrote: On Thu, 29 Aug 2002, jean-frederic clere wrote: I am +1 for merging the code but in daemon. I am using the daemon code for projects not related with mod_jk and I would perfer to have it independant from mod_jk. An other point to be against moving it in mod_jk is that the code has been moved recently in commons (sandbox) I do not thing that it is a good idea to move it back in the Tomcat repos. Also if we move it from daemon to mod_jk we have to ask it to the common dev list before moving it. Ok, not 'move'. What about 'copy' :-) ? There is a lot of duplication, I just want to make sure that jk has all the features that it needs - starting the VM is one thing I want to review and 'copy', if there's something that we missed in jk. I would also like to 'copy' the service monitor and copy and modify the service registration ( I like the jk_nt_service properties file, but the code is a bit ugly right now ). I still see no good reasons to make a 'copy'... Surely the code in daemon needs a cleaning and some changes to fit mod_jk needs. A ant download task could bring the needed source in the mod_jk directory to ease the release mechanism. I will try to find time to get the JVM started under Apache as it was in mod_jserv using the code in daemon. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
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=10671. 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=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp README.txt
jfclere 2002/08/30 01:43:19 Modified:webapp README.txt Log: Fix PR: 11436. Revision ChangesPath 1.19 +2 -3 jakarta-tomcat-connectors/webapp/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/README.txt,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- README.txt21 Mar 2002 13:49:44 - 1.18 +++ README.txt30 Aug 2002 08:43:19 - 1.19 @@ -61,9 +61,8 @@ To build the tomcat-webapp.jar you have to do the following: -* Copy build.properties.sample to build.properties - -* Edit build.properties to taste. +* Edit build.properties to taste. This file is created by ./configure when + the WebApp module is configured, see below. * Run ant. It'll build the tomcat-webapp.jar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11436] - Patch for README.txt, there is no build.properties.sample anymore
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=11436. 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=11436 Patch for README.txt, there is no build.properties.sample anymore [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4112] - isapi_redirect.dll does not handle Tomcat down case gracefully
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=4112. 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=4112 isapi_redirect.dll does not handle Tomcat down case gracefully --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 11:25 --- Does anyone now if this bug left the following error in the Windows system event log:- The HTTP server encountered an unhandled exception while processing the ISAPI Application ' isapi_redirect + 0x19B0 '. If not, would this be a new bug? I not yet sure of the Tomcat version number as the install is on a client machine. Regards, Howard ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina build.xml
remm2002/08/30 04:40:04
Modified:catalina build.xml
Log:
- Create the shared/classes and shared/lib folders.
Revision ChangesPath
1.127 +2 -0 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.126
retrieving revision 1.127
diff -u -r1.126 -r1.127
--- build.xml 13 Aug 2002 12:28:06 - 1.126
+++ build.xml 30 Aug 2002 11:40:04 - 1.127
@@ -1017,6 +1017,8 @@
mkdir dir=${catalina.deploy}/common/lib/
mkdir dir=${catalina.deploy}/server/classes/
mkdir dir=${catalina.deploy}/server/lib/
+mkdir dir=${catalina.deploy}/shared/classes/
+mkdir dir=${catalina.deploy}/shared/lib/
mkdir dir=${catalina.deploy}/work/
mkdir dir=${catalina.deploy}/temp/
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2 build.xml
remm2002/08/30 04:40:35
Modified:jasper2 Tag: tomcat_4_branch build.xml
Log:
- Don't copy Jasper to shared/lib.
Revision ChangesPath
No revision
No revision
1.7.2.1 +0 -8 jakarta-tomcat-jasper/jasper2/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/build.xml,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- build.xml 12 Jun 2002 23:15:27 - 1.7
+++ build.xml 30 Aug 2002 11:40:34 - 1.7.2.1
@@ -173,10 +173,7 @@
target name=deploy-prepare
mkdir dir=${jasper.deploy}/
mkdir dir=${jasper.deploy}/bin/
-mkdir dir=${jasper.deploy}/common/classes/
mkdir dir=${jasper.deploy}/common/lib/
-mkdir dir=${jasper.deploy}/shared/classes/
-mkdir dir=${jasper.deploy}/shared/lib/
/target
@@ -191,11 +188,6 @@
fixcrlf srcdir=${jasper.deploy}/bin includes=*.bat eol=crlf/
chmod perm=+x file=${jasper.deploy}/bin/jasper.sh/
chmod perm=+x file=${jasper.deploy}/bin/jspc.sh/
-
-!-- Runtime Library --
-copy todir=${jasper.deploy}/shared/lib
- fileset dir=${jasper.build}/shared/lib /
-/copy
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSR77 and JSR88
Hi, I am a member of the web app group of the Forte tools. Our group is responsible for the Tomcat integration with the Netbeans/Forte IDE. We are now planning new features for the next Forte release. We have plans for a JSR77 (managament) and JSR88 (deployment) implementation. Can you give me information of your plans in this issue? It will really help us. Thanks, Damian. - Damian Frach Software Engineer, Forte Tools Software Platforms and Products [EMAIL PROTECTED] [EMAIL PROTECTED] Sun Microsystems Czech s.r.o. Evropska 33E 160 00 Prague 6 - Dejvice Tel.: +420 (2) 3300 - 9183 3300 - 9311 Fax.: +420 (2) 3300 - 9299 Mobile: +420 (604) 6277 - 20 Private: Tunelaru 328 Praha 5 - Zbraslav 15600 Tel: +420 (2) 57924924 Polni 10Stepankovice74728 Tel: +420 (653) 6750 - 27 - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-datasource-examples-howto.xml
glenn 2002/08/30 06:41:25
Modified:webapps/tomcat-docs jndi-datasource-examples-howto.xml
Log:
Add FAQ for Random Closed Connection Exceptions
Revision ChangesPath
1.5 +67 -0
jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-datasource-examples-howto.xml
Index: jndi-datasource-examples-howto.xml
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-datasource-examples-howto.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jndi-datasource-examples-howto.xml18 Aug 2002 00:55:25 - 1.4
+++ jndi-datasource-examples-howto.xml30 Aug 2002 13:41:25 - 1.5
@@ -749,6 +749,73 @@
/subsection
+subsection name=Random Connection Closed Exceptions
+p
+These can occur when one request gets a db connection from the connection
+pool and closes it twice. When using a connection pool, closing the
+connection just returns it to the pool for reuse by another request,
+it doesn't close the connection. And Tomcat uses multiple threads to
+handle concurrent requests. Here is an example of the sequence
+of events which could cause this error in Tomcat:
+pre
+ Request 1 running in Thread 1 gets a db connection.
+
+ Request 1 closes the db connection.
+
+ The JVM switches the running thread to Thread 2
+
+ Request 2 running in Thread 2 gets a db connection
+ (the same db connection just closed by Request 1).
+
+ The JVM switches the running thread back to Thread 1
+
+ Request 1 closes the db connection a second time in a finally block.
+
+ The JVM switches the running thread back to Thread 2
+
+ Request 2 Thread 2 tries to use the db connection but fails
+ because Request 1 closed it.
+/pre
+Here is an example of properly written code to use a db connection
+obtained from a connection pool:
+pre
+ Connection conn = null;
+ Statement stmt = null; // Or PreparedStatement if needed
+ ResultSet rs = null;
+ try {
+conn = ... get connection from connection pool ...
+stmt = conn.createStatement(select ...);
+rs = stmt.executeQuery();
+... iterate through the result set ...
+rs.close();
+rs = null;
+stmt.close();
+stmt = null;
+conn.close(); // Return to connection pool
+conn = null; // Make sure we don't close it twice
+ } catch (SQLException e) {
+... deal with errors ...
+ } finally {
+// Always make sure result sets and statements are closed,
+// and the connection is returned to the pool
+if (rs != null) {
+ try { rs.close(); } catch (SQLException e) { ; }
+ rs = null;
+}
+if (stmt != null) {
+ try { stmt.close(); } catch (SQLException e) { ; }
+ stmt = null;
+}
+if (conn != null) {
+ try { conn.close(); } catch (SQLException e) { ; }
+ conn = null;
+}
+ }
+/pre
+/p
+
+/subsection
+
/section
/body
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
De: Bojan Smojver [mailto:[EMAIL PROTECTED]] Enviado el: 30 de agosto de 2002 1:11 Para: Tomcat Dev List Asunto: RE: Spec question: RE BUG 12052 On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote: We know how r-parsed_uri.port gets his value? Yep. It's getting it from the URL, not the headers. Wrong, It takes the port and ServerName from the Host: header if the Request-uri is relative ( most common case ) and from the Reqeust-Uri if it is absolute.. rfc2616 Section 5.2 strict compliance.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp/support wa_apr.m4
jfclere 2002/08/30 07:15:06
Modified:webapp Makedefs.in Makefile.in configure.in
webapp/apache-1.3 Makefile.in
webapp/support wa_apr.m4
Log:
Arrange to allow to use the released version of APR.
Revision ChangesPath
1.22 +5 -1 jakarta-tomcat-connectors/webapp/Makedefs.in
Index: Makedefs.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makedefs.in,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Makedefs.in 14 May 2002 22:06:20 - 1.21
+++ Makedefs.in 30 Aug 2002 14:15:06 - 1.22
@@ -80,6 +80,10 @@
EXTRA_LDFLAGS = @EXTRA_LDFLAGS@
EXTRA_INCLUDES = @EXTRA_INCLUDES@
+# apr library name
+APR_LIBNAME = @APR_LIBNAME@
+APR_LIB = @APR_LIB@
+
# Module to build
MODULE = @MODULE@
1.37 +2 -2 jakarta-tomcat-connectors/webapp/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- Makefile.in 14 May 2002 22:37:15 - 1.36
+++ Makefile.in 30 Aug 2002 14:15:06 - 1.37
@@ -132,7 +132,7 @@
apr-build: $(LIB_DIR)
@$(MAKE) SUBF=$(MAKEFLAGS) SUBD=$(APR_DIR) SUBT=all subdir
$(LIBTOOL) --mode=install \
- cp $(APR_DIR)/libapr.la $(LIB_DIR)/libapr.la
+ cp $(APR_DIR)/$(APR_LIBNAME) $(LIB_DIR)/$(APR_LIBNAME)
$(LIBTOOL) --mode=finish $(LIB_DIR)
apr-clean:
1.63 +10 -5 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- configure.in 14 May 2002 22:37:15 - 1.62
+++ configure.in 30 Aug 2002 14:15:06 - 1.63
@@ -93,6 +93,8 @@
dnl Directories locations are defined here
dnl --
WA_VARIABLE([APR_DIR])
+WA_VARIABLE([APR_LIB])
+WA_VARIABLE([APR_LIBNAME])
WA_VARIABLE([SRC_DIR])
WA_VARIABLE([TGT_DIR])
WA_VARIABLE([TC4_DIR])
@@ -179,12 +181,15 @@
WA_APR_GET([CPP],[${APR_DIR}],[CPP])
WA_APR_GET([SHELL],[${APR_DIR}],[SHELL])
-WA_APR_GET([CFLAGS],[${APR_DIR}],[EXTRA_CFLAGS])
-WA_APR_GET([CPPFLAGS],[${APR_DIR}],[EXTRA_CPPFLAGS])
-WA_APR_GET([LDFLAGS],[${APR_DIR}],[EXTRA_LDFLAGS])
+WA_APR_GET([CFLAGS],[${APR_DIR}],[CFLAGS])
+WA_APR_GET([CPPFLAGS],[${APR_DIR}],[CPPFLAGS])
+WA_APR_GET([LDFLAGS],[${APR_DIR}],[LDFLAGS])
-WA_APR_GET([LDFLAGS],[${APR_DIR}],[EXTRA_LIBS])
+WA_APR_GET([LDFLAGS],[${APR_DIR}],[LIBS])
WA_APR_GET([CPPFLAGS],[${APR_DIR}],[EXTRA_INCLUDES])
+
+WA_APR_LIB([APR_LIB],[${APR_DIR}])
+WA_APR_LIBNAME([APR_LIBNAME],[${APR_DIR}])
AC_MSG_CHECKING([for apr headers])
WA_APPEND([INCLUDES],[-I${APR_DIR}/include])
1.29 +3 -3 jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Makefile.in 13 May 2002 23:25:09 - 1.28
+++ Makefile.in 30 Aug 2002 14:15:06 - 1.29
@@ -85,7 +85,7 @@
$(INCLUDES) $(LOCAL_INCLUDES) \
-Wc,$(CPPFLAGS) $(CFLAGS) \
-Wl,$(LDFLAGS) $(LIBS) \
- -L$(LIB_DIR) -lapr \
+ -L$(LIB_DIR) -l$(APR_LIB) \
$(OBJ_DIR)/*.o $
# +++ EXPERIMENTAL +++ LIBTOOL COMPILE, APXS LINK +++
@@ -100,4 +100,4 @@
#$(CFLAGS) $(EXTRA_CFLAGS)
#
# $(MODFILE): $(OBJECT)
-#$(APXS) -c -o $@ -L$(OBJ_DIR) -lapr $ $(OBJ_DIR)/*.o
+#$(APXS) -c -o $@ -L$(OBJ_DIR) -l$(APR_LIB) $ $(OBJ_DIR)/*.o
1.6 +54 -6 jakarta-tomcat-connectors/webapp/support/wa_apr.m4
Index: wa_apr.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/wa_apr.m4,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wa_apr.m4 13 May 2002 23:23:19 - 1.5
+++ wa_apr.m4 30 Aug 2002 14:15:06 - 1.6
@@ -100,18 +100,18 @@
dnl Retrieve a value from the configured APR source tree
dnl $1 = Environment variable name for the returned value
dnl $2 = APR sources directory as returned by WA_APR
-dnl $3 = APR variable name (found in $2/APRVARS)
+dnl $3 = APR variable name (found in $2/apr-config)
dnl
DO NOT REPLY [Bug 11592] - Starting apache sever
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=11592. 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=11592 Starting apache sever [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 14:43 --- Without the httpd version this bug is invalid. I have just tried with 2.0.41-dev and I cannot reproduce it). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11722] - There is no build.properties.sample file.
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=11722. 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=11722 There is no build.properties.sample file. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 14:45 --- *** This bug has been marked as a duplicate of 11436 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11436] - Patch for README.txt, there is no build.properties.sample anymore
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=11436. 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=11436 Patch for README.txt, there is no build.properties.sample anymore [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 14:45 --- *** Bug 11722 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-datasource-examples-howto.xml
[EMAIL PROTECTED] wrote: glenn 2002/08/30 06:41:25 Modified:webapps/tomcat-docs jndi-datasource-examples-howto.xml Log: Add FAQ for Random Closed Connection Exceptions It seems I missed that update (unfortunaltely, I had to do the packaging now, or next monday). Anyway, it is likely we'll have a few issues to fix in 4.1.10 which would make it necessary to release another milestone. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[4.1.10] New test milestone released
A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.10/ Significant changes over 4.1.9 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Stable versions of components from Jakarta Commons, including DBCP 1.0 The list of changes is available in the release notes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12194] New: - Tomcat does not send WWW-Authenticate header
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=12194. 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=12194 Tomcat does not send WWW-Authenticate header Summary: Tomcat does not send WWW-Authenticate header Product: Tomcat 3 Version: 3.2.3 Final Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Auth AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a web app contains an error page for code 401 like error-page error-code401/error-code location/401.html/location /error-page The header WWW-Authenticate: Basic realm=Protected Area name is not sent causing HTTP/1.1 agents not to pop the login box. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12196] New: - request.getRemoteUser() returns null for AJP request with remote username
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=12196. 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=12196 request.getRemoteUser() returns null for AJP request with remote username Summary: request.getRemoteUser() returns null for AJP request with remote username Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Tomcat 4.1.9beta, request.getRemoteUser() no longer returns the remoteUser provided via AJP. Setup: Sun JDK 1.3.1 Tomcat 4.1.9 mod_jk Microsoft IIS Win2K I added a line request.org.apache.jk.common.HandlerRequest.tomcatAuthentication = false to my conf/jk2.properties file, but although this does set the tomcatAuthentication property on HandlerRequest, the remote user is not propagated to the HttpServletRequest that the servlet eventually receives. The discontinuity turned out to be in org.apache.coyote.tomcat4.CoyoteRequest where getRemoteUser is returning the userPrincipal property, which has not been set. I modified my getRemoteUser to return coyoteRequest.getRemoteUser().toString() and this fixed my problem, but perhaps there is a better fix, perhaps making a modification in CoyoteAdapter.postParseRequest? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12109] - Using functions in EL causes a NPE to be thrown in the GenerateELFunctionMap.java
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=12109. 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=12109 Using functions in EL causes a NPE to be thrown in the GenerateELFunctionMap.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 16:54 --- Fixed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/08/30 09:54:09
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Fixed 12109: Using functions in EL causes a NPE to be thrown in the
GenerateELFunctionMap.java
Revision ChangesPath
1.86 +17 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- Generator.java30 Aug 2002 01:43:53 - 1.85
+++ Generator.java30 Aug 2002 16:54:09 - 1.86
@@ -589,15 +589,21 @@
new JspUtil.FunctionSignature( fnSignature,
tli.getShortName(), err );
out.print( quote( functionSignature.getMethodName() ) );
-out.print( , new Class[] { );
+out.print(, );
Class[] args = functionSignature.getParameterTypes();
-for( int j = 0; j args.length; j++ ) {
-out.print( args[j].getName() + .class );
-if( j (args.length - 1) ) {
-out.print( , );
-}
-}
-out.println( } ) ); );
+ if (args != null) {
+ out.print(new Class[] { );
+ for( int j = 0; j args.length; j++ ) {
+ out.print( args[j].getName() + .class );
+ if( j (args.length - 1) ) {
+ out.print( , );
+ }
+ }
+ out.print(} );
+ } else {
+ out.print(null);
+ }
+out.println()););
}
}
out.popIndent();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSR77 and JSR88
On Fri, 30 Aug 2002, Damian Frach wrote: We are now planning new features for the next Forte release. We have plans for a JSR77 (managament) and JSR88 (deployment) implementation. Can you give me information of your plans in this issue? We had few discussions. Tomcat is currently using a slightly different naming scheme than JSR77, but I think that will change for 5.0. It is possible to create some wrappers that implement JSR77/88 for 4.1. Right now we apparently agreed on a 2-layer configuration mechanism for tomcat5.0 - all config data storage will expose a JNDI interface, and runtime changes and info will be available via JMX ( or direct calls/introspection ). Most likely the new naming scheme will be an extension of JSR77 - we'll probably expose much more attributes. BTW, the JNDI layer would probably allow the nice JNDI browser in netbeans to be used to configure any aspect of tomcat ( offline ). We welcome any suggestion and contribution. Costin It will really help us. Thanks, Damian. - Damian Frach Software Engineer, Forte Tools Software Platforms and Products [EMAIL PROTECTED] [EMAIL PROTECTED] Sun Microsystems Czech s.r.o. Evropska 33E 160 00 Prague 6 - Dejvice Tel.: +420 (2) 3300 - 9183 3300 - 9311 Fax.: +420 (2) 3300 - 9299 Mobile: +420 (604) 6277 - 20 Private: Tunelaru 328 Praha 5 - Zbraslav 15600 Tel: +420 (2) 57924924 Polni 10Stepankovice74728 Tel: +420 (653) 6750 - 27 - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: Wrong, It takes the port and ServerName from the Host: header if the Request-uri is relative ( most common case ) and from the Reqeust-Uri if it is absolute.. rfc2616 Section 5.2 strict compliance.. The comment in apache2.0 core.c seems to sugest otherwise ( we never trust the port from the user ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
On Fri, 30 Aug 2002, jean-frederic clere wrote: I still see no good reasons to make a 'copy'... Well, for the JNI invocation ( starting the VM inprocess ) - I just want to make sure that jk is not missing any 'trick' - as you know this is a very OS-specific and delicate problem. Right now it seems to work well, but we require LD_LIBRARY_PATH to be set before with java .so in it - if deamon can get around that on linux, than that's something to copy. The other thing to copy is the service monitor and service starter - which seems cool and cleaner than jk_nt_service. I still want to keep the wrapper.properties, it gives a lot of control and is easier to use ( IMO ) then using CLI. Another reason - we'll have a single native build to worry about and the user will have a more consistent behavior ( same logs, same config, etc ) Surely the code in daemon needs a cleaning and some changes to fit mod_jk needs. A ant download task could bring the needed source in the mod_jk directory to ease the release mechanism. Well, it's a bit more than 'copy' - I would like to use the same logger and same communication mechanism with the VM as jk is using ( i.e. messages, invoke/get/setAttribute, etc). I will try to find time to get the JVM started under Apache as it was in mod_jserv using the code in daemon. +1. You may also 'copy' some code from jserv. I think it should also work under IIS and the other servers - the Apache parent process will act as the 'controller'. One important thing is that the code in daemon just starts the JVM and supports 'restart' ( using that 123 return code ). What we would need and what jserv did is to keep it alive - i.e. unless a special 'stop me' return code is given, we should restart the process if it dies. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
- Another cause to worry is the comment in apache2 core.c: There are two options regarding what the name of a server is. The canonical name as defined by ServerName and Port, or the client's name as supplied by a possible Host: header or full URI. We never trust the port passed in the client's headers, we always use the port of the actual socket. Reviewed the code ( briefly ) and it seems there is a contradiction between this comment and the actual behavior the apache2 has.. Apache2 allways obey a Host: header if present in the request ( for relative request uris of course) .. for both Servername and port, maybe this comment is directed to not use internally the parsed port only the real socket port, i dont know.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: - Another cause to worry is the comment in apache2 core.c: There are two options regarding what the name of a server is. The canonical name as defined by ServerName and Port, or the client's name as supplied by a possible Host: header or full URI. We never trust the port passed in the client's headers, we always use the port of the actual socket. Reviewed the code ( briefly ) and it seems there is a contradiction between this comment and the actual behavior the apache2 has.. Apache2 allways obey a Host: header if present in the request ( for relative request uris of course) .. for both Servername and port, maybe this comment is directed to not use internally the parsed port only the real socket port, i dont know.. It may very well be a security issue ( and quite a big one ! ). There are sites using all kinds of firewalls and settings in httpd.conf to restrict access to some hosts or ports ( say from internal network ). If Host: info is used for security checkings - it would be trivial to bypass some of this security. In particular - people may have servlets that check getServerName() to find if 'localhost' was used - the spec change will leave them with a huge hole ( any request with forged Host: localhost will pass ). I love this kind of aparently trivial 'clarifications' with deep implications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jtc/naming
Remy,
I would like to create a new dir in j-t-c, for the naming contexts
used in jk config and some other 'experiments'.
I started few ant tasks and ant 'dynamic property' ( ${jndi:...} )
and ant jndi tasks ( jndiSet, jndiCopy, etc ). That would allow
ant tasks to do automated config changes - and will allow us
to better test the jndi code.
If possible, I would love some layout changes - we can keep the
old classes, but a more strucutred layout would help a lot.
The 'resources' package is a bit unintuitive - it's more of
a 'vfs'. The 'proxy' should ( IMO ) have its own package
and be useable to cache any of the dir contexts. I would also
group all the *Ref classes in the base dir into a 'ref' package.
None of this is important - just nice ( and we can preserve backward
compat by keeping the old files in place, and using the new
dir for the new layout ).
What do you think ?
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2 build.xml
kinman 2002/08/30 11:04:50
Modified:jasper2 build.xml
Log:
- Don't copy jasper to shared/lib
Revision ChangesPath
1.17 +0 -8 jakarta-tomcat-jasper/jasper2/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/build.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- build.xml 20 Aug 2002 19:25:11 - 1.16
+++ build.xml 30 Aug 2002 18:04:50 - 1.17
@@ -211,10 +211,7 @@
target name=deploy-prepare
mkdir dir=${jasper.deploy}/
mkdir dir=${jasper.deploy}/bin/
-mkdir dir=${jasper.deploy}/common/classes/
mkdir dir=${jasper.deploy}/common/lib/
-mkdir dir=${jasper.deploy}/shared/classes/
-mkdir dir=${jasper.deploy}/shared/lib/
/target
@@ -228,11 +225,6 @@
fixcrlf srcdir=${jasper.deploy}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${jasper.deploy}/bin includes=*.bat eol=crlf/
chmod perm=+x file=${jasper.deploy}/bin/jspc.sh/
-
-!-- Runtime Library --
-copy todir=${jasper.deploy}/shared/lib
- fileset dir=${jasper.build}/shared/lib /
-/copy
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question about the processing of Cookie: headers.
Hello .. One of my compatriots is having a problem with a 3rd party peice of software that attempting to access a Tomcat 4.0.4 server. The 3rd party software .. acting as a client .. is sending a requst with a cookie: header with the following value .. JSESSIONID=F40180928E56604E197E25DEA7C4EF6F; domain=null; path=/ecs Tomcat 4.0.4 complains with an IllegalArgumentException exception .. The exception occurs in the Coyote adaptor.. org.apache.coyote.tomcat4CoyoteAdapter in method parseCookies .. when 'copying' the cookies for the current request .. calling 'new Cookie()' .. From rfc 2109 the cookie header does appear to be 'wrong' since domain and path .. in this case .. should be $Domain and $Path .. However .. there is code in the jakarta-servletapi .. javax.servlet.http.Cookie .. that I do have a question about .. The code for the Cookie constructor disallows cookies with the names of the set-cookie attribute values .. this is what is causing the above exception .. Sooo .. the question is: Where in rfc 2109 does it say that cookie names cannot be the names of the set-cookie attribute values ?? While I have reported back to the 3rd party that thier software has 'problems' .. I dont understand why Tomcat is performing the tests specified in the code .. If anyone could comment on this .. it would be greatly appreciated .. Len
RE: Spec question: RE BUG 12052
-Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 30 de agosto de 2002 19:54 Para: Tomcat Developers List Asunto: RE: Spec question: RE BUG 12052 It may very well be a security issue ( and quite a big one ! ). There are sites using all kinds of firewalls and settings in httpd.conf to restrict access to some hosts or ports ( say from internal network ). If Host: info is used for security checkings - it would be trivial to bypass some of this security. In particular - people may have servlets that check getServerName() to find if 'localhost' was used - the spec change will leave them with a huge hole ( any request with forged Host: localhost will pass ). Good Comment.. In the particular case you have pointed, it's a user problem, a request with Host: Localhost can be only be issued by someone with Remote Ip=localhost.. So one can take some security measures to check the correctness of the request.. All other use case i can imagine fall within the users problems, if the correct VS has received the request, it's the Remote IP appropiate for that VS? matchs port where the request has been received the port where is suppoussed that the VS is? But By far in the Journey we have learned something, never trust a Host Header without first trust the Remote IP, at least for ultra-secure apps.. And another thing, i wonder if it would be appropiate to check if a request came from the (at least) correct port before dispatching it to the VS.. at least within TC, and check if Apache2 is taking any measures to be certain of this fact.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util ExtensionValidator.java
horwat 2002/08/30 11:41:27
Modified:catalina/src/share/org/apache/catalina/util
ExtensionValidator.java
Log:
If a META-INF directory exists without a manifest file, handle condition gracefully.
Revision ChangesPath
1.3 +6 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java
Index: ExtensionValidator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/ExtensionValidator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ExtensionValidator.java 29 Aug 2002 23:56:12 - 1.2
+++ ExtensionValidator.java 30 Aug 2002 18:41:26 - 1.3
@@ -220,6 +220,8 @@
}
} catch (javax.naming.NamingException nex) {
// Application does not contain a MANIFEST.MF file
+} catch (java.util.NoSuchElementException nse) {
+// Application does not contain a MANIFEST.MF file
} catch (java.io.IOException iox) {
// Unable to load MANIFEST.MF file
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: It may very well be a security issue ( and quite a big one ! ). There are sites using all kinds of firewalls and settings in httpd.conf to restrict access to some hosts or ports ( say from internal network ). If Host: info is used for security checkings - it would be trivial to bypass some of this security. In particular - people may have servlets that check getServerName() to find if 'localhost' was used - the spec change will leave them with a huge hole ( any request with forged Host: localhost will pass ). Good Comment.. In the particular case you have pointed, it's a user problem, a request with Host: Localhost can be only be issued by someone with Remote Ip=localhost.. 'localhost' is just an example. The server may have 2 ip addresses, one visible from outside and one restricted by firewalls to only internal users ( and used for example for content updates ). In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() and get the address that received the request. Since the servlet spec doesn't provide any 'declarative' support for this kind of access control - I think this is a valid solution. A firewall or routing can protect the internal address ( say 10.0.0.1 - on a network card connected only to the internal net, and a firewall restricting outside access to this IP ). In 2.4 this will fail ( opening potential holes ) and in addition this kind of check will be impossible to implement - since the address where the request was received will no longer be available. So one can take some security measures to check the correctness of the request.. For example ? All other use case i can imagine fall within the users problems, if the correct VS has received the request, it's the Remote IP appropiate for that VS? matchs port where the request has been received the port where is suppoussed that the VS is? If by 'user' you mean the servlet author - I disagree. Such checks are prefectly reasonable and correct IMO. But By far in the Journey we have learned something, never trust a Host Header without first trust the Remote IP, at least for ultra-secure apps.. Well, the remoteIP is much more difficult to test - if you're a big organization you may have dozens of internal IPs. And most people do trust their firewalls to restrict access to a particular IP, I've seen this kind of setup in several cases ( where you use a special interface for internal users ). And another thing, i wonder if it would be appropiate to check if a request came from the (at least) correct port before dispatching it to the VS.. at least within TC, and check if Apache2 is taking any measures to be certain of this fact.. The comment in apache sugest that Host shouldn't be trusted. If they started to trust it sudenly - they should at least modify the comment and explain how is this trust justified. Host is sent by the user - it is trivial to forge. The port and host that actually receives the request are pretty safe and difficult to trick, especially if a firewall is used in front. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-datasource-examples-howto.xml
Thats ok. Remy Maucherat wrote: [EMAIL PROTECTED] wrote: glenn 2002/08/30 06:41:25 Modified:webapps/tomcat-docs jndi-datasource-examples-howto.xml Log: Add FAQ for Random Closed Connection Exceptions It seems I missed that update (unfortunaltely, I had to do the packaging now, or next monday). Anyway, it is likely we'll have a few issues to fix in 4.1.10 which would make it necessary to release another milestone. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
I think you're missing the virtual server angle. There is NOT a 1-1 mapping from ip address to DNS name. It's N-M. Even from the standpoint of a single machine which received the request, there are many possible names for the IP address. So, given a request like: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org The only way to know which host the client intended is the Host header. So, yes, this is spoofable, and should not be used as a security mechanism. It was never designed to be one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 2:50 PM To: Tomcat Developers List Subject: RE: Spec question: RE BUG 12052 On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: It may very well be a security issue ( and quite a big one ! ). There are sites using all kinds of firewalls and settings in httpd.conf to restrict access to some hosts or ports ( say from internal network ). If Host: info is used for security checkings - it would be trivial to bypass some of this security. In particular - people may have servlets that check getServerName() to find if 'localhost' was used - the spec change will leave them with a huge hole ( any request with forged Host: localhost will pass ). Good Comment.. In the particular case you have pointed, it's a user problem, a request with Host: Localhost can be only be issued by someone with Remote Ip=localhost.. 'localhost' is just an example. The server may have 2 ip addresses, one visible from outside and one restricted by firewalls to only internal users ( and used for example for content updates ). In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() and get the address that received the request. Since the servlet spec doesn't provide any 'declarative' support for this kind of access control - I think this is a valid solution. A firewall or routing can protect the internal address ( say 10.0.0.1 - on a network card connected only to the internal net, and a firewall restricting outside access to this IP ). In 2.4 this will fail ( opening potential holes ) and in addition this kind of check will be impossible to implement - since the address where the request was received will no longer be available. So one can take some security measures to check the correctness of the request.. For example ? All other use case i can imagine fall within the users problems, if the correct VS has received the request, it's the Remote IP appropiate for that VS? matchs port where the request has been received the port where is suppoussed that the VS is? If by 'user' you mean the servlet author - I disagree. Such checks are prefectly reasonable and correct IMO. But By far in the Journey we have learned something, never trust a Host Header without first trust the Remote IP, at least for ultra-secure apps.. Well, the remoteIP is much more difficult to test - if you're a big organization you may have dozens of internal IPs. And most people do trust their firewalls to restrict access to a particular IP, I've seen this kind of setup in several cases ( where you use a special interface for internal users ). And another thing, i wonder if it would be appropiate to check if a request came from the (at least) correct port before dispatching it to the VS.. at least within TC, and check if Apache2 is taking any measures to be certain of this fact.. The comment in apache sugest that Host shouldn't be trusted. If they started to trust it sudenly - they should at least modify the comment and explain how is this trust justified. Host is sent by the user - it is trivial to forge. The port and host that actually receives the request are pretty safe and difficult to trick, especially if a firewall is used in front. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 30 de agosto de 2002 20:50 Para: Tomcat Developers List Asunto: RE: Spec question: RE BUG 12052 The server may have 2 ip addresses, one visible from outside and one restricted by firewalls to only internal users ( and used for example for content updates ). In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() and get the address that received the request. Since the servlet :), I need to announce that TC is not behaving this way since 2 years ago or more, getServerName and getServerPort relies in the Host header :)), so one never knows if the adapter where the request was received is one or another.. only that the user seems to request some Host: or another.. of course there are ways ( at least in 4.X ) to get to know that a request comes exactly from one address, but they are config tricks.. spec doesn't provide any 'declarative' support for this kind of access control - I think this is a valid solution. A firewall or routing can protect the internal address ( say 10.0.0.1 - on a network card connected only to the internal net, and a firewall restricting outside access to this IP ). In 2.4 this will fail ( opening potential holes ) and in addition this kind of check will be impossible to implement - since the address where the request was received will no longer be available. What 2.4 is trying to specify, is what TC is doing right now, and i agree that the definition open some holes, when TC is behind a webserver, it must be the webserver who decides which are the actual servername and port is, not TC.. Back to the roots, the only use the Host: header has is to select a particular VS, and to get back to the original Request uri ( module encode problems of course :) that was typed by the user, for example to form a correct Location: header in case a 301.. For the second use, clearly Apache does what it suppoussed todo, and more, it documents his behavior in the httpd.conf file # UseCanonicalName: Determines how Apache constructs self-referencing # URLs and the SERVER_NAME and SERVER_PORT variables. # When set Off, Apache will use the Hostname and Port supplied # by the client. When set On, Apache will use the value of the # ServerName directive. # UseCanonicalName Off :) For the VS Matching, apache2 just uses the name ( for name based VS there is no other way to do it ), but not the port supplied ( Just tested ), the port for a VS match in A2 has to be the real socket port.. but never the name can be other than the supplied, cheated or not.. Anyway i have some doubts with the 2.4 spec definition, maybe is too hard to tie this info in the API to the one present in the Host: header, and probably the good behavior is to distinguish if the request comes from the Standalone connector or not, in the case the request comes from SC follow A2 strategies, adding our own UseCanonicalName and so on, but trust A2 ( or IIS or whatever ) if used behind them Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jakarta-servleapi-5
Is needed any process to get to committer access j-s-5? votes or whatever ? If the tomcat people is going to maintain the examples inside there, i think is obvious we need commit access there.. if not i vote to move the examples where mere mortal committers can alleviate the pains of his users.. :) Thanks.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
strange behavior about response object in container
Hi, I am modifying the Tomcat 4.0.4 to make it a proxy cache server. I am extending the container's (StandardHost) invoke(Request, Response) function to be able to forward a request if there is no cache for it. I use the apache commons-httpclient to implement the forwarding semantics. While I implement the transfering of data from httpclient method object to the Response object, I noticed some strange behavior regarding the Response object. What I did is first get a HttpServletResponse object reference from the Response object hresp, then I will call a loop of resp.setHeader() , then I do OutputStream os = resp.getOutputStream(); os.write(response_body_text_as_byte_array) When the origin server is another Tomcat server, it does not work, however if I comment out resp.setHeader(...), it is working (I mean the result shown in the browser) I do the forwarding inside a servlet, even with rest.setHeader(...), it still works. I wonder why is that? BTW, I am using IE 6 as browser. I feel I should do the setting of headers, they may contain cookies and other info. When I try against www.microsoft.com (url in the request), with header setting, it works, without header setting, it does not. Quite the opposite of Tomcat. When I try against www.yahoo.com, i find the same behavior as Tomcat. I wonder how it is related to the origin server, the format of their response or version? Thanks! --Zhenxin Wang DoCoMo Labs USA
Re: jakarta-servleapi-5
I agree! access to changing the examples is hindered. Perhaps we should take a vote like this? [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [ ] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone Cheers, -bob On Fri, 2002-08-30 at 18:07, Ignacio J. Ortega wrote: Is needed any process to get to committer access j-s-5? votes or whatever ? If the tomcat people is going to maintain the examples inside there, i think is obvious we need commit access there.. if not i vote to move the examples where mere mortal committers can alleviate the pains of his users.. :) Thanks.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-servleapi-5
Bob, Good idea. Here's my vote. [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [X] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12200] New: - Translation error thrown when accessing fragment scoped variables
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=12200. 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=12200 Translation error thrown when accessing fragment scoped variables Summary: Translation error thrown when accessing fragment scoped variables Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a jsp:attribute elemnt is used to defined a fragment ,and this fragment in turn takes in a parameter,then a translation time exception is thrown. relevant test : tcatjsp2-tests/jsp2/jspfragpos/jspFragmentAttributes.jsp The error message is attached below: org.apache.jasper.JasperException: /jsp2/jspfragpos/jspFragmentAttributes.jsp(4,36) Not allowed in a template text body. at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:95) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:440) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:126) at org.apache.jasper.compiler.Parser.parseElementsTemplateText(Parser.java:1506) at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1626) at org.apache.jasper.compiler.Parser.parseNamedAttributes(Parser.java:1672) at org.apache.jasper.compiler.Parser.parseJspAttributeAndBody(Parser.java:993) at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:965) at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1257) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1405) at org.apache.jasper.compiler.Parser.parse(Parser.java:149) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:210) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:160) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:257) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:381) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:552) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:241) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 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:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at
Re: [4.1.10] New test milestone released
Not the lucky one... Something like: logic:iterate id=sub name=scope property=associations bean:write name=sub property=value/ /logic:iterate It'll fist generate a duplicated declaration ( once at top level, once at block level ) for _jspx_sub_1, and then look for a variable named 'sub' that is not declared. Costin ( about to leave in vacation :-) Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.10/ Significant changes over 4.1.9 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Stable versions of components from Jakarta Commons, including DBCP 1.0 The list of changes is available in the release notes. Remy -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-servleapi-5
AFAIK jakarta-servletapi is considered a separate project - no idea why and how. I think it's the PMC who can decide about this - a project can't vote to get commit access to a different project. I have no idea how this was set up - but in any case you have my +1 on changing access, and if this is rejected you have my +1 on moving examples in an accessible place. Costin Patrick Luby wrote: Bob, Good idea. Here's my vote. [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [X] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone Patrick -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jakarta-servleapi-5
De: Bob Herrmann [mailto:[EMAIL PROTECTED]] Enviado el: 31 de agosto de 2002 0:42 Para: Tomcat Developers List Asunto: Re: jakarta-servleapi-5 Hola Bob: Ohh yeah, new committers, just readed archives, the vote was in middle august, just when i was toasting myself to death at the Beach, what a pain!!! :)) Welcome aboard anyway!! ;) [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [X] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone Saludos , Ignacio J. Ortega PS.(Hey Sun, we need some beers too, not only developers ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-servleapi-5
How many and who have commit access to j-s-5 currently anyway? How do people get voted in? [X] Change access to jakarta-servletapi-5 to allow all tomcat committers Amy Bob Herrmann wrote: I agree! access to changing the examples is hindered. Perhaps we should take a vote like this? [ ] Create new jakarta-servletjsp-examples [ ] Move examples into another exiting repository [?fill this in?] [ ] Change access to jakarta-servletapi-5 to allow all tomcat committers [ ] Leave it all alone Cheers, -bob On Fri, 2002-08-30 at 18:07, Ignacio J. Ortega wrote: Is needed any process to get to committer access j-s-5? votes or whatever ? If the tomcat people is going to maintain the examples inside there, i think is obvious we need commit access there.. if not i vote to move the examples where mere mortal committers can alleviate the pains of his users.. :) Thanks.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12200] - Translation error thrown when accessing fragment scoped variables
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=12200. 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=12200 Translation error thrown when accessing fragment scoped variables [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-31 00:04 --- The TLD referenced in the jsp file contains elements fragment-attribut and fragment-input which removed from the spec in PFD. Wonder why the schema for TLD is not giving out error message? Is it turned off by default now? Withou proper info from TLD, jasper is assuming a template text body for jsp:attribute and disallowd EL in it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12201] New: - Problme defining values for type element in attributes of custom actions
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=12201. 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=12201 Problme defining values for type element in attributes of custom actions Summary: Problme defining values for type element in attributes of custom actions Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the type element of an attribute belonging to a Custom Attribute is specified as boolean then a translation exception occurs which says : Unknown attribute type (boolean) for attribute test This happens with the JSTL tag c:when This also happens when a attribute has String defined as type. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jakarta-servleapi-5
De: Amy Roh [mailto:[EMAIL PROTECTED]] Enviado el: 31 de agosto de 2002 2:04 Para: Tomcat Developers List Asunto: Re: jakarta-servleapi-5 How many and who have commit access to j-s-5 currently bash-2.04$ grep servletapi /home/cvs/CVSROOT/avail avail|craigmcc,eduardop,dannyc,jhunter,jon,kinman,remm,patrickl|jakarta- servletapi,jakarta-servletapi-4,jakarta-servletapi-5 bash-2.04$ Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-servleapi-5
Ignacio J. Ortega wrote: De: Amy Roh [mailto:[EMAIL PROTECTED]] Enviado el: 31 de agosto de 2002 2:04 Para: Tomcat Developers List Asunto: Re: jakarta-servleapi-5 How many and who have commit access to j-s-5 currently bash-2.04$ grep servletapi /home/cvs/CVSROOT/avail avail|craigmcc,eduardop,dannyc,jhunter,jon,kinman,remm,patrickl|jakarta- servletapi,jakarta-servletapi-4,jakarta-servletapi-5 bash-2.04$ I see. Gracias, :-) Amy Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12203] New: - Tomcat Apache log errors when accessing Tomcat via Apache
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=12203. 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=12203 Tomcat Apache log errors when accessing Tomcat via Apache Summary: Tomcat Apache log errors when accessing Tomcat via Apache Product: Tomcat 4 Version: 4.0.4 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 1. Apache 1.3.26 Tomcat 4.0.4 on same host. latest mod_webapp.so; 2. Installed/configured Apache, Tomcat mod_webapp.so as instructed; http://myserver.mycfo.com:8080/examples work well (jsp servlet); 3. Created VirtualHost apache.mycfo.com and verified it works all right; then added: WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples in VirtualHost ... block; 4. Changed Name= in Engine ... of server.xml to apache.mycfo.com; 5. Access http://apache.mycfo.com/examples/jsp got The page cannot be displayed. 6. Check logs: 6.1 Apache logs/error_log: [Fri Aug 30 14:33:11 2002] [notice] child pid 7839 exit signal Segmentation Fault (11) 6.2 Tomcat logs/apache_log.2002-08-30.txt: 2002-08-30 14:33:10 WarpEngine[apache.mycfo.com]: Mapping request 2002-08-30 14:33:10 WarpHost[apache.mycfo.com]: Mapping request for Host 2002-08-30 14:33:10 [org.apache.catalina.connector.warp.WarpConnector] Connection from /127.0.0.1:44034 to /127.0.0.1:8008 2002-08-30 14:33:10 [org.apache.catalina.connector.warp.WarpConnection] Exception on socket java.io.IOException: Premature packet header end at org.apache.catalina.connector.warp.WarpConnection.recv(WarpConnection.java:237) at org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHandler.java:112) at org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java:194) at java.lang.Thread.run(Thread.java:536) 2002-08-30 14:33:11 [org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings (2) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Fri, 2002-08-30 at 23:51, Ignacio J. Ortega wrote: De: Bojan Smojver [mailto:[EMAIL PROTECTED]] Enviado el: 30 de agosto de 2002 1:11 Para: Tomcat Dev List Asunto: RE: Spec question: RE BUG 12052 On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote: We know how r-parsed_uri.port gets his value? Yep. It's getting it from the URL, not the headers. Wrong, It takes the port and ServerName from the Host: header if the Request-uri is relative ( most common case ) and from the Reqeust-Uri if it is absolute.. rfc2616 Section 5.2 strict compliance.. I had another look at Apache 2.0 code and I think you're right. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12200] - Translation error thrown when accessing fragment scoped variables
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=12200. 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=12200 Translation error thrown when accessing fragment scoped variables [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-08-31 01:02 --- This happend after I cahnged the TLD to have variable elemenst with a fragment sub element in conformance with the spec. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12204] New: - Validation of TLD does not happen
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=12204. 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=12204 Validation of TLD does not happen Summary: Validation of TLD does not happen Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If a tLD has element which are incvalid then Tomcat does not thrwo an error either at startup or translation time of the JSP that refers to this TLD. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12204] - Validation of TLD does not happen
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=12204. 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=12204 Validation of TLD does not happen [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-31 02:26 --- XML validation is off by default in Tomcat 5. To enable XML validation, add the following 2 attributes to each Host element in conf/server.xml: xmlValidation=true xmlNamespaceAware=true -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] Build and run the catalina tester webapp against tomcat5
This patch builds the catalina tester app in the context of tomcat-5, and installs and runs in the tmp directory, the same way that watchdog is run. I had to change a couple of the build variables in tester, to match some of the new ones. Also the examples web app is not expanded by default, so the 'touch' tasks had to be removed. Since the tomcat.base is rebuilt every run, the touches are redundant. Unfortunately, many of the tester tests are failing. I don't know, yet, if they are bugs in tester or bugs in tomcat. But at least there's a baseline for comparison. -- Steve Downey -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/08/30 20:37:16
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Do not process named attribute using property editor if it is a fragment
Revision ChangesPath
1.87 +6 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- Generator.java30 Aug 2002 16:54:09 - 1.86
+++ Generator.java31 Aug 2002 03:37:16 - 1.87
@@ -2515,10 +2515,12 @@
if (attrs[i].isExpression()) {
// Do nothing
} else if (attrs[i].isNamedAttribute()) {
- attrValue = convertString(
+ if (!n.checkIfAttributeIsJspFragment(attrs[i].getName())) {
+ attrValue = convertString(
c[0], attrValue, attrName,
handlerInfo.getPropertyEditorClass(attrName),
false);
+ }
} else if (attrs[i].isELInterpreterInput()) {
// run attrValue through the expression interpreter
attrValue = JspUtil.interpreterCall(this.isTagFile,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
