DO NOT REPLY [Bug 13378] - Generated code assumes definition of getServletContext() in base class.
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=13378. 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=13378 Generated code assumes definition of getServletContext() in base class. --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 06:38 --- I think bug is in org.apache.jasper.compiler.TagPoolManagerGenerator.generate(ServletWriter,Class) [I'm looking at TagPoolManagerGenerator.java 1.3] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java LocalStrings.properties
remm2002/10/08 00:56:04
Modified:catalina/src/share/org/apache/catalina/servlets Tag:
tomcat_40_branch DefaultServlet.java
LocalStrings.properties
Log:
- Add additional safeguards for 4.0.x.
Revision ChangesPath
No revision
No revision
1.39.2.7 +22 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.39.2.6
retrieving revision 1.39.2.7
diff -u -r1.39.2.6 -r1.39.2.7
--- DefaultServlet.java 18 Apr 2002 03:08:04 - 1.39.2.6
+++ DefaultServlet.java 8 Oct 2002 07:56:04 - 1.39.2.7
@@ -97,6 +97,7 @@
import javax.servlet.ServletException;
import javax.servlet.ServletContext;
import javax.servlet.ServletOutputStream;
+import javax.servlet.UnavailableException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@@ -515,6 +516,11 @@
if (debug 999)
showRequestInfo(request);
+// Verify that we were not accessed using the invoker servlet
+if (request.getAttribute(Globals.INVOKED_ATTR) != null)
+throw new UnavailableException
+(sm.getString(defaultServlet.cannotInvoke));
+
// Serve the requested resource, including the data content
serveResource(request, response, true);
@@ -534,6 +540,11 @@
HttpServletResponse response)
throws IOException, ServletException {
+// Verify that we were not accessed using the invoker servlet
+if (request.getAttribute(Globals.INVOKED_ATTR) != null)
+throw new UnavailableException
+(sm.getString(defaultServlet.cannotInvoke));
+
// Serve the requested resource, without the data content
serveResource(request, response, false);
@@ -552,7 +563,14 @@
protected void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
+
+// Verify that we were not accessed using the invoker servlet
+if (request.getAttribute(Globals.INVOKED_ATTR) != null)
+throw new UnavailableException
+(sm.getString(defaultServlet.cannotInvoke));
+
doGet(request, response);
+
}
1.9.2.1 +1 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties,v
retrieving revision 1.9
retrieving revision 1.9.2.1
diff -u -r1.9 -r1.9.2.1
--- LocalStrings.properties 15 Sep 2001 23:31:30 - 1.9
+++ LocalStrings.properties 8 Oct 2002 07:56:04 - 1.9.2.1
@@ -1,3 +1,4 @@
+defaultServlet.cannotInvoke=Cannot invoke default servlet through invoker
defaultservlet.directorylistingfor=Directory Listing for:
defaultservlet.upto=Up to:
defaultservlet.subdirectories=Subdirectories:
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2002/10/08 00:58:23 Modified:.RELEASE-NOTES-4.1.txt Log: - Add an explicit warning. Revision ChangesPath 1.23 +4 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- RELEASE-NOTES-4.1.txt 24 Sep 2002 08:35:48 - 1.22 +++ RELEASE-NOTES-4.1.txt 8 Oct 2002 07:58:23 - 1.23 @@ -842,3 +842,6 @@ default in all webapp. Enabling it for all webapps is possible by editing $CATALINA_HOME/conf/web.xml to uncomment the /servlet/* servlet-mapping definition. + +Using the invoker servlet in a production environment is not recommended and +is unsupported. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP 2.0's J2SE 1.4 Requirement
On 5/10/02 12:43 am, Mark Roth [EMAIL PROTECTED] wrote: It has been brought to my attention that some members of the Tomcat community have expressed a desire to see a requirement lower than J2SE 1.4 in JSP 2.0. Great... One more reason to start thinking about kicking JSP out of the door! :-) I'm not going to run 1.4 in production for quite some time :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP 2.0's J2SE 1.4 Requirement
Costin Manolache wrote: iasandcb wrote: Now it's almost clear that SRV 2.4 requires JDK 1.2 and JSP 2.0 does JDK 1.4. The main issue is discrepancy of J2SE requirement between SRV 2.4 and JSP 2.0, which are supposed to come up together. Actually, it isn't. All we know is that the current draft has this requirement. We should find a proper procedure ( for example a vote on tomcat dev ) and then ask our representative in JCP ( Geir for example - he's a very nice person ) to request a change. I don't know what's the proper mechanism yet - but Apache does have a representative and a vote, and we should have a way to have the opinion of tomcat-dev expressed. If the final JSP2.0 will require 1.4 - then we'll have to do that. It would be very unfortunate ( especially for jsp people ), and will require ( IMO ) a separate tomcat without JSPs. My opinion ( and it seems a lot of people have the same opinion ) that portability ( in the sense of beeing able to run on most OS and platforms ) seems to agree with what Apache is doing in most projects ( Apache server runs on more platforms than java - and did that even before 'write once, run everywhere'). We should first explore the alternative for having this opinion confirmed ( vote ? ) and expressed in the expert group. If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. +1 here . If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or 4.1.x on my Linux and iSeries productions boxes. Could we imagine alternatives ? - Tomcat 5 using Serlvet 2.3/JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0 depending the JVM found at runtime ? - Tomcat 5 bundled without JSP 2.0 ? - Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ? I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0) will delay for a long time its adoption by companies, until all platform got JDK 1.4, which means for example that people which use IBM SDK on Linux or mainframes systems will have to wait up to the end of year ad minima. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13398] New: - CoyoteInputStream positioned at the end of the stream
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=13398. 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=13398 CoyoteInputStream positioned at the end of the stream Summary: CoyoteInputStream positioned at the end of the stream Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi. Here is the problem : I get a stream from a HttpServletRequest object with the getInputStream method. The returned stream (a CoyoteInputStream object) is ok, but it's current position is always set to the end of the stream ! I've fixed temporary the bug on my local installation by forcing the stream to be read from the begining but an other problem occurs : the input stream contains sometimes the http header ! Thanks ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13398] - CoyoteInputStream positioned at the end of the stream
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=13398. 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=13398 CoyoteInputStream positioned at the end of the stream [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 08:55 --- Hmmm, no sorry. Posting and putting works fine with non broken clients and standlone mode. (and upgrade to 4.1.12) I will require a full test case (client + server) to resolve this as something other that WORKSFORME. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tomcat4 write in conf files which is not FHS compliant
Hi to all, Tomcat 4 make write access to 2 files in the conf directory, jk2.properties and tomcat-users.xml (and may be others). The problem is that FHS indicate that a conf directory should be read only. For instance, tomcat4 rpm install the conf directory in /etc/tomcat4 and use symlink to map it to /var/tomcat4/conf. What could be done to have a behaviour following FHS recommandations ? Could we imagine having jk2.properties and tomcat-users.xml (and other files in conf which may be updated by tomcat4) in another directory, ie work/conf ? Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Hello list, I'm updating from Tomcat 4.0.2 to 4.1.12 and decided to upgrade the Tomcat connector as well. I've had some problems with mod_webapp before, and as Tomcat docs recommend mod_jk2 over deprecated mod_jk, I chose JK2. I'm running Tomcat 4.1.12 and Apache 1.13.26 on Solaris 8, and having hard time trying to get mod_jk2 to work with Apache. I'm not a C-programmer, so makefiles, compiler settings, linkers etc. are bit of a mystery to me. However, this is what I have done: Compile mod_jk2 (2.0.0 / 2.0.1) with gcc 3.2: [root@solaris native2]# setenv CC /usr/local/bin/gcc [root@solaris native2]# setenv CFLAGS -DBSD_COMP -fPIC [root@solaris native2]# chmod u+x buildconf.sh [root@solaris native2]# ./buildconf.sh [root@solaris native2]# ./configure --with-apxs=/opt/apache/bin/apxs --with-tomcat41=/opt/jakarta-tomcat-4.1.12 [root@solaris native2]# make [root@solaris native2]# cd ../build/jk2/apache13 [root@solaris apache13]# cp mod_jk2.so /opt/apache/libexec Make will fail if I remove either of the compiler flags... not sure what they do, required a lot of Google searches (and some trial error) to get even this far. Maybe I've done something wrong here? Then I configured Apache and Tomcat to use mod_jk2 (workers2.properties, jk2.properties). Everything seems to be in place, but when I try to start Apache, it fails with a segmentation fault. Last lines of jk2.log: [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (345)]: shm.init(): file=/opt/apache/logs/jk2.shm size=1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (257)]: shm.create(): file open /opt/apache/logs/jk2.shm 1048576 1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (365)]: shm.create(): shm created 0xfe30 Last lines of truss output: 20309: open(/opt/apache/logs/jk2.shm, O_RDWR|O_CREAT, 0777) = 3 20309: stat(/opt/apache/logs/jk2.shm, 0xFFBEF970)= 0 20309: d=0x0225 i=329401 m=0100755 l=1 u=0 g=1 sz=1048576 20309: at = Oct 8 11:50:08 EEST 2002 [ 1034067008 ] 20309: mt = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: ct = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: bsz=8192 blks=2064 fs=ufs 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 119) = 119 20309: mmap(0x, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xFE30 20309: close(3)= 0 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 91) = 91 20309: time() = 1034067008 20309: Incurred fault #6, FLTBOUNDS %pc = 0xFF1B3144 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x 20309: Received signal #11, SIGSEGV [default] 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Should I just stick with mod_webapp? Regards, Hannu Kivimaki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jmx and context administration
hi all, currently I am working with tomcat-4.1-cvs-head and mx4j. I have looked at the org.apache.catalina.mbeans package but couldn't find a MBean or a Method for adding contexts to a catalina host entry. What I want to do is stop start and add a context to catalina during runtime w/ JMX, as I have some huge context I want to enable on demand. - is this feature currently implemented? - is anybody working on implementing a feature like that? - is catalina capable of dynamic context unloading ( i think so, as AFAIR the manager privileged context is able to do this ) - are you planing on implementing a jmx/connector to connect to jmx via rmi or something like this? thanks -- Jakob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
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=13392. 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=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 09:12 --- This is completely normal, and your tag is not spec compliant (see the lifecycle diagram). Release is only called when the instance will be marked for GCing. You can either disable tag pooling or fix your tag. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml tomcat.nsi
remm2002/10/08 02:36:39
Modified:.build.xml tomcat.nsi
Log:
- Update to NSIS CVS.
Revision ChangesPath
1.37 +0 -2 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- build.xml 29 Sep 2002 15:08:22 - 1.36
+++ build.xml 8 Oct 2002 09:36:39 - 1.37
@@ -403,8 +403,6 @@
fileset dir=resources /
/copy
copy file=${nsis.installoptions.dll} todir=${tomcat.dist} /
-copy file=${nsis.home}/Examples/Modern UI/ModernUI.nsh
- todir=${tomcat.dist} /
copy file=${javaservice.exe} tofile=${tomcat.dist}/bin/tomcat.exe /
filter token=VERSION value=${version}/
copy file=tomcat.nsi tofile=${tomcat.dist}/tomcat.nsi
1.8 +33 -29jakarta-tomcat-5/tomcat.nsi
Index: tomcat.nsi
===
RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- tomcat.nsi29 Sep 2002 15:08:22 - 1.7
+++ tomcat.nsi8 Oct 2002 09:36:39 - 1.8
@@ -6,12 +6,17 @@
!define VERSION @VERSION@
!verbose 3
- !include ModernUI.nsh
+ !include ${NSISDIR}\Contrib\Modern UI\System.nsh
!verbose 4
;
;Configuration
+ ;Language
+;English
+LoadLanguageFile ${NSISDIR}\Contrib\Language files\English.nlf
+!include ${NSISDIR}\Contrib\Modern UI\English.nsh
+
;General
Name ${NAME} ${VERSION}
OutFile tomcat-installer.exe
@@ -33,11 +38,11 @@
ComponentText Check the components you want to install and uncheck the
components you don't want to install. Click Next to continue.
;Folder-select dialog
+ !insertmacro MUI_ENGLISH_DIRTEXT
InstallDir $PROGRAMFILES\Apache Group\Tomcat 5.0
- DirText Setup will install ${NAME} in the following folder.$\r$\n$\r$\nTo
install in this folder, click Install. To install in a different folder, click Browse
and select another folder.
;Uninstaller
- UninstallText This will uninstall ${NAME} from your system.
+ !insertmacro MUI_ENGLISH_UNINSTALLTEXT
InstType Normal
InstType Minimum
@@ -210,17 +215,17 @@
!insertmacro MUI_INNERDIALOG_INIT
!insertmacro MUI_INNERDIALOG_START 1
- !insertmacro MUI_INNERDIALOG_TEXT 1033 1040 If you accept all the terms of
the agreement, choose I Agree to continue. If you choose Cancel, Setup will close. You
must accept the agreement to install ${NAME}.
+ !insertmacro MUI_INNERDIALOG_TEXT 1040 $(MUI_INNERTEXT_LICENSE)
!insertmacro MUI_INNERDIALOG_STOP 1
!insertmacro MUI_INNERDIALOG_START 2
- !insertmacro MUI_INNERDIALOG_TEXT 1033 1042 Description
- !insertmacro MUI_INNERDIALOG_TEXT 1033 1043 Hover your mouse over a
component to see it's description.
+ !insertmacro MUI_INNERDIALOG_TEXT 1042 $(MUI_INNERTEXT_DESCRIPTION_TITLE)
+ !insertmacro MUI_INNERDIALOG_TEXT 1043 $(MUI_INNERTEXT_DESCRIPTION_INFO)
!insertmacro MUI_INNERDIALOG_STOP 2
!insertmacro MUI_INNERDIALOG_START 3
- !insertmacro MUI_INNERDIALOG_TEXT 1033 1041 Destination Folder
- !insertmacro MUI_INNERDIALOG_STOP 3
+ !insertmacro MUI_INNERDIALOG_TEXT 1041 $(MUI_INNERTEXT_DESTINATIONFOLDER)
+!insertmacro MUI_INNERDIALOG_STOP 3
!insertmacro MUI_INNERDIALOG_END
@@ -243,28 +248,28 @@
!insertmacro MUI_PAGE_INIT
!insertmacro MUI_PAGE_START 1
- !insertmacro MUI_HEADER_TEXT 1033 License Agreement Please review the
license terms before installing ${NAME}.
+ !insertmacro MUI_HEADER_TEXT $(MUI_TEXT_LICENSE_TITLE)
$(MUI_TEXT_LICENSE_SUBTITLE)
!insertmacro MUI_PAGE_STOP 1
!insertmacro MUI_PAGE_START 2
- !insertmacro MUI_HEADER_TEXT 1033 Choose Components Choose the components
you want to install.
+ !insertmacro MUI_HEADER_TEXT $(MUI_TEXT_COMPONENTS_TITLE)
$(MUI_TEXT_COMPONENTS_SUBTITLE)
!insertmacro MUI_PAGE_STOP 2
!insertmacro MUI_PAGE_START 3
- !insertmacro MUI_HEADER_TEXT 1033 Choose Install Location Choose the
folder in which to install ${NAME}.
-!insertmacro MUI_PAGE_STOP 3
+ !insertmacro MUI_HEADER_TEXT $(MUI_TEXT_DIRSELECT_TITLE)
$(MUI_TEXT_DIRSELECT_SUBTITLE)
+ !insertmacro MUI_PAGE_STOP 3
!insertmacro MUI_PAGE_START 4
- !insertmacro MUI_HEADER_TEXT 1033 Installing Please wait while ${NAME} is
being installed.
+ !insertmacro MUI_HEADER_TEXT $(MUI_TEXT_INSTALLING_TITLE)
$(MUI_TEXT_INSTALLING_SUBTITLE)
!insertmacro MUI_PAGE_STOP 4
!insertmacro MUI_PAGE_START 5
- !insertmacro MUI_HEADER_TEXT 1033
Re: tomcat4 write in conf files which is not FHS compliant
Henri Gomez wrote: Hi to all, Tomcat 4 make write access to 2 files in the conf directory, jk2.properties and tomcat-users.xml (and may be others). The problem is that FHS indicate that a conf directory should be read only. I have the same problem with /opt where I am installing Tomcat. For instance, tomcat4 rpm install the conf directory in /etc/tomcat4 and use symlink to map it to /var/tomcat4/conf. What could be done to have a behaviour following FHS recommandations ? Could we imagine having jk2.properties and tomcat-users.xml (and other files in conf which may be updated by tomcat4) in another directory, ie work/conf ? I am using catalina-home and catalina-base. catalina-home contains the fixed data. catalina-base contains the instance data. I have the following (opt/SMAWoIS/jakarta-tomcat-4.1.12 is catalina-home): +++ # ls -l /opt/SMAWoIS/jakarta-tomcat total 12 drwxr-xr-x 2 root other512 Oct 8 11:34 bin drwxr-xr-x 2 nobody other512 Oct 8 11:31 conf drwxr-xr-x 4 root other512 Oct 3 10:32 conf.save drwxr-xr-x 2 nobody other512 Oct 8 11:31 logs lrwxrwxrwx 1 root other 42 Oct 8 11:31 webapps - /opt/SMAWoIS/jakarta-tomcat-4.1.12/webapps drwxr-xr-x 3 nobody other512 Oct 3 12:04 work +++ The user nobody needs to write in conf because of these 2 files. That is the same for logs because the log files are not created at the right place in time (I am using daemon to start the Tomcat). conf.save is a save of the conf directory. Regards -- 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: JSP 2.0's J2SE 1.4 Requirement
Henri Gomez wrote: Costin Manolache wrote: iasandcb wrote: Now it's almost clear that SRV 2.4 requires JDK 1.2 and JSP 2.0 does JDK 1.4. The main issue is discrepancy of J2SE requirement between SRV 2.4 and JSP 2.0, which are supposed to come up together. Actually, it isn't. All we know is that the current draft has this requirement. We should find a proper procedure ( for example a vote on tomcat dev ) and then ask our representative in JCP ( Geir for example - he's a very nice person ) to request a change. I don't know what's the proper mechanism yet - but Apache does have a representative and a vote, and we should have a way to have the opinion of tomcat-dev expressed. If the final JSP2.0 will require 1.4 - then we'll have to do that. It would be very unfortunate ( especially for jsp people ), and will require ( IMO ) a separate tomcat without JSPs. My opinion ( and it seems a lot of people have the same opinion ) that portability ( in the sense of beeing able to run on most OS and platforms ) seems to agree with what Apache is doing in most projects ( Apache server runs on more platforms than java - and did that even before 'write once, run everywhere'). We should first explore the alternative for having this opinion confirmed ( vote ? ) and expressed in the expert group. If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. +1 here . If Tomcat 5 require JDK 1.4, I'll have to stay with Tomcat 3.3.x or 4.1.x on my Linux and iSeries productions boxes. Could we imagine alternatives ? - Tomcat 5 using Serlvet 2.3/JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 ? - Tomcat 5 using Servlet 2.4 and JSP 1.2 or JSP 2.0 depending the JVM found at runtime ? - Tomcat 5 bundled without JSP 2.0 ? - Tomcat 5 bundled with velocity or tea instead of JSP 2.0 ? I'm afraid that making JDK 1.4 mandatory for Tomcat 5 (or JSP 2.0) will delay for a long time its adoption by companies, until all platform got JDK 1.4, which means for example that people which use IBM SDK on Linux or mainframes systems will have to wait up to the end of year ad minima. As I will probably have to deliver JSP 2.0 with the next Tomcat I would prefer that JSP 2.0 only requires JDK 1.3. But I like the idea of having a modular Tomcat. So Tomcat 5 bundled without JSP 2.0 but with ready for adding adding JSP, velocity or whatever sounds great. -- 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: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Hannu Kivimäki wrote: Hello list, I'm updating from Tomcat 4.0.2 to 4.1.12 and decided to upgrade the Tomcat connector as well. I've had some problems with mod_webapp before, and as Tomcat docs recommend mod_jk2 over deprecated mod_jk, I chose JK2. I'm running Tomcat 4.1.12 and Apache 1.13.26 on Solaris 8, and having hard time trying to get mod_jk2 to work with Apache. I'm not a C-programmer, so makefiles, compiler settings, linkers etc. are bit of a mystery to me. However, this is what I have done: Compile mod_jk2 (2.0.0 / 2.0.1) with gcc 3.2: [root@solaris native2]# setenv CC /usr/local/bin/gcc [root@solaris native2]# setenv CFLAGS -DBSD_COMP -fPIC [root@solaris native2]# chmod u+x buildconf.sh [root@solaris native2]# ./buildconf.sh [root@solaris native2]# ./configure --with-apxs=/opt/apache/bin/apxs --with-tomcat41=/opt/jakarta-tomcat-4.1.12 [root@solaris native2]# make [root@solaris native2]# cd ../build/jk2/apache13 [root@solaris apache13]# cp mod_jk2.so /opt/apache/libexec Make will fail if I remove either of the compiler flags... not sure what they do, required a lot of Google searches (and some trial error) to get even this far. Maybe I've done something wrong here? Then I configured Apache and Tomcat to use mod_jk2 (workers2.properties, jk2.properties). Everything seems to be in place, but when I try to start Apache, it fails with a segmentation fault. Last lines of jk2.log: [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (345)]: shm.init(): file=/opt/apache/logs/jk2.shm size=1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (257)]: shm.create(): file open /opt/apache/logs/jk2.shm 1048576 1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (365)]: shm.create(): shm created 0xfe30 Last lines of truss output: 20309: open(/opt/apache/logs/jk2.shm, O_RDWR|O_CREAT, 0777) = 3 20309: stat(/opt/apache/logs/jk2.shm, 0xFFBEF970)= 0 20309: d=0x0225 i=329401 m=0100755 l=1 u=0 g=1 sz=1048576 20309: at = Oct 8 11:50:08 EEST 2002 [ 1034067008 ] 20309: mt = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: ct = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: bsz=8192 blks=2064 fs=ufs 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 119) = 119 20309: mmap(0x, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xFE30 20309: close(3)= 0 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 91) = 91 20309: time() = 1034067008 20309: Incurred fault #6, FLTBOUNDS %pc = 0xFF1B3144 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x 20309: Received signal #11, SIGSEGV [default] 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Could you send more information from the core dump? Should I just stick with mod_webapp? If it works for you, why not ;-) Regards, Hannu Kivimaki -- 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: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Hi Jean-Frederic, And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Could you send more information from the core dump? Sure, but I'm not very familiar with C and debugging, so I need some instructions. I have the dump file, root access and the server seems to have mdb (and older adb) installed. What should I type in debugger? Hannu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Hannu Kivimäki wrote: Hi Jean-Frederic, And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Could you send more information from the core dump? Sure, but I'm not very familiar with C and debugging, so I need some instructions. I have the dump file, root access and the server seems to have mdb (and older adb) installed. What should I type in debugger? Something like $c: +++ $ mdb ./toto core Loading modules: [ ] $c libc.so.1`memset+0x3c(1, ffbefd44, ffbefd4c, 20800, 0, 0) _start+0x108(0, 0, 0, 0, 0, 0) +++ Hannu -- 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: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Could you send more information from the core dump? Sure, but I'm not very familiar with C and debugging, so I need some instructions. I have the dump file, root access and the server seems to have mdb (and older adb) installed. What should I type in debugger? Something like $c: +++ $ mdb ./toto core Loading modules: [ ] $c libc.so.1`memset+0x3c(1, ffbefd44, ffbefd4c, 20800, 0, 0) _start+0x108(0, 0, 0, 0, 0, 0) +++ Ok... Loading modules: [ ] $c libc.so.1`strlen+0x80(0, d2d11, 0, a2e81, 0, fe674f8b) libc.so.1`vsnprintf+0x5c(ffbed7e9, 7fff, fe674f70, ffbef8a4, fe674f5d, 90) mod_jk2.so`jk2_logger_file_jkVLog+0x480(b2068, b3998, fe674f50, 90, 0, fe674f70) mod_jk2.so`jk2_logger_file_jkLog+0x44(b2068, b3998, fe674f50, 90, 0, fe674f70) mod_jk2.so`jk2_uriMap_addUriEnv+0xb0(b2068, b49f0, d2c50, fe666334, 0, d2475) mod_jk2.so`jk2_uriEnv_factory+0x198(b2068, d23e8, d2420, d2478, d2480, fe665f7c) mod_jk2.so`jk2_env_createBean2+0x420(b2068, b4118, fe675000, fe674fc8, fe65a30c, fe674a00) mod_jk2.so`jk2_uriMap_init+0x74(b2068, b49f0, fe667784, fe65ce80, fe65a30c, fe676730) mod_jk2.so`jk2_workerEnv_init+0x370(b2068, b41d0, fe66ef78, 12a, 1, fe676df0) mod_jk2.so`jk2_init+0x130(a54c8, a54a0, fe67191c, 0, 6f725741, 6f723131) ap_init_modules+0x58(a54a0, a54c8, a2400, 0, ff23cfdc, 86c80) main+0x4fc(1, ffbefd2c, ffbefd34, a2e78, 0, 0) _start+0x5c(0, 0, 0, 0, 0, 0) Hannu *** Hannu Kivimäki IT-suunnittelija Suomen Keltaiset Sivut Oy / Verkkomedia Kalevankatu 30, 00100 Helsinki Tel +358 10 7010 266 Fax +358 10 7010 231 [EMAIL PROTECTED] *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[POLL/VOTE] tcpnodelay to true by default ?
What about setting tcpnodelay to true by default for Ajp13 connectors java implemtations ? It should fix MacOS X latency problems and should be the default for any persistant connections... Comments welcome... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets InvokerServlet.java
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 5:34 AM remm2002/10/07 13:33:31 Modified:catalina/src/share/org/apache/catalina/servlets Tag: tomcat_40_branch InvokerServlet.java Log: - Port patch. - Proposed fix for 13365. Please review. I have confirmed the fix for 13365. When I requested the /examples/servlet/default/jsp/snp/snoop.jsp url on the browser, HTTP 404 Status had been returned. The patch I suggested to Bugzilla 13365 is unnecessary. Thanks. -- Kan Ogawa [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.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=12699. 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=12699 Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1 --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 13:20 --- We have the same problem with 1.3.23 with mod_perl, mod_php, mod_proxy, and mod_ssl. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/lib tomcat-coyote.jar tomcat-http11.jar tomcat-util.jar
remm2002/10/08 06:28:25 Modified:lib Tag: tomcat_40_branch tomcat-coyote.jar tomcat-http11.jar tomcat-util.jar Log: - Update J-T-C components. Revision ChangesPath No revision No revision 1.1.2.5 +171 -177 jakarta-tomcat-4.0/lib/Attic/tomcat-coyote.jar Binary file 1.1.2.5 +106 -95 jakarta-tomcat-4.0/lib/Attic/tomcat-http11.jar Binary file 1.1.2.11 +693 -512 jakarta-tomcat-4.0/lib/Attic/tomcat-util.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Globals.java
remm2002/10/08 06:31:53 Modified:catalina/src/share/org/apache/catalina Tag: tomcat_40_branch Globals.java Log: - Update version number. Revision ChangesPath No revision No revision 1.39.2.26 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java Index: Globals.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v retrieving revision 1.39.2.25 retrieving revision 1.39.2.26 diff -u -r1.39.2.25 -r1.39.2.26 --- Globals.java 24 Sep 2002 08:34:40 - 1.39.2.25 +++ Globals.java 8 Oct 2002 13:31:53 - 1.39.2.26 @@ -219,7 +219,7 @@ /** * The descriptive information about this server and version. */ -public static final String SERVER_INFO = Apache Tomcat/4.0.6-dev; +public static final String SERVER_INFO = Apache Tomcat/4.0.6; /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html
remm2002/10/08 06:32:16 Modified:webapps/ROOT Tag: tomcat_40_branch index.html Log: - Update version number. Revision ChangesPath No revision No revision 1.29.2.25 +1 -1 jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html,v retrieving revision 1.29.2.24 retrieving revision 1.29.2.25 diff -u -r1.29.2.24 -r1.29.2.25 --- index.html24 Sep 2002 08:35:09 - 1.29.2.24 +++ index.html8 Oct 2002 13:32:16 - 1.29.2.25 @@ -44,7 +44,7 @@ td align=left valign=top table trtd align=left valign=topbTomcat/b/td/tr -trtd align=left valign=topbVersion 4.0.6 Dev/b/td/tr +trtd align=left valign=topbVersion 4.0.6/b/td/tr /table /td td align=righta href=http://jakarta.apache.org/;img src=jakarta-banner.gif height=100 width=350 border=0 alt=The Jakarta Project/a/td -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0.6.txt
remm2002/10/08 06:34:54 Added: .Tag: tomcat_40_branch RELEASE-NOTES-4.0.6.txt Log: - Add release notes. Revision ChangesPath No revision No revision 1.1.2.1 +284 -0jakarta-tomcat-4.0/Attic/RELEASE-NOTES-4.0.6.txt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Globals.java
remm2002/10/08 06:37:57 Modified:catalina/src/share/org/apache/catalina Tag: tomcat_40_branch Globals.java Log: - Revert version number. Revision ChangesPath No revision No revision 1.39.2.27 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java Index: Globals.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v retrieving revision 1.39.2.26 retrieving revision 1.39.2.27 diff -u -r1.39.2.26 -r1.39.2.27 --- Globals.java 8 Oct 2002 13:31:53 - 1.39.2.26 +++ Globals.java 8 Oct 2002 13:37:57 - 1.39.2.27 @@ -219,7 +219,7 @@ /** * The descriptive information about this server and version. */ -public static final String SERVER_INFO = Apache Tomcat/4.0.6; +public static final String SERVER_INFO = Apache Tomcat/4.0.7-dev; /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html
remm2002/10/08 06:38:19 Modified:webapps/ROOT Tag: tomcat_40_branch index.html Log: - Revert version number. Revision ChangesPath No revision No revision 1.29.2.26 +1 -1 jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/ROOT/Attic/index.html,v retrieving revision 1.29.2.25 retrieving revision 1.29.2.26 diff -u -r1.29.2.25 -r1.29.2.26 --- index.html8 Oct 2002 13:32:16 - 1.29.2.25 +++ index.html8 Oct 2002 13:38:19 - 1.29.2.26 @@ -44,7 +44,7 @@ td align=left valign=top table trtd align=left valign=topbTomcat/b/td/tr -trtd align=left valign=topbVersion 4.0.6/b/td/tr +trtd align=left valign=topbVersion 4.0.7 Dev/b/td/tr /table /td td align=righta href=http://jakarta.apache.org/;img src=jakarta-banner.gif height=100 width=350 border=0 alt=The Jakarta Project/a/td -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
mod_webapp has been orphaned. mod_jk JK2 is a new codebase that is still considered beta. mod_jk 1.2 with Ajp13 has been relatively stable for a while. I use this combination with Apache 1.3.26 on both Solaris 7 and Solaris 8 on sparc for production systems using Tomcat 4.1.12. IHMO, mod_jk 1.2 is currently the best choice for production. Regards, Glenn Hannu Kivimäki wrote: Hello list, I'm updating from Tomcat 4.0.2 to 4.1.12 and decided to upgrade the Tomcat connector as well. I've had some problems with mod_webapp before, and as Tomcat docs recommend mod_jk2 over deprecated mod_jk, I chose JK2. I'm running Tomcat 4.1.12 and Apache 1.13.26 on Solaris 8, and having hard time trying to get mod_jk2 to work with Apache. I'm not a C-programmer, so makefiles, compiler settings, linkers etc. are bit of a mystery to me. However, this is what I have done: Compile mod_jk2 (2.0.0 / 2.0.1) with gcc 3.2: [root@solaris native2]# setenv CC /usr/local/bin/gcc [root@solaris native2]# setenv CFLAGS -DBSD_COMP -fPIC [root@solaris native2]# chmod u+x buildconf.sh [root@solaris native2]# ./buildconf.sh [root@solaris native2]# ./configure --with-apxs=/opt/apache/bin/apxs --with-tomcat41=/opt/jakarta-tomcat-4.1.12 [root@solaris native2]# make [root@solaris native2]# cd ../build/jk2/apache13 [root@solaris apache13]# cp mod_jk2.so /opt/apache/libexec Make will fail if I remove either of the compiler flags... not sure what they do, required a lot of Google searches (and some trial error) to get even this far. Maybe I've done something wrong here? Then I configured Apache and Tomcat to use mod_jk2 (workers2.properties, jk2.properties). Everything seems to be in place, but when I try to start Apache, it fails with a segmentation fault. Last lines of jk2.log: [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (345)]: shm.init(): file=/opt/apache/logs/jk2.shm size=1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (257)]: shm.create(): file open /opt/apache/logs/jk2.shm 1048576 1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (365)]: shm.create(): shm created 0xfe30 Last lines of truss output: 20309: open(/opt/apache/logs/jk2.shm, O_RDWR|O_CREAT, 0777) = 3 20309: stat(/opt/apache/logs/jk2.shm, 0xFFBEF970)= 0 20309: d=0x0225 i=329401 m=0100755 l=1 u=0 g=1 sz=1048576 20309: at = Oct 8 11:50:08 EEST 2002 [ 1034067008 ] 20309: mt = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: ct = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: bsz=8192 blks=2064 fs=ufs 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 119) = 119 20309: mmap(0x, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xFE30 20309: close(3)= 0 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 91) = 91 20309: time() = 1034067008 20309: Incurred fault #6, FLTBOUNDS %pc = 0xFF1B3144 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x 20309: Received signal #11, SIGSEGV [default] 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Should I just stick with mod_webapp? Regards, Hannu Kivimaki -- 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]
cvs commit: jakarta-tomcat-connectors/jk/native2 STATUS.txt
mturk 2002/10/08 08:00:18 Modified:jk/native2 STATUS.txt Log: Update status info Revision ChangesPath 1.2 +4 -3 jakarta-tomcat-connectors/jk/native2/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/STATUS.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- STATUS.txt6 Oct 2002 07:52:27 - 1.1 +++ STATUS.txt8 Oct 2002 15:00:18 - 1.2 @@ -3,7 +3,8 @@ Release: -2.0.1 : in progress +2.0.2 : in progress +2.0.1 : released October 6, 2002 2.0.0 : released September 30, 2002 RELEASE SHOWSTOPPERS: @@ -17,6 +18,6 @@ will allow asynchronous communication, and will be used for various management messages. -STUFF FOR 2.0.1: +STUFF FOR 2.1: * Use the APR for as a System abstraction layer through the code. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.12-LE ClassLoader Problems
I successfully started over again with a fresh installation of Tomcat 4.1.12-LE, uncovering another side effect of the tomcat classloader. I find that the ClassLoader-HOWTO is very vague in explaining the exact boundaries of the classloaders...here's why: To make it work: moved commons-beanutils, and commons-logging to common/lib from server/lib, these were duplicated before because I didn't understand (more like pay attention) the server can use resources from there. I believe this caused come kind of mismatch in the classloader when testing isAssignableFrom(). Copied the commons-digester to my web-app (my app code uses it and the other commons packages). The problem: I shouldn't need to put the commons-digester.jar in BOTH the server/lib, and my webapp/WEB-INF/lib, when I can place it in the commons/lib. But, doing just that, tomcat fails to start. Though the writeup on the classloaders helps a lot, it doesn't explain why the commons-digester.jar has to be in the server/lib ONLY for catalina to start. I assume this is a bug? If so, please let me know and I'll put it in bugzilla. Kevin Ross Kevin Ross wrote: Environment: commons-logging-1.0.2.jar log4j-1.2.6.jar Apache Tomcat/4.1.12-LE-jdk14 Situation: I have my own realm implementation that is stable in Tomcat 4.0.3-LE, and I'm moving up to 4.1.12. In addition, I am also moving all of my codebase to the commons-logging package. After moving to commons-logging, everything in my codebase works in a simple JVM, i.e. JUnit tests and Java Applications. When this is inside the tomcat classloader heirarchy though, NOTHING works. Each of the following scenarios describe the things I've done, with somewhat different results, but all leading back to incompatible class loading schemes. Is there a tomcat bug? The first scenario describes a situation where a server realm component is finding the log4j classes using the method from the LogFactoryImpl.isLog4JAvailable() method...it returns 'true' when the log4j classes ARE NOT in the server/lib, but all the way down in one of my webapp/lib. I believe this is a tomcat issue. == This scenario is debug output I placed in the methods that the LogFactory uses to determine if log4j is available. I copied loadClass(), isLog4JAvailable(), getContextClassLoader() from the LogFactory and LogFactoryImpl into my Realm, and here is the output when I put log4j.jar in my 'operations' webapp and made sure that the log4j.jar is not available anywhere else in the tomcat heirarchy: -loadClass(org.apache.log4j.Category) -trying the context classloader from Thread.getContextClassLoader() -got the context classloader from Thread.getContextClassLoader() -contextClassLoader worked. returning class org.apache.log4j.Category -trying Class.forName(org.apache.log4j.Category) -Class.forName RETURNING an exception. isLog4JAvailable(): true This should be false! Why should a server component be able to access my webapp's jars??? Is the commons-logging package unsafely assuming how a classloader will work, or is the Tomcat-Catalina configuration of tiered classloaders incorrectly allowing access to that class via the thread context classLoader? Nonetheless, even if the tomcat class loader isn't doing it's job exactly, the commons-logging package tests for that class via the contextClassLoader, but it then cannot instantiate the class. That would mean that it's not using the context class loader to instantiate...wouldn't it? If so, that is inconsistent as well. == When I put the log4j-1.2.6.jar in with the latest commons-logging-1.0.2.jar in catalina\server\lib: Using CATALINA_BASE: .. Using CATALINA_HOME: .. Using CATALINA_TMPDIR: ..\temp Using JAVA_HOME: C:\Development\lib\jdk\j2sdk1.4.0 Exception during startup processing java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout at org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.ja va:153) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImp l.java:285) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409) at org.apache.commons.digester.Digester.init(Digester.java:281) at org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:2 80) at
DO NOT REPLY [Bug 13378] - Generated code assumes definition of getServletContext() in base class.
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=13378. 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=13378 Generated code assumes definition of getServletContext() in base class. --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 15:02 --- Oh, sorry -- when I wrote Servlet API above, I actually meant HttpJspPage API. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.12-LE ClassLoader Problems
Kevin Ross wrote: I successfully started over again with a fresh installation of Tomcat 4.1.12-LE, uncovering another side effect of the tomcat classloader. I find that the ClassLoader-HOWTO is very vague in explaining the exact boundaries of the classloaders...here's why: To make it work: moved commons-beanutils, and commons-logging to common/lib from server/lib, these were duplicated before because I didn't understand (more like pay attention) the server can use resources from there. I believe this caused come kind of mismatch in the classloader when testing isAssignableFrom(). Copied the commons-digester to my web-app (my app code uses it and the other commons packages). The problem: I shouldn't need to put the commons-digester.jar in BOTH the server/lib, and my webapp/WEB-INF/lib, when I can place it in the commons/lib. But, doing just that, tomcat fails to start. Though the writeup on the classloaders helps a lot, it doesn't explain why the commons-digester.jar has to be in the server/lib ONLY for catalina to start. I assume this is a bug? If so, please let me know and I'll put it in bugzilla. Don't bother. Whatever CL problems are left in TC 4.1 (I assume it will be only tricky cases) won't be fixed. In 5.0, I'll be pushing to use standard Java 2 delegation, and the problems should go away. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Glenn Nielsen wrote: mod_webapp has been orphaned. Not completly. I am trying to find time to maintain it. Of course I have not enough time to enhance it. mod_jk JK2 is a new codebase that is still considered beta. mod_jk 1.2 with Ajp13 has been relatively stable for a while. I use this combination with Apache 1.3.26 on both Solaris 7 and Solaris 8 on sparc for production systems using Tomcat 4.1.12. The binary for Solaris8 are available at http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/solaris8/ I have also a Solaris6 machine somewhere. Should I produce binaries on it? (I cannot test on Solaris6 only build). IHMO, mod_jk 1.2 is currently the best choice for production. Regards, Glenn Hannu Kivimäki wrote: Hello list, I'm updating from Tomcat 4.0.2 to 4.1.12 and decided to upgrade the Tomcat connector as well. I've had some problems with mod_webapp before, and as Tomcat docs recommend mod_jk2 over deprecated mod_jk, I chose JK2. I'm running Tomcat 4.1.12 and Apache 1.13.26 on Solaris 8, and having hard time trying to get mod_jk2 to work with Apache. I'm not a C-programmer, so makefiles, compiler settings, linkers etc. are bit of a mystery to me. However, this is what I have done: Compile mod_jk2 (2.0.0 / 2.0.1) with gcc 3.2: [root@solaris native2]# setenv CC /usr/local/bin/gcc [root@solaris native2]# setenv CFLAGS -DBSD_COMP -fPIC [root@solaris native2]# chmod u+x buildconf.sh [root@solaris native2]# ./buildconf.sh [root@solaris native2]# ./configure --with-apxs=/opt/apache/bin/apxs --with-tomcat41=/opt/jakarta-tomcat-4.1.12 [root@solaris native2]# make [root@solaris native2]# cd ../build/jk2/apache13 [root@solaris apache13]# cp mod_jk2.so /opt/apache/libexec Make will fail if I remove either of the compiler flags... not sure what they do, required a lot of Google searches (and some trial error) to get even this far. Maybe I've done something wrong here? Then I configured Apache and Tomcat to use mod_jk2 (workers2.properties, jk2.properties). Everything seems to be in place, but when I try to start Apache, it fails with a segmentation fault. Last lines of jk2.log: [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (345)]: shm.init(): file=/opt/apache/logs/jk2.shm size=1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (257)]: shm.create(): file open /opt/apache/logs/jk2.shm 1048576 1048576 [Tue Oct 08 08:50:08 2002] (debug) [jk_shm.c (365)]: shm.create(): shm created 0xfe30 Last lines of truss output: 20309: open(/opt/apache/logs/jk2.shm, O_RDWR|O_CREAT, 0777) = 3 20309: stat(/opt/apache/logs/jk2.shm, 0xFFBEF970)= 0 20309: d=0x0225 i=329401 m=0100755 l=1 u=0 g=1 sz=1048576 20309: at = Oct 8 11:50:08 EEST 2002 [ 1034067008 ] 20309: mt = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: ct = Oct 8 11:48:24 EEST 2002 [ 1034066904 ] 20309: bsz=8192 blks=2064 fs=ufs 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 119) = 119 20309: mmap(0x, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xFE30 20309: close(3)= 0 20309: time() = 1034067008 20309: write(5, [ T u e O c t 0 8 .., 91) = 91 20309: time() = 1034067008 20309: Incurred fault #6, FLTBOUNDS %pc = 0xFF1B3144 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x 20309: Received signal #11, SIGSEGV [default] 20309:siginfo: SIGSEGV SEGV_MAPERR addr=0x And some debugger info from the core dump: 0xFF1B3144/i libc.so.1`strlen+0x80: ld[%o1], %o2 Any suggestions? Should I just stick with mod_webapp? Regards, Hannu Kivimaki -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSESupport.java
bobh2002/10/08 09:49:43
Modified:util/java/org/apache/tomcat/util/net/jsse JSSESupport.java
Log:
- fixes problem with JDK1.4's JSSE trying to negociate certs on a socket that has no
data flowing
Revision ChangesPath
1.2 +45 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Index: JSSESupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JSSESupport.java 4 Oct 2002 20:03:10 - 1.1
+++ JSSESupport.java 8 Oct 2002 16:49:43 - 1.2
@@ -66,6 +66,8 @@
import java.security.cert.CertificateFactory;
import javax.net.ssl.SSLSession;
import javax.net.ssl.SSLSocket;
+import javax.net.ssl.HandshakeCompletedListener;
+import javax.net.ssl.HandshakeCompletedEvent;
import java.security.cert.CertificateFactory;
import javax.security.cert.X509Certificate;
@@ -127,6 +129,9 @@
session.invalidate();
ssl.setNeedClientAuth(true);
ssl.startHandshake();
+ if (1.4.equals(System.getProperty(java.specification.version))) {
+ synchronousHandshake(ssl);
+ }
session = ssl.getSession();
jsseCerts = session.getPeerCertificateChain();
if(jsseCerts == null)
@@ -198,5 +203,45 @@
}
return buf.toString();
}
+
+/**
+ * JSSE in JDK 1.4 has an issue/feature that requires us to do a
+ * read() to get the client-cert. As suggested by Andreas
+ * Sterbenz
+ */
+private static void synchronousHandshake(SSLSocket socket)
+throws IOException {
+InputStream in = socket.getInputStream();
+int oldTimeout = socket.getSoTimeout();
+socket.setSoTimeout(100);
+Listener listener = new Listener();
+socket.addHandshakeCompletedListener(listener);
+byte[] b = new byte[0];
+socket.startHandshake();
+int maxTries = 50; // 50 * 100 = example 5 second rehandshake timeout
+for (int i = 0; i maxTries; i++) {
+try {
+int x = in.read(b);
+} catch (SocketTimeoutException e) {
+// ignore
+}
+if (listener.completed) {
+break;
+}
+}
+socket.removeHandshakeCompletedListener(listener);
+socket.setSoTimeout(oldTimeout);
+if (listener.completed == false) {
+throw new SocketTimeoutException(SSL Cert handshake timeout);
+}
+}
+
+private static class Listener implements HandshakeCompletedListener {
+volatile boolean completed = false;
+public void handshakeCompleted(HandshakeCompletedEvent event) {
+completed = true;
+}
+}
+
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Henri Gomez wrote: What about setting tcpnodelay to true by default for Ajp13 connectors java implemtations ? It should fix MacOS X latency problems and should be the default for any persistant connections... +1 - if it doesn't affect any existing usecase. It shouldn't. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
[+1] Theoretical backup: Analyzing the protocol at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html and the tcp dump confirms that ajp13 first sends Headers (small load) back to Apache, followed by Body Chunk (big load) and then an End Response (small load). I can't draw nice ASCII art but here's the summary for a typical request-response loop currently (there is a variation with TC getting body chunk from Apache but not considered here). 1. Apache --- request headers TC 2. Apache --- response headers TC There are 2 scenarios that can happen after this. 3a. Apache --- response body TC This happens immediately if size of the response chunk is greater than MSS or MTU (say 1500 bytes), regardless of whether TCP_NODELAY is on or off. Apache ---end response headers TC 3b. Apache --- DELAYED_ACK TC Apache --- response body + end response headers TC If TCP_NODELAY is off, TC waits for ACK from Apache. However, on Mac OS X and RedHat, DELAYED_ACK is turned on by default in the OS. On the Mac OS X, it's 200ms and I think it is 40ms with RH. Hence, if size of the response chunk is less than say 1500 bytes, there will be a delay of ~200ms on Mac OS X before Apache sees the body[1]. The good thing about this is that the end response headers is usually coalesced with the response body due to TCP_NODELAY off (Nagle). Now imagine that TCP_NODELAY Is turned on by default, then we would see the scenario of 3a happening all the time, regardless of size of body. This will result in faster response. The downside that I see is that end response headers will be sent in a separate packet. Some lab results: I patched up TC's ajp13 java class and gave the patch to our QA person. After 4 hours of testing, she reported that 1. performance for small body chunks (typical size 1500) is now on par with ajp12 2. performance for bigger body chunks does not degrade. [1] We did almost all our tests on Mac OS X but I ran the test a few times on RedHat. The degradation doesn't seem to be as bad on Redhat. I only saw a 50% drop in performance, comparing ajp13 to ajp12. I have read that Linux kernel is smarter on the DELAYED_ACK algorithm. [2] I'm sorry that we didn't do tests on the rest of the platforms supported by Apache and Tomcat but hopefully, you will be convinced by the theoretical underpinnings. Thank you for your kind attention. Comments and counter-points welcome. Han Ming On Tuesday, October 8, 2002, at 04:26 AM, Henri Gomez wrote: What about setting tcpnodelay to true by default for Ajp13 connectors java implemtations ? It should fix MacOS X latency problems and should be the default for any persistant connections... Comments welcome... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
I'm convinced, thank you very much for taking the time to test and analyze this. We should switch the setting in the main branch - not sure if Remy has a branch for 4.1/4.0, and if he has I think he should decide if he wants this backported. If anything happens we can roll back. I hope we'll hear more from Han Ming in future :-) Costin Han Ming Ong wrote: [+1] Theoretical backup: Analyzing the protocol at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html and the tcp dump confirms that ajp13 first sends Headers (small load) back to Apache, followed by Body Chunk (big load) and then an End Response (small load). I can't draw nice ASCII art but here's the summary for a typical request-response loop currently (there is a variation with TC getting body chunk from Apache but not considered here). 1. Apache --- request headers TC 2. Apache --- response headers TC There are 2 scenarios that can happen after this. 3a. Apache ---response body TC This happens immediately if size of the response chunk is greater than MSS or MTU (say 1500 bytes), regardless of whether TCP_NODELAY is on or off. Apache --- end response headers TC 3b. Apache ---DELAYED_ACK TC Apache --- response body + end response headers TC If TCP_NODELAY is off, TC waits for ACK from Apache. However, on Mac OS X and RedHat, DELAYED_ACK is turned on by default in the OS. On the Mac OS X, it's 200ms and I think it is 40ms with RH. Hence, if size of the response chunk is less than say 1500 bytes, there will be a delay of ~200ms on Mac OS X before Apache sees the body[1]. The good thing about this is that the end response headers is usually coalesced with the response body due to TCP_NODELAY off (Nagle). Now imagine that TCP_NODELAY Is turned on by default, then we would see the scenario of 3a happening all the time, regardless of size of body. This will result in faster response. The downside that I see is that end response headers will be sent in a separate packet. Some lab results: I patched up TC's ajp13 java class and gave the patch to our QA person. After 4 hours of testing, she reported that 1. performance for small body chunks (typical size 1500) is now on par with ajp12 2. performance for bigger body chunks does not degrade. [1] We did almost all our tests on Mac OS X but I ran the test a few times on RedHat. The degradation doesn't seem to be as bad on Redhat. I only saw a 50% drop in performance, comparing ajp13 to ajp12. I have read that Linux kernel is smarter on the DELAYED_ACK algorithm. [2] I'm sorry that we didn't do tests on the rest of the platforms supported by Apache and Tomcat but hopefully, you will be convinced by the theoretical underpinnings. Thank you for your kind attention. Comments and counter-points welcome. Han Ming On Tuesday, October 8, 2002, at 04:26 AM, Henri Gomez wrote: What about setting tcpnodelay to true by default for Ajp13 connectors java implemtations ? It should fix MacOS X latency problems and should be the default for any persistant connections... Comments welcome... -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs menu.jk.idx
mturk 2002/10/08 10:56:42 Modified:jk/xdocs menu.jk.idx Log: Remove the CRLF. Revision ChangesPath 1.2 +9 -9 jakarta-tomcat-connectors/jk/xdocs/menu.jk.idx Index: menu.jk.idx === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.jk.idx,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu.jk.idx 20 Sep 2002 15:43:01 - 1.1 +++ menu.jk.idx 8 Oct 2002 17:56:42 - 1.2 @@ -1,9 +1,9 @@ -?xml version=1.0 encoding=ISO-8859-1? - -section name=JK -document href=jk/aphowto.xml/ -document href=jk/domhowto.xml/ -document href=jk/iishowto.xml/ -document href=jk/neshowto.xml/ -document href=jk/workershowto.xml/ -/section +?xml version=1.0 encoding=ISO-8859-1? + +section name=JK +document href=jk/aphowto.xml/ +document href=jk/domhowto.xml/ +document href=jk/iishowto.xml/ +document href=jk/neshowto.xml/ +document href=jk/workershowto.xml/ +/section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs menu.jk2.idx
mturk 2002/10/08 10:57:07 Modified:jk/xdocs menu.jk2.idx Log: Remove the CRLF and add JK2 Howto. Revision ChangesPath 1.3 +19 -16jakarta-tomcat-connectors/jk/xdocs/menu.jk2.idx Index: menu.jk2.idx === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.jk2.idx,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- menu.jk2.idx 3 Oct 2002 15:32:51 - 1.2 +++ menu.jk2.idx 8 Oct 2002 17:57:07 - 1.3 @@ -1,16 +1,19 @@ -?xml version=1.0 encoding=ISO-8859-1? - -section name=JK2 -/section -section name=Configuration in the Tomcat -document href=jk2/configtc.xml/ -document href=jk2/configtcex.xml/ -/section -section name=Configuration in the Web Server -document href=jk2/configweb.xml/ -document href=jk2/configwebcom.xml/ -document href=jk2/configwebex.xml/ -/section -section name=Installation -document href=jk2/installhowto.xml/ -/section \ No newline at end of file +?xml version=1.0 encoding=ISO-8859-1? + +section name=JK2 +/section +section name=Configuration in the Tomcat +document href=jk2/configtc.xml/ +document href=jk2/configtcex.xml/ +/section +section name=Configuration in the Web Server +document href=jk2/configweb.xml/ +document href=jk2/configwebcom.xml/ +document href=jk2/configwebex.xml/ +/section +section name=Installation +document href=jk2/installhowto.xml/ +/section +section name=Howto +document href=jk2/confighowto.xml/ +/section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13241] - Tomcat 4.1.12 / Webapps:Examples / Disabled
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=13241. 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=13241 Tomcat 4.1.12 / Webapps:Examples / Disabled --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 17:59 --- Well, it seems that Xerces 2.2.0 has a bug since the web-jsptaglibrary_1_2.dtd file is parsed without any errors using Crimson. I'm trying to get the bug confirmed with the xerces-j team. The only thing I know is that one user of Xalan currently report the same problem (Xalan uses Xerces). More to comes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 confighowto.xml
mturk 2002/10/08 10:59:25 Added: jk/xdocs/jk2 confighowto.xml Log: Add the Quick start configuration howto. There will be addition sections like one for the JNI and virtual hosting. Of course evryone are more then wellcome to add more context to that, but it should follow the 'minimum' concept. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/xdocs/jk2/confighowto.xml Index: confighowto.xml === ?xml version=1.0? document properties titleQuick Start JK2 Configuration Guide/title author email=[EMAIL PROTECTED]Mladen Turk/author date$Date: 2002/10/08 17:59:25 $/date /properties section name=Introduction p This document describes the configuration files used by JK2 on the Tomcat and Web Server side: ul li bjk2.properties/b is used on the Tomcat side. It's installation path in the $TOMCAT_HOME/conf directory. /li li bworkers2.properties/b is used on the webserver side. For the Apache servers the default path is in the ServerRoot/conf directory. /li /ul Although JK2 has many things in common with mod_jk, the configuration is quite different, and all the directives should be inside the workers2.properties. This enables JK2 to have the same configuration file no mater what the web server it's connected to. /p /section section name=Minimum Configuration p Minimum configuration is the simplest one to make the JK2 working. The used channel will be socket, and lot of options are used by default. Both the Tomcat and web server are on the same computer. /p p jk2.properties: source # The default port is 8009 but you can use onother one # channelSocket.port=8019 /source That is all needed on the Tomcat side to configure the JK2. /p p workers2.properties: source # Define the comunication channel [channel.socket:localhost:8009] info=Ajp13 forwarding over socket tomcatId=localhost:8009 # Map the Tomcat examples webapp to the Web server uri space [uri:/examples/*] info=Map the whole webapp /source /p p Start the Tomcat and Web server and browse to the ahttp://localhost/examples//a /p /section /document -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|UNCONFIRMED |NEW everconfirmed|0 |1 --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 18:33 --- 10/7/02 Ned Gerhart, Software Engineer [EMAIL PROTECTED] I've had identical results to those reported originally by Joseph Tan. We have had success with Tomcat 3.3.1 in the USS environment, but later versions have problems as described here. Please let me know if there is anything Attachmate Corporation can do to help speed resolution of this bug...thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/naming/src/org/apache/naming/res LocalStrings.properties
costin 2002/10/08 11:46:43
Modified:naming build.xml
naming/src jndi.properties
naming/src/org/apache/naming/ant JndiProperties.java
naming/src/org/apache/naming/core BaseDirContext.java
ContextAccessController.java DirContextHelper.java
NamingContextEnumeration.java
naming/src/org/apache/naming/modules/fs FileDirContext.java
fsURLContextFactory.java
naming/src/org/apache/naming/modules/java
SelectorContext.java javaURLContextFactory.java
naming/src/org/apache/naming/modules/memory
MemoryNamingContext.java
naming/src/org/apache/naming/res LocalStrings.properties
Added: naming/src/org/apache/naming/ant JndiEnv.java
naming/src/org/apache/naming/core BaseNamingImpl.java
NamingEntry.java
Removed: naming/src/org/apache/naming/modules/memory NamingEntry.java
Log:
Few fixes. It should now work ( including the test target ). It requires
ant-sax2.jar, from ant/proposals/embed ( for testing and to compile
the ant hooks ).
I'll probably move the ant-specific stuff into embed.
Revision ChangesPath
1.2 +6 -6 jakarta-tomcat-connectors/naming/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/naming/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 25 Sep 2002 19:32:17 - 1.1
+++ build.xml 8 Oct 2002 18:46:42 - 1.2
@@ -33,12 +33,6 @@
pathelement location=${jndi.home}/lib/jndibrowser.jar/
/path
-systemPath pathRef=build-main.classpath /
-taskdef name=jndiSet classname=org.apache.naming.ant.JndiSet/
-taskdef name=jndiProperties
classname=org.apache.naming.ant.JndiProperties/
-taskdef name=jndiFileCtx classname=org.apache.naming.file.FileDirContext/
-
-jndiProperties/
target name=main
mkdir dir=${naming.build.dir}/classes/
@@ -57,6 +51,12 @@
/target
target name=test
+systemPath pathRef=build-main.classpath /
+taskdef name=jndiSet classname=org.apache.naming.ant.JndiSet/
+taskdef name=jndiProperties
classname=org.apache.naming.ant.JndiProperties/
+taskdef name=jndiFileCtx
classname=org.apache.naming.modules.fs.FileDirContext/
+
+jndiProperties/
jndiSet context=/foo value=bar /
jndiFileCtx docBase=/tmp id=docBaseId /
1.2 +2 -2 jakarta-tomcat-connectors/naming/src/jndi.properties
Index: jndi.properties
===
RCS file: /home/cvs/jakarta-tomcat-connectors/naming/src/jndi.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jndi.properties 25 Sep 2002 19:26:53 - 1.1
+++ jndi.properties 8 Oct 2002 18:46:42 - 1.2
@@ -2,5 +2,5 @@
#java.naming.factory.state=
#java.naming.factory.control=
-java.naming.factory.initial=org.apache.naming.memory.memoryURLContextFactory
-java.naming.factory.url.pkgs=org.apache.naming
\ No newline at end of file
+java.naming.factory.initial=org.apache.naming.modules.memory.memoryURLContextFactory
+java.naming.factory.url.pkgs=org.apache.naming.modules
1.2 +5 -1
jakarta-tomcat-connectors/naming/src/org/apache/naming/ant/JndiProperties.java
Index: JndiProperties.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/naming/src/org/apache/naming/ant/JndiProperties.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JndiProperties.java 25 Sep 2002 19:29:17 - 1.1
+++ JndiProperties.java 8 Oct 2002 18:46:42 - 1.2
@@ -87,7 +87,11 @@
// System.setProperty( java.naming.factory.initial,
org.apache.naming.memory.MemoryInitialContextFactory );
}
-public Object getProperty( Project p, String ns, String name ) {
+public boolean setProperty( Object p, String ns, String name, Object value ) {
+return false;
+}
+
+public Object getProperty( Object p, String ns, String name ) {
if( ! name.startsWith( PREFIX ) )
return null;
1.1
jakarta-tomcat-connectors/naming/src/org/apache/naming/ant/JndiEnv.java
Index: JndiEnv.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
DO NOT REPLY [Bug 13419] New: - Weird seg fault on Mac OS X for mod_jk2 + Apache2
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=13419.
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=13419
Weird seg fault on Mac OS X for mod_jk2 + Apache2
Summary: Weird seg fault on Mac OS X for mod_jk2 + Apache2
Product: Tomcat 4
Version: 4.1.12
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I configured Apache 2.0.42, Tomcat 4.1.12 and downloaded
jakarta-tomcat-connectors-4.1.12-src. I managed to use GNU's libtoolize to
configure (./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-apr-lib=/usr/local/apache2/lib
--with-apr-include=/usr/local/apache2/include
--with-tomcat1=/usr/local/jakarta-tomcat-4.1.12).
The compilation was successful and I copied mod_jk2.so to
/usr/local/apache2/modules. I configured httpd.conf to load the module and
appended the following:
IfModule mod_jk2.c
JkSet config.file /usr/local/apache2/conf/workers2.properties
/IfModule
I added a super simple workers2.properties file in the same dir and tried
to start apache. I got a seg fault. Here's the stacktrace from Mac OS X
default crash logger:
Thread 0 Crashed:
#0 0x90001600 in strlen
#1 0x900023e0 in vfprintf
#2 0x900017ec in fprintf
#3 0x0061dd18 in jk2_map_default_get (jk_map.c:104) - see codes below for the
statement
#4 0x0061bbb4 in jk2_env_getBean2 (jk_env.c:423)
#5 0x0061af40 in jk2_env_createBean2 (jk_env.c:218)
#6 0x00636754 in jk2_create_config (mod_jk2.c:344)
#7 0x0002214c in ap_single_module_configure (config.c:1845)
I'm adding my own printf's. For completeness, here's the function
static void *jk2_map_default_get(jk_env_t *env, jk_map_t *m,
const char *name)
{
int i;
jk_map_private_t *mPriv;
void *result=NULL;
if(name==NULL )
return NULL;
fprintf(stdout, \nentering for %s , name);
mPriv=(jk_map_private_t *)m-_private;
fprintf(stdout, (no. maps: %d)\n, mPriv-size);
for(i = 0 ; i mPriv-size ; i++) {
fprintf(stdout, \t%d: , i);
if ((mPriv-names[i]) == NULL) {
fprintf(stdout, null mPriv-names[]);
return NULL;
}
fprintf(stdout, %p , (mPriv-names[i]));
fflush(stdout);
fprintf(stdout, %s , mPriv-names[i]); /* this is line 104 */
fprintf(stdout, (%p) \n, mPriv-values[i]);
if(0 == strcmp(mPriv-names[i], name)) {
result = mPriv-values[i];
break;
}
}
fprintf(stdout, done for %s\n, name);
return result;
}
And as per requested by Costin, I added the printf in the put function:
...
if(mPriv-size mPriv-capacity) {
mPriv-values[mPriv-size] = value;
/* XXX this is wrong - either we take ownership and copy both
name and value,
or none. The caller should do that if he needs !
Sure, but we should have our copy...
mPriv-names[mPriv-size] = (char *)name;
*/
mPriv-names[mPriv-size] = m-pool-pstrdup(env,m-pool, name);
printf(put '%s' (addr: %p) with value: %p \n, mPriv-names[mPriv-size],
(mPriv-names[mPriv-size]), value);
mPriv-size ++;
rc = JK_OK;
}
...
And finally, here's the output:
put 'logger.file' (addr: 0x19b948) with value: 0x61d984
put 'logger.win32' (addr: 0x19b94c) with value: 0x61dac8
put 'workerEnv' (addr: 0x19b950) with value: 0x62c698
put 'uriMap' (addr: 0x19b954) with value: 0x62a3d4
put 'uriEnv' (addr: 0x19b958) with value: 0x627fa4
put 'endpoint' (addr: 0x19b95c) with value: 0x61a65c
put 'uri' (addr: 0x19b960) with value: 0x627fa4
put 'config' (addr: 0x19b964) with value: 0x61a028
put 'ajp13' (addr: 0x19b968) with value: 0x62f168
put 'lb' (addr: 0x19b96c) with value: 0x6308dc
put 'status' (addr: 0x19b970) with value: 0x632c2c
put 'run' (addr: 0x19b974) with value: 0x630d60
put 'channel.un' (addr: 0x19b978) with value: 0x617dc8
put 'channel.apr' (addr: 0x19b97c) with value: 0x615644
put 'shm' (addr: 0x19b980) with value: 0x626ee8
put 'channel.socket' (addr: 0x19b984) with value: 0x616c64
put 'handler.response' (addr: 0x19b988) with value: 0x61cff0
put 'handler.logon' (addr: 0x19b98c) with value: 0x61c578
put 'threadMutex' (addr: 0x19b990) with value: 0x620da8
put 'procMutex' (addr: 0x19b994) with value: 0x6209fc
put 'channel.jni' (addr: 0x19b998) with value: 0x6157b0
put 'worker.jni' (addr: 0x19b99c) with value: 0x62f3f4
put 'vm' (addr: 0x19b9a0) with value: 0x62a864
put 'signal' (addr: 0x19b9a4) with value: 0x627038
put 'user' (addr: 0x19b9a8) with value: 0x62a7a8
entering for threadMutex (no. maps: 25)
0: 0x19b948
Re: Solaris 8, JK2, Apache 1.3.x - Segmentation fault
Ok... Loading modules: [ ] $c libc.so.1`strlen+0x80(0, d2d11, 0, a2e81, 0, fe674f8b) libc.so.1`vsnprintf+0x5c(ffbed7e9, 7fff, fe674f70, ffbef8a4, fe674f5d, 90) mod_jk2.so`jk2_logger_file_jkVLog+0x480(b2068, b3998, fe674f50, 90, 0, fe674f70) mod_jk2.so`jk2_logger_file_jkLog+0x44(b2068, b3998, fe674f50, 90, 0, fe674f70) mod_jk2.so`jk2_uriMap_addUriEnv+0xb0(b2068, b49f0, d2c50, fe666334, 0, d2475) mod_jk2.so`jk2_uriEnv_factory+0x198(b2068, d23e8, d2420, d2478, d2480, fe665f7c) mod_jk2.so`jk2_env_createBean2+0x420(b2068, b4118, fe675000, fe674fc8, fe65a30c, fe674a00) mod_jk2.so`jk2_uriMap_init+0x74(b2068, b49f0, fe667784, fe65ce80, fe65a30c, fe676730) mod_jk2.so`jk2_workerEnv_init+0x370(b2068, b41d0, fe66ef78, 12a, 1, fe676df0) mod_jk2.so`jk2_init+0x130(a54c8, a54a0, fe67191c, 0, 6f725741, 6f723131) ap_init_modules+0x58(a54a0, a54c8, a2400, 0, ff23cfdc, 86c80) main+0x4fc(1, ffbefd2c, ffbefd34, a2e78, 0, 0) _start+0x5c(0, 0, 0, 0, 0, 0) This looks similar to bug #13419 but I have the seg fault on Mac OS X instead. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Costin Manolache wrote: I'm convinced, thank you very much for taking the time to test and analyze this. We should switch the setting in the main branch - not sure if Remy has a branch for 4.1/4.0, and if he has I think he should decide if he wants this backported. There's no branch at all in j-t-c. I think I'm +1 for it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13423] New: - Tomcat freezes if started via Runtime.exec()
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=13423. 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=13423 Tomcat freezes if started via Runtime.exec() Summary: Tomcat freezes if started via Runtime.exec() Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have created a program launcher that calls Java applications via Runtime.exec(). One of these programs calls an application that contains an embedded version of Tomcat. This version of Tomcat is version 4.1.12. When Tomcat starts to run the application freezes and no other services are started. If I run the same application without calling it via Runtime.exec() is works fine. Therefore, it seems that Tomcat has a problem if the application it is running in was started via a Runtime.exec() call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances
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=13392. 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=13392 When tag pooling is enabled, release() is not called on tag instances [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 20:32 --- I dont agree, you are re-using the tag instance and the variables are not starting at a known state. The spec does say that you have to guarantee that release() is called during garbage collection, but the tag pooling feature also should reset the tag instance prior to re-use. This is a very practical part of the functionality. It is also a backward compatibility problem becuase tag pooling is on by default and existing applications will not run without turning it off. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Proposal] Security Audit
Hi, I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I would like to collect as more as information as where you think I should look at (code, security hole, etc.). I'm planning to do the audit using the default SecurityManager. Rigth now, I have started looking at: - doPrivilege blocks. Are they small enough? Can they be reduced? - JSP generated code. Are they secure? Can a malicious app uses the code to access o.a.catalina code? - Is catalina.policy restricted enough? - Is our Classloader secure? Any direction/ideas/recommendations will be appreciated. Thanks, -- Jeanfrancois -- 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/resources messages.properties messages_es.properties messages_ja.properties
luehe 2002/10/08 16:22:58
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_ja.properties
Log:
Added error message for jasper.error.emptybodycontent.nonempty
Revision ChangesPath
1.33 +5 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- Parser.java 28 Sep 2002 00:46:28 - 1.32
+++ Parser.java 8 Oct 2002 23:22:57 - 1.33
@@ -1611,7 +1611,8 @@
}
else if( bodyType.equalsIgnoreCase( TagInfo.BODY_CONTENT_EMPTY ) ) {
if( !reader.matchesETag( tag ) ) {
- err.jspError(start, jasper.error.emptybodycontent.nonempty);
+ err.jspError(start, jasper.error.emptybodycontent.nonempty,
+ tag);
}
}
else if( bodyType == JAVAX_BODY_CONTENT_PLUGIN ) {
1.44 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- messages.properties 27 Sep 2002 20:18:32 - 1.43
+++ messages.properties 8 Oct 2002 23:22:57 - 1.44
@@ -303,3 +303,4 @@
jsp.error.page.pageencoding.conflict=Page-encoding specified in jsp-property-group
({0}) is different from that specified in page directive ({1})
jsp.error.attribute.non_rt_with_expr=According to TLD, attribute {0} does not
accept any expressions
jsp.error.scripting.variable.missing_name=Unable to determine scripting variable
name from attribute {0}
+jasper.error.emptybodycontent.nonempty=According to TLD, tag {0} must be empty, but
is not
1.15 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
Index: messages_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- messages_es.properties24 Sep 2002 21:24:58 - 1.14
+++ messages_es.properties8 Oct 2002 23:22:57 - 1.15
@@ -223,3 +223,4 @@
jsp.error.page.pageencoding.conflict=
jsp.error.attribute.non_rt_with_expr=
jsp.error.scripting.variable.missing_name=
+jasper.error.emptybodycontent.nonempty=
1.15 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties
Index: messages_ja.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- messages_ja.properties27 Sep 2002 20:18:32 - 1.14
+++ messages_ja.properties8 Oct 2002 23:22:57 - 1.15
@@ -254,3 +254,4 @@
jsp.error.page.pageencoding.conflict=
jsp.error.attribute.non_rt_with_expr=
jsp.error.scripting.variable.missing_name=
+jasper.error.emptybodycontent.nonempty=
--
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/resources messages.properties messages_es.properties messages_ja.properties
luehe 2002/10/08 16:42:07
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Parser.java
jasper2/src/share/org/apache/jasper/resources Tag:
tomcat_4_branch messages.properties
messages_es.properties messages_ja.properties
Log:
Added error message for jasper.error.emptybodycontent.nonempty
Revision ChangesPath
No revision
No revision
1.7.2.3 +5 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- Parser.java 17 Aug 2002 00:14:23 - 1.7.2.2
+++ Parser.java 8 Oct 2002 23:42:06 - 1.7.2.3
@@ -747,7 +747,8 @@
// There are 3 body content types: empty, jsp, or tag-dependent.
if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)) {
if (!reader.matchesETag(tagName)) {
- err.jspError(start, jasper.error.emptybodycontent.nonempty);
+ err.jspError(start, jasper.error.emptybodycontent.nonempty,
+ tagName);
}
} else if (bc.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT)) {
// parse the body as text
No revision
No revision
1.9.2.3 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.9.2.2
retrieving revision 1.9.2.3
diff -u -r1.9.2.2 -r1.9.2.3
--- messages.properties 21 Aug 2002 17:54:24 - 1.9.2.2
+++ messages.properties 8 Oct 2002 23:42:06 - 1.9.2.3
@@ -251,3 +251,4 @@
jsp.error.single.line.number=\n\nAn error occurred at line: {0} in the jsp file:
{1}\n\n
jsp.error.multiple.line.number=\n\nAn error occurred between lines: {0} and {1} in
the jsp file: {2}\n\n
jsp.error.corresponding.servlet=Generated servlet error:\n
+jasper.error.emptybodycontent.nonempty=According to TLD, tag {0} must be empty, but
is not
1.3.2.2 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
Index: messages_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- messages_es.properties18 Jul 2002 23:25:05 - 1.3.2.1
+++ messages_es.properties8 Oct 2002 23:42:06 - 1.3.2.2
@@ -207,3 +207,4 @@
jsp.error.internal.filenotfound=
jsp.error.parse.xml.invalidPublicId=
jsp.error.usebean.notinsamefile=El tag useBean debe empezar y acabar en el mismo
archivo fisico
+jasper.error.emptybodycontent.nonempty=
1.2.2.1 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties
Index: messages_ja.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_ja.properties,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- messages_ja.properties26 Jun 2002 16:50:38 - 1.2
+++ messages_ja.properties8 Oct 2002 23:42:06 - 1.2.2.1
@@ -241,3 +241,4 @@
jsp.error.single.line.number=\n\nJSP\u30d5\u30a1\u30a4\u30eb: {1}
\u306e\u4e2d\u306e\u884c:
{0}\u3067\u30a8\u30e9\u30fc\u304c\u767a\u751f\u3057\u307e\u3057\u305f\n\n
jsp.error.multiple.line.number=\n\nJPS\u30d5\u30a1\u30a4\u30eb:
{2}\u306e\u4e2d\u306e{0}\u884c\u76ee\u3068{1}\u884c\u76ee\u306e\u9593\u3067\u30a8\u30e9\u30fc\u304c\u767a\u751f\u3057\u307e\u3057\u305f\n\n
jsp.error.corresponding.servlet=\u751f\u6210\u3055\u308c\u305f\u30b5\u30fc\u30d6\u30ec\u30c3\u30c8\u306e\u30a8\u30e9\u30fc\u3067\u3059:\n
+jasper.error.emptybodycontent.nonempty=
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13430] New: - WWW-Authenticate Header Is Not Sent
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=13430. 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=13430 WWW-Authenticate Header Is Not Sent Summary: WWW-Authenticate Header Is Not Sent Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5: XSD change and javadoc clarification
NOTE: This patch requires some changes to Jasper2 before committing. Please let me know if there are any questions or concerns. jsr152/src/share/javax/serlvet/jsp/el/Expression.java - Removed null as a return value for error - method must throw an exception to signal an error. jsr152/src/share/dtd/jsp_2_0.xsd: jsr154/src/share/dtd/jsp_2_0.xsd: - As per the Expert Group's decision, changed scripting-enabled to scripting-invalid and el-enabled to el-ignored. Jasper2 needs to be updated accordingly. -- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Index: jsr152/src/share/dtd/jsp_2_0.xsd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/jsp_2_0.xsd,v retrieving revision 1.3 diff -u -r1.3 jsp_2_0.xsd --- jsr152/src/share/dtd/jsp_2_0.xsd20 Sep 2002 01:56:44 - 1.3 +++ jsr152/src/share/dtd/jsp_2_0.xsd9 Oct 2002 00:07:29 - @@ -8,7 +8,7 @@ version=2.0 xsd:annotation xsd:documentation -@(#)jsp_2_0.xsds 1.12 09/18/02 +%W% %G% /xsd:documentation /xsd:annotation @@ -150,16 +150,17 @@ xsd:element name=url-pattern type=j2ee:url-patternType maxOccurs=unbounded/ -xsd:element name=el-enabled +xsd:element name=el-ignored type=j2ee:true-falseType minOccurs=0 xsd:annotation xsd:documentation -Can be used to easily set the isELEnabled +Can be used to easily set the isELIgnored property of a group of JSP pages. By default, the EL evaluation is enabled for Web Applications using -a Servlet 2.4 or greater web.xml. +a Servlet 2.4 or greater web.xml, and disabled + otherwise. /xsd:documentation /xsd:annotation @@ -181,15 +182,15 @@ /xsd:documentation /xsd:annotation /xsd:element -xsd:element name=scripting-enabled +xsd:element name=scripting-invalid type=j2ee:true-falseType minOccurs=0 xsd:annotation xsd:documentation -Can be used to easily set the isScriptingEnabled -property of a group of JSP pages. By default, -scripting is enabled. +Can be used to easily disable scripting in a +group of JSP pages. By default, scripting is + enabled. /xsd:documentation /xsd:annotation Index: jsr152/src/share/javax/servlet/jsp/el/Expression.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/el/Expression.java,v retrieving revision 1.1 diff -u -r1.1 Expression.java --- jsr152/src/share/javax/servlet/jsp/el/Expression.java 19 Aug 2002 16:29:50 - 1.1 +++ jsr152/src/share/javax/servlet/jsp/el/Expression.java 9 Oct 2002 00:07:29 +- @@ -81,7 +81,7 @@ * * @param vResolver A VariableResolver instance that can be used at runtime to * resolve the name of implicit objects into Objects. - * @return The result of the expression evaluation or null if errors were encountered. + * @return The result of the expression evaluation. * * @exception ELException Thrown if the expression evaluation failed. */ Index: jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java,v retrieving revision 1.3 diff -u -r1.3 ExpressionEvaluator.java --- jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java 3 Oct 2002 23:01:44 - 1.3 +++ jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java 9 Oct 2002 +00:07:33 - @@ -105,8 +105,7 @@ * it is invoked. * @param defaultPrefix The default prefix to use when a function is * encountered with no prefix. - * @return The Expression object encapsulating the arguments, or null - * if errors were encountered. + * @return The Expression object encapsulating the arguments. * * @exception ELException Thrown if parsing errors were found. */ @@ -135,8 +134,7 @@ * it is invoked. * @param defaultPrefix The default prefix to use when a function is * encountered with no prefix. - * @return The result of the expression evaluation or null if errors - * were encountered. + * @return The result of the expression evaluation. * * @exception ELException Thrown if the expression evaluation failed. */ Index: jsr154/src/share/dtd/j2ee_1_4.xsd === RCS file:
DO NOT REPLY [Bug 13430] - WWW-Authenticate Header Is Not Sent
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=13430. 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=13430 WWW-Authenticate Header Is Not Sent --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 00:18 --- Just like bug #12194, for Tomcat 3 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 WWW-Authenticate Header is not sent, causing agents not to prompt for credentials. When no error-page, Tomcat behaves as expected. So this code never works : oResponse.setHeader(WWW-Authenticate, BASIC realm=\Intranet\); oResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED); Using Apache 1.3 + mod_jk + Tomcat 4.1.12 + IBM JDK 1.3.1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] JikesJavaCompiler / pick up system classpath on Windows
The way I have Jasper running in 3.2.4, I have JikesJavaCompiler set up to
pass the -bootclasspath and -extdirs parameters to Jikes, based on
sun.boot.class.path and java.ext.dirs. It seemed to work quite well; it
meant that Jikes did not need any special handling in terms of setting up
the classpath on Win32.
I recently started looking at Tomcat 4.0.5 and noticed that it doesn't do
this, so I made a little patch against 4.0.5.
--- JikesJavaCompiler.java.orig Mon Sep 23 10:39:02 2002
+++ JikesJavaCompiler.java Mon Oct 07 18:04:16 2002
@@ -187,11 +187,16 @@
String[] compilerCmd = null;
+ String bootClassPath = System.getProperty(sun.boot.class.path);
+ String extDirs = System.getProperty(java.ext.dirs);
+
if( outdir != null ) {
compilerCmd = new String[] {
quote + compilerPath + quote,
//XXX - add encoding once Jikes supports it
-classpath, quote + classpath + MicrosoftClasspath + quote,
+-bootclasspath, quote + bootClassPath + quote,
+-extdirs, quote + extDirs + quote,
-d, quote + outdir + quote,
-nowarn,
+E,
@@ -202,6 +207,8 @@
quote + compilerPath + quote,
//XXX - add encoding once Jikes supports it
-classpath, quote + classpath + MicrosoftClasspath +
quote,
+ -bootclasspath, quote + bootClassPath + quote,
+ -extdirs, quote + extDirs + quote,
-nowarn,
+E,
quote + source + quote
end-of-patch
The quotes don't seem to be necessary, but I followed the convention used in
the 4.0.5 source code.
I don't know whether these extdirs and bootclasspath arguments exist on
Jikes/Linux, and I doubt the Microsoft Java VM would have those system
properties.
Sorry, nothing for 4.1.x; my company only recently added official support
for 4.0.5 after staying at 3.2.x for the longest time. It should be trivial
to add to the same in 4.1, though.
_
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
log4j.jar locked by Tomcat even after remove/undeploy ....
Hi Tomcat developers,
Below is a discussion that has been ongoing on the log4j-dev list. We are
trying to figure out why the log4j jar file is locked after a webapp is
removed from Tomcat using the Tomcat manager app. Basically, all jar
resources in a webapp are let go after a manager remove except for the
log4j jar (within WEB-INF/lib). In order to remove the lock on the jar,
Tomcat has to be shut down completely, not just have the webapp
removed. We had thought we had found the reason for it (static
initializers) but that didn't turn out to be reproducible. At this point,
we are a bit perplexed.
Can any Tomcat developers tell us if there are any classloading issues with
Tomcat that might cause Tomcat to hold onto a jar file in the WEB-INF/lib
directory after the app has been removed via the manager app? Could it be
commons-logging that is holding onto it? Any help would be appreciated.
BTW, could cross-post responses to [EMAIL PROTECTED]?
thanks,
Jake
Date: Mon, 07 Oct 2002 07:12:30 -0500
To: Log4J Developers List [EMAIL PROTECTED]
From: Jacob Kjome [EMAIL PROTECTED]
Subject: RE: FW: log4j.jar locked by Tomcat even after remove/undeploy
I'll pose this question to the tomcat-user and/or tomcat-dev list sometime
today. Maybe they can help us out on this.
Jake
At 09:39 PM 10/6/2002 -0700, you wrote:
I swear, I reproduced this multiple times before I posted my earlier
message. When I just tried it, the problem did not happen. Ack, this is
frustrating!
What else can we use to attack this problem? Is there some way to tell what
is active in the JVM that is preventing the jar from being unloaded?
-Mark
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 05, 2002 6:46 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: log4j.jar locked by Tomcat even after remove/undeploy
Hi Mark,
I am now subscribed to the log4j-dev list.
I tested all the scenarios that you described, but I never found
static_test.jar to be locked except for when the application is installed
(as expected). When I remove the app, the only thing that is locked is
log4j-1.2.6.jar. I can delete everything other than that.
It is really curious that it locks for you and doesn't for me???
The thing
is in Barracuda, the open source Presentation Framework, where the
Log4jInit and Log4jApplicationWatch come from, there are a number
of places
that use static initializers and I find no locking issues with the
Barracuda libraries.
Has anyone else reproduced Mark's results?
BTW, mark, when you use Log4jInit, you can just have the param for the
FileApender look something like this:
param name=File value=${barracuda.log.home}/main.log /
Basically, Log4jInit gerates a system variable based on the name of the
webapp context. Here is how it works:
[name of webapp context].log.home
So, a webapp at:
http://localhost:8080/barracuda/
would create a system variable named barracuda.log.home
A webapp at:
http://localhost:8080/myapp/
would create a system variable named myapp.log.home
Just look for the file main.log in WEB-INF/logs directory of you
webapp. If the logs directory doesn't exist, it will be
created. So, it
doesn't matter where your webapp is deployed from as long as it isn't
deployed directly from a .war file, you will never have to bother setting
the path. It will be found automatically.
If you want to override the path where the log file gets written,
just set
the log4j-log-home parameter for the Log4jInit servlet in the web.xml
such as:
param-namelog4j-log-home/param-name
param-valueD:\my\logging\path/param-value
Nice and flexible, heh?
Jake
At 10:52 AM 10/4/2002 -0700, you wrote:
The discussion has moved to the log4j-dev email list, but I don't know if
you are currently subscribed to that list, so I am forwarding it to you.
Please let me know what you find.
-Mark
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 11:18 PM
To: [EMAIL PROTECTED]
Subject: RE: log4j.jar locked by Tomcat even after remove/undeploy
Ceki Jake,
I have done some more tests, and I believe very strongly that
the problem is
in Tomcat. I have enclosed my entire webapp (I am still using the one I
made last night, with some modifications, and you will need to add the
log4j-1.2.6.jar to your deployment; I did not include it in the
enclosed zip
file).
Here is what I do, you tell me what you think:
1) I created 2 new classes, org.womacknet.StaticTest and
org.womacknet.NonStaticTest. StaticTest has a static initializer defined
and 2 static members. NonStaticTest does not have a static
intitializer and
only an instance member. I compiled these files and put them
into their own
static_test.jar, which I placed into the
WG: A new session should be invalidated automatically with response failure
Dear servlet container developers,
this is a proposal in order to improve the session management with
respect to saving of third party server side resources. This is the
same proposal I've sent as feedback to the Java Servlet Specification
Version 2.4 Proposed Final Draft August 5th 2002 (see below).
Although not (yet?) part of the Servlet Specification as a must,
it doesn't contradict the current or the upcoming specification.
Therefore, I suggest that you implement the described feature
with Tomcat just soon if you would agree to the proposal.
I'm not a subscriber of the tomcat-dev mailing list. So I'd be
pleased to receive any reply with the sender's address of this
message.
Kind Regards
Helmut Barthel
[EMAIL PROTECTED]
-Ursprüngliche Nachricht-
Von: Helmut Barthel [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 4. Oktober 2002 15:56
An: '[EMAIL PROTECTED]'
Betreff: A new session should be invalidated automatically with response
failure
Technical Feedback to
Java Servlet Specification Version 2.4
Proposed Final Draft August 5th 2002
SRV.7.5 Session Timeouts
Comment:
A paragraph like the following should be appended:
'The container must invalidate a new session immediately if itself
has finally found out that the session creating request cannot be
responded successfully.'
If the container itself knows that the client will never be able to join
the prospective session it should be required to invalidate such a
useless session object in order to release resources already bound to
the session, as soon as possible.
Discussion:
A logon servlet will often allocate special server side resource objects
and bind them to a newly created session object.
If the container cannot finish the response to the logon request for any
reasons the then useless session object continues to exist. Hence, the
resources remain bounded to it until the session times out.
This situation can arise easily, for example, because of impatient users.
If the resource allocation takes some time, that user species will
probably click the logon button again (or the cancel button of the
browser and then the logon button again). Hence, the user caused valuable
resources to be allocated twice. Let's tighten up this scenario: The
resource provider may request for the user's name and may be configured
in order to allow only one allocation per user at a time. Then the
impatient user will lose the firstly allocated resource (now parked with
the unjoinable first session) and will get an already connected message
from the resource provider while answering the second logon request.
Though the user is guilty, he will probably become angry, nevertheless.
As a thinkable workaround, the servlet programmer could bind an allocated
resource to the session as late as possible in the logon servlet's service
method - after testing the connection to the client:
HttpSession session = request.getSession();
SomeResourse resource = null;
if (session.isNew()) {
resource = ... // allocate the resource
try {
response.setBufferSize(large enough value);
... // write the response's success output
response.flushBuffer(); // test the client connection!
session.setAttribute(SomeResource, resource); // bind now
} catch (IOException e) {
// javax.servlet.ServletException:
// Connection reset by peer: socket write error
resource = null; // release the resource
session.invalidate();
}
return;
}
Such a workaround is neither generalizable to all possible programming
requirements of the servlet, nor it is guaranteed to work well with all
container implementations (e.g., the flushBuffer method is not *required*
to throw the declared IOException).
Kind Regards
Helmut Barthel
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jmx and context administration
hi all, currently I am working with tomcat-4.1-cvs-head and mx4j. I have looked at the org.apache.catalina.mbeans package but couldn't find a MBean or a Method for adding contexts to a catalina host entry. What I want to do is stop start and add a context to catalina during runtime w/ JMX, as I have some huge context I want to enable on demand. - is this feature currently implemented? - is anybody working on implementing a feature like that? - is catalina capable of dynamic context unloading ( i think so, as AFAIR the manager privileged context is able to do this ) - are you planing on implementing a jmx/connector to connect to jmx via rmi or something like this? thanks -- Jakob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows XP |Solaris --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 01:49 --- I am also having this problem on solaris 8, encoding enabled. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 01:56 --- Sorry, I didn't read the posts carefully enough. My problem isn't the encoding-- It looks like the jikes compilation command is not including the filename to be compiled. Here's the output with DEBUG verbosityLevel: An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] jsp/error500_jsp.java added as /export/home/mpark/jakarta-tomcat- 4.1.12/work/Standalone/localhost/memento/jsp/error500_jsp.class doesn't exist. [javac] Compiling 1 source file [javac] Using jikes compiler dropping /usr/java1.2/jre/jre/lib/rt.jar from path as it doesn't exist dropping /usr/java1.2/Classes/classes.jar from path as it doesn't exist dropping /usr/java1.2/Classes/ui.jar from path as it doesn't exist [javac] Compilation arguments: [javac] '-classpath' [javac] '/usr/java1.2/jre/lib/ext/iiimp.jar:/usr/java/lib/tools.jar:/export/home /mpark/jakarta-tomcat-4.1.12/bin/bootstrap.jar:/export/home/mpark/jakarta- tomcat-4.1.12/webapps/memento/WEB-INF/classes:/export/home/mpark/jakarta-tomcat- 4.1.12/webapps/memento/WEB-INF/lib/log4j-1.2.6.jar:/export/home/mpark/jakarta- tomcat-4.1.12/webapps/memento/WEB- INF/lib/memento.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/webapps/memento/WEB-INF/lib/webapp.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/shared/classes:/export/home/mpark/jakarta-tomcat- 4.1.12/common/classes:/export/home/mpark/jakarta-tomcat- 4.1.12/common/endorsed/xercesImpl.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/endorsed/xmlParserAPIs.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/jasper-compiler.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/commons-logging-api.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/naming-factory.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/ant.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/naming-common.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/naming-resources.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/commons-collections.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/activation.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/jta.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/commons-dbcp.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/mail.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/jasper-runtime.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/jdbc2_0-stdext.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/jndi.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/commons-pool.jar:/export/home/mpark/jakarta-tomcat- 4.1.12/common/lib/servlet.jar:/usr/java1.2/jre/lib/rt.jar:/export/home/mpark/jak arta-tomcat-4.1.12/work/Standalone/localhost/memento' [javac] '-encoding' [javac] 'ISO-8859-1' [javac] '-g' [javac] [javac] The ' characters around the executable and arguments are [javac] not part of the command. [javac] File to be compiled: [javac] /export/home/mpark/jakarta-tomcat- 4.1.12/work/Standalone/localhost/memento/jsp/error500_jsp.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Help! Tomcat problem
I got the following exception when I run TC5. I am using xerces-2_0_1. I tried disable xmlValidation, but still have the problem. catalina.sh run Using CATALINA_BASE: /home/kchung/tc/jakarta-tomcat-5/build Using CATALINA_HOME: /home/kchung/tc/jakarta-tomcat-5/build Using CATALINA_TMPDIR: /home/kchung/tc/jakarta-tomcat-5/build/temp Using JAVA_HOME: /tomc/j2sdk1.4.0/ Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance Oct 8, 2002 7:17:03 PM org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer Oct 8, 2002 7:17:06 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/5.0 Oct 8, 2002 7:17:08 PM org.apache.catalina.loader.WebappLoader start INFO: Reloading checks are enabled for this Context java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.registerLocalSchema(ContextConfig.java :740) at org.apache.catalina.startup.ContextConfig.createWebDigester(ContextConfig.java:5 93) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:628) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:774) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.ja va:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:791) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2290) at org.apache.catalina.startup.Catalina.start(Catalina.java:516) at org.apache.catalina.startup.Catalina.execute(Catalina.java:402) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav a:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid url-pattern in servlet mapping
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=13014. 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=13014 OS/390/USS - Invalid url-pattern in servlet mapping --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 03:11 --- Ned, We can live with version 331 for the time being until it is fixed. Have you found the source of this bug ? If so, is there any work around ? There was a discussion about support for running Tomcat on EBCDIC systems back in 28 Dec 1999 and then around 24 Mar 2000 in the tomcat-dev list. Then the subject was not heard of since then. Can anyone in the Development team comment on this subject ? Will there be any serious work on supporting Tomcat on EBCDIC systems such as IBM's USS ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13084] - jsp compilation with jikes fails
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=13084. 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=13084 jsp compilation with jikes fails [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Solaris |Windows XP --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 03:54 --- Matt, Just because you have a related problem on Solaris doesn't mean you change the original OS version. Given everyone's comments in this bug, this is an issue on Windows. If this exact issue was happening on Solaris, the solution would be to change the OS to All, not switch it to your own platform. I'm changing it back to the Original value Windows XP. I think we can assume any version of Windows. If you think this is wrong, change the OS to all, but since your issue seems different from this one, I suggest a new bug report instead. Jake -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13441] New: - WebApp Connector not writing status code properly on HTTP/1.1 responses
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=13441. 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=13441 WebApp Connector not writing status code properly on HTTP/1.1 responses Summary: WebApp Connector not writing status code properly on HTTP/1.1 responses Product: Tomcat 4 Version: 4.1.12 Platform: Other URL: http://web.dotinc.net/dynamic/dapps/test OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] All of our dynamic pages generated from Tomcat 4.1.12 hooked into our Apache server (2.0.40) via mod_webapp are now broken when viewed with IE 6 (upgraded to Service Pack 1). It seems that static pages from the server work OK but all of the dynamic pages are broken. When the same pages are viewed through mod_rewrite by proxying directly to port 8080 on Tomcat, they work fine. It seems that the only difference between the pages that work and those that don't is the status response code for the pages that are served properly. For the pages that work, the status line in the response header is HTTP/1.1 200 OK for the WebApp served pages, it is HTTP/1.1 OK This URL worked OK with the previous version of IE but breaks IE 6 SP 1. This problem does not affect loading of these dynamic pages on any Netscape browsers I have tried but Netscape 4.77 pops up a dialog saying Unknown Status Code 0! before loading the page. I think this is occuring because it is trying to parse the OK as a number because the 200 status code is missing. This problem started occurring when we upgraded both Tomcat and the Apache server recently on our main Linux Web server and a client testing another dynamic site encountered this problem the day after the switchover occurred. p.s. the mod_rewrite solution mentioned above serves as a viable workaround to the problem but and redirects would have to be modified to be absolute URLs or possible changed to server HTML with meta tag refreshes. Hope this description and sample URL help fix the bug right away. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler TagPoolManagerGenerator.java
billbarker2002/10/08 22:56:09 Modified:src/share/org/apache/jasper/compiler TagPoolManagerGenerator.java Log: Remove dependency on GenericServlet from the generated java file. The spec only allow us to assume that the base class is a Servlet, not a GenericServlet. This works for all conforming base classes. Fix for bug #13378 Reported by: Jorgen Rydenius [EMAIL PROTECTED] Revision ChangesPath 1.4 +2 -2 jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolManagerGenerator.java Index: TagPoolManagerGenerator.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolManagerGenerator.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TagPoolManagerGenerator.java 11 May 2001 18:42:57 - 1.3 +++ TagPoolManagerGenerator.java 9 Oct 2002 05:56:09 - 1.4 @@ -90,7 +90,7 @@ writer.pushIndent(); // writer.println(org.apache.jasper.runtime.TagPoolManager.getDefaultPoolManager();); writer.println(( + Constants.JSP_RUNTIME_PACKAGE -+ .TagPoolManager) getServletContext().getAttribute(\ + ++ .TagPoolManager) getServletConfig().getServletContext().getAttribute(\ + TagPoolManager.CONTEXT_ATTRIBUTE_NAME + \);); writer.popIndent(); } -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13430] - WWW-Authenticate Header Is Not Sent
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=13430. 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=13430 WWW-Authenticate Header Is Not Sent --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 06:02 --- Thi is a dupe of a 4.0.x bug, I think. The spec doesn't require supporting error pages for internal container status codes (as per an answer given by Craig). The problem here is that we have to reset the response to some kind of knwon state. It was proposed that only the critical headers be reset during the operation. See the ErrorDispatcherValve for more info. If you could submit a patch, that would help (otherwise, this won't get fixed anytime soon). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13378] - Generated code assumes definition of getServletContext() in base class.
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=13378. 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=13378 Generated code assumes definition of getServletContext() in base class. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 06:20 --- Now fixed in the CVS HEAD. It will appear in the next nightly, and in 3.3.2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL/VOTE] tcpnodelay to true by default ?
Costin Manolache wrote: I'm convinced, thank you very much for taking the time to test and analyze this. We should switch the setting in the main branch - not sure if Remy has a branch for 4.1/4.0, and if he has I think he should decide if he wants this backported. If anything happens we can roll back. I'll make the change in JTC for Ajp connectors. I hope we'll hear more from Han Ming in future :-) Hope so, welcome Apple members. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.1.12 rpm release 2 uploaded
A quick note to warn rpms users that rpm release 2 of tomcat 4.1.12 has been released and fix : - fix tomcat4.conf to use /etc/java/java.conf - fix tomcat4 initd to be sure that we'll stop/start the task owner by TOMCAT_USER and running catalina - fix perms on /etc/tomcat4, contents is owned by root.tomcat4, and only jk2.properties and tomcat-users.xml could be updated by tomcat4 user. - change ref and use of xerces-j2.jar by jaxp_parser_impl.jar. - include ant 1.5.1 - remove commons-lang as no more required - copy a correct mod_jk.jpeg Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK 2.0.1 for Linux (binaries and rpms) uploaded
JK 2.0.1 for Linux i386 binaries and rpms (including sources) are available : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.1/bin/linux/i386/ http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.1/rpms/ Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
