Re: A!p$ghsa
Please r564g!he4a56a3haafdogu#mfn3o SMTP Error #201 Norton AntiVirus eliminato1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.21 ?
Remy Maucherat wrote: I did post a message on the PMC list asking for a final word on our binary dependencies (installer + JMX). I'm also wondering if it whould be a good idea to pick up the latest Jasper fixes in a 5.0.21 tag. I got approval from Geir (the PMC chair) to ship with MX4J and the installer. So there will be a new 5.0.21 tag today, with new binaries :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
From: Remy Maucherat I got approval from Geir (the PMC chair) to ship with MX4J and the installer. So there will be a new 5.0.21 tag today, with new binaries :) That's really good news. Hope it'll last for a while :) MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2004/03/30 03:21:53
Modified:.build.xml
Log:
- Include jmx.jar again.
Revision ChangesPath
1.181 +1 -3 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.180
retrieving revision 1.181
diff -u -r1.180 -r1.181
--- build.xml 12 Mar 2004 14:35:45 - 1.180
+++ build.xml 30 Mar 2004 11:21:53 - 1.181
@@ -1130,9 +1130,7 @@
!-- Copy the contents of each build directory --
copy todir=${tomcat.dist}/bin
- fileset dir=${tomcat.build}/bin
-exclude name=jmx.jar /
- /fileset
+ fileset dir=${tomcat.build}/bin /
/copy
copy todir=${tomcat.dist}/common/classes
fileset dir=${tomcat.build}/common/classes /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.21 ?
Mladen Turk wrote: From: Remy Maucherat I got approval from Geir (the PMC chair) to ship with MX4J and the installer. So there will be a new 5.0.21 tag today, with new binaries :) That's really good news. Hope it'll last for a while :) BTW, are there any new procrun binaries for this build ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5/resources welcome.bin.html welcome.main.html
remm2004/03/30 03:23:21
Modified:.RELEASE-NOTES
resources welcome.bin.html welcome.main.html
Log:
- Include jmx.jar again.
Revision ChangesPath
1.14 +1 -16 jakarta-tomcat-5/RELEASE-NOTES
Index: RELEASE-NOTES
===
RCS file: /home/cvs/jakarta-tomcat-5/RELEASE-NOTES,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- RELEASE-NOTES 22 Mar 2004 18:51:50 - 1.13
+++ RELEASE-NOTES 30 Mar 2004 11:23:21 - 1.14
@@ -11,7 +11,6 @@
KNOWN ISSUES IN THIS RELEASE:
-* JMX required
* Tomcat 5.0 and JNI Based Applications
* Tomcat 5.0 Standard APIs Available
* Tomcat 5.0 and XML Parsers
@@ -23,20 +22,6 @@
* Symlinking static resources
* Enabling invoker servlet
* When all else fails
-
-
-
-JMX required
-
-
-Due to new licensing guidelines mandated by the Apache Software
-Foundation Board of Directors, a JMX implementation can no longer
-be distributed with the Apache Tomcat binaries. As a result, you
-must download a JMX 1.2 implementation (such as the Sun Reference
-Implementation) and copy the JAR containing the API and
-implementation of the JMX specification to: ${catalina.home}/bin/jmx.jar
-
-For similar reasons, a Windows installer for Tomcat is no longer available.
-
1.3 +0 -8 jakarta-tomcat-5/resources/welcome.bin.html
Index: welcome.bin.html
===
RCS file: /home/cvs/jakarta-tomcat-5/resources/welcome.bin.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- welcome.bin.html 22 Mar 2004 18:53:19 - 1.2
+++ welcome.bin.html 30 Mar 2004 11:23:21 - 1.3
@@ -15,12 +15,4 @@
and must be untarred with a GNU compatible version of tar. The version
of CODEtar/CODE on Solaris and Mac OS X will not work with
these files./b/P
-pbNOTE: Due to new licensing guidelines mandated by the Apache Software
-Foundation Board of Directors, a JMX implementation can no longer
-be distributed with the Apache Tomcat binaries. As a result, you
-must download a JMX 1.2 implementation (such as the Sun Reference
-Implementation) and copy the JAR containing the API and
-implementation of the JMX specification to: ${catalina.home}/bin/jmx.jarbr
-For similar reasons, a Windows installer for Tomcat is no longer available.
-/b/P
P/P/BODY/HTML
1.4 +0 -8 jakarta-tomcat-5/resources/welcome.main.html
Index: welcome.main.html
===
RCS file: /home/cvs/jakarta-tomcat-5/resources/welcome.main.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- welcome.main.html 22 Mar 2004 18:53:19 - 1.3
+++ welcome.main.html 30 Mar 2004 11:23:21 - 1.4
@@ -18,14 +18,6 @@
and must be untarred with a GNU compatible version of tar. The version
of CODEtar/CODE on Solaris and Mac OS X will not work with
these files./b/P
-pbNOTE: Due to new licensing guidelines mandated by the Apache Software
-Foundation Board of Directors, a JMX implementation can no longer
-be distributed with the Apache Tomcat binaries. As a result, you
-must download a JMX 1.2 implementation (such as the Sun Reference
-Implementation) and copy the JAR containing the API and
-implementation of the JMX specification to: ${catalina.home}/bin/jmx.jarbr
-For similar reasons, a Windows installer for Tomcat is no longer available.
-/b/P
PThank you for using A href=http://jakarta.apache.org/tomcat;Tomcat/A!.
/P
PBThe Apache Jakarta Project/B BRA
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Lisa Hanly/STL/Brown Group is out of the office.
I will be out of the office starting 03/10/2004 and will not return until 06/02/2004. I am on maternity leave. You may email Margaret Smith, Marketing Manager of Dr. Scholl's Footwear at [EMAIL PROTECTED] in my absence. * [This message and its contents have been scanned for viruses] * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j classpath merging?
Hello Matthew, We have just added new code to log4j in order to provide a complete solution to the problem you are describing. It has several advantages over ContextClassLoaderSelector you mentioned. For more details, see http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ and http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/selector/ More comments below. I'm using log4j to log application code for several websites, each of which has at least one WebApp, and some of which have more than one. I'm configuring log4j with an initialization servlet (that also does a few other things) from a properties file using .configureAndWatch(java.io.File). I'd like to allow each webapp to have its own log4j configuration. The typical configuration I am using logs to the console with the site name and webapp name prepended, logs a similar format to a RollingFileAppender with the file name determined by the site name, and a SMTPAppender for error notification. All of these are working fine, with one small exception... the configuration of the last properties file loaded is used for all debug output. For example, I am expecting to see: [www.domainname.com] log message [www.someothername.com] some other log message [www.athirddomain.com] yet another log message Instead, I'm seeing: [www.domainname.com] log message [www.domainname.com] some other log message [www.domainname.com] yet another log message I am using a large amount of common code across these webapps, so I can't just separate configurations by class name. Presently, I'm putting the log4j.jar file in the WEB-INF/lib for each webapp, and the properties file is in WEB-INF/properties (eg, not one of the standard log4j locations). I'm using log4j-1.2.8; I've seen this problem on both Tomcat 4.1.24 and 5.0.19. I found that when I put the log4j.properties file in WEB-INF/classes/log4j.properties it didn't seem to be found at all, which is why I moved to this method. I suspect that if the log4j code had already initialized itself from somewhere (perhaps for tomcat internal use?) it wouldn't need to look in specific webapp classpaths and thus wouldn't pick up the configuration. A bit of googling ran across the class below, which fixes the problem, except that you have to initialize log4j with that class, and you can only do so once; subsequent initializations (eg, with the same initializer servlet in multiple webapps) either throw ugly errors or could be easily overwritten by any webapp that disagreed with the idea and wanted to do something else. http://cvs.apache.org/viewcvs.cgi/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/ContextClassLoaderSelector.java?rev=1.7view=markup Since I had already written a Valve for something else and had sample code handy, I wrote a Valve to initialize log4j with a similar policy. This works and has solved my problem, but leaves me with three questions: 1) Is this the way it's supposed to work? (If so, someone should fix the log4j documentation). What part of log4j documentation should be fixed? It is not clear to me what you mean by is the way it's supposed to work?. However, the fact that class loading issues are problematic has been known for quite a while. 2) If it's supposed to work this way, then it seems to me that setting the log4j policy to use separate heirarchies by classpath should be the default policy. I can't think of any reason why one webapp's logging configuration should be able to alter any other webapp's logging. Am I wrong? Having separate hierarchies for each web-app is certainly a reasonable policy. However, we are still testing the various implementation of this policy and cannot make it default before through testing. 3) If I'm right about 2, is there a better way to do it than a valve? Using a valve means I can drop the addition into an existing configuration, but it seems exceedingly awkward to run all requests through an extra layer just to get a class loaded and initialized once-and-only-once with no webapp dependencies. Is there a better construct for this sort of thing? What does the valve do? I'd be interested to study in the code. 4) If there's interest I'd gladly contribute the valve to the apache codebase so others can just modify their server.xml rather than writing code; is there any interest in doing that? Please do. We should perhaps continue this discussion in [EMAIL PROTECTED] -- Matthew Hunter ([EMAIL PROTECTED]) Public Key: http://matthew.infodancer.org/public_key.txt Homepage: http://matthew.infodancer.org/index.jsp Politics: http://www.triggerfinger.org/index.jsp -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Jess Holle wrote: mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x releases had with mod_dir. Specifically something like: Alias /MyWebApp D:\my_app_view\Myapp/codebase Directory D:\my_app_view\Myapp/codebase Options Indexes FollowSymLinks /Directory Directory D:\my_app_view\Myapp/codebase/WEB-INF AllowOverride None deny from all /Directory IfModule mod_jk2.c Location /MyWebApp/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location /IfModule Does not successfully map /MyWebApp/servlet/* to MyWebApp's servlets. Rather I get 404's. Once I comment out the Alias and Directory lines, the JkUriSet directive works as expected (but the overall app does not work properly, of course). This worked fine with mod_jk2 2.0.2. This sort of configuration is *very* helpful in that it allows configuration of additional web apps by Including one conf file per web app and containing everything necessary for that web app for both mod_jk and mod_jk2 -- thus allowing the LoadModule line to determine everything and keeping web app configurations nicely separated. A fix (patch now, 2.0.5 later?) for this would be greatly appreciated as there are important fixes and enhancements in mod_jk2 2.0.4. Without this working, however, 2.0.4 is a non-starter for me. -- Jess Holle P.S. I can certainly give more details, file a bugzilla bug, etc, as necessary. I just got back from vacation, tried out mod_jk2 2.0.4 and wanted to get the ball rolling on this issue before I trudged through my e-mail backlog. Is it with Apache-2.0 or Apache-1.3? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/tester/src/bin tester.xml
remm2004/03/30 04:34:42
Modified:tester/src/bin tester.xml
Log:
- Fix two tests after Jasper changes.
Revision ChangesPath
1.10 +2 -2 jakarta-tomcat-catalina/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/tester/src/bin/tester.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- tester.xml19 Aug 2003 19:07:43 - 1.9
+++ tester.xml30 Mar 2004 12:34:42 - 1.10
@@ -320,13 +320,13 @@
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/ErrorPage09
debug=${debug}
- status=200
+ status=500
outContent=ErrorPage10 PASSED/
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/WrappedErrorPage09
debug=${debug}
- status=200
+ status=500
outContent=ErrorPage10 PASSED/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
-Original Message- From: Remy Maucherat So there will be a new 5.0.21 tag today, with new binaries :) That's really good news. Hope it'll last for a while :) BTW, are there any new procrun binaries for this build ? Bill did some bug fixes and updates, but I'm afraid he didn't done any jtc/procrun binary builds. I can do that but only later this evening. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.21 ?
Mladen Turk wrote: Bill did some bug fixes and updates, but I'm afraid he didn't done any jtc/procrun binary builds. I can do that but only later this evening. I can wait until later today for new binaries, no problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.21 ?
hurray!!! that is good to hear. peter Remy Maucherat [EMAIL PROTECTED] wrote: Remy Maucherat wrote: I did post a message on the PMC list asking for a final word on our binary dependencies (installer + JMX). I'm also wondering if it whould be a good idea to pick up the latest Jasper fixes in a 5.0.21 tag. I got approval from Geir (the PMC chair) to ship with MX4J and the installer. So there will be a new 5.0.21 tag today, with new binaries :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
jk2: dependencies between logger.file and workerEnv
I've just produce a non-Windows version of the DSAPI (Lotus Domino)
connector and I had a bit of a struggle getting the initialisation code
right because of co-dependencies between workerEnv and logger.file. It
seems that logger.file needs workerEnv to exist for it to initialise
itself but the workerEnv initialisation code expects a logger to exist.
I've ended up with workerEnv initialisation logging to an uninitialised
file logger which results in log output being sent to stdout. Not
terribly satisfactory but it allows the connector to load.
jk_logger_file.c can easily be doctored to remove the dependency on
workerEnv but it would then lose the ability to expand named properties
in the passed in filename (like: ${serverRoot}/logs/jk2.log).
Any thoughts on the nicest way to fix it? I don't mind implementing a
fix but I don't want to make unpalatable changes to the common jk2 code.
--
Andy Armstrong, Tagish
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lisa Hanly/STL/Brown Group is out of the office.
Hi, I'll unsubscribe and send a congratulations message! ;) Yoav Shapira Millennium Research Informatics -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 6:40 AM To: Tomcat Developers List Subject: Lisa Hanly/STL/Brown Group is out of the office. I will be out of the office starting 03/10/2004 and will not return until 06/02/2004. I am on maternity leave. You may email Margaret Smith, Marketing Manager of Dr. Scholl's Footwear at [EMAIL PROTECTED] in my absence. * [This message and its contents have been scanned for viruses] * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
Hi, Note that we must properly reference MX4J and NSIS in our NOTICE file for this release. I see the file (in jakarta-tomcat-catalina/NOTICE) hasn't changed since I created it a month ago. If no one beats me to it, I'll make the changes later today. Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 5:38 AM To: Tomcat Developers List Subject: Re: 5.0.21 ? Remy Maucherat wrote: I did post a message on the PMC list asking for a final word on our binary dependencies (installer + JMX). I'm also wondering if it whould be a good idea to pick up the latest Jasper fixes in a 5.0.21 tag. I got approval from Geir (the PMC chair) to ship with MX4J and the installer. So there will be a new 5.0.21 tag today, with new binaries :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lisa Hanly/STL/Brown Group is out of the office.
Shapira, Yoav wrote: Hi, I'll unsubscribe and send a congratulations message! ;) Since I now also wield the Supreme Power (TM), I already unsubscribed her :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
Hi, Ok. Yes, I heard about that. I think it should be in jakarta-tomcat-5 instead, BTW. The CVS module doesn't matter as much as the fact NOTICE (and LICENSE) need to end up in the top-level directory of our distribution when it's unpacked. From where does the build dist take the LICENSE/NOTICE files? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Kin-Man Chung wrote:
I think your only valid point is the one about the need to make
errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
but we are not bundling jspc scripts anymore, so I didn't feel there
is a need for it. Anyway, its value can be set with an ant task.
Otherwise, Jasper behaves the same as before when
errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it
take more time to compile, but that's a compile-time vs. runt-time
tradeoff that all compilers make.
The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time. For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem. For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.
I'm not arguing with the overall intent of your change. Rather I
believe that calling the constructor during compilation is wasteful and
improper as the environment *can* differ between compilation and
runtime. Also, the fact that a failure to compile in this fashion
generates a partial Java source means that once a compilation fails due
to an environmental issue it will continue to fail even when the
environment is corrected (e.g. when another server comes back up).
That's certainly not appropriate.
If you have ideas about how to modify Generator that works better, please
submit a patch, and I'll see if it can be incorporated.
I must profess ignorance as to how to submit an official patch (e.g. how
to generate one), but here's a diff with Generator.java version 1.230
from CVS of what I'm suggesting:
22a23
*import java.lang.reflect.Constructor;*
1224c1225,1226
bean.newInstance();
---
// Next line will throw exception if
public no-args constructor cannot be found
*Constructor constructor =
bean.getConstructor( new Class[] {} );
*
Essentially, I'm suggesting we check for the existence of the default
constructor, but don't call it. That takes the same amount of real code
(2 more lines thanks to my import and gratuitous comment) and avoids (1)
actually constructing the bean during compilation and (2) making any
unnecessary assumptions about compilation vs. runtime environmental
conditions.
Applying this diff to Generator.java addresses my issue and I believe is
an overall improvement and better aligned with the JSP specification. I
would greatly appreciate it if this could be incorporated into the
Jasper/Tomcat source stream.
--
Jess Holle
[EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Sorry, I should have said mod_alias, not mod_dir... -- Jess Holle Jess Holle wrote: mod_jk2 2.0.4 seems to have the same issues that several mod_jk 1.2.x releases had with mod_dir. Specifically something like: Alias /MyWebApp D:\my_app_view\Myapp/codebase Directory D:\my_app_view\Myapp/codebase Options Indexes FollowSymLinks /Directory Directory D:\my_app_view\Myapp/codebase/WEB-INF AllowOverride None deny from all /Directory IfModule mod_jk2.c Location /MyWebApp/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location /IfModule Does not successfully map /MyWebApp/servlet/* to MyWebApp's servlets. Rather I get 404's. Once I comment out the Alias and Directory lines, the JkUriSet directive works as expected (but the overall app does not work properly, of course). This worked fine with mod_jk2 2.0.2. This sort of configuration is *very* helpful in that it allows configuration of additional web apps by Including one conf file per web app and containing everything necessary for that web app for both mod_jk and mod_jk2 -- thus allowing the LoadModule line to determine everything and keeping web app configurations nicely separated. A fix (patch now, 2.0.5 later?) for this would be greatly appreciated as there are important fixes and enhancements in mod_jk2 2.0.4. Without this working, however, 2.0.4 is a non-starter for me. -- Jess Holle P.S. I can certainly give more details, file a bugzilla bug, etc, as necessary. I just got back from vacation, tried out mod_jk2 2.0.4 and wanted to get the ball rolling on this issue before I trudged through my e-mail backlog.
Re: Tomcat 5.0.20 Issue
Jess Holle wrote: I'm not arguing with the overall intent of your change. Rather I believe that calling the constructor during compilation is wasteful and improper as the environment *can* differ between compilation and runtime. Also, the fact that a failure to compile in this fashion generates a partial Java source means that once a compilation fails due to an environmental issue it will continue to fail even when the environment is corrected (e.g. when another server comes back up). That's certainly not appropriate. At the heart of the problem is that you do not seem to know what a JavaBean is. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 NOTICE build.xml LICENSE
remm2004/03/30 06:48:55
Modified:.build.xml LICENSE
Added: .NOTICE
Log:
- Add NOTICE file is dists.
Revision ChangesPath
1.182 +14 -4 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.181
retrieving revision 1.182
diff -u -r1.181 -r1.182
--- build.xml 30 Mar 2004 11:21:53 - 1.181
+++ build.xml 30 Mar 2004 14:48:54 - 1.182
@@ -1120,8 +1120,9 @@
!-- Copy the top-level documentation files --
copy todir=${tomcat.dist}
fileset dir=.
-include name=LICENSE/
include name=INSTALLING.txt/
+include name=LICENSE/
+include name=NOTICE/
include name=README.txt/
include name=RELEASE*/
include name=RUNNING.txt/
@@ -1344,6 +1345,8 @@
zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=LICENSE /
zipfileset dir=${tomcat.dist} prefix=${final.name}
+ includes=NOTICE /
+ zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=README.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}
includes=RELEASE-NOTES /
@@ -1361,6 +1364,8 @@
zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
includes=LICENSE /
zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
+ includes=NOTICE /
+ zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
includes=README.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}-embed
includes=RELEASE-NOTES /
@@ -1374,6 +1379,8 @@
zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
includes=LICENSE /
zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
+ includes=NOTICE /
+ zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
includes=README.txt /
zipfileset dir=${tomcat.dist} prefix=${final.name}-deployer
includes=RELEASE-NOTES /
@@ -1399,7 +1406,7 @@
target name=package-tgz
fixcrlf srcdir=${tomcat.dist}
- includes=*.txt,LICENSE eol=lf/
+ includes=*.txt,LICENSE,NOTICE eol=lf/
fixcrlf srcdir=${tomcat.dist}/conf eol=lf/
tar longfile=gnu compression=gzip
tarfile=${tomcat.release}/v${version}/bin/${final.name}.tar.gz
@@ -1429,6 +1436,7 @@
include name=webapps/** /
include name=work/** /
include name=LICENSE /
+include name=NOTICE /
include name=README.txt /
include name=RELEASE-NOTES /
include name=RUNNING.txt /
@@ -1452,12 +1460,13 @@
target name=package-embed-tgz
fixcrlf srcdir=${tomcat.dist}
- includes=*.txt,LICENSE eol=lf/
+ includes=*.txt,LICENSE,NOTICE eol=lf/
fixcrlf srcdir=${tomcat.embed} includes=*.xml eol=lf/
tar longfile=gnu compression=gzip
tarfile=${tomcat.release}/v${version}/bin/${final.name}-embed.tar.gz
tarfileset dir=${tomcat.dist} prefix=${final.name}-embed
include name=LICENSE /
+include name=NOTICE /
include name=README.txt /
include name=RELEASE-NOTES /
/tarfileset
@@ -1469,12 +1478,13 @@
target name=package-deployer-tgz
fixcrlf srcdir=${tomcat.dist}
- includes=*.txt,LICENSE eol=lf/
+ includes=*.txt,LICENSE,NOTICE eol=lf/
fixcrlf srcdir=${tomcat.deployer} includes=*.xml eol=lf/
tar longfile=gnu compression=gzip
tarfile=${tomcat.release}/v${version}/bin/${final.name}-deployer.tar.gz
tarfileset dir=${tomcat.dist} prefix=${final.name}-deployer
include name=LICENSE /
+include name=NOTICE /
include name=README.txt /
include name=RELEASE-NOTES /
/tarfileset
1.3 +201 -61 jakarta-tomcat-5/LICENSE
Index: LICENSE
===
RCS file: /home/cvs/jakarta-tomcat-5/LICENSE,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LICENSE 24 Dec 2003 19:53:47 - 1.2
+++ LICENSE 30 Mar 2004 14:48:54 - 1.3
@@ -1,61 +1,201 @@
-/* = *
- * *
- * The Apache Software License, Version 1.1 *
- * *
- * Copyright (c) 1999, 2000 The Apache Software Foundation. *
- * All rights reserved.*
- * *
- *
Re: 5.0.21 ?
Shapira, Yoav wrote: Ok. Yes, I heard about that. I think it should be in jakarta-tomcat-5 instead, BTW. The CVS module doesn't matter as much as the fact NOTICE (and LICENSE) need to end up in the top-level directory of our distribution when it's unpacked. From where does the build dist take the LICENSE/NOTICE files? It's jakarta-tomcat-5. So what kind of statements go in NOTICE ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5/resources INSTALLLICENSE
remm2004/03/30 06:51:03 Modified:resources INSTALLLICENSE Log: - New license. Revision ChangesPath 1.5 +201 -60 jakarta-tomcat-5/resources/INSTALLLICENSE Index: INSTALLLICENSE === RCS file: /home/cvs/jakarta-tomcat-5/resources/INSTALLLICENSE,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- INSTALLLICENSE24 Dec 2003 19:53:47 - 1.4 +++ INSTALLLICENSE30 Mar 2004 14:51:03 - 1.5 @@ -1,60 +1,201 @@ - - - The Apache Software License, Version 1.1 - - Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. - All rights reserved. - - - -Redistribution and use in source and binary forms, with or without modi- -fication, are permitted provided that the following conditions are met: - -1. Redistributions of source code must retain the above copyright notice, - this list of conditions and the following disclaimer. - -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - -3. The end-user documentation included with the redistribution, if any, - must include the following acknowlegement: - - This product includes software developed by the Apache Software - Foundation http://www.apache.org/. - - Alternately, this acknowlegement may appear in the software itself, if - and wherever such third-party acknowlegements normally appear. - -4. The names The Jakarta Project, Tomcat, and Apache Software - Foundation must not be used to endorse or promote products derived - from this software without prior written permission. For written - permission, please contact [EMAIL PROTECTED]. - -5. Products derived from this software may not be called Apache nor may - Apache appear in their names without prior written permission of the - Apache Software Foundation. - -THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED -OR IMPLIED WARRANTIES INCLUDING, BUT NOT LIMITED TO, -THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS -FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT -SHALL THE APACHE SOFTWARE FOUNDATION OR ITS -CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, -INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT -OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, -OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND -ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, -STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR -OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS -SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY -OF SUCH DAMAGE. - - - -This software consists of voluntary contributions made by many indivi- -duals on behalf of the Apache Software Foundation. For more information -on the Apache Software Foundation, please see http://www.apache.org/. - - + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE,
Re: Bug: jk2 2.0.4 vs. mod_dir
Jess Holle wrote: Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. Settings and test case of course more than welcome :=} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
Hi, It's jakarta-tomcat-5. OK, will put there. So what kind of statements go in NOTICE ? Short, for example: Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. The original software is available from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/; So for us it might be Java Management Extensions (JMX) support is provided by the MX4J package, which is open source software. The original software as well as the list of developers is available at http://mx4j.sourceforge.net.; That's it for MX4J. A similar thing for NSIS. So two more paragraphs in our NOTICE file and we're all set license-wise. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
I certainly know what a JavaBean is, Remy. First, *any* constructor can fail and throw an exception due to any number of factors -- including a JavaBean constructor. Second, I did not write the beans in question. I'm simply seeking to maintain reasonable resiliency in their handling. My proposed change does that and is in better keeping with the intent of the spec than testing if the bean constructor actually succeeds at a given time. Finally, though I strongly feel this patch is an overall improvement (and have received off-list mail to that effect), I will patch my own Tomcat as necessary if the Tomcat group is not flexible in this matter. -- Jess Holle Remy Maucherat wrote: Jess Holle wrote: I'm not arguing with the overall intent of your change. Rather I believe that calling the constructor during compilation is wasteful and improper as the environment *can* differ between compilation and runtime. Also, the fact that a failure to compile in this fashion generates a partial Java source means that once a compilation fails due to an environmental issue it will continue to fail even when the environment is corrected (e.g. when another server comes back up). That's certainly not appropriate. At the heart of the problem is that you do not seem to know what a JavaBean is. Rémy - 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-5 NOTICE
yoavs 2004/03/30 07:20:06 Modified:.NOTICE Log: Added info about MX4J and NSIS to NOTICE file. Revision ChangesPath 1.2 +11 -0 jakarta-tomcat-5/NOTICE Index: NOTICE === RCS file: /home/cvs/jakarta-tomcat-5/NOTICE,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- NOTICE30 Mar 2004 14:48:54 - 1.1 +++ NOTICE30 Mar 2004 15:20:06 - 1.2 @@ -1,2 +1,13 @@ This product includes software developed by The Apache Software Foundation (http://www.apache.org/). + +Java Management Extensions (JMX) support is provided by +the MX4J package, which is open source software. The +original software and related information is available +at http://mx4j.sourceforge.net. + +The Windows Installer is built with the Nullsoft +Scriptable Install Sysem (NSIS), which is +open source software. The original software and +related information is available at +http://nsis.sourceforge.net. \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.21 ?
Hi, I've made and committed the changes to jakarta-tomcat-5/NOTICE, so we're all set for the release as far as the license requirements are concerned. Yoav Shapira Millennium Research Informatics -Original Message- From: Shapira, Yoav Sent: Tuesday, March 30, 2004 9:56 AM To: Tomcat Developers List Subject: RE: 5.0.21 ? Hi, It's jakarta-tomcat-5. OK, will put there. So what kind of statements go in NOTICE ? Short, for example: Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. The original software is available from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/; So for us it might be Java Management Extensions (JMX) support is provided by the MX4J package, which is open source software. The original software as well as the list of developers is available at http://mx4j.sourceforge.net.; That's it for MX4J. A similar thing for NSIS. So two more paragraphs in our NOTICE file and we're all set license-wise. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
Henri Gomez wrote: Jess Holle wrote: Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. - 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: Bug: jk2 2.0.4 vs. mod_alias
jean-frederic clere wrote: Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. I have also managed to reproduce this more succinctly than previously in almost the same fashion with: Alias /servlets-examples D:\Tomcats\Tomcat5020\webapps\servlets-examples Location /servlets-examples/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location The Tomcat servlet examples are not accessible with these settings. They are, however, (apart from static content like images, etc) once you remove the Alias line. This example is clearly contrived as it is simplified down to the bare essentials. There are larger reasons for me needing to take this sort of approach... -- Jess Holle P.S. I see warnings that worker is deprecated and that I should use group in the logs. Is this just a change in terminology? Where does it all apply?
Re: Bug: jk2 2.0.4 vs. mod_alias
Jess Holle wrote: jean-frederic clere wrote: Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. I have also managed to reproduce this more succinctly than previously in almost the same fashion with: Alias /servlets-examples D:\Tomcats\Tomcat5020\webapps\servlets-examples Location /servlets-examples/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location The Tomcat servlet examples are not accessible with these settings. They are, however, (apart from static content like images, etc) once you remove the Alias line. P.S. Let me know if I should file a Bugzilla bug for this -- Jess Holle
Re: Bug: jk2 2.0.4 vs. mod_dir
jean-frederic clere wrote: Henri Gomez wrote: Jess Holle wrote: Henri Gomez wrote: Jess Holle wrote: Sorry, I should have said mod_alias, not mod_dir... With Apache 1.3 or 2.0 ? 2.0.49 on Windows. I have not tried Solaris or AIX yet. [I have not bothered with mod_jk2 with Apache 1.3 -- I just use mod_jk there on an old with old sort of principle.] I can produce a more definitive test case as needed. I poked around in the sources -- diffing them with 2.0.2 sources, etc, but I couldn't quickly find the issue. Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. And using a VirtualHost works around the problem... (That is why I have not dectected it before). - 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]
Re: Bug: jk2 2.0.4 vs. mod_alias
Jess Holle wrote: Jess Holle wrote: jean-frederic clere wrote: Settings and test case of course more than welcome :=} I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. I have also managed to reproduce this more succinctly than previously in almost the same fashion with: Alias /servlets-examples D:\Tomcats\Tomcat5020\webapps\servlets-examples Location /servlets-examples/servlet/* JkUriSet worker ajp13:wtJk2Worker /Location The Tomcat servlet examples are not accessible with these settings. They are, however, (apart from static content like images, etc) once you remove the Alias line. P.S. Let me know if I should file a Bugzilla bug for this No that would be a duplicate of 18472 or 28016. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: container managed security
I searched for some time in various archives, bug databases, mailing lists etc trying to find this information but my searching basically always brings me back to here. All I want to do is set up container managed security to allow unencrypted sessions on protected resources, along with an SSL-based non-clear text form-based login. I discussed this partly with different people at different times but was not involved (or paying attention would be a better way to put it) when the servlet spec gurus and followers discussed the issue, and subsequently I have unanswered questions about the implementation of changes (in tomcat) that leave my requirement unattainable (almost). I have scoured the mailing list archives, google and sun for relevant info, but haven't found anything, even though that is the place to which people constantly refer me. I know this is old ground but I need to get the low-down on it. Thanks in advance for any tips, links, pointers or explanations! Adam On 03/12/2004 06:46 PM Adam Hardy wrote: In tomcat 4 I was able to to protect my app with non-SSL security-constraints while using SSL form-based authentication so that the passwords were not sent in clear text. This has been a specification of the last 3 projects I have worked on. In tomcat 5 this is impossible without coding a work-around. I logged this as a bug in tomcat but it was closed as 'invalid'. http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I remember 6 months ago someone saying that the tomcat developers had decided that due to the danger of session-hijacking, if it was worth encrypting the login, it was worth encrypting the whole session traffic. Due to the charges that the extra hardware brings when doing all logged-in sessions in SSL, amongst other reasons, I disagreed and developed a work-around to let me carry on using the Struts Tomcat security features. This took me a few days back then, and then this week something else cropped up which caused me to revisit the work-around code and spend 2 days adding to it (and documenting it - it's pretty arcane). It occurred to me that this will always happen. The work-around is vulnerable to any changes in the servlet spec of course, but also in tomcat and in struts. I would appreciate finding out the whole story on this - last time I just let it go through lack of time. If I'm in the wrong place - perhaps the JCP Servlet working group would be better - can someone point me in the right direction? Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/procrun tomcat.exe.manifest
mturk 2004/03/30 09:28:43 Added: procrun tomcat.exe.manifest Log: Add XP manifest file for XP style GUI Revision ChangesPath 1.1 jakarta-tomcat-connectors/procrun/tomcat.exe.manifest Index: tomcat.exe.manifest === ?xml version=1.0 encoding=UTF-8 standalone=yes? assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 assemblyIdentity version=1.0.0.0 processorArchitecture=X86 name=Apache.Procrun.Tomcat type=win32 / descriptionTomcat Service Manager/description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=X86 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency /assembly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/procrun tomcat.rc
mturk 2004/03/30 09:29:12 Modified:procrun tomcat.rc Log: Add manifest resource for XP GUI style Revision ChangesPath 1.5 +1 -1 jakarta-tomcat-connectors/procrun/tomcat.rc Index: tomcat.rc === RCS file: /home/cvs/jakarta-tomcat-connectors/procrun/tomcat.rc,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- tomcat.rc 27 Feb 2004 15:14:09 - 1.4 +++ tomcat.rc 30 Mar 2004 17:29:12 - 1.5 @@ -21,7 +21,7 @@ #ifndef PROCRUN_CONSOLE IDI_ICOCONTRY ICONtomcatr.ico IDI_ICOCONTRYSTOP ICONtomcats.ico - +1 24 tomcat.exe.manifest BMPSPLASH BITMAP tomcat.bmp #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/procrun/bin tomcatw.exe tomcat.exe
mturk 2004/03/30 09:31:32 Modified:procrun/bin tomcatw.exe tomcat.exe Log: Latest binary builds Revision ChangesPath 1.8 +208 -63 jakarta-tomcat-connectors/procrun/bin/tomcatw.exe Binary file 1.8 +26 -24jakarta-tomcat-connectors/procrun/bin/tomcat.exe Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24882] - mod_jk (and mod_jk2) missing post parameters in a fail over scenario
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24882 mod_jk (and mod_jk2) missing post parameters in a fail over scenario [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Version|4.1.27 |4.1.29 --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 17:35 --- Configuration: - 6 Tomcat-4.1.29 servers (binary package from jakarta.apache.org) on Fedora Core 1 Linux, all updates applied, and j2sdk-1.4.2_03 (rpm from java.sun.com); - 1 Apache-2.0.48 server (rpm from distribution) on Fedora Core 1 Linux, all updates applied, and mod_jk2-2.0.4 (binary package from jakarta.apache.org). The bug posted previously, generated by POST in a load balance enviornment, is still present in the new version of mod_jk2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug: jk2 2.0.4 vs. mod_dir
jean-frederic clere wrote: I think I have reproduced it with the following: +++ Alias /examples /opt/SMAWoIS/jakarta-tomcat-4.1.29/webapps/examples Location /examples/servlet/* JkUriSet group ajp13:pgtr0327:8009 /Location +++ The /examples/servlet/* uri has /examples/servlet/*-1 for uri and match_type suffix sounds weird for me. And using a VirtualHost works around the problem... (That is why I have not dectected it before). And to re-iterate 2.0.2 does not have this issue. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] New: - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28058.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28058
JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
Summary: JspRuntimeLibrary.getContextRelativePath() can throw
StringIndexOutOfBoundsException
Product: Tomcat 5
Version: 5.0.19
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A program I am working on is throwing an exception
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
from within
org.apache.jasper.runtime.JspRuntimeLibrary.getContextRelativePath
(JspRuntimeLibrary.java:963)
According to the docs http://jakarta.apache.org/tomcat/tomcat-5.0-
doc/servletapi/javax/servlet/http/HttpServletRequest.html#getServletPath(),
getServletPath() can return an empty string which is what is happening in my
app. The line in question:
uri.substring(0, uri.lastIndexOf('/')) + '/' + relativePath
where uri is an empty string is what is causing this exception to be thrown.
As you can see uri.lastIndexOf is going to return -1 and uri.substring(0, -1)
just does not work.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.21 ?
Are you using commons-daemon-1.0 or HEAD for jsvc? There is also a fix for a nasty bug with jsvc in the CVS. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 4:42 AM Subject: Re: 5.0.21 ? Mladen Turk wrote: Bill did some bug fixes and updates, but I'm afraid he didn't done any jtc/procrun binary builds. I can do that but only later this evening. I can wait until later today for new binaries, no problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java
kinman 2004/03/30 11:18:43
Modified:jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
Log:
- Fix bugzilla 28058: JspRuntimeLibrary.getContextRelativePath() can throw
StringIndexOutOfBoundsException
Revision ChangesPath
1.30 +4 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- JspRuntimeLibrary.java17 Mar 2004 19:23:04 - 1.29
+++ JspRuntimeLibrary.java30 Mar 2004 19:18:43 - 1.30
@@ -916,12 +916,14 @@
String pathInfo = (String)
request.getAttribute(javax.servlet.include.path_info);
if (pathInfo == null) {
-uri = uri.substring(0, uri.lastIndexOf('/'));
+if (uri.lastIndexOf('/') = 0)
+uri = uri.substring(0, uri.lastIndexOf('/'));
}
}
else {
uri = hrequest.getServletPath();
-uri = uri.substring(0, uri.lastIndexOf('/'));
+if (uri.lastIndexOf('/') = 0)
+uri = uri.substring(0, uri.lastIndexOf('/'));
}
return uri + '/' + relativePath;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 19:21 --- I was able to reproduce your problem w/ TC 5.0.19. I assume you have a chain of jsp:include, and have the following jsp-config element in your web.xml: jsp-config jsp-property-group url-pattern/*/url-pattern /jsp-property-group /jsp-config If so, this bug has already been fixed - it is a duplicate of Bugzilla 27704 (Result of request.getServletPath() wrong in case JSP inside jsp-property-group). The fix is in CVS, and will be available in TC 5.0.21. Please confirm that your problem is being caused by the above jsp-config, and I will go ahead and close this bug as a duplicate of Bugzilla 27704. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 19:29 --- Thats my problem. Though it's not a chain of jsp includes. I have a servlet that forwards a request to a JSP using the jsp named dispatcher. The JSP then has an include in it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 19:32 --- The servlet is at servlet-mapping servlet-namefoo/servlet-name url-pattern/*/url-pattern /servlet-mapping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Your test for bad beans is much weaker than what it is now. For instance,
you do not catch the case where the bean class is abstract.
However, I am sympathetic to your view on this. If I can be convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.
-Kin-man
Date: Tue, 30 Mar 2004 08:30:05 -0600
From: Jess Holle [EMAIL PROTECTED]
Subject: Re: Tomcat 5.0.20 Issue
To: Tomcat Developers List [EMAIL PROTECTED]
X-OriginalArrivalTime: 30 Mar 2004 14:30:06.0040 (UTC)
FILETIME=[7EEF4580:01C41663]
Kin-Man Chung wrote:
I think your only valid point is the one about the need to make
errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
but we are not bundling jspc scripts anymore, so I didn't feel there
is a need for it. Anyway, its value can be set with an ant task.
Otherwise, Jasper behaves the same as before when
errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it
take more time to compile, but that's a compile-time vs. runt-time
tradeoff that all compilers make.
The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time. For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem. For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.
I'm not arguing with the overall intent of your change. Rather I
believe that calling the constructor during compilation is wasteful and
improper as the environment *can* differ between compilation and
runtime. Also, the fact that a failure to compile in this fashion
generates a partial Java source means that once a compilation fails due
to an environmental issue it will continue to fail even when the
environment is corrected (e.g. when another server comes back up).
That's certainly not appropriate.
If you have ideas about how to modify Generator that works better, please
submit a patch, and I'll see if it can be incorporated.
I must profess ignorance as to how to submit an official patch (e.g. how
to generate one), but here's a diff with Generator.java version 1.230
from CVS of what I'm suggesting:
22a23
*import java.lang.reflect.Constructor;*
1224c1225,1226
bean.newInstance();
---
// Next line will throw exception if
public no-args constructor cannot be found
*Constructor constructor =
bean.getConstructor( new Class[] {} );
*
Essentially, I'm suggesting we check for the existence of the default
constructor, but don't call it. That takes the same amount of real code
(2 more lines thanks to my import and gratuitous comment) and avoids (1)
actually constructing the bean during compilation and (2) making any
unnecessary assumptions about compilation vs. runtime environmental
conditions.
Applying this diff to Generator.java addresses my issue and I believe is
an overall improvement and better aligned with the JSP specification. I
would greatly appreciate it if this could be incorporated into the
Jasper/Tomcat source stream.
--
Jess Holle
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Kin-Man Chung wrote: Your test for bad beans is much weaker than what it is now. For instance, you do not catch the case where the bean class is abstract. Ah, yes, you are correct. That can also be easily checked with an additional line of code, of course. However, I am sympathetic to your view on this. If I can be convinced that we have covered all checks that we can do without too much trouble, I'll fix Jasper. I don't know of any other issues that I'm overlooking besides the possibility of the constructor failing -- which is, of course, what I'm trying to overlook :-) getConstructor() will only return public constructors (as per Javadoc and the Java sources), so that's handled already. I'll add and test the missing line (or possibly 2) shortly. Thanks for the help. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 20:25 --- Created an attachment (id=11064) Test Case - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 20:26 --- I have attached a test case. /test/jsp/test.jsp displays This is a test /test/jsp/include.jsp throws java.lang.StringIndexOutOfBoundsException - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 20:41 --- I was able to reproduce this bug using the servlet wildcard mapping. Bugzilla 27704 fixes the problem where the including JSP was mapped to by a /* jsp-config mapping (and getServletPath() used to be empty), but it does not address the case where a servlet mapped to by /* is the entry point. Kin-Man committed a fix earlier that fixes this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Jess Holle wrote:
Kin-Man Chung wrote:
Your test for bad beans is much weaker than what it is now. For
instance,
you do not catch the case where the bean class is abstract.
Ah, yes, you are correct. That can also be easily checked with an
additional line of code, of course.
However, I am sympathetic to your view on this. If I can be
convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.
I don't know of any other issues that I'm overlooking besides the
possibility of the constructor failing -- which is, of course, what
I'm trying to overlook :-)
getConstructor() will only return public constructors (as per Javadoc
and the Java sources), so that's handled already.
I'll add and test the missing line (or possibly 2) shortly.
Actually I was also missing a check to see if the class was public :-(
Here's my new proposed diff:
22a23
import java.lang.reflect.Constructor;
23a25
import java.lang.reflect.Modifier;
1224c1226,1231
bean.newInstance();
---
int beanModifiers = bean.getModifiers();
if ( !Modifier.isPublic( beanModifiers ) )
throw new IllegalAccessException( Bean
class is not public );
if ( Modifier.isAbstract( beanModifiers )
|| Modifier.isInterface( beanModifiers ) )
throw new InstantiationException( Bean
class is abstract );
Constructor constructor =
bean.getConstructor( new Class[] {} );
--
Jess Holle
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
hgomez 2004/03/30 13:50:11
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
gzip compression could also be used in HTTP 1.0
Revision ChangesPath
1.99 +5 -2
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.98
retrieving revision 1.99
diff -u -r1.98 -r1.99
--- Http11Processor.java 29 Feb 2004 22:51:56 - 1.98
+++ Http11Processor.java 30 Mar 2004 21:50:11 - 1.99
@@ -1333,9 +1333,12 @@
*/
private boolean isCompressable() {
+// Nope Compression could works in HTTP 1.0 also
+// cf: mod_deflate
+
// Compression only since HTTP 1.1
-if (! http11)
-return false;
+// if (! http11)
+//return false;
// Check if browser support gzip encoding
MessageBytes acceptEncodingMB =
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24882] - mod_jk (and mod_jk2) missing post parameters in a fail over scenario
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24882 mod_jk (and mod_jk2) missing post parameters in a fail over scenario --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 21:52 --- There is case with POST DATA more than 4k where we couldn't send the whole datas to the second tomcat. Could you tell us the POST DATA size ? Also could you check it with mod_jk 1.2.6-dev (CVS) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Email account utilization warning.
Dear user, the management of Apache.org mailing system wants to let you know that, Some of our clients complained about the spam (negative e-mail content) outgoing from your e-mail account. Probably, you have been infected by a proxy-relay trojan server. In order to keep your computer safe, follow the instructions. Further details can be obtained from attached file. For security reasons attached file is password protected. The password is 04168. Have a good day, The Apache.org team http://www.apache.org Norton AntiVirus Deleted1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28058] - JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28058 JspRuntimeLibrary.getContextRelativePath() can throw StringIndexOutOfBoundsException --- Additional Comments From [EMAIL PROTECTED] 2004-03-30 23:59 --- I think your test case has a problem unrelated to the StringIndexOutOfBoundsException issue it uncovered. Not only the initial request, but also the target of your jsp:include will be routed through your test servlet (due to the /* mapping), which means you end up doing a request dispatcher forward (from your servlet) inside an include. As a result of this, you'll see this warning in the logs: WARNING: Internal error flushing the buffer in release(): java.io.IOException: Stream closed when releasing the page context of the including JSP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28071] New: - New ArbitraryQueryJDBCRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28071. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28071 New ArbitraryQueryJDBCRealm Summary: New ArbitraryQueryJDBCRealm Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Donating code to allow users to specify the query used to check a username/password or a role. This is much more flexible than the included JDBCRealm. Unit test included. We've been using this for a long time and haven't seen a problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28071] - New ArbitraryQueryJDBCRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28071. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28071 New ArbitraryQueryJDBCRealm --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 02:13 --- Created an attachment (id=11067) source code for ArbitraryQueryJDBCRealm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28071] - New ArbitraryQueryJDBCRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28071. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28071 New ArbitraryQueryJDBCRealm --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 02:14 --- Created an attachment (id=11068) unit test for arbitraryqueryjdbcrealm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28071] - New ArbitraryQueryJDBCRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28071. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28071 New ArbitraryQueryJDBCRealm --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 02:16 --- Example usage (placed in context.xml) : Realm className=com.hic.web.ArbitraryQueryJDBCRealm debug=99 driverName=@db.driver@ connectionURL=@db.url@ connectionName=@db.user@ connectionPassword=@db.pw@ userQuery=select password from ACCOUNT where username = BINARY ? and activated = 1 roleQuery=select 'account' / And, of course, feel free to do whatever you want with this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28072] New: - The TomCat can't be started.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28072. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28072 The TomCat can't be started. Summary: The TomCat can't be started. Product: Tomcat 4 Version: 4.0 Beta 4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is the message of TomCat show me wen I started : The files - Djava.endorsed.dirs is untraceable. To check that the way and the name of the file are correct and that all the library necessary are available. Tank you for all. Hayssam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24882] - mod_jk (and mod_jk2) missing post parameters in a fail over scenario
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24882 mod_jk (and mod_jk2) missing post parameters in a fail over scenario --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 06:48 --- I tested mod_jk 1.x CVS Version and it resloved the initial bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24882] - mod_jk (and mod_jk2) missing post parameters in a fail over scenario
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24882 mod_jk (and mod_jk2) missing post parameters in a fail over scenario --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 07:15 --- jk 1.2.6-dev from CVS works and not with 2.0.4 ? Strange, the code is very similar. Could you give us more informations about the size of POSTED data ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24882] - mod_jk (and mod_jk2) missing post parameters in a fail over scenario
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24882. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24882 mod_jk (and mod_jk2) missing post parameters in a fail over scenario [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-31 07:45 --- Well I tested it on Fedora Core 1 with jk2 2.0.4, netcat being used as first tomcat and tomcat 3.3.1 as the second one and the recovery works in POST. Send more details and configurations but until that, I consider the bug as INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
