[GUMP] Build Failure - jakarta-tomcat-5
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-02-18/jakarta-tomcat-5.html Buildfile: build.xml prepare-release: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0 [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src init: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes deploy-static: deploy: [echo] Target: Servlet API - Dist ... prepare: static: compile: examples: javadoc: jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr154/build dist: [echo] Target: JSP API - Dist ... prepare: static: compile: examples: javadoc: jar: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr152/build dist: [echo] Target: Catalina - Deploy ... deploy-prepare: deploy-static: deploy: [echo] Target: Catalina - Deploy ... flags: flags.display: [echo] --- Build environment for Catalina --- [echo] If ${property_name} is displayed, then the property is not set) [echo] --- Build options --- [echo] full.dist=${full.dist} [echo] build.sysclasspath=only [echo] compile.debug=on [echo] compile.deprecation=off [echo] compile.optimize=off [echo] --- Ant Flags --- [echo] style task available (required)=true [echo] --- JDK --- [echo] jdk.1.2.present=true [echo] jdk.1.3.present=true [echo] jdk.1.4.present=true [echo] --- Source Dependencies --- [echo] jtc.home.present=true [echo] --- Required Libraries --- [echo] beanutils.present=true [echo] collections.present=true [echo] digester.present=true [echo] jaxp.present=true [echo] jndi.present=true [echo] logging.present=true [echo] regexp.present=true [echo] --- Optional Libraries --- [echo] dbcp.present=true [echo] fileupload.present=${fileupload.present} [echo] jaas.present=true [echo] javamail.present=true [echo] jmx.present=true [echo] jsse.present=true [echo] jta.present=true [echo] junit.present=true [echo] lang.present=${lang.present} [echo] launcher.present=${launcher.present} [echo] launcher.bootstrap.present=${launcher.bootstrap.present} [echo] ldap.present=true [echo] modeler.present=true [echo] pool.present=true [echo] tyrex.present=${tyrex.present} [echo] --- Required JARs --- [echo] jndi.jar.present(except JDK 1.3+)=true [echo] regexp.jar.present=true [echo] servlet-api.jar.present=true [echo] xerces2.jars.present(except JDK 1.4+)=true [echo] --- Optional JARs --- [echo] dbcp.jar.present=true [echo] fileupload.jar.present=${fileupload.jar.present} [echo] jaas.jar.present=true [echo] javamail.jar.present=true [echo] jdbc20ext.jar.present=true [echo] jmx.jar.present=true [echo] jta.jar.present=true [echo] junit.jar.present=${junit.jar.present} [echo] modeler.jar.present=true [echo] pool.jar.present=true [echo] tyrex.jar.present=${tyrex.jar.present} [echo] --- Conditional compilation flags --- [echo] compile.dbcp=true [echo] compile.jaas=true [echo] compile.javamail=true [echo] compile.jmx=true [echo] compile.jndi=true [echo] compile.jsse=true [echo] compile.jta=true [echo] compile.junit=true [echo] compile.ldap=true [echo] compile.ssi=true [echo] compile.tyrex=${compile.tyrex} [echo] --- Distribution flags --- [echo] copy.dbcp.jar=true [echo] copy.jmx.jar=true [echo] copy.launcher.jars=${copy.launcher.jars} [echo] copy.logging.jar=true [echo] copy.modeler.jar=true [echo] copy.pool.jar=true build-prepare: copy-dbcp.jar: copy-fileupload.jar: copy-jmx.jar: copy-launcher.jars: copy-modeler.jar: copy-pool.jar: copy-xerces2.jars: build-static: build-tomcat-util: detect: build-prepare: build-main: [echo] - Java-utils - [echo] -- puretls.present = ${puretls.present} [echo] -- jsse.present = true [echo] -- commons-logging = true [echo] -- jmx = true /opt/jmx-1_0_1-ri_bin/jmx/lib/jmxri.jar [echo] -- modeler = true /home/rubys/jakarta/jakarta-commons/modeler/dist/commons-modeler.jar build-catalina-core: build-catalina-optional: build-catalina: build-main: deploy-prepare: deploy-static: catalina-jars: deploy-catalina: build-tomcat-coyote: init: [echo] Coyote 1.0-dev prepare: static: report-tc5: [echo] Tomcat5 detected report-tc4: report-tc33: report: compile.shared: compile.tomcat5:
[GUMP] Build Failure - jakarta-tomcat-jk-native
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-02-18/jakarta-tomcat-jk-native.html Buildfile: build.xml init: [echo] /home/rubys [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk apache20: apache13: iis: netscape: jni: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni [so] Compiling 4 out of 4 Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c [so] Compile failed 1 /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c [so] Command:libtool --mode=compile cc -c -o /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/jk_jnicb.o -I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common -I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni -I/usr/java/j2sdk1.4.1_01/jre/../include -I${build.compiler.base}/include -g -W /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c [so] Output: [so] mkdir /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/.libs [so] cc -c -I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common -I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni -I/usr/java/j2sdk1.4.1_01/jre/../include -I\${build.compiler.base}/include -g -W /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c -fPIC -DPIC -o /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/.libs/jk_jnicb.lo [so] StdErr: [so] In file included from /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.h:2, [so] from /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c:64: [so] /usr/java/j2sdk1.4.1_01/include/jni.h:27:20: jni_md.h: No such file or directory BUILD FAILED file:///home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/build.xml:63: Compile failed /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c Total time: 6 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Users get wrong session after reload.
Hello, We are using Tomcat 4.1.18 here. If we reload our application, sometimes a user gets a session of somebody else. Big problem. I think the problem is here: In ...catalina.session.JDBCStore.java, line 507, there is this code. preparedLoadSql.setString(1, id); rst = preparedLoadSql.executeQuery(); Is this thread safe? Isn't this better? synchronized(preparedLoadSql) { preparedLoadSql.setString(1, id); rst = preparedLoadSql.executeQuery(); } Any suggestions? If this isn't the cause of the problem, what can be the cause? Because it's a race condition it's difficault to debug. Greetings, Ronald. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request to Fix Tomcat Standalone 302 redirect Issue
Can this functionality be back-ported to the 4.1 tree? tia, Jim -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 04:48 To: Tomcat Developers List Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue - Original Message - From: neal [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 8:00 PM Subject: RE: Request to Fix Tomcat Standalone 302 redirect Issue So it *will* be in tomcat 5? My head is spinning...so confusing. How does one access o.a.t.u.http.mapper.Mapper? Is this something that will be configurable via web.xml? It will be in configurable in 'server.xml' (or, at least it will be when I do my next commit :). Anyone have a ballpark idea on when Tomcat 5 will be released? Or at least when a release-candidate-quality binary will be available? :) Thanks. Neal -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 16, 2003 8:01 PM To: Tomcat Developers List Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue For TC 5, it isn't in DefaultServlet (which gets called way too late). It's in o.a.t.u.http.mapper.Mapper. - Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 6:43 PM Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue If I remember that thread correctly, the functionality was not been added according to the code. http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina /src/share /org/apache/catalina/servlets/DefaultServlet.java?rev=1.5content- type=text/ vnd.viewcvs-markup -Tim neal wrote: I just took a look at the web.xml file found within the tomcat 5 download (jakarta-tomcat-catalina/catalina/conf) and saw no indication of the inclusion of this patch. Per indications in the thread referred to below, I looked for an indication that an init parameter was included that could be toggled to achieve this behavior but nothing was denoted in the comments above this node that would suggest it is a new feature. Could someone please confirm that this feature has been included into tomcat 5 and instruct me as to how I would access this new functionality? I really really really want the forward behavior for my default page. :-\ Thanks Neal -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 16, 2003 11:39 AM To: Tomcat Developers List Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue 5 will *probably* not be final until - The specs(Serlvet 2.4, jsp 2.) become final - The many internal changes are tested more - The committers vote to declare it so From seeing past messages - it looks like the specs being declared final is the buggest hurdle (to wait for). (But there have been some significant internal changes which need more testing) But anyone is free to use it since the source is available to make their own release. -Tim neal wrote: Actually, I just went to download tomcat 5 and it looks like there's no release candidate of Tomcat 5 yet ... that its still in testing. Is this correct? Does anyone know a timeframe for release? Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17162] New: - Cannot catch IllegalStateException with web.xml after exceeding maxActiveSessions limit
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=17162. 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=17162 Cannot catch IllegalStateException with web.xml after exceeding maxActiveSessions limit Summary: Cannot catch IllegalStateException with web.xml after exceeding maxActiveSessions limit Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I cannot catch IllegalStateException with web.xml after exceeding maxActiveSessions limit. I set the attribute maxActiveSessions for my context in server.xml. When the the limit is reached it throws an IllegalStateException (in the browser it shows 500 error with 'IllegalStateException:createSession:Too many active sessions') I can't find an easy way to handle this exception with Tomcat. I tried adding error-page tags in web.xml to catch this exception but that didn't work. It seems that after the exception Tomcat doesn't use web.xml the same. I tried testing with the servlet SessionExample that comes with Tomcat. I set the maxActiveSessions to 3. Then added an error-page tag for error code 404 to the web.xml to test this. With fewer than three sessions, on a file not found error it fowarded to the page I specified. After 3 sessions it did not forward to the page I had specified. Is there a way for Tomcat to handle this exception it throws? Basically I only want a website saying too many users. Do I have to handle this somehow in my code? Thank you for you time and for the great product you produce. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15520] - JSP-Servlet is broken
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=15520. 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=15520 JSP-Servlet is broken --- Additional Comments From [EMAIL PROTECTED] 2003-02-18 16:23 --- I can confirm this issue on 4.1.17. But upgrading to 4.1.18 worked wonders. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17171] New: - Tomcat 5 Nightly binaries are not available
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=17171. 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=17171 Tomcat 5 Nightly binaries are not available Summary: Tomcat 5 Nightly binaries are not available Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Installable Packages AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I want to download a binary version of the latest Tomcat 5, but when I go to the nightly builds area - the .zip and .tar.gz files are empty for the binary versions: http://cvs.apache.org/builds/jakarta-tomcat-5/nightly/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native build.xml
costin 2003/02/18 09:53:57 Modified:jk/native build.xml Log: Port back the os detection from jk2. This should solve the gump failure. Revision ChangesPath 1.37 +19 -0 jakarta-tomcat-connectors/jk/native/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- build.xml 16 Jan 2003 21:00:57 - 1.36 +++ build.xml 18 Feb 2003 17:53:57 - 1.37 @@ -51,6 +51,25 @@ available property=HAVE_APR file=${apr.include}/apr.h / mkdir dir=${jk.build}/jk / +condition property=linux + equals arg1=${os.name} arg2=Linux/ +/condition +condition property=solaris + equals arg1=${os.name} arg2=SunOS/ +/condition +condition property=win32 + os family=windows/ +/condition +condition property=hpux + equals arg1=${os.name} arg2=HP-UX/ +/condition +!-- I believe they are using cross-compilation, so checking the os.name + doesn't help. We'll check if the NDK is installed instead -- +condition property=netware + available file=novellndk.home / +/condition +echo message=linux=${linux} solaris=${solaris} win32=${win32} hpux=${hpux} netware=${netware}/ + /target target name=jni depends=init - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.1] Tagging today
From my experience, Tomcat 5.0.1 doesn't appear to have any critical issue remaining. I plan to put the 5.0.1 tag later today and release alpha binaries. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... -- Jeanfrancois build-static: [copy] Copying 1 file to /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/server/webapps/admin [copy] Copying 1 file to /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/server/webapps/admin/WEB-INF/classes/org/apache/webapp/admin build-main: [javac] Compiling 1 source file to /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/server/webapps/admin/WEB-INF/classes [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/server/webapps/admin/WEB-INF/src/admin [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/webapps/ROOT/WEB-INF/src [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/webapps/ROOT/WEB-INF/classes [mkdir] Created dir: /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/webapps/jsp-examples/WEB-INF/src [jasper2] org.apache.jasper.JasperException: XML parsing error on file /WEB-INF/lib/standard.jar: (line 307, col 39) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.processTldsInJar(TldLocationsCache.java:302) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.processJars(TldLocationsCache.java:239) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:171) [jasper2] at org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:392) [jasper2] at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:534) [jasper2] at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:447) [jasper2] at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:504) [jasper2] at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1541) [jasper2] at org.apache.jasper.compiler.Parser.parse(Parser.java:164) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:270) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:155) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:142) [jasper2] at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:243) [jasper2] at org.apache.jasper.JspC.processFile(JspC.java:572) [jasper2] at org.apache.jasper.JspC.execute(JspC.java:808) [jasper2] at java.lang.reflect.Method.invoke(Native Method) [jasper2] at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:147) [jasper2] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) [jasper2] at org.apache.tools.ant.Task.perform(Task.java:319) [jasper2] at org.apache.tools.ant.Target.execute(Target.java:309) [jasper2] at org.apache.tools.ant.Target.performTasks(Target.java:336) [jasper2] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [jasper2] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:371) [jasper2] at org.apache.tools.ant.Task.perform(Task.java:319) [jasper2] at org.apache.tools.ant.Target.execute(Target.java:309) [jasper2] at org.apache.tools.ant.Target.performTasks(Target.java:336) [jasper2] at org.apache.tools.ant.Project.executeTarget(Project.java:1306) [jasper2] at org.apache.tools.ant.Project.executeTargets(Project.java:1250) [jasper2] at org.apache.tools.ant.Main.runBuild(Main.java:610) [jasper2] at org.apache.tools.ant.Main.start(Main.java:196) [jasper2] at org.apache.tools.ant.Main.main(Main.java:235) [jasper2] [ERROR] TldLocationsCache - -Exception initializing TldLocationsCache org.apache.jasper.JasperException: XML parsing error on file /WEB-INF/lib/standard.jar: (line 307, col 39) [jasper2] org.apache.jasper.JasperException: XML parsing error on file /WEB-INF/jsp/example-taglib.tld: (line 307, col 39) [jasper2] at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:145) [jasper2] at org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:255) [jasper2] at org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:197) [jasper2] at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:448) [jasper2] at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:504) [jasper2] at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1541) [jasper2] at org.apache.jasper.compiler.Parser.parse(Parser.java:164) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:270) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:155) [jasper2] at org.apache.jasper.compiler.ParserController.parse(ParserController.java:142) [jasper2] at
Re: [5.0.1] Tagging today
Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15520] - JSP-Servlet is broken
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=15520. 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=15520 JSP-Servlet is broken [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-18 19:09 --- Yes, there was a bug in those prereleases with the refactored writer which was passed to Jasper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). I'd need a Win9x compatible version of procrun to make the release, also :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17178] New: - if user-agent sends cookies that add up more than 4K SocketInputStream throws an exception
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=17178. 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=17178 if user-agent sends cookies that add up more than 4K SocketInputStream throws an exception Summary: if user-agent sends cookies that add up more than 4K SocketInputStream throws an exception Product: Tomcat 4 Version: 4.1.20 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The SocketInputStream class reads HTTP headers up to a maximum of 4096 bytes (HttpHeader.MAX_VALUE_SIZE), after that it fails logging the exception in catalina's log. I assume they hardcoded this limit assuming the maximum length of a single Cookie (4K). However, browsers append cookies into a single Cookies header separating the cookies with ';'. If you have 2 cookies going with the same request and adding up more than 4K, then the request fails. Offending code [SocketInputStream, line 461]: if ((2 * maxRead) = HttpHeader.MAX_VALUE_SIZE) { As browsers are recommended to support at least 20 cookies to a single web site of 4K each, the value of the HttpHeader.MAX_VALUE_SIZE should be 20 bigger. [This applies to all 4.x versions] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17179] New: - Compile time includes outside of WEB context root, are not found
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=17179. 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=17179 Compile time includes outside of WEB context root, are not found Summary: Compile time includes outside of WEB context root, are not found Product: Tomcat 4 Version: 4.1.8 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Static includes of the form : %@ include file=../testinc.jsp % where the current directory is the root of the web application, and so testinc.jsp lives one or more directory levels above the root of the web app. Produce an error : org.apache.jasper.JasperException: /test2.jsp(3,0) File ../testinc.jsp not found This is a difference in behaviour from Tomcat 4.0.5, which would allow this compilation. Note - I tried working around this by copying the jasper-compiler.jar jasper- runtime.jar files from Tomcat 4.0.5 to Tomcat 4.1.8 but the problem still remained. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17179] - Compile time includes outside of WEB context root, are not found
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=17179. 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=17179 Compile time includes outside of WEB context root, are not found [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-02-18 20:15 --- Allowing access to resources outside the webapp is a security vulnerability -- in fact, this was the reason that 4.0.5 was replaced by 4.0.6. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP @include directive
Hi, I need to use include directive in JSP that points to file physically located outside directory tree for Web application context. I tested two forms of include directive: %@include file=/../inc/name.inc % and %@include file=/symlink/name.inc %. As far as I can tell from Tomcat 4.1.18 sources the former is forbidden, i.e., cannot specify path that goes beyond application context. The latter is OK, as long as org.apache.naming.resources.FileDirContext.setAllowLinking() has been called with true argument. Symlinks are disallowed by default and I don't see any place in the code where setAllowLinking method gets called. Sounds like a problem to me. Please tell me if above behavior is erroneous, and how can I cope with this situation. Thank you, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). +1 for fixing the bug too - but I don't know how :-) It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). +1 for fixing the bug too - but I don't know how :-) It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. The bug happens in the jsp-examples precompilation (which is supposed to work also, right ?). One of the tag examples apparently causes problems. One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. +1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml
[EMAIL PROTECTED] wrote: costin 2003/02/16 20:38:45 Modified:resources mbeans.xml Log: Few cosmetic changes in names. Add a context using JMX ( /admin1 ). The procedure is simple: 1. create an mbean using the o.aStandardContext as code and the JSR77 name. 2. Call start() 3. Enjoy :-) Awesome! :-) What is the status of tomcat5 JMX support (including dynamic configs)? Do you have a todo list or howto docs? I'd like to help now that I think I have some more time to spend. Thanks, Amy The context will use the domain to locate the engine and will insert itself in the running server. To remove the context - just call the stop method on the JSR77 name. Revision ChangesPath 1.5 +30 -5 jakarta-tomcat-5/resources/mbeans.xml Index: mbeans.xml === RCS file: /home/cvs/jakarta-tomcat-5/resources/mbeans.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- mbeans.xml 16 Jan 2003 23:16:12 - 1.4 +++ mbeans.xml 17 Feb 2003 04:38:45 - 1.5 @@ -11,8 +11,10 @@ property name=tomcat.src location=.. / property name=catalina.src location=../../jakarta-tomcat-catalina / property name=jakarta-commons location=${base.src}/jakarta-commons / +!-- + property name=jmx.home location=${base.dir}/mx4j-1.1.1 / +-- property name=jmx.home location=${base.dir}/jmx-ri_1.2 / - property name=tomcat.home location=${tomcat.src}/build / property name=commons-modeler.home location=${jakarta-commons}/modeler/dist / @@ -23,6 +25,11 @@ path id=tomcatCP-extra / + !-- + taskdef name=commons-logger classname=org.apache.tools.ant.listener.CommonsLoggingListener/ + commons-logger/ + -- + target name=init unless=init.done property name=tomcat.home location=.. / @@ -156,21 +163,39 @@ target name=run depends=init description=Start tomcat as an mbean using server.xml config and returns +property name=domain value=Catalina / modeler code=org.apache.catalina.startup.Catalina - name=Catalina:type=server / + name=${domain}:type=server / -jmxSet objectName=Catalina:type=server +jmxSet objectName=${domain}:type=server attribute=catalinaHome value=${tomcat.home}/ !-- We could also call init and set other properties - init should load the modules -- -jmx objectName=Catalina:type=server +jmx objectName=${domain}:type=server operation=start / - + + echo message=Tomcat5 running/ + +!-- let's add a context - using JMX -- +property name=admin1Name + value=${domain}:j2eeType=WebModule,name=//localhost/admin1,J2EEApplication=none,J2EEServer=none / + +modeler code=org.apache.catalina.core.StandardContext + name=${admin1Name} / + +jmxSet objectName=${admin1Name} +attribute=docBase +value=${tomcat.home}/server/webapps/admin / + +jmx objectName=${admin1Name} + operation=init / + + /target !-- Await - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17184] New: - jsp:include does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17184. 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=17184 jsp:include does not work Summary: jsp:include does not work Product: Tomcat 4 Version: 4.1.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] i was not able to include my jsp page using include command. The compiler did not gave an error. However using the %@ include % command it worked fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17185] New: - webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive
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=17185. 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=17185 webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive Summary: webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The isELIgnored directive is defaulted to true for webapps deployed with a pre- 2.4 descriptor, per spec, by a couple lines of code in Compiler.java. After that happens, a %@ page isELIgnored=false % directive is encountered in Validator.java, but does not take effect because it thinks the true value was explicitly specified in a jsp-config. The net result is that it's not possible to set isELIgnored to false in a pre-2.4 webapp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java CoyoteConnector.java
costin 2003/02/18 14:51:40 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java CoyoteConnector.java Log: Merged few changes from 5.0 to enable JMX on thread pools and connector. This is in the HEAD - jk and http adapters already have the dependency on JMX and modeler. Note that the code is called only if the connector is registered with JMX - if not, nothing will happen. Revision ChangesPath 1.14 +4 -34 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java Index: CoyoteAdapter.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- CoyoteAdapter.java10 Dec 2002 08:43:21 - 1.13 +++ CoyoteAdapter.java18 Feb 2003 22:51:39 - 1.14 @@ -64,53 +64,23 @@ package org.apache.coyote.tomcat4; -import java.io.BufferedInputStream; -import java.io.EOFException; -import java.io.InterruptedIOException; -import java.io.InputStream; import java.io.IOException; -import java.io.OutputStream; -import java.net.InetAddress; -import java.net.Socket; -import java.util.ArrayList; -import java.util.Enumeration; -import java.util.Iterator; -import java.util.Locale; -import java.util.StringTokenizer; -import java.util.TreeMap; -import javax.servlet.ServletException; import javax.servlet.http.Cookie; import javax.servlet.http.HttpServletRequest; -import javax.servlet.http.HttpServletResponse; import org.apache.tomcat.util.buf.ByteChunk; -import org.apache.tomcat.util.buf.HexUtils; import org.apache.tomcat.util.buf.MessageBytes; import org.apache.tomcat.util.http.Cookies; import org.apache.tomcat.util.http.ServerCookie; import org.apache.coyote.ActionCode; -import org.apache.coyote.ActionHook; import org.apache.coyote.Adapter; -import org.apache.coyote.InputBuffer; -import org.apache.coyote.OutputBuffer; import org.apache.coyote.Request; import org.apache.coyote.Response; -import org.apache.catalina.Connector; -import org.apache.catalina.Container; import org.apache.catalina.Globals; -import org.apache.catalina.HttpRequest; -import org.apache.catalina.HttpResponse; -import org.apache.catalina.Lifecycle; -import org.apache.catalina.LifecycleEvent; -import org.apache.catalina.LifecycleException; -import org.apache.catalina.LifecycleListener; import org.apache.catalina.Logger; -import org.apache.catalina.util.LifecycleSupport; -import org.apache.catalina.util.RequestUtil; import org.apache.catalina.util.StringManager; -import org.apache.catalina.util.StringParser; /** 1.23 +85 -59 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java Index: CoyoteConnector.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- CoyoteConnector.java 10 Feb 2003 09:57:37 - 1.22 +++ CoyoteConnector.java 18 Feb 2003 22:51:39 - 1.23 @@ -65,36 +65,15 @@ package org.apache.coyote.tomcat4; -import java.io.IOException; -import java.net.InetAddress; -import java.net.ServerSocket; -import java.net.Socket; -import java.net.UnknownHostException; -import java.security.AccessControlException; -import java.util.Stack; import java.util.Vector; -import java.util.Enumeration; -import java.security.KeyStoreException; -import java.security.NoSuchAlgorithmException; -import java.security.cert.CertificateException; -import java.security.UnrecoverableKeyException; -import java.security.KeyManagementException; - import org.apache.tomcat.util.IntrospectionUtils; -import org.apache.coyote.ActionCode; -import org.apache.coyote.ActionHook; import org.apache.coyote.Adapter; -import org.apache.coyote.InputBuffer; -import org.apache.coyote.OutputBuffer; import org.apache.coyote.ProtocolHandler; import org.apache.catalina.Connector; import org.apache.catalina.Container; -import org.apache.catalina.HttpRequest; -import org.apache.catalina.HttpResponse; import org.apache.catalina.Lifecycle; -import org.apache.catalina.LifecycleEvent; import org.apache.catalina.LifecycleException; import org.apache.catalina.LifecycleListener; import org.apache.catalina.Logger; @@ -105,6 +84,11 @@ import org.apache.catalina.net.ServerSocketFactory; import org.apache.catalina.util.LifecycleSupport; import org.apache.catalina.util.StringManager; +import org.apache.commons.modeler.Registry; +
DO NOT REPLY [Bug 17185] - webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive
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=17185. 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=17185 webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-02-18 23:05 --- The page directive with isELIgnored attribute is defined only in JSP 2.0, which requires a 2.4 descriptor. You are asking for trouble if you use JSP 2.0 features with a 2.3 descriptor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Date: Tue, 18 Feb 2003 21:46:54 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5.0.1] Tagging today To: Tomcat Developers List [EMAIL PROTECTED] Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). +1 for fixing the bug too - but I don't know how :-) It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. The bug happens in the jsp-examples precompilation (which is supposed to work also, right ?). One of the tag examples apparently causes problems. The strange thing is the error hapeened with source.jsp, which is not one of the exmaples. Do you guys know what it's for? I also don't believe jsp-examples has been successful compiled with JSPC before. I know haven't tried that with JSP2.0 examples. With automatic compiling of the tag files, I won't be surprise if there are problems. :) One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. +1. +1 from me too. However, is Jspc good enough now? Are there areas that need to be fixed? We should not make this a requirement for tomcat5 and recommand such a practice until it is good enough. For now we should just turn off precompilation of the examples until the problem is identified and fixed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Kin-Man Chung wrote: Date: Tue, 18 Feb 2003 21:46:54 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5.0.1] Tagging today To: Tomcat Developers List [EMAIL PROTECTED] Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). +1 for fixing the bug too - but I don't know how :-) It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. The bug happens in the jsp-examples precompilation (which is supposed to work also, right ?). One of the tag examples apparently causes problems. The strange thing is the error hapeened with source.jsp, which is not one of the exmaples. Do you guys know what it's for? It's actually in \jsp2\tagfiles\panel.jsp. I also don't believe jsp-examples has been successful compiled with JSPC before. I know haven't tried that with JSP2.0 examples. With automatic compiling of the tag files, I won't be surprise if there are problems. :) One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. +1. +1 from me too. However, is Jspc good enough now? Are there areas that need to be fixed? We should not make this a requirement for tomcat5 and recommand such a practice until it is good enough. For now we should just turn off precompilation of the examples until the problem is identified and fixed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java
costin 2003/02/18 15:37:01 Modified:catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java Log: Typo. Revision ChangesPath 1.48 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java Index: MBeanUtils.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- MBeanUtils.java 12 Feb 2003 22:06:33 - 1.47 +++ MBeanUtils.java 18 Feb 2003 23:37:00 - 1.48 @@ -977,7 +977,7 @@ String webMod=// + ((hostName==null)? DEFAULT :hostName ) + path; name = new ObjectName(domain + :j2eeType=Servlet,name= + sname + ,WebModule= + -webMod + ,J2EEAppilication=none,J2EEServer=none); +webMod + ,j2eeApplication=none,J2EEServer=none); return (name); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java
costin 2003/02/18 15:40:28 Modified:catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java Log: Typo - again... Revision ChangesPath 1.49 +6 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java Index: MBeanUtils.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- MBeanUtils.java 18 Feb 2003 23:37:00 - 1.48 +++ MBeanUtils.java 18 Feb 2003 23:40:27 - 1.49 @@ -945,7 +945,7 @@ String localName= // + ((host.getName()==null)? DEFAULT : host.getName()) + path; name = new ObjectName(domain + :j2eeType=WebModule,name= + - localName + ,j2eeApplication=none,j2eeServer=none); + localName + ,J2EEApplication=none,J2EEServer=none); return (name); } @@ -977,7 +977,7 @@ String webMod=// + ((hostName==null)? DEFAULT :hostName ) + path; name = new ObjectName(domain + :j2eeType=Servlet,name= + sname + ,WebModule= + -webMod + ,j2eeApplication=none,J2EEServer=none); +webMod + ,J2EEApplication=none,J2EEServer=none); return (name); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java ApplicationHttpRequest.java
luehe 2003/02/18 15:49:46 Modified:catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java ApplicationHttpRequest.java Log: Followup to fix for Bugtraq 4658324: Only in the case of the forward (not include!) method of the RequestDispatcher must the path elements of the request object (including queryString) exposed to the target servlet reflect the path used to obtain the RequestDispatcher (in the case of the include method, the path elements of the original request are preserved). Revision ChangesPath 1.10 +6 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java Index: ApplicationDispatcher.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- ApplicationDispatcher.java12 Feb 2003 17:39:11 - 1.9 +++ ApplicationDispatcher.java18 Feb 2003 23:49:45 - 1.10 @@ -467,6 +467,7 @@ wrequest.setAttribute(Globals.FORWARD_QUERY_STRING_ATTR, queryString); wrequest.setQueryString(queryString); + wrequest.setQueryParams(queryString); } // only set the Dispatcher Type to Forward if it has not been set. It will have @@ -627,7 +628,7 @@ if (queryString != null) { wrequest.setAttribute(Globals.INCLUDE_QUERY_STRING_ATTR, queryString); - wrequest.setQueryString(queryString); + wrequest.setQueryParams(queryString); } wrequest.setAttribute(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR, 1.4 +23 -6 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java Index: ApplicationHttpRequest.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ApplicationHttpRequest.java 12 Feb 2003 17:39:11 - 1.3 +++ ApplicationHttpRequest.java 18 Feb 2003 23:49:45 - 1.4 @@ -191,6 +191,12 @@ /** + * The query parameters for the current request. + */ +private String queryParamString = null; + + +/** * Have the parameters for this request already been parsed? */ private boolean parsedParams = false; @@ -544,6 +550,17 @@ } +/** + * Save query parameters for this request. + * + * @param queryString The query string containing parameters for this + *request + */ +void setQueryParams(String queryString) { +this.queryParamString = queryString; +} + + // -- Protected Methods @@ -613,7 +630,7 @@ */ private void mergeParameters() { -if ((queryString == null) || (queryString.length() 1)) +if ((queryParamString == null) || (queryParamString.length() 1)) return; HashMap queryParameters = new HashMap(); @@ -622,7 +639,7 @@ encoding = ISO-8859-1; try { RequestUtil.parseParameters -(queryParameters, queryString, encoding); +(queryParameters, queryParamString, encoding); } catch (Exception e) { ; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
luehe 2003/02/18 16:33:28 Modified:catalina/src/share/org/apache/catalina/session StandardSession.java Log: Fix for Bugtraq 4688277: Invoking session.invalidate() after setting max inactive interval to 0 does not throw IllegalStateException The reason for this failure has been that setMaxInactiveInterval does not expire the session immediately if the 'interval' argument equals 0. Revision ChangesPath 1.13 +7 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java Index: StandardSession.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- StandardSession.java 10 Feb 2003 09:59:01 - 1.12 +++ StandardSession.java 19 Feb 2003 00:33:27 - 1.13 @@ -495,6 +495,9 @@ public void setMaxInactiveInterval(int interval) { this.maxInactiveInterval = interval; +if (isValid interval == 0) { +expire(); +} } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml
costin 2003/02/18 17:04:45 Modified:catalina/src/share/org/apache/catalina/mbeans mbeans-descriptors.xml Log: Remove processing time, it is not that usefull. Revision ChangesPath 1.75 +1 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml Index: mbeans-descriptors.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- mbeans-descriptors.xml13 Feb 2003 19:28:50 - 1.74 +++ mbeans-descriptors.xml19 Feb 2003 01:04:44 - 1.75 @@ -2376,10 +2376,6 @@ description=Number of sessions that expired ( doesn't include explicit invalidations ) type=int / -attribute name=processingTime - description=Time spent doing housekeeping and expiration - type=long / - attribute name=duplicates description=Number of duplicated session ids generated type=int / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17185] - webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive
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=17185. 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=17185 webapps with pre-2.4 descriptors may not set isELIgnored=false in page directive --- Additional Comments From [EMAIL PROTECTED] 2003-02-19 03:09 --- Regardless, it is not spec compliant behavior - see section JSP.3.3.2 and table JSP.3-1. I'm aware it's an odd situation, but I have my reasons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Kin-Man Chung wrote: It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. The bug happens in the jsp-examples precompilation (which is supposed to work also, right ?). One of the tag examples apparently causes problems. The strange thing is the error hapeened with source.jsp, which is not one of the exmaples. Do you guys know what it's for? I also don't believe jsp-examples has been successful compiled with JSPC before. I know haven't tried that with JSP2.0 examples. With automatic compiling of the tag files, I won't be surprise if there are problems. :) It doesn't matter what it's for - if it is valid JSP it should compile with jspc the same as with jspservlet :-). If it's not valid - it should be removed... One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. +1. +1 from me too. However, is Jspc good enough now? Are there areas that need to be fixed? We should not make this a requirement for tomcat5 and recommand such a practice until it is good enough. For now we should just turn off precompilation of the examples until the problem is identified and fixed. It's not a requirement for tomcat5 - people can use whatever they want. Our examples and the admin and all jsps we ship should be precompiled - it is a very bad example if the first time you load hello.jsp it takes 1 minute. If people add a jsp to the examples - it will be compiled by jspservet and will work as before. Jspc works fine - the generated code is exactly the same as with JspServlet. I used it with pretty complex apps ( with 4.1 ). The only problem that jspc may have is that a lot of the development on jasper is done using jspservlet, and far less testing is done on jspc - and if we start precompiling it'll be more likely the problems will be fixed. The difference is just in the calling environment. BTW, IMO it is also much better for the code stability - as changes are made to jasper, knowing that all admin and examples compile is a good test. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17190] New: - Classloader-problem with xerces not seeing webapp-classes
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=17190. 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=17190 Classloader-problem with xerces not seeing webapp-classes Summary: Classloader-problem with xerces not seeing webapp- classes Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is similar to bug 16221 but way more serious. We have a web-application that uses Xerces2 and gives it a class-name to instanciate for the document-class. However since tomcat uses Xerces2 now (4.0.3 with xerces1 works fine) the endorsed xerces2 is used. But this xerces2 does not see the classes of the servlet's war-file or the libraries therein that it was called from and thus does not function correctly aynmore. Due to bug 16221 we cannot use the xerces2 (that is _not_ part of j2se or the servlet-api) inside our war-file as stated in the documentation. It does work if our application-classes are copied to the endored- directory and we could not make xerces2 not globaly visible by having it in the server/lib -directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Standalone - 302 Redirect Issue
Can someone please confirm the option to switch the welcome file behavior from a redirection to a rd.forward was included in the mapper for Tomcat 5.0? I have heard both that it was and that it wasn't. I guess I have the following questions still: 1. Is this functionality going to be included in Tomcat 5? 2. Where/when can I find documentation on how to configure this new feature? 3. When will a release candidate of Tomcat5 be available? I understand there are not set dates for these sorts of things but a general ballpark idea would help me to plan. Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17193] New: - java.net.bindException during shutdown in Tomcat 4.1.18
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=17193. 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=17193 java.net.bindException during shutdown in Tomcat 4.1.18 Summary: java.net.bindException during shutdown in Tomcat 4.1.18 Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Following error was encountered while shutdown, i m giving complete log message from startup to shutdown [INFO] Registry - -Loading registry information [INFO] Registry - -Creating new Registry instance [INFO] Registry - -Creating MBeanServer [INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1.18 [INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 8080 [INFO] ChannelSocket - -JK2: ajp13 listening on 0.0.0.0/0.0.0.0:8009 [INFO] JkMain - -Jk running ID=0 time=10/100 config=d:\Tomcat 4.1.18 \conf\jk2.properties Stopping service Tomcat-Standalone java.net.BindException: Cannot assign requested address: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:350) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:137) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:124) at java.net.Socket.init(Socket.java:268) at java.net.Socket.init(Socket.java:122) at org.apache.jk.common.ChannelSocket.destroy(ChannelSocket.java:417) at org.apache.jk.server.JkMain.stop(JkMain.java:308) at org.apache.jk.server.JkCoyoteHandler.destroy (JkCoyoteHandler.java:179) at org.apache.coyote.tomcat4.CoyoteConnector.stop (CoyoteConnector.java:1081) at org.apache.catalina.core.StandardService.stop (StandardService.java:546) at org.apache.catalina.core.StandardServer.stop (StandardServer.java:2224) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run (Catalina.java:624) what i figured out by looking at the code of ChannelSocket.java was that in method init of class ChannelSocket the following code if (getAddress() == null) setAddress(0.0.0.0); is setting 'inet' variable to address 0.0.0.0, which is creating problems at the time of shutdown when method destroy is called and a new socket creation is tried which results in the above mentioned Bind Exception... if (inet == null) { s=new Socket(127.0.0.1, port ); }else{ s=new Socket(inet, port ); // setting soLinger to a small value will help shutdown the // connection quicker s.setSoLinger(true, 0); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagFileProcessor.java
billbarker2003/02/18 23:03:45 Modified:jasper2/src/share/org/apache/jasper JspCompilationContext.java jasper2/src/share/org/apache/jasper/compiler TagFileProcessor.java Log: Fix for most of the pre-compile problems with TC-5. The basic problem is that with Jspc, there is no 'RuntimeContext'. I've patched around the worst parts of it, but I'm the first to admit that I don't know Jasper down to this sort of level. Jan, Kin-Man, please review (and feel free to -1 if I've broken something). Revision ChangesPath 1.32 +5 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java Index: JspCompilationContext.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- JspCompilationContext.java12 Feb 2003 16:37:11 - 1.31 +++ JspCompilationContext.java19 Feb 2003 07:03:44 - 1.32 @@ -201,6 +201,8 @@ public ClassLoader getClassLoader() { if( loader != null ) return loader; + if( rctxt == null) + return getClass().getClassLoader(); return rctxt.getParentClassLoader(); } 1.40 +62 -49 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java Index: TagFileProcessor.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- TagFileProcessor.java 5 Feb 2003 23:35:21 - 1.39 +++ TagFileProcessor.java 19 Feb 2003 07:03:45 - 1.40 @@ -412,60 +412,73 @@ JspCompilationContext ctxt = compiler.getCompilationContext(); JspRuntimeContext rctxt = ctxt.getRuntimeContext(); -JspServletWrapper wrapper = + JspServletWrapper wrapper = null; + if( rctxt != null ) { + wrapper = (JspServletWrapper) rctxt.getWrapper(tagFilePath); - synchronized(rctxt) { - if (wrapper == null) { - wrapper = new JspServletWrapper(ctxt.getServletContext(), - ctxt.getOptions(), - tagFilePath, - tagInfo, - ctxt.getRuntimeContext(), - (JarFile) ctxt.getTagFileJars().get(tagFilePath)); - rctxt.addWrapper(tagFilePath,wrapper); + synchronized(rctxt) { + if (wrapper == null) { + wrapper = new JspServletWrapper(ctxt.getServletContext(), + ctxt.getOptions(), + tagFilePath, + tagInfo, + ctxt.getRuntimeContext(), + (JarFile) ctxt.getTagFileJars().get(tagFilePath)); + rctxt.addWrapper(tagFilePath,wrapper); + } } + } else { + wrapper = new JspServletWrapper(ctxt.getServletContext(), + ctxt.getOptions(), + tagFilePath, + tagInfo, + ctxt.getRuntimeContext(), + (JarFile)ctxt.getTagFileJars().get(tagFilePath) + ); + } + - Class tagClazz; - int tripCount = wrapper.incTripCount(); - try { - if (tripCount 0) { - // When tripCount is greater than zero, a circular - // dependency exists. The circularily dependant tag - // file is compiled in prototype mode, to avoid infinite - // recursion. + Class tagClazz; + int tripCount = wrapper.incTripCount(); + try { + if (tripCount 0) { + // When tripCount is greater than zero, a circular + // dependency exists. The circularily dependant tag + // file is compiled in prototype mode, to avoid infinite + // recursion. - JspServletWrapper tempWrapper - = new JspServletWrapper(ctxt.getServletContext(), -
Re: Tomcat Standalone - 302 Redirect Issue
- Original Message - From: neal [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, February 18, 2003 10:36 PM Subject: Tomcat Standalone - 302 Redirect Issue Can someone please confirm the option to switch the welcome file behavior from a redirection to a rd.forward was included in the mapper for Tomcat 5.0? I have heard both that it was and that it wasn't. I guess I have the following questions still: 1. Is this functionality going to be included in Tomcat 5? As of last (long) weekend, it is included in Tomcat 5. But before people get confused, it isn't a true rd.forward. It works more like an Apache/httpd rewrite. 2. Where/when can I find documentation on how to configure this new feature? When is still an open question (patches are always welcome :). The configuration option is 'processWelcomeResources' on the Connector element ('true' means forward, 'false' is the old TC 4.x behavior: The current default is 'true'). 3. When will a release candidate of Tomcat5 be available? I understand there are not set dates for these sorts of things but a general ballpark idea would help me to plan. My limited understanding of this is that, as a JCP member, Apache can't have a 'release' version before the Servlet-2.4 JSP-2.0 Specs go final (but IANAL). This means that anyone that actually knows the answer is under an NDA, so they can't tell you. Thanks. Neal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagFileProcessor.java
billbarker2003/02/18 23:39:49 Modified:jasper2/src/share/org/apache/jasper JspCompilationContext.java jasper2/src/share/org/apache/jasper/compiler TagFileProcessor.java Log: Avoid the Tab-Police. (no functional changes) Revision ChangesPath 1.33 +105 -105 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java Index: JspCompilationContext.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- JspCompilationContext.java19 Feb 2003 07:03:44 - 1.32 +++ JspCompilationContext.java19 Feb 2003 07:39:49 - 1.33 @@ -127,10 +127,10 @@ // jspURI _must_ be relative to the context public JspCompilationContext(String jspUri, - boolean isErrPage, - Options options, + boolean isErrPage, + Options options, ServletContext context, - JspServletWrapper jsw, + JspServletWrapper jsw, JspRuntimeContext rctxt) { this.jspUri = canonicalURI(jspUri); @@ -153,25 +153,25 @@ } this.rctxt = rctxt; - this.tagFileJars = new Hashtable(); +this.tagFileJars = new Hashtable(); this.servletPackageName = Constants.JSP_PACKAGE_NAME; - this.outUrls = new URL[2]; +this.outUrls = new URL[2]; } public JspCompilationContext(String tagfile, - TagInfo tagInfo, + TagInfo tagInfo, Options options, ServletContext context, - JspServletWrapper jsw, + JspServletWrapper jsw, JspRuntimeContext rctxt, - JarFile tagFileJar) { + JarFile tagFileJar) { this(tagfile, false, options, context, jsw, rctxt); this.isTagFile = true; this.tagInfo = tagInfo; - this.tagFileJar = tagFileJar; - if (tagFileJar != null) { - isPackagedTagFile = true; - } +this.tagFileJar = tagFileJar; +if (tagFileJar != null) { +isPackagedTagFile = true; +} } /* Methods to override */ @@ -201,13 +201,13 @@ public ClassLoader getClassLoader() { if( loader != null ) return loader; - if( rctxt == null) - return getClass().getClassLoader(); +if( rctxt == null) +return getClass().getClassLoader(); return rctxt.getParentClassLoader(); } public void setClassLoader(URLClassLoader loader) { - this.loader = loader; +this.loader = loader; } /** -- Input/Output -- */ @@ -237,7 +237,7 @@ } public Compiler getCompiler() { - return jspCompiler; +return jspCompiler; } /** -- Access resources in the webapp -- */ @@ -295,7 +295,7 @@ * of any imported taglibs. */ public Hashtable getTagFileJars() { - return this.tagFileJars; +return this.tagFileJars; } /** @@ -305,7 +305,7 @@ * corresponding tag file is not packaged in a JAR. */ public JarFile getTagFileJar() { - return this.tagFileJar; +return this.tagFileJar; } /* Common implementation */ @@ -320,35 +320,35 @@ return className; } - if (isTagFile) { - className = tagInfo.getTagClassName(); - int lastIndex = className.lastIndexOf('.'); - if (lastIndex != -1) { - className = className.substring(lastIndex + 1); - } - } else { - int iSep = jspUri.lastIndexOf('/') + 1; - int iEnd = jspUri.length(); - StringBuffer modifiedClassName = - new StringBuffer(jspUri.length() - iSep); - if (!Character.isJavaIdentifierStart(jspUri.charAt(iSep)) || - jspUri.charAt(iSep) == '_' ) { - // If the first char is not a start of Java identifier or is _ - // prepend a '_'. - modifiedClassName.append('_'); - } - for (int i = iSep; i iEnd; i++) { - char
cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2003/02/18 23:59:20 Modified:.tomcat.nsi Log: - Further tweaks. Revision ChangesPath 1.25 +7 -7 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- tomcat.nsi17 Feb 2003 13:05:11 - 1.24 +++ tomcat.nsi19 Feb 2003 07:59:19 - 1.25 @@ -72,7 +72,7 @@ ;Descriptions LangString DESC_SecTomcat ${LANG_ENGLISH} Install the Tomcat Servlet container. LangString DESC_SecTomcatCore ${LANG_ENGLISH} Install the Tomcat Servlet container core. -LangString DESC_SecTomcatService ${LANG_ENGLISH} Install the Tomcat service, used to automatically start Tomcat in the background when the computer is started. This requires Windows NT 4.0, Windows 2000 or Windows XP. +LangString DESC_SecTomcatService ${LANG_ENGLISH} Automatically start Tomcat when the computer is started. This requires Windows NT 4.0, Windows 2000 or Windows XP. LangString DESC_SecTomcatSource ${LANG_ENGLISH} Install the Tomcat source code. LangString DESC_SecTomcatDocs ${LANG_ENGLISH} Install the Tomcat documentation bundle. This include documentation on the servlet container and its configuration options, on the Jasper JSP page compiler, as well as on the native webserver connectors. LangString DESC_SecMenu ${LANG_ENGLISH} Create a Start Menu program group for Tomcat. @@ -202,14 +202,14 @@ CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Tomcat 5.0 Program Directory.lnk \ $INSTDIR - CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat (old).lnk \ - $2\bin\java.exe \ - '-Duser.dir=$INSTDIR\bin LauncherBootstrap -launchfile catalina.xml catalina start' \ - $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL - CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat.lnk \ $INSTDIR\bin\tomcatw.exe \ '//GT//Tomcat5' \ + $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL + + CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat (old).lnk \ + $2\bin\java.exe \ + '-Duser.dir=$INSTDIR\bin LauncherBootstrap -launchfile catalina.xml catalina start' \ $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL SectionEnd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]