DO NOT REPLY [Bug 48869] Intermitten SSL handshake failure | Appears that client (Tomcat) is unable to send the certificate chain back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48869 hbajaj changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920225 - /tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Author: timw
Date: Mon Mar 8 08:08:46 2010
New Revision: 920225
URL: http://svn.apache.org/viewvc?rev=920225&view=rev
Log:
Fixing VC6 build by replacing uses of strcpy_s with StringCbCopy.
Modified:
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=920225&r1=920224&r2=920225&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Mon Mar 8 08:08:46 2010
@@ -2458,7 +2458,7 @@
logger->log = iis_log_to_file;
/* Remember the current log file name for the next potential
rotate */
-strcpy_s(log_file_effective, sizeof(log_file_effective),
log_file_name);
+StringCbCopy(log_file_effective, sizeof(log_file_effective),
log_file_name);
rc = JK_TRUE;
} else {
logger = NULL;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.26
On 03/06/2010 10:55 AM, Mark Thomas wrote: > On 06/03/2010 06:54, jean-frederic clere wrote: >> Hi, >> >> I plan to tag 6.0.26 on Sunday evening (Neuchatel time) and release on >> Monday. >> Comments? > > +1. Do you really mean release on Monday? hm... Starting the vote for the release on Monday... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48869] Intermitten SSL handshake failure | Appears that client (Tomcat) is unable to send the certificate chain back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48869 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r920225 - /tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
On 03/08/2010 09:08 AM, t...@apache.org wrote: Author: timw Date: Mon Mar 8 08:08:46 2010 New Revision: 920225 URL: http://svn.apache.org/viewvc?rev=920225&view=rev Log: Fixing VC6 build by replacing uses of strcpy_s with StringCbCopy. There are bunch of other functions with _s suffix you've added. They are not part of MSVCRT.dll both on x86 and x64 platforms. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.26
On 08/03/2010 08:09, jean-frederic clere wrote: > On 03/06/2010 10:55 AM, Mark Thomas wrote: >> On 06/03/2010 06:54, jean-frederic clere wrote: >>> Hi, >>> >>> I plan to tag 6.0.26 on Sunday evening (Neuchatel time) and release on >>> Monday. >>> Comments? >> >> +1. Do you really mean release on Monday? > > hm... Starting the vote for the release on Monday... Though so :) Konstantin's improved fixes for 48668 need one more vote and then I think we'll be good to go. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r920093 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/reference/iis.xml
On 03/08/2010 08:57 AM, Tim Whittington wrote: Thanks I'm trying to track down a VC6 install so I can test the .dsp build before I commit. Maybe a move to VC2003 as a minimum might be in order some day. We just need MSVCRT, and the functions you've added are Microsoft vision of POSIX functionality. We'll switch when httpd switches version. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48848] fn:endsWith fails with repeated search string
https://issues.apache.org/bugzilla/show_bug.cgi?id=48848 --- Comment #5 from Jose Miguel Samper 2010-03-08 08:45:04 UTC --- This bug is the same as bug #32896 Bug #32896 was fixed in 2005!!! but standard-taglibs project has not released any version since 2004. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.26
On 03/08/2010 09:35 AM, Mark Thomas wrote: > On 08/03/2010 08:09, jean-frederic clere wrote: >> On 03/06/2010 10:55 AM, Mark Thomas wrote: >>> On 06/03/2010 06:54, jean-frederic clere wrote: Hi, I plan to tag 6.0.26 on Sunday evening (Neuchatel time) and release on Monday. Comments? >>> >>> +1. Do you really mean release on Monday? >> >> hm... Starting the vote for the release on Monday... > > Though so :) > > Konstantin's improved fixes for 48668 need one more vote and then I > think we'll be good to go. hm the 3 patches go very well togother. Won't it be more easy to have only one vote for the whole correction? Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920247 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: jfclere Date: Mon Mar 8 09:36:47 2010 New Revision: 920247 URL: http://svn.apache.org/viewvc?rev=920247&view=rev Log: My votes. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920247&r1=920246&r2=920247&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 09:36:47 2010 @@ -105,7 +105,7 @@ Honor isELIgnored and isDeferredSyntaxAllowed when parsing. Backport of r919851: http://people.apache.org/~kkolinko/patches/2010-03-07_tc6_bug48668_r919851.patch - +1: kkolinko, markt + +1: kkolinko, markt, jfclere -1: 2) Fix for jasper.compiler.Validator @@ -126,5 +126,5 @@ Make handling of isELIgnored and isDeferredSyntaxAllowedAsLiteral consistent This is *NOT* required for spec compliance http://svn.apache.org/viewvc?rev=920110&view=rev - +1: markt + +1: markt, jfclere -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Enable RAW headers by default in IIS Tomcat connector
+1 On 07.03.2010 22:40, Tim Whittington wrote: I've committed this change now. I replaced USE_RAW_HEADERS with USE_CGI_HEADERS, and inverted all the conditionals. cheers tim On Mon, Feb 8, 2010 at 9:13 PM, Tim Whittington wrote: OK, the most conservative change will be to enable USE_RAW_HEADERS in the makefiles/projects and leave the code untouched - I'll make the change after 1.2.29 is out. cheers tim On Mon, Feb 8, 2010 at 9:03 PM, Rainer Jungwrote: On 08.02.2010 08:46, Mladen Turk wrote: On 02/08/2010 08:38 AM, Tim Whittington wrote: There's a USE_RAW_HEADERS define that will force the use of the raw HTTP headers and avoid this problem, so I'd propose that we make that behaviour the default. I agree with having it default, but is it possible to have additional configure option that would allow legacy mode? I agree. I'm not sure, whether there could be some compatibility problems with existing apps, so changing default but still being able to switch back lets us move forward and in case someone complains he can switch back. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat Connectors doc
Hi, I wanted to do some modifications around how tomcat handles the connections. Is there any document explaining how the flow is from when a packet is received on a connection and how it is serviced by the servlet and responded back? Regards, Bharath
svn commit: r920257 - /tomcat/trunk/BUILDING.txt
Author: markt
Date: Mon Mar 8 10:14:44 2010
New Revision: 920257
URL: http://svn.apache.org/viewvc?rev=920257&view=rev
Log:
No need for separate ant download
Modified:
tomcat/trunk/BUILDING.txt
Modified: tomcat/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?rev=920257&r1=920256&r2=920257&view=diff
==
--- tomcat/trunk/BUILDING.txt (original)
+++ tomcat/trunk/BUILDING.txt Mon Mar 8 10:14:44 2010
@@ -85,7 +85,6 @@
* Go to that directory, and do:
cd ${tomcat.source}
-ant download
ant
* NOTE: Users accessing the Internet through a proxy must use a properties
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat Connectors doc
Actually found a nice doc for that: http://tomcat.apache.org/tomcat-6.0-doc/architecture/requestProcess/requestProcess.pdf If there is anything else, do let me know. Regards, Bharath On Mon, Mar 8, 2010 at 2:12 AM, Bharath Vasudevan wrote: > Hi, > I wanted to do some modifications around how tomcat handles the > connections. Is there any document explaining how the flow is from when a > packet is received on a connection and how it is serviced by the servlet and > responded back? > > Regards, > Bharath >
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
2010/3/8 Mark Thomas :
> On 07/03/2010 21:26, Konstantin Kolinko wrote:
>> 2010/3/7 Konstantin Kolinko :
>>> 2010/3/7 Mark Thomas :
On 07/03/2010 18:45, ma...@apache.org wrote:
> Author: markt
> Date: Sun Mar 7 18:45:50 2010
> New Revision: 920055
>
> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
> Log:
> Both TLD and web.xml determine if deferred EL syntax is treated as EL or
> as a literal
>>>
>>> Ah, I see. That is said in the chapter "Backwards Compatibility with
>>> JSP 2.0" that precedes the main spec pages (page xxiv in JSP 2.2
>>> Specification).
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>
>> Re: r920110:
>>
>> 2010/3/7 :
>>> Author: markt
>>> Date: Sun Mar 7 20:54:01 2010
>>> New Revision: 920110
>>>
>>> URL: http://svn.apache.org/viewvc?rev=920110&view=rev
>>> Log:
>>> isELIgnored depends on library version and web.xml declaration
>>>
>>> Modified:
>>> tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
>>> =
>>> --- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
>>> +++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Sun Mar 7
>>> 20:54:01 2010
>>> @@ -1077,12 +1077,15 @@
>>> boolean deferred = false;
>>> double libraryVersion = Double.parseDouble(
>>> tagInfo.getTagLibrary().getRequiredVersion());
>>> + boolean elIgnored =
>>> + pageInfo.isELIgnored() ||
>>> + libraryVersion < 2.0;
>>> boolean deferredSyntaxAllowedAsLiteral =
>>> pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
>>> libraryVersion < 2.1;
>>>
>>> ELNode.Nodes el = null;
>>> - if (!runtimeExpression && !pageInfo.isELIgnored()) {
>>> + if (!runtimeExpression && !elIgnored) {
>>> el = ELParser.parse(attrs.getValue(i),
>>> deferredSyntaxAllowedAsLiteral);
>>> Iterator nodes = el.iterator();
>>>
>>
>> I see no provision in the spec for the above change.
>>
>> The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
>> does say that only about #{} expressions.
>>
>> The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
>> (page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
>> (page 123/478) do not mention that either.
>
> The TCK passes either way. Given that the spec doesn't cover this and
> neither does the TCK do we:
> a) stick to the letter of the spec
> b) treat isELIgnored and isDeferredSyntaxAllowedAsLiteral consistently
>
> I have a preference for b) but if the majority disagree I'm happy to revert.
>
Compatibility between JSP 2.0 and JSP 1.2 (aka isELIgnored) is covered
by JSP 2.0 spec.
See "Backwards Compatibility with JSP 1.2" in the preface section of
JSP 2.0 spec (page 20 of 478)
Among compatibility mechanisms mentioned there, using Tag Library
version to switch EL processing in attributes is not mentioned.
At that time the main concern for compatibility were users of JSTL 1.0.
citing (page 22):
"Users of JSTL 1.0 will need to either
"upgrade their taglib imports to the JSTL 1.1 uris, or they will need to use the
"_rt versions of the tags (e.g. c_rt instead of c, or fmt_rt instead of fmt).
/citing.
> In a similar area on which the spec is silent, if I use a TLD that
> declares it requires JSP 2.1 in a web applciation that declares servlet
> 2.3 in web.xml is that an error? At the moment it works but it feels
> wrong. Thoughts?
An example of that I think will be the case when the tag library is
provided by the container, and we deploy an application created for
the older version of specification. If Tag library was updated, does
its URL change, or is it still available under the old URL?
I think that URL change between JSTL 1.0 and 1.1 was an exception, and
the authors would like to avoid it in the future.
Thus such deployment won't be an error.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920265 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Mar 8 10:55:28 2010 New Revision: 920265 URL: http://svn.apache.org/viewvc?rev=920265&view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920265&r1=920264&r2=920265&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 10:55:28 2010 @@ -121,10 +121,17 @@ +1: kkolinko +1: markt with http://svn.apache.org/viewvc?rev=920055&view=rev -1: + kkolinko: +1 with 920055 + + 3) + http://people.apache.org/~kkolinko/patches/2010-03-07_tc7_48668_Compiler.patch + +1: kkolinko + -1: * Follow up for https://issues.apache.org/bugzilla/show_bug.cgi?id=48668 Make handling of isELIgnored and isDeferredSyntaxAllowedAsLiteral consistent This is *NOT* required for spec compliance http://svn.apache.org/viewvc?rev=920110&view=rev +1: markt, jfclere - -1: + -1: kkolinko: JSP 2.0 spec chapter "Backwards Compatibility with JSP 1.2" (page xx (20 of 478)) + does not mention it. So I think it is against the spec. See r920055 thread on d...@. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.26
2010/3/8 jean-frederic clere : > On 03/08/2010 09:35 AM, Mark Thomas wrote: >> On 08/03/2010 08:09, jean-frederic clere wrote: >>> On 03/06/2010 10:55 AM, Mark Thomas wrote: On 06/03/2010 06:54, jean-frederic clere wrote: > Hi, > > I plan to tag 6.0.26 on Sunday evening (Neuchatel time) and release on > Monday. > Comments? +1. Do you really mean release on Monday? >>> >>> hm... Starting the vote for the release on Monday... >> >> Though so :) >> >> Konstantin's improved fixes for 48668 need one more vote and then I >> think we'll be good to go. > > hm the 3 patches go very well togother. Won't it be more easy to have > only one vote for the whole correction? I won't be programming for the next ~4-6 hours. So I, personally, cannot do it earlier than that. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48600] Performance issue with tags
https://issues.apache.org/bugzilla/show_bug.cgi?id=48600 --- Comment #11 from Philippe Prados 2010-03-08 11:03:45 UTC --- Ok. It's correct with JBoss but no with Tomcat. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.26
On 03/08/2010 12:01 PM, Konstantin Kolinko wrote: > 2010/3/8 jean-frederic clere : >> On 03/08/2010 09:35 AM, Mark Thomas wrote: >>> On 08/03/2010 08:09, jean-frederic clere wrote: On 03/06/2010 10:55 AM, Mark Thomas wrote: > On 06/03/2010 06:54, jean-frederic clere wrote: >> Hi, >> >> I plan to tag 6.0.26 on Sunday evening (Neuchatel time) and release on >> Monday. >> Comments? > > +1. Do you really mean release on Monday? hm... Starting the vote for the release on Monday... >>> >>> Though so :) >>> >>> Konstantin's improved fixes for 48668 need one more vote and then I >>> think we'll be good to go. >> >> hm the 3 patches go very well togother. Won't it be more easy to have >> only one vote for the whole correction? > > I won't be programming for the next ~4-6 hours. So I, personally, > cannot do it earlier than that. No pb. Better double checking now than later. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920281 - /tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Author: mturk
Date: Mon Mar 8 11:45:37 2010
New Revision: 920281
URL: http://svn.apache.org/viewvc?rev=920281&view=rev
Log:
Use StringCbPrintf instead sprintf_s and use existing logger for logging new
rotation file name
Modified:
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=920281&r1=920280&r2=920281&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Mon Mar 8 11:45:37 2010
@@ -2437,7 +2437,7 @@
strftime(log_file_name, sizeof(log_file_name_buf), log_file,
tm_now);
} else {
/* Otherwise append the number of seconds to the base name */
-sprintf_s(log_file_name, sizeof(log_file_name_buf), "%s.%d",
log_file, (long)t);
+StringCbPrintf(log_file_name, sizeof(log_file_name_buf), "%s.%d",
log_file, (long)t);
}
} else {
log_file_name = log_file;
@@ -2445,10 +2445,7 @@
/* Close the current log file if required, and the effective log file name
has changed */
if (log_open && strncmp(log_file_name, log_file_effective,
strlen(log_file_name)) != 0) {
-FILE* lf = ((jk_file_logger_t* )logger->logger_private)->logfile;
-fprintf_s(lf, "Log rotated to %s\r\n", log_file_name);
-fflush(lf);
-
+jk_log(logger, JK_LOG_INFO, "Log rotated to %s", log_file_name);
rc = jk_close_file_logger(&logger);
log_open = JK_FALSE;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920297 - in /tomcat/trunk/java/org/apache/catalina: Lifecycle.java util/LifecycleBase.java
Author: markt
Date: Mon Mar 8 12:39:57 2010
New Revision: 920297
URL: http://svn.apache.org/viewvc?rev=920297&view=rev
Log:
Handle component failure without throwing a whole stack of exceptions
Adds a new permitted transition from NEW to STOPPED that does not fire any
events
Modified:
tomcat/trunk/java/org/apache/catalina/Lifecycle.java
tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
Modified: tomcat/trunk/java/org/apache/catalina/Lifecycle.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Lifecycle.java?rev=920297&r1=920296&r2=920297&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Lifecycle.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Lifecycle.java Mon Mar 8 12:39:57
2010
@@ -27,23 +27,25 @@
*
* The valid state transitions for components that support Lifecycle are:
*
- * <--
- * | |
- * start() |auto auto stop()|
- * NEW --->--- STARTING_PREP -->- STARTING -->- STARTED -->---|
- * | ||
- * auto| ||
- * -<- MUST_STOP --<--- ||
- * |||
- * ---<--^
- * | |
- * |auto autostart()|
- * STOPPING_PREP -->- STOPPING -->- STOPPED -->
- * ^
- * |stop()
- * |
- * FAILED
- *
+ *<--
+ *| |
+ * start() |auto auto stop()|
+ * NEW ->--- STARTING_PREP -->- STARTING -->- STARTED -->---|
+ * || ||
+ * |auto| ||
+ * |stop() -<- MUST_STOP --<--- ||
+ * | |||
+ * | ---<--^
+ * | | |
+ * | |auto autostart()|
+ * |STOPPING_PREP -->- STOPPING -->- STOPPED -->
+ * | ^ ^
+ * | |stop()|
+ * | | |
+ * | FAILED|
+ * ||
+ * --->-->---
+ *
* Any state can transition to FAILED.
*
* Calling start() while a component is in states STARTING_PREP, STARTING or
@@ -52,6 +54,11 @@
* Calling stop() while a component is in states STOPPING_PREP, STOPPING or
* STOPPED has no effect.
*
+ * Calling stop() while a component is in state NEW transitions the component
+ * to STOPPED. This is typically encountered when a component fails to start
and
+ * does not start all its sub-components. When the component is stopped, it
will
+ * try to stop all sub-components - even those it didn't start.
+ *
* MUST_STOP is used to indicate that the {...@link #stop()} should be called
on
* the component as soon as {...@link start()} exits.
*
Modified: tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java?rev=920297&r1=920296&r2=920297&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java Mon Mar 8
12:39:57 2010
@@ -185,6 +185,11 @@
return;
}
+if (state.equals(LifecycleState.NEW)) {
+state = LifecycleState.STOPPED;
+return;
+}
+
if (!state.equals(LifecycleState.STARTED) &&
!state.equals(LifecycleState.FAILED)) {
invalidTransition(Lifecycle.BEFORE_STOP_EVENT);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920298 - in /tomcat/trunk/java/org/apache/catalina/loader: LocalStrings.properties WebappClassLoader.java
Author: markt
Date: Mon Mar 8 12:45:56 2010
New Revision: 920298
URL: http://svn.apache.org/viewvc?rev=920298&view=rev
Log:
Add context name to leak detection log messages
Modified:
tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=920298&r1=920297&r2=920298&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties Mon
Mar 8 12:45:56 2010
@@ -17,7 +17,6 @@
fileClassLoader.exists=Repository {0} does not exist
fileClassLoader.jarFile=Cannot read JAR file {0}
fileClassLoader.restricted=Cannot load restricted class {0}
-jdbcLeakPrevention.jdbcRemoveFailed=Unable to de-register driver {0}
standardLoader.addRepository=Adding repository {0}
standardLoader.alreadyStarted=Loader has already been started
standardLoader.checkInterval=Cannot set reload check interval to {0} seconds
@@ -30,23 +29,23 @@
standardLoader.starting=Starting this Loader
standardLoader.stopping=Stopping this Loader
webappClassLoader.illegalJarPath=Illegal JAR entry detected with name {0}
-webappClassLoader.jdbcRemoveFailed=JDBC driver de-registration failed
-webappClassLoader.jdbcRemoveStreamError=Exception closing input stream during
JDBC driver de-registration
+webappClassLoader.jdbcRemoveFailed=JDBC driver de-registration failed for web
application [{0}]
+webappClassLoader.jdbcRemoveStreamError=Exception closing input stream during
JDBC driver de-registration for web application [{0}]
webappClassLoader.stopped=Illegal access: this web application instance has
been stopped already. Could not load {0}. The eventual following stack trace
is caused by an error thrown for debugging purposes as well as to attempt to
terminate the thread which caused the illegal access, and has no functional
impact.
webappClassLoader.readError=Resource read error: Could not load {0}.
-webappClassLoader.clearJbdc=A web application registered the JBDC driver [{0}]
but failed to unregister it when the web application was stopped. To prevent a
memory leak, the JDBC Driver has been forcibly unregistered.
-webappClassLoader.clearReferencesResourceBundlesCount=Removed [{0}]
ResourceBundle references from the cache
-webappClassLoader.clearReferencesResourceBundlesFail=Failed to clear
ResourceBundle references
-webappClassLoader.clearRmiInfo=Failed to find class sun.rmi.transport.Target
to clear context class loader. This is expected on non-Sun JVMs.
-webappClassLoader.clearRmiFail=Failed to clear context class loader referenced
from sun.rmi.transport.Target
-webappClassLoader.clearThreadLocalDebug=A web application created a
ThreadLocal with key of type [{0}] (value [{1}]). The ThreadLocal has been
correctly set to null and the key will be removed by GC. However, to simplify
the process of tracing memory leaks, the key has been forcibly removed.
-webappClassLoader.clearThreadLocal=A web application created a ThreadLocal
with key of type [{0}] (value [{1}]) and a value of type [{2}] (value [{3}])
but failed to remove it when the web application was stopped. To prevent a
memory leak, the ThreadLocal has been forcibly removed.
-webappClassLoader.clearThreadLocalFail=Failed to clear ThreadLocal references
-webappClassLoader.stopThreadFail=Failed to terminate thread named [{0}]
-webappClassLoader.stopTimerThreadFail=Failed to terminate TimerThread named
[{0}]
+webappClassLoader.clearJbdc=The web application [{0}] registered the JBDC
driver [{1}] but failed to unregister it when the web application was stopped.
To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
+webappClassLoader.clearReferencesResourceBundlesCount=Removed [{0}]
ResourceBundle references from the cache for web application [{1}]
+webappClassLoader.clearReferencesResourceBundlesFail=Failed to clear
ResourceBundle references for web application [{0}]
+webappClassLoader.clearRmiInfo=Failed to find class sun.rmi.transport.Target
to clear context class loader for web application [{0}]. This is expected on
non-Sun JVMs.
+webappClassLoader.clearRmiFail=Failed to clear context class loader referenced
from sun.rmi.transport.Target for web application [{0}]
+webappClassLoader.clearThreadLocalDebug=The web application [{0}] created a
ThreadLocal with key of type [{1}] (value [{2}]). The ThreadLocal has been
correctly set to null and the key will be removed by GC. However, to simplify
the process of tracing memory leaks, the key has been forcibly removed.
+webappClassLoader.clearThreadLocal=The web application [{0}] created a
ThreadLocal with key of type [{1}] (value [{2}]) and a value of
svn commit: r920305 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Mar 8 12:48:22 2010 New Revision: 920305 URL: http://svn.apache.org/viewvc?rev=920305&view=rev Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920305&r1=920304&r2=920305&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 12:48:22 2010 @@ -135,3 +135,10 @@ +1: markt, jfclere -1: kkolinko: JSP 2.0 spec chapter "Backwards Compatibility with JSP 1.2" (page xx (20 of 478)) does not mention it. So I think it is against the spec. See r920055 thread on d...@. + +* Improve log messages when a potential leak is detected by including the name + of the offending context + http://svn.apache.org/viewvc?view=revision&revision=920298 + +1: markt + -1: + \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Feedback on tomcat memory leak protection
On 06/03/2010 22:49, Sylvain Laurent wrote: > >> On 03/03/2010 21:12, Sylvain Laurent wrote: >> >>> 3) a couple of months ago I had proposed on this very list a kind of memory >>> leak protection >> for those leaks caused by threads with incorrect CCL. I called this the >> ExpendableClassLoader. >> Please have a look at my post back then : >> http://mail-archives.apache.org/mod_mbox/tomcat-dev/200903.mbox/%3cb1be8ffd-f13f-4b2b-b25a-83f2f855b...@m4x.org%3e >>> Since I did not get any feedback about this idea at all, neither positive >>> nor negative, >> I can only assume that my post got lost in the middle of the other ones. I >> still think that >> this ExpendableClassLoader would improve the memory leak protection. >> Actually it would make >> the JreMemoryLeakPreventionListener useless and developers would not have to >> think about which >> option of the JreMemoryLeakPreventionListener is useful to them. >> I suspect the lack of full source code (the Tomcat lists drop >> attachments) had something to do with it. The concept sounds promising >> and would be better than continually adding to the >> JreLeakPreventionListener. > > Should I try to pursue my investigation and provide a patch ? for TC 6 or 7 ? A full patch in diff -u format attached to a Bugzilla enhancement request for Tomcat 7 is the way to go. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Message string encoding and TC 5.5.x
2010/3/6 Mark Thomas : > On 06/03/2010 10:39, Rainer Jung wrote: >> I lost track w.r.t. UTF-8 conversion: is it still OK to use ISO-8859 >> encoded message strings in the tc 5.5.x LocalStrings_XX.properties >> files? We removed all of them in trunk and TC 6.0.x but there are lots >> of them in TC 5.5.x. Any need to change? > > To be safe, all of the 5.5.x properties files should be run through > native2ascii. > These properties should be in 8859-1 isn't it ? I'm currently battling with some of our applications, under 6.0.18 we didn't have any problems with the JVM in french, but with 6.0.24/6.0.25, I should change the JVM langage to fr :( - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: LocalProperties
I see another error on o.a.c.session.LocalStrings_fr.properties
standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement
de session (session event listener) a
g\u00e9n\u00e9r\u0persistentManager.loading=Chargement de {0} sessions
persistantes
Instead we should have :
standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement
de session (session event listener) a g\u00e9n\u00e9r\u00e9 une
exception
The \u0persistentM... produce an exception !
2010/3/5 Rainer Jung :
> On 05.03.2010 21:37, jean-frederic clere wrote:
>>
>> On 03/05/2010 09:24 PM, Henri Gomez wrote:
>>>
>>> Hi to all,
>>>
>>> I sent some patches to Jean-Fred about the LocalString_fr.properties.
>>
>> I have noticed it is in fact fix in trunk but not in tc6.0.x I have
>> submitted a new proposal. Please double check... It is not my day today
>> :-/
>>
>> Cheers
>>
>> Jean-Frederic
>
> Merci for clarifying.
>
> Have a better weekend!
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: LocalProperties
BTW, I quickly checked the various properties in TC and the french
translations seems in a hurry.
Someone is working on it ?
Regards
2010/3/8 Henri Gomez :
> I see another error on o.a.c.session.LocalStrings_fr.properties
>
> standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement
> de session (session event listener) a
> g\u00e9n\u00e9r\u0persistentManager.loading=Chargement de {0} sessions
> persistantes
>
> Instead we should have :
>
> standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement
> de session (session event listener) a g\u00e9n\u00e9r\u00e9 une
> exception
>
>
> The \u0persistentM... produce an exception !
>
>
>
> 2010/3/5 Rainer Jung :
>> On 05.03.2010 21:37, jean-frederic clere wrote:
>>>
>>> On 03/05/2010 09:24 PM, Henri Gomez wrote:
Hi to all,
I sent some patches to Jean-Fred about the LocalString_fr.properties.
>>>
>>> I have noticed it is in fact fix in trunk but not in tc6.0.x I have
>>> submitted a new proposal. Please double check... It is not my day today
>>> :-/
>>>
>>> Cheers
>>>
>>> Jean-Frederic
>>
>> Merci for clarifying.
>>
>> Have a better weekend!
>>
>> Rainer
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920390 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: jfclere
Date: Mon Mar 8 16:29:48 2010
New Revision: 920390
URL: http://svn.apache.org/viewvc?rev=920390&view=rev
Log:
Another french translation problem to fix.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920390&r1=920389&r2=920390&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 16:29:48 2010
@@ -141,4 +141,23 @@
http://svn.apache.org/viewvc?view=revision&revision=920298
+1: markt
-1:
-
\ No newline at end of file
+
+* Another french translation problem (Submit by Henri Gomez):
+Index: java/org/apache/catalina/session/LocalStrings_fr.properties
+===
+--- java/org/apache/catalina/session/LocalStrings_fr.properties
(revision 920226)
java/org/apache/catalina/session/LocalStrings_fr.properties
(working copy)
+@@ -61,7 +61,8 @@
+ standardSession.getValueNames.ise="getValueNames": Session d\u00e9j\u00e0
invalid\u00e9e
+ standardSession.notSerializable=Impossible de s\u00e9rialiser l''attribut de
session {0} pour la session {1}
+ standardSession.removeAttribute.ise="removeAttribute": Session d\u00e9j\u00e0
invalid\u00e9e
+-standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement de
session (session event listener) a
g\u00e9n\u00e9r\u0persistentManager.loading=Chargement de {0} sessions
persistantes
++standardSession.sessionEvent=L''\u00e9couteur d''\u00e9v\u00e8nement de
session (session event listener) a g\u00e9n\u00e9r\u00e9 une exception
++persistentManager.loading=Chargement de {0} sessions persistantes
+ standardSession.setAttribute.iae="setAttribute": Attribut {0} non
s\u00e9rialisable
+ standardSession.setAttribute.ise="setAttribute": Session d\u00e9j\u00e0
invalid\u00e9e
+ standardSession.setAttribute.namenull="setAttribute": le nom de
param\u00e8tre ne peut \u00eatre nul
+ +1: jfclere
+ -1:
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920392 - in /tomcat/trunk/java/org/apache: coyote/http11/Http11Processor.java tomcat/util/net/JIoEndpoint.java tomcat/util/net/SocketWrapper.java
Author: fhanik
Date: Mon Mar 8 16:38:35 2010
New Revision: 920392
URL: http://svn.apache.org/viewvc?rev=920392&view=rev
Log:
more work towards making the JIO connector ready for async
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java?rev=920392&r1=920391&r2=920392&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java Mon Mar 8
16:38:35 2010
@@ -185,12 +185,13 @@
error = true;
}
-boolean keptAlive = false;
+boolean keptAlive = socketWrapper.isKeptAlive();
while (started && !error && keepAlive) {
// Parsing the request header
try {
+//TODO - calculate timeout based on length in queue
(System.currentTimeMills() - wrapper.getLastAccess() is the time in queue)
if (keptAlive) {
if (keepAliveTimeout > 0) {
socket.setSoTimeout(keepAliveTimeout);
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java?rev=920392&r1=920391&r2=920392&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java Mon Mar 8
16:38:35 2010
@@ -187,10 +187,12 @@
public void run() {
boolean close = false;
// Process the request from this socket
-if (!setSocketOptions(socket.getSocket())) { //this does a
handshake and resets socket value
+if ( (!socket.isKeptAlive()) &&
(!setSocketOptions(socket.getSocket())) ) { //this does a handshake and resets
socket value
close = true;
-} else if (!handler.process(socket)) {
-close = true;
+}
+
+if ( (!close) ) {
+close = !handler.process(socket);
}
if (close) {
// Close socket
@@ -203,7 +205,10 @@
// Ignore
}
} else {
+socket.setKeptAlive(true);
+socket.access();
//keepalive connection
+//TODO - servlet3 check async status, we may just be in a hold
pattern
getExecutor().execute(new SocketProcessor(socket));
}
// Finish up this request
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java?rev=920392&r1=920391&r2=920392&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java Mon Mar 8
16:38:35 2010
@@ -21,13 +21,14 @@
protected volatile E socket;
-protected long lastAccess = -1;
-protected boolean currentAccess = false;
+protected volatile long lastAccess = -1;
+protected volatile boolean currentAccess = false;
protected long timeout = -1;
protected boolean error = false;
protected long lastRegistered = 0;
protected volatile int keepAliveLeft = 100;
protected boolean async = false;
+protected boolean keptAlive = false;
public SocketWrapper(E socket) {
reset(socket);
@@ -55,5 +56,6 @@
public int getKeepAliveLeft() { return this.keepAliveLeft; }
public void setKeepAliveLeft(int keepAliveLeft) { this.keepAliveLeft =
keepAliveLeft;}
public int decrementKeepAlive() { return (--keepAliveLeft);}
-
+public boolean isKeptAlive() {return keptAlive;}
+public void setKeptAlive(boolean keptAlive) {this.keptAlive = keptAlive;}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920410 - /tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
Author: markt
Date: Mon Mar 8 17:22:33 2010
New Revision: 920410
URL: http://svn.apache.org/viewvc?rev=920410&view=rev
Log:
Use the Lifecycle state to dtermine if the context is in the correct state to
allow configuration
Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=920410&r1=920409&r2=920410&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java Mon Mar
8 17:22:33 2010
@@ -61,6 +61,7 @@
import org.apache.catalina.Context;
import org.apache.catalina.Engine;
import org.apache.catalina.Host;
+import org.apache.catalina.LifecycleState;
import org.apache.catalina.Service;
import org.apache.catalina.Wrapper;
import org.apache.catalina.connector.Connector;
@@ -887,7 +888,7 @@
private FilterRegistration.Dynamic addFilter(String filterName,
String filterClass, Filter filter) throws IllegalStateException {
-if (context.initialized) {
+if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
//TODO Spec breaking enhancement to ignore this restriction
throw new IllegalStateException(
sm.getString("applicationContext.addFilter.ise",
@@ -1016,7 +1017,7 @@
private ServletRegistration.Dynamic addServlet(String servletName,
String servletClass, Servlet servlet) throws IllegalStateException
{
-if (context.initialized) {
+if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
//TODO Spec breaking enhancement to ignore this restriction
throw new IllegalStateException(
sm.getString("applicationContext.addServlet.ise",
@@ -1145,7 +1146,7 @@
public void setSessionTrackingModes(
Set sessionTrackingModes) {
-if (context.getAvailable()) {
+if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
throw new IllegalStateException(
sm.getString("applicationContext.setSessionTracking.ise",
getContextPath()));
@@ -1230,7 +1231,7 @@
@Override
public void addListener(T t) {
-if (context.getAvailable()) {
+if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
throw new IllegalStateException(
sm.getString("applicationContext.addListener.ise",
getContextPath()));
@@ -1300,7 +1301,7 @@
@Override
public void declareRoles(String... roleNames) {
-if (context.initialized) {
+if (!context.getState().equals(LifecycleState.STARTING_PREP)) {
//TODO Spec breaking enhancement to ignore this restriction
throw new IllegalStateException(
sm.getString("applicationContext.addRole.ise",
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] C-T-R for any translation fixes
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
3. I think that we can have C-T-R for any whitespace changes in the
code. These are generally discouraged, but might be necessary to ease
backporting of patches.
Note, that whitespace-only changes
a) can be verified in viewvc when viewing the committed patch in
"Colored Diff" mode. E.g.,
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
b) can be verified by svn diff command:
svn diff -x -w
will generate a patch ignoring all whitespace changes.
Whitespace changes can hinder applying other patches, generated before
them. As for line numbers, e.g. when deciphering stack traces, we can
always look at the SVN tags that we have from the releases.
I am +1 for C-T-R these.
4. Trivial fixes for any English message strings and message constants
in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
those.
Adding/removing parameters, and changing code that displays these
messages is not a trivial change.
Things to beware here are single quotes and '{}' brackets. If message
string does not have arguments, it is used as is, and those symbols
have no special meaning. If it does have arguments, those symbols
have special meaning. E.g., there will be an exception if there is
'{}' that does not contain a number and is not inside single quotes.
5. Any fixes for any translations.
I cannot review the textual part of the changes, only the technical
part, and that can be as well done looking at the commit email.
The risks here are not very high, as tomcat-i18n-*.jar files do not
contain any code in them and can be fixed without recompiling.
The technical requirement here is that
all *.properties files should contain only 7-bit characters. All
others should be \u escaped. The program to perform such
conversion is native2ascii.
For consistency, there should be end-of-line character on the last
line of the file (as native2ascii always adds it).
The specification (JavaDoc for java.util.Properties) says that the
files are technically in ISO-8859-1, but, as was discussed around a
year ago, we should not allow 8-bit characters from the upper part of
ISO-8859-1 charset. The reasons that I remember are:
1). Some IDEs (or IDE plugins) have configuration where by default
they are reading *.properties files not in ISO-8859-1, but in the
system default encoding. Thus, if the file has character from the
upper part of ISO-8859-1, they can be read incorrectly. My own story
of observing this was with the PropertiesEditor Plugin for EclipseIDE
I suppose that using system encoding by default have some meaning.
E.g. when running native2ascii before opening the file in the IDE this
setting will allow to open them correctly.
2). We had some files in ISO-8859-1, some in Windows-1252, some in
UTF-8. There should have been some reason why that happened.
That said, I am +1 for C-T-R for any translation fixes.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing "C-T-R" or "trivial" in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
Your vote proposal is not very much readable.
Please make a standard single request for vote and
check boxes +1, -1 (+0, -0 are irrelevant thought, but might be added as well)
On 03/08/2010 06:34 PM, Konstantin Kolinko wrote:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
3. I think that we can have C-T-R for any whitespace changes in the
code. These are generally discouraged, but might be necessary to ease
backporting of patches.
Note, that whitespace-only changes
a) can be verified in viewvc when viewing the committed patch in
"Colored Diff" mode. E.g.,
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
b) can be verified by svn diff command:
svn diff -x -w
will generate a patch ignoring all whitespace changes.
Whitespace changes can hinder applying other patches, generated before
them. As for line numbers, e.g. when deciphering stack traces, we can
always look at the SVN tags that we have from the releases.
I am +1 for C-T-R these.
4. Trivial fixes for any English message strings and message constants
in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
those.
Adding/removing parameters, and changing code that displays these
messages is not a trivial change.
Things to beware here are single quotes and '{}' brackets. If message
string does not have arguments, it is used as is, and those symbols
have no special meaning. If it does have arguments, those symbols
have special meaning. E.g., there will be an exception if there is
'{}' that does not contain a number and is not inside single quotes.
5. Any fixes for any translations.
I cannot review the textual part of the changes, only the technical
part, and that can be as well done looking at the commit email.
The risks here are not very high, as tomcat-i18n-*.jar files do not
contain any code in them and can be fixed without recompiling.
The technical requirement here is that
all *.properties files should contain only 7-bit characters. All
others should be \u escaped. The program to perform such
conversion is native2ascii.
For consistency, there should be end-of-line character on the last
line of the file (as native2ascii always adds it).
The specification (JavaDoc for java.util.Properties) says that the
files are technically in ISO-8859-1, but, as was discussed around a
year ago, we should not allow 8-bit characters from the upper part of
ISO-8859-1 charset. The reasons that I remember are:
1). Some IDEs (or IDE plugins) have configuration where by default
they are reading *.properties files not in ISO-8859-1, but in the
system default encoding. Thus, if the file has character from the
upper part of ISO-8859-1, they can be read incorrectly. My own story
of observing this was with the PropertiesEditor Plugin for EclipseIDE
I suppose that using system encoding by default have some meaning.
E.g. when running native2ascii before opening the file in the IDE this
setting will allow to open them correctly.
2). We had some files in ISO-8859-1, some in Windows-1252, some in
UTF-8. There should have been some reason why that happened.
That said, I am +1 for C-T-R for any translation fixes.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing "C-T-R" or "trivial" in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920422 - in /tomcat/trunk: java/org/apache/catalina/realm/JNDIRealm.java webapps/docs/realm-howto.xml
Author: markt
Date: Mon Mar 8 17:59:51 2010
New Revision: 920422
URL: http://svn.apache.org/viewvc?rev=920422&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48629
Make nested role search work with username as well as DN
Add roleNested to the docs
Patch provided by Felix Schumacher
Modified:
tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java
tomcat/trunk/webapps/docs/realm-howto.xml
Modified: tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java?rev=920422&r1=920421&r2=920422&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/JNDIRealm.java Mon Mar 8
17:59:51 2010
@@ -30,7 +30,9 @@
import java.util.Hashtable;
import java.util.Iterator;
import java.util.List;
+import java.util.Map;
import java.util.Set;
+import java.util.Map.Entry;
import javax.naming.Context;
import javax.naming.CommunicationException;
@@ -1683,12 +1685,12 @@
// Directory Groups". It avoids group slurping and handles cyclic
group memberships as well.
// See http://middleware.internet2.edu/dir/ for details
-Set newGroupDNs = new HashSet(groupMap.keySet());
-while (!newGroupDNs.isEmpty()) {
-Set newThisRound = new HashSet(); // Stores
the groups we find in this iteration
+Map newGroups = new
HashMap(groupMap);
+while (!newGroups.isEmpty()) {
+Map newThisRound = new HashMap(); // Stores the groups we find in this iteration
-for (String groupDN : newGroupDNs) {
-filter = roleFormat.format(new String[] { groupDN });
+for (Entry group : newGroups.entrySet()) {
+filter = roleFormat.format(new String[] { group.getKey(),
group.getValue() });
if (containerLog.isTraceEnabled()) {
containerLog.trace("Perform a nested group search with
base "+ roleBase + " and filter " + filter);
@@ -1706,7 +1708,7 @@
String name = getAttributeValue(roleName, attrs);
if (name != null && dname != null &&
!groupMap.keySet().contains(dname)) {
groupMap.put(dname, name);
-newThisRound.add(dname);
+newThisRound.put(dname, name);
if (containerLog.isTraceEnabled()) {
containerLog.trace(" Found nested role "
+ dname + " -> " + name);
@@ -1720,7 +1722,7 @@
}
}
-newGroupDNs = newThisRound;
+newGroups = newThisRound;
}
}
Modified: tomcat/trunk/webapps/docs/realm-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/realm-howto.xml?rev=920422&r1=920421&r2=920422&view=diff
==
--- tomcat/trunk/webapps/docs/realm-howto.xml (original)
+++ tomcat/trunk/webapps/docs/realm-howto.xml Mon Mar 8 17:59:51 2010
@@ -651,6 +651,12 @@
roleName - the attribute in a role entry
containing the name of that role.
+roleNested - enable nested roles. Set to
+ true if you want to nest roles in roles. If configured
+ every newly found roleName and distinguished
+ Name will be recursively tried for a new role search.
+ The default value is false.
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920423 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Mar 8 18:01:51 2010 New Revision: 920423 URL: http://svn.apache.org/viewvc?rev=920423&view=rev Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920423&r1=920422&r2=920423&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 18:01:51 2010 @@ -161,3 +161,10 @@ +++ +1: jfclere -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48629 + Allow user names as well as DNs to be used with the nested role search + Add roleNested to the docs + Patch provided by Felix Schumacher + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48629] JNDIRealm and roleNested doesn't work with roleSearch="(member={1})"
https://issues.apache.org/bugzilla/show_bug.cgi?id=48629 --- Comment #6 from Mark Thomas 2010-03-08 18:01:55 UTC --- Thanks for the patch. I have applied it to trunk and proposed it for 6.0.x. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
CTR for non code area in TC : +1
2010/3/8 Mladen Turk :
> Your vote proposal is not very much readable.
> Please make a standard single request for vote and
> check boxes +1, -1 (+0, -0 are irrelevant thought, but might be added as
> well)
>
>
>
>
> On 03/08/2010 06:34 PM, Konstantin Kolinko wrote:
>>
>> 1. We already have Commit-Then-Review for any documentation, including
>> JavaDoc and code comments.
>>
>> 2. I think that we can have C-T-R for any svn metadata (svn:
>> properties), as those are not the code. I am +1.
>>
>>
>> 3. I think that we can have C-T-R for any whitespace changes in the
>> code. These are generally discouraged, but might be necessary to ease
>> backporting of patches.
>>
>> Note, that whitespace-only changes
>> a) can be verified in viewvc when viewing the committed patch in
>> "Colored Diff" mode. E.g.,
>>
>> http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
>> b) can be verified by svn diff command:
>>
>> svn diff -x -w
>>
>> will generate a patch ignoring all whitespace changes.
>> Whitespace changes can hinder applying other patches, generated before
>> them. As for line numbers, e.g. when deciphering stack traces, we can
>> always look at the SVN tags that we have from the releases.
>>
>> I am +1 for C-T-R these.
>>
>>
>> 4. Trivial fixes for any English message strings and message constants
>> in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
>> those.
>>
>> Adding/removing parameters, and changing code that displays these
>> messages is not a trivial change.
>>
>> Things to beware here are single quotes and '{}' brackets. If message
>> string does not have arguments, it is used as is, and those symbols
>> have no special meaning. If it does have arguments, those symbols
>> have special meaning. E.g., there will be an exception if there is
>> '{}' that does not contain a number and is not inside single quotes.
>>
>>
>> 5. Any fixes for any translations.
>>
>> I cannot review the textual part of the changes, only the technical
>> part, and that can be as well done looking at the commit email.
>>
>> The risks here are not very high, as tomcat-i18n-*.jar files do not
>> contain any code in them and can be fixed without recompiling.
>>
>> The technical requirement here is that
>> all *.properties files should contain only 7-bit characters. All
>> others should be \u escaped. The program to perform such
>> conversion is native2ascii.
>>
>> For consistency, there should be end-of-line character on the last
>> line of the file (as native2ascii always adds it).
>>
>> The specification (JavaDoc for java.util.Properties) says that the
>> files are technically in ISO-8859-1, but, as was discussed around a
>> year ago, we should not allow 8-bit characters from the upper part of
>> ISO-8859-1 charset. The reasons that I remember are:
>>
>> 1). Some IDEs (or IDE plugins) have configuration where by default
>> they are reading *.properties files not in ISO-8859-1, but in the
>> system default encoding. Thus, if the file has character from the
>> upper part of ISO-8859-1, they can be read incorrectly. My own story
>> of observing this was with the PropertiesEditor Plugin for EclipseIDE
>>
>> I suppose that using system encoding by default have some meaning.
>> E.g. when running native2ascii before opening the file in the IDE this
>> setting will allow to open them correctly.
>>
>> 2). We had some files in ISO-8859-1, some in Windows-1252, some in
>> UTF-8. There should have been some reason why that happened.
>>
>> That said, I am +1 for C-T-R for any translation fixes.
>>
>>
>> 6. Should we mark C-T-R commits somehow in the commit message?
>> E.g. writing "C-T-R" or "trivial" in the message?
>>
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>>
>
>
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920449 - /tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java
Author: markt
Date: Mon Mar 8 18:58:28 2010
New Revision: 920449
URL: http://svn.apache.org/viewvc?rev=920449&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48661
If the response has been committed, include the error page like Jasper does
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java?rev=920449&r1=920448&r2=920449&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardHostValve.java Mon Mar
8 18:58:28 2010
@@ -416,18 +416,25 @@
request.setPathInfo(errorPage.getLocation());
try {
-// Reset the response (keeping the real error code and message)
-response.resetBuffer(true);
-
// Forward control to the specified location
ServletContext servletContext =
request.getContext().getServletContext();
RequestDispatcher rd =
servletContext.getRequestDispatcher(errorPage.getLocation());
-rd.forward(request.getRequest(), response.getResponse());
-// If we forward, the response is suspended again
-response.setSuspended(false);
+if (response.isCommitted()) {
+// Response is committed - including the error page is the
+// best we can do
+rd.include(request.getRequest(), response.getResponse());
+} else {
+// Reset the response (keeping the real error code and message)
+response.resetBuffer(true);
+
+rd.forward(request.getRequest(), response.getResponse());
+
+// If we forward, the response is suspended again
+response.setSuspended(false);
+}
// Indicate that we have successfully processed this custom page
return (true);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920455 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Mar 8 19:00:05 2010 New Revision: 920455 URL: http://svn.apache.org/viewvc?rev=920455&view=rev Log: Proposal Add missing svn link Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920455&r1=920454&r2=920455&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 19:00:05 2010 @@ -166,5 +166,13 @@ Allow user names as well as DNs to be used with the nested role search Add roleNested to the docs Patch provided by Felix Schumacher + http://svn.apache.org/viewvc?rev=920422&view=rev +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48661 + Make error page behaviour consistent. If a response has been committed, include + the error page + http://svn.apache.org/viewvc?rev=920449&view=rev + +1: mark + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48661] inconsistent error page behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661 --- Comment #1 from Mark Thomas 2010-03-08 19:00:17 UTC --- This has been fixed in trunk and proposed for 6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
I propose to relax our RTC policy and use CTR for the types of changes
listed below:
2010/3/8 Konstantin Kolinko :
> 1. We already have Commit-Then-Review for any documentation, including
> JavaDoc and code comments.
>
Already decided. No need to vote.
> 2. I think that we can have C-T-R for any svn metadata (svn:
> properties), as those are not the code. I am +1.
>
Allow C-T-R for changes to svn properties:
[ ] +1
[ ] 0
[ ] -1
>
> 3. I think that we can have C-T-R for any whitespace changes in the
> code. These are generally discouraged, but might be necessary to ease
> backporting of patches.
>
> Note, that whitespace-only changes
> a) can be verified in viewvc when viewing the committed patch in
> "Colored Diff" mode. E.g.,
> http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
> b) can be verified by svn diff command:
>
> svn diff -x -w
>
> will generate a patch ignoring all whitespace changes.
> Whitespace changes can hinder applying other patches, generated before
> them. As for line numbers, e.g. when deciphering stack traces, we can
> always look at the SVN tags that we have from the releases.
>
> I am +1 for C-T-R these.
>
Allow C-T-R for any whitespace changes:
[ ] +1
[ ] 0
[ ] -1
>
> 4. Trivial fixes for any English message strings and message constants
> in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
> those.
>
> Adding/removing parameters, and changing code that displays these
> messages is not a trivial change.
>
> Things to beware here are single quotes and '{}' brackets. If message
> string does not have arguments, it is used as is, and those symbols
> have no special meaning. If it does have arguments, those symbols
> have special meaning. E.g., there will be an exception if there is
> '{}' that does not contain a number and is not inside single quotes.
>
Allow C-T-R for trivial fixes to English messages that are in resource files
and those that are inline in the code. This includes typos and rephrasing,
but does not include adding/removing message parameters.
Technical issues to beware are mentioned above.
[ ] +1
[ ] 0
[ ] -1
>
> 5. Any fixes for any translations.
>
> I cannot review the textual part of the changes, only the technical
> part, and that can be as well done looking at the commit email.
>
> The risks here are not very high, as tomcat-i18n-*.jar files do not
> contain any code in them and can be fixed without recompiling.
>
> The technical requirement here is that
> all *.properties files should contain only 7-bit characters. All
> others should be \u escaped. The program to perform such
> conversion is native2ascii.
>
> For consistency, there should be end-of-line character on the last
> line of the file (as native2ascii always adds it).
>
> The specification (JavaDoc for java.util.Properties) says that the
> files are technically in ISO-8859-1, but, as was discussed around a
> year ago, we should not allow 8-bit characters from the upper part of
> ISO-8859-1 charset. The reasons that I remember are:
>
> 1). Some IDEs (or IDE plugins) have configuration where by default
> they are reading *.properties files not in ISO-8859-1, but in the
> system default encoding. Thus, if the file has character from the
> upper part of ISO-8859-1, they can be read incorrectly. My own story
> of observing this was with the PropertiesEditor Plugin for EclipseIDE
>
> I suppose that using system encoding by default have some meaning.
> E.g. when running native2ascii before opening the file in the IDE this
> setting will allow to open them correctly.
>
> 2). We had some files in ISO-8859-1, some in Windows-1252, some in
> UTF-8. There should have been some reason why that happened.
>
> That said, I am +1 for C-T-R for any translation fixes.
>
Allow C-T-R for any fixes for non-English resource files.
The files must use 7-bit characters only. Other symbols must be
escaped with \u, as does native2ascii.
[ ] +1
[ ] 0
[ ] -1
>
> 6. Should we mark C-T-R commits somehow in the commit message?
> E.g. writing "C-T-R" or "trivial" in the message?
>
This is not mandatory, but I would prefer some indication in the
commit message, that it was done using CTR rule. I propose to write
"C-T-R", but I wouldn't mind if others will write just "trivial" or
something like that.
Require some indication in the commit message for code that usually is
covered by RTC, that this commit was done using C-T-R rule.
[ ] +1
[ ] 0
[ ] -1
My own votes for 2.,3.,4.,5. are +1, but for 6. my vote is -0.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920456 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Mar 8 19:00:57 2010 New Revision: 920456 URL: http://svn.apache.org/viewvc?rev=920456&view=rev Log: Vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920456&r1=920455&r2=920456&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 19:00:57 2010 @@ -159,7 +159,7 @@ standardSession.setAttribute.ise="setAttribute": Session d\u00e9j\u00e0 invalid\u00e9e standardSession.setAttribute.namenull="setAttribute": le nom de param\u00e8tre ne peut \u00eatre nul +++ - +1: jfclere + +1: jfclere, markt -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48629 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920479 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Mar 8 19:42:09 2010 New Revision: 920479 URL: http://svn.apache.org/viewvc?rev=920479&view=rev Log: votes Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920479&r1=920478&r2=920479&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 19:42:09 2010 @@ -159,7 +159,7 @@ standardSession.setAttribute.ise="setAttribute": Session d\u00e9j\u00e0 invalid\u00e9e standardSession.setAttribute.namenull="setAttribute": le nom de param\u00e8tre ne peut \u00eatre nul +++ - +1: jfclere, markt + +1: jfclere, markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48629 @@ -167,12 +167,12 @@ Add roleNested to the docs Patch provided by Felix Schumacher http://svn.apache.org/viewvc?rev=920422&view=rev - +1: markt + +1: markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48661 Make error page behaviour consistent. If a response has been committed, include the error page http://svn.apache.org/viewvc?rev=920449&view=rev - +1: mark + +1: markt, kkolinko -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48685] Spnego Support in Tomcat
https://issues.apache.org/bugzilla/show_bug.cgi?id=48685 Mark Thomas changed: What|Removed |Added Severity|normal |enhancement --- Comment #5 from Mark Thomas 2010-03-08 19:45:38 UTC --- The patch will not be applied in it's current form. There are a number of issues. In no particular: - format (bracket placement, random white-space changes) - use of a system property that makes SPNEGO configuration global - lack of documentation This last point is particularly important given that this depends on a specifically configured JAAS realm. I am still leaning towards creating a new authenticator for this. The spec allows containers to add additional methods beyond BASIC, FORM, etc. Given the effort required to test this, I'm not going to start setting up a domain and the like until there is some documentation, particularly on the JAAS configuration required. The other issues with the patch I am less concerned with given that it is likely to be extensively re-worked before it is included. I'm also marking this as an enhancement. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920480 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Mar 8 19:47:53 2010 New Revision: 920480 URL: http://svn.apache.org/viewvc?rev=920480&view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920480&r1=920479&r2=920480&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 19:47:53 2010 @@ -139,8 +139,9 @@ * Improve log messages when a potential leak is detected by including the name of the offending context http://svn.apache.org/viewvc?view=revision&revision=920298 - +1: markt + +1: markt, kkolinko -1: + kkolinko: I would prefer contextName to always be the 0th argument of the message * Another french translation problem (Submit by Henri Gomez): +++ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/08/2010 08:00 PM, Konstantin Kolinko wrote: I propose to relax our RTC policy and use CTR for the types of changes listed below: Usually a vote has a single voting item, but all those things you've put to vote are something many projects already have as a policy. Allow C-T-R for changes to svn properties: [ ] +1 [ ] 0 [X] -1 -1 because it can mean anything and nothing. Changing line endings, executable flag, mime type all falls into svn properties for which change one needs a good reason. If you meant svn logs and svn commit message typos then +1 for those (but you should said that) Allow C-T-R for any whitespace changes: [X] +1 [ ] 0 [ ] -1 Allow C-T-R for trivial fixes to English messages that are in resource files and those that are inline in the code. This includes typos and rephrasing, but does not include adding/removing message parameters. Technical issues to beware are mentioned above. [X] +1 [ ] 0 [ ] -1 Allow C-T-R for any fixes for non-English resource files. The files must use 7-bit characters only. Other symbols must be escaped with \u, as does native2ascii. [X] +1 [ ] 0 [ ] -1 Require some indication in the commit message for code that usually is covered by RTC, that this commit was done using C-T-R rule. [X] +1 [ ] 0 [ ] -1 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920506 - /tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Author: markt
Date: Mon Mar 8 20:59:18 2010
New Revision: 920506
URL: http://svn.apache.org/viewvc?rev=920506&view=rev
Log:
Whitespace
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=920506&r1=920505&r2=920506&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Mon Mar 8
20:59:18 2010
@@ -1052,25 +1052,23 @@
java.lang.reflect.Method meth = JspRuntimeLibrary
.getReadMethod(bean, property);
String methodName = meth.getName();
-out
-
.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString("
-+ "((("
-+ beanName
-+ ")_jspx_page_context.findAttribute("
-+ "\""
-+ name + "\"))." + methodName + "(;");
+
out.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString("
++ "((("
++ beanName
++ ")_jspx_page_context.findAttribute("
++ "\""
++ name + "\"))." + methodName + "(;");
} else if (varInfoNames.contains(name)) {
// The object is a custom action with an associated
// VariableInfo entry for this name.
// Get the class name and then introspect at runtime.
-out
-
.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString"
-+
"(org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty"
-+ "(_jspx_page_context.findAttribute(\""
-+ name
-+ "\"), \""
-+ property
-+ "\")));");
+
out.printil("out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString"
++
"(org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty"
++ "(_jspx_page_context.findAttribute(\""
++ name
++ "\"), \""
++ property
++ "\")));");
} else {
StringBuilder msg =
new StringBuilder("jsp:getProperty for bean with name '");
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920532 - /tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Author: markt
Date: Mon Mar 8 21:53:29 2010
New Revision: 920532
URL: http://svn.apache.org/viewvc?rev=920532&view=rev
Log:
Revisit https://issues.apache.org/bugzilla/show_bug.cgi?id=48701
Allow TagVariableInfo as well as VariableInfo to introduce objects later used
by - JSP.5.3
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=920532&r1=920531&r2=920532&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Mon Mar 8
21:53:29 2010
@@ -1711,6 +1711,20 @@
pageInfo.getVarInfoNames().add(info.getVarName());
}
}
+TagVariableInfo[] tagInfos = n.getTagVariableInfos();
+if (tagInfos != null && tagInfos.length > 0) {
+for (int i = 0; i < tagInfos.length; i++) {
+TagVariableInfo tagInfo = tagInfos[i];
+if (tagInfo != null) {
+String name = tagInfo.getNameFromAttribute();
+if (name == null) {
+name = tagInfo.getNameGiven();
+}
+pageInfo.getVarInfoNames().add(name);
+}
+}
+}
+
if (n.implementsSimpleTag()) {
generateCustomDoTag(n, handlerInfo, tagHandlerVar);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920534 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Mar 8 21:55:37 2010 New Revision: 920534 URL: http://svn.apache.org/viewvc?rev=920534&view=rev Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920534&r1=920533&r2=920534&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Mar 8 21:55:37 2010 @@ -177,3 +177,10 @@ http://svn.apache.org/viewvc?rev=920449&view=rev +1: markt, kkolinko -1: + +* Revisit https://issues.apache.org/bugzilla/show_bug.cgi?id=48701 + Allow TagVariableInfo as well as VariableInfo to introduce objects later used + by - JSP.5.3 + http://svn.apache.org/viewvc?rev=920532&view=rev + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48701] jsp:getProperty broken for certain cases
https://issues.apache.org/bugzilla/show_bug.cgi?id=48701 --- Comment #6 from Mark Thomas 2010-03-08 21:55:43 UTC --- Agreed. TagVariableInfo should be just as acceptable for this purpose. I have fixed this in trunk and proposed it for 6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 08.03.2010 20:00, Konstantin Kolinko wrote: I propose to relax our RTC policy and use CTR for the types of changes listed below: 2. I think that we can have C-T-R for any svn metadata (svn: properties), as those are not the code. I am +1. Allow C-T-R for changes to svn properties: [ ] +1 [X] 0 [ ] -1 3. I think that we can have C-T-R for any whitespace changes in the code. These are generally discouraged, but might be necessary to ease backporting of patches. Allow C-T-R for any whitespace changes: [X] +1 [ ] 0 [ ] -1 4. Trivial fixes for any English message strings and message constants in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R those. Allow C-T-R for trivial fixes to English messages that are in resource files and those that are inline in the code. This includes typos and rephrasing, but does not include adding/removing message parameters. Technical issues to beware are mentioned above. [X] +1 [ ] 0 [ ] -1 5. Any fixes for any translations. Allow C-T-R for any fixes for non-English resource files. The files must use 7-bit characters only. Other symbols must be escaped with \u, as does native2ascii. [X] +1 [ ] 0 [ ] -1 6. Should we mark C-T-R commits somehow in the commit message? E.g. writing "C-T-R" or "trivial" in the message? [X] +1 [ ] 0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
2010/3/8 Mladen Turk : > On 03/08/2010 08:00 PM, Konstantin Kolinko wrote: >> Allow C-T-R for changes to svn properties: >> [ ] +1 >> [ ] 0 >> [X] -1 >> > > -1 because it can mean anything and nothing. > Changing line endings, executable flag, mime type > all falls into svn properties for which change > one needs a good reason. > If you meant svn logs and svn commit message typos > then +1 for those (but you should said that) > I meant svn:eol-style, svn:mime-type, svn:keywords, svn:executable. svn:log is a revision property which is repository-wide, so it is not a subject of RTC. My reasoning is that because we distribute our sources as zip/tar.gz archives, which do not have svn properties, none of those properties are essential. Also, 1. I believe that every committer has their reasons when applying the change, and I trust those reasons. 2. C-T-R still allows you to object, and also to revert the change immediately. It is just a question of whether we need three votes here. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920580 - in /tomcat: tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java
Author: kkolinko Date: Tue Mar 9 00:04:30 2010 New Revision: 920580 URL: http://svn.apache.org/viewvc?rev=920580&view=rev Log: JavaDoc correction C-T-R Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java?rev=920580&r1=920579&r2=920580&view=diff == --- tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java Tue Mar 9 00:04:30 2010 @@ -28,12 +28,12 @@ * webapp without the need for assembly all the webapp dependencies as jars in * WEB-INF/lib. * - * + * ** - * + * * * * This is not meant to be used for production. Modified: tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java?rev=920580&r1=920579&r2=920580&view=diff == --- tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java (original) +++ tomcat/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java Tue Mar 9 00:04:30 2010 @@ -29,12 +29,12 @@ * webapp without the need for assembly all the webapp dependencies as jars in * WEB-INF/lib. * - * + * ** * - * + * * * * This is not meant to be used for production. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org*
svn commit: r920596 - /tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
Author: kkolinko
Date: Tue Mar 9 00:43:23 2010
New Revision: 920596
URL: http://svn.apache.org/viewvc?rev=920596&view=rev
Log:
Amendment for BZ 48668 fixes.
Use setter methods that accept String value to set pageInfo properties.
Throw an exception if tagInfo is not available for a tag file or
requiredVersion is not parseable. (Both of that should not happen).
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=920596&r1=920595&r2=920596&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Mar 9
00:43:23 2010
@@ -152,18 +152,19 @@
JspUtil.booleanValue(
jspProperty.isErrorOnUndeclaredNamespace()));
}
-if (ctxt.getTagInfo() != null) {
+if (ctxt.isTagFile()) {
try {
double libraryVersion = Double.parseDouble(ctxt.getTagInfo()
.getTagLibrary().getRequiredVersion());
if (libraryVersion < 2.0) {
-pageInfo.setELIgnored(true);
+pageInfo.setIsELIgnored("true", null, errDispatcher, true);
}
if (libraryVersion < 2.1) {
-pageInfo.setDeferredSyntaxAllowedAsLiteral(true);
+pageInfo.setDeferredSyntaxAllowedAsLiteral("true", null,
+errDispatcher, true);
}
} catch (NumberFormatException ex) {
-// ignored
+errDispatcher.jspError(ex);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
Overall, We'd be better off leaving everything as it is.
6.0.24 had a huge amount of changes, and also a series of rapid
regressions, and probably more to follow.
To keep the branch stable, we should work in a stable manner, RTC has
worked well for that
Filip
On 03/08/2010 10:34 AM, Konstantin Kolinko wrote:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
+1
3. I think that we can have C-T-R for any whitespace changes in the
code. These are generally discouraged, but might be necessary to ease
backporting of patches.
-1, makes tracing down when and how code changed a pain in the rear.
It's not beneficial.
Note, that whitespace-only changes
a) can be verified in viewvc when viewing the committed patch in
"Colored Diff" mode. E.g.,
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
b) can be verified by svn diff command:
svn diff -x -w
will generate a patch ignoring all whitespace changes.
Whitespace changes can hinder applying other patches, generated before
them. As for line numbers, e.g. when deciphering stack traces, we can
always look at the SVN tags that we have from the releases.
I am +1 for C-T-R these.
4. Trivial fixes for any English message strings and message constants
in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
those.
Adding/removing parameters, and changing code that displays these
messages is not a trivial change.
Things to beware here are single quotes and '{}' brackets. If message
string does not have arguments, it is used as is, and those symbols
have no special meaning. If it does have arguments, those symbols
have special meaning. E.g., there will be an exception if there is
'{}' that does not contain a number and is not inside single quotes.
5. Any fixes for any translations.
I cannot review the textual part of the changes, only the technical
part, and that can be as well done looking at the commit email.
The risks here are not very high, as tomcat-i18n-*.jar files do not
contain any code in them and can be fixed without recompiling.
The technical requirement here is that
all *.properties files should contain only 7-bit characters. All
others should be \u escaped. The program to perform such
conversion is native2ascii.
For consistency, there should be end-of-line character on the last
line of the file (as native2ascii always adds it).
The specification (JavaDoc for java.util.Properties) says that the
files are technically in ISO-8859-1, but, as was discussed around a
year ago, we should not allow 8-bit characters from the upper part of
ISO-8859-1 charset. The reasons that I remember are:
1). Some IDEs (or IDE plugins) have configuration where by default
they are reading *.properties files not in ISO-8859-1, but in the
system default encoding. Thus, if the file has character from the
upper part of ISO-8859-1, they can be read incorrectly. My own story
of observing this was with the PropertiesEditor Plugin for EclipseIDE
I suppose that using system encoding by default have some meaning.
E.g. when running native2ascii before opening the file in the IDE this
setting will allow to open them correctly.
2). We had some files in ISO-8859-1, some in Windows-1252, some in
UTF-8. There should have been some reason why that happened.
That said, I am +1 for C-T-R for any translation fixes.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing "C-T-R" or "trivial" in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/08/2010 12:00 PM, Konstantin Kolinko wrote:
I propose to relax our RTC policy and use CTR for the types of changes
listed below:
2010/3/8 Konstantin Kolinko:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
Already decided. No need to vote.
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
Allow C-T-R for changes to svn properties:
[ ] +1
[X] 0
[ ] -1
3. I think that we can have C-T-R for any whitespace changes in the
code. These are generally discouraged, but might be necessary to ease
backporting of patches.
Note, that whitespace-only changes
a) can be verified in viewvc when viewing the committed patch in
"Colored Diff" mode. E.g.,
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
b) can be verified by svn diff command:
svn diff -x -w
will generate a patch ignoring all whitespace changes.
Whitespace changes can hinder applying other patches, generated before
them. As for line numbers, e.g. when deciphering stack traces, we can
always look at the SVN tags that we have from the releases.
I am +1 for C-T-R these.
Allow C-T-R for any whitespace changes:
[ ] +1
[ ] 0
[X] -1
4. Trivial fixes for any English message strings and message constants
in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
those.
Adding/removing parameters, and changing code that displays these
messages is not a trivial change.
Things to beware here are single quotes and '{}' brackets. If message
string does not have arguments, it is used as is, and those symbols
have no special meaning. If it does have arguments, those symbols
have special meaning. E.g., there will be an exception if there is
'{}' that does not contain a number and is not inside single quotes.
Allow C-T-R for trivial fixes to English messages that are in resource files
and those that are inline in the code. This includes typos and rephrasing,
but does not include adding/removing message parameters.
Technical issues to beware are mentioned above.
[ ] +1
[X] 0
[ ] -1
5. Any fixes for any translations.
I cannot review the textual part of the changes, only the technical
part, and that can be as well done looking at the commit email.
The risks here are not very high, as tomcat-i18n-*.jar files do not
contain any code in them and can be fixed without recompiling.
The technical requirement here is that
all *.properties files should contain only 7-bit characters. All
others should be \u escaped. The program to perform such
conversion is native2ascii.
For consistency, there should be end-of-line character on the last
line of the file (as native2ascii always adds it).
The specification (JavaDoc for java.util.Properties) says that the
files are technically in ISO-8859-1, but, as was discussed around a
year ago, we should not allow 8-bit characters from the upper part of
ISO-8859-1 charset. The reasons that I remember are:
1). Some IDEs (or IDE plugins) have configuration where by default
they are reading *.properties files not in ISO-8859-1, but in the
system default encoding. Thus, if the file has character from the
upper part of ISO-8859-1, they can be read incorrectly. My own story
of observing this was with the PropertiesEditor Plugin for EclipseIDE
I suppose that using system encoding by default have some meaning.
E.g. when running native2ascii before opening the file in the IDE this
setting will allow to open them correctly.
2). We had some files in ISO-8859-1, some in Windows-1252, some in
UTF-8. There should have been some reason why that happened.
That said, I am +1 for C-T-R for any translation fixes.
Allow C-T-R for any fixes for non-English resource files.
The files must use 7-bit characters only. Other symbols must be
escaped with \u, as does native2ascii.
[ ] +1
[X] 0
[ ] -1
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing "C-T-R" or "trivial" in the message?
This is not mandatory, but I would prefer some indication in the
commit message, that it was done using CTR rule. I propose to write
"C-T-R", but I wouldn't mind if others will write just "trivial" or
something like that.
Require some indication in the commit message for code that usually is
covered by RTC, that this commit was done using C-T-R rule.
[ ] +1
[X] 0
[ ] -1
My own votes for 2.,3.,4.,5. are +1, but for 6. my vote is -0.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920608 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Author: kkolinko
Date: Tue Mar 9 01:28:14 2010
New Revision: 920608
URL: http://svn.apache.org/viewvc?rev=920608&view=rev
Log:
Revert r920110
Compatibility with JSP 1.2 tag libraries had to be covered by JSP 2.0
specification,
see "Backwards Compatibility with JSP 1.2" in the Preface part of JSP 2.0
specification,
and there is no provision for this feature.
Discussed in the Re: r920055 thread on dev@
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Validator.java?rev=920608&r1=920607&r2=920608&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Tue Mar 9
01:28:14 2010
@@ -1077,15 +1077,12 @@ class Validator {
boolean deferred = false;
double libraryVersion = Double.parseDouble(
tagInfo.getTagLibrary().getRequiredVersion());
-boolean elIgnored =
-pageInfo.isELIgnored() ||
-libraryVersion < 2.0;
boolean deferredSyntaxAllowedAsLiteral =
pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
libraryVersion < 2.1;
ELNode.Nodes el = null;
-if (!runtimeExpression && !elIgnored) {
+if (!runtimeExpression && !pageInfo.isELIgnored()) {
el = ELParser.parse(attrs.getValue(i),
deferredSyntaxAllowedAsLiteral);
Iterator nodes = el.iterator();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920632 - in /tomcat/trunk/test: org/apache/jasper/compiler/ webapp-2.4/WEB-INF/ webapp-2.5/WEB-INF/ webapp-3.0/WEB-INF/
Author: kkolinko
Date: Tue Mar 9 02:58:50 2010
New Revision: 920632
URL: http://svn.apache.org/viewvc?rev=920632&view=rev
Log:
Updated the tests because r920110 was reverted in r920608.
Modified:
tomcat/trunk/test/org/apache/jasper/compiler/TestValidator.java
tomcat/trunk/test/webapp-2.4/WEB-INF/tags11.tld
tomcat/trunk/test/webapp-2.4/WEB-INF/tags12.tld
tomcat/trunk/test/webapp-2.5/WEB-INF/tags11.tld
tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld
tomcat/trunk/test/webapp-3.0/WEB-INF/tags11.tld
tomcat/trunk/test/webapp-3.0/WEB-INF/tags12.tld
Modified: tomcat/trunk/test/org/apache/jasper/compiler/TestValidator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/jasper/compiler/TestValidator.java?rev=920632&r1=920631&r2=920632&view=diff
==
--- tomcat/trunk/test/org/apache/jasper/compiler/TestValidator.java (original)
+++ tomcat/trunk/test/org/apache/jasper/compiler/TestValidator.java Tue Mar 9
02:58:50 2010
@@ -91,9 +91,9 @@ public class TestValidator extends Tomca
String result = res.toString();
-assertTrue(result.indexOf("${'00-hello world'}") > 0);
+assertTrue(result.indexOf("00-hello world") > 0);
assertTrue(result.indexOf("#{'01-hello world'}") > 0);
-assertTrue(result.indexOf("${'02-hello world'}") > 0);
+assertTrue(result.indexOf("02-hello world") > 0);
assertTrue(result.indexOf("#{'03-hello world'}") > 0);
assertTrue(result.indexOf("04-hello world") > 0);
assertTrue(result.indexOf("#{'05-hello world'}") > 0);
@@ -116,9 +116,9 @@ public class TestValidator extends Tomca
String result = res.toString();
-assertTrue(result.indexOf("${'00-hello world'}") > 0);
+assertTrue(result.indexOf("00-hello world") > 0);
assertTrue(result.indexOf("#{'01-hello world'}") > 0);
-assertTrue(result.indexOf("${'02-hello world'}") > 0);
+assertTrue(result.indexOf("02-hello world") > 0);
assertTrue(result.indexOf("#{'03-hello world'}") > 0);
assertTrue(result.indexOf("04-hello world") > 0);
assertTrue(result.indexOf("#{'05-hello world'}") > 0);
@@ -141,9 +141,9 @@ public class TestValidator extends Tomca
String result = res.toString();
-assertTrue(result.indexOf("${'00-hello world'}") > 0);
+assertTrue(result.indexOf("00-hello world") > 0);
assertTrue(result.indexOf("#{'01-hello world'}") > 0);
-assertTrue(result.indexOf("${'02-hello world'}") > 0);
+assertTrue(result.indexOf("02-hello world") > 0);
assertTrue(result.indexOf("#{'03-hello world'}") > 0);
assertTrue(result.indexOf("04-hello world") > 0);
assertTrue(result.indexOf("#{'05-hello world'}") > 0);
Modified: tomcat/trunk/test/webapp-2.4/WEB-INF/tags11.tld
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-2.4/WEB-INF/tags11.tld?rev=920632&r1=920631&r2=920632&view=diff
==
--- tomcat/trunk/test/webapp-2.4/WEB-INF/tags11.tld (original)
+++ tomcat/trunk/test/webapp-2.4/WEB-INF/tags11.tld Tue Mar 9 02:58:50 2010
@@ -30,6 +30,7 @@
echo
yes
+ true
Modified: tomcat/trunk/test/webapp-2.4/WEB-INF/tags12.tld
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-2.4/WEB-INF/tags12.tld?rev=920632&r1=920631&r2=920632&view=diff
==
--- tomcat/trunk/test/webapp-2.4/WEB-INF/tags12.tld (original)
+++ tomcat/trunk/test/webapp-2.4/WEB-INF/tags12.tld Tue Mar 9 02:58:50 2010
@@ -25,11 +25,12 @@
Echo
-org.apache.jasper.compiler.TestValidator$Echo
+org.apache.jasper.compiler.TestValidator$Echo
empty
echo
yes
+ true
Modified: tomcat/trunk/test/webapp-2.5/WEB-INF/tags11.tld
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-2.5/WEB-INF/tags11.tld?rev=920632&r1=920631&r2=920632&view=diff
==
--- tomcat/trunk/test/webapp-2.5/WEB-INF/tags11.tld (original)
+++ tomcat/trunk/test/webapp-2.5/WEB-INF/tags11.tld Tue Mar 9 02:58:50 2010
@@ -30,6 +30,7 @@
echo
yes
+ true
Modified: tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld?rev=920632&r1=920631&r2=920632&view=diff
==
--- tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld (original)
+++ tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld Tue Mar 9 02:58:50 2010
@@ -25,11 +25,12 @@
Echo
-org.apache.jasper.compiler.TestValidator$Echo
+org.apache.jasper.compiler.TestValidator$Echo
empty
echo
yes
+ true
DO NOT REPLY [Bug 47242] request for AJP command line client
https://issues.apache.org/bugzilla/show_bug.cgi?id=47242 --- Comment #12 from chamith buddhika 2010-03-09 03:01:22 UTC --- Created an attachment (id=25106) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25106) AJP Client Bug Fix Version After some debugging I was able to fix the issue above mentioned by Ken. I am attaching new version with this. Any suggestions are welcome. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
2010/3/8 Konstantin Kolinko :
> 2010/3/8 Mark Thomas :
>> On 07/03/2010 21:26, Konstantin Kolinko wrote:
>>>
>>> Re: r920110:
>>> (...)
>>> I see no provision in the spec for the above change.
>>>
>>> The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
>>> does say that only about #{} expressions.
>>>
>>> The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
>>> (page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
>>> (page 123/478) do not mention that either.
>>
>> The TCK passes either way. Given that the spec doesn't cover this and
>> neither does the TCK do we:
>> a) stick to the letter of the spec
>> b) treat isELIgnored and isDeferredSyntaxAllowedAsLiteral consistently
>>
>> I have a preference for b) but if the majority disagree I'm happy to revert.
>>
>
> Compatibility between JSP 2.0 and JSP 1.2 (aka isELIgnored) is covered
> by JSP 2.0 spec.
>
> See "Backwards Compatibility with JSP 1.2" in the preface section of
> JSP 2.0 spec (page 20 of 478)
>
> Among compatibility mechanisms mentioned there, using Tag Library
> version to switch EL processing in attributes is not mentioned.
>
> At that time the main concern for compatibility were users of JSTL 1.0.
>
> citing (page 22):
> "Users of JSTL 1.0 will need to either
> "upgrade their taglib imports to the JSTL 1.1 uris, or they will need to use
> the
> "_rt versions of the tags (e.g. c_rt instead of c, or fmt_rt instead of fmt).
> /citing.
>
One more evidence against r920110:
JSP 2.0 allows ${} expressions to be used for attributes that are
specified as true even for JSP 1.2 and
earlier tags.
That is an important use case.
BTW, r920110 changes only Validator, not Parser or JspDocumentParser.
I think that is why TCK did not catch it.
>> In a similar area on which the spec is silent, if I use a TLD that
>> declares it requires JSP 2.1 in a web applciation that declares servlet
>> 2.3 in web.xml is that an error? At the moment it works but it feels
>> wrong. Thoughts?
>
> An example of that I think will be the case when the tag library is
> provided by the container, and we deploy an application created for
> the older version of specification. If Tag library was updated, does
> its URL change, or is it still available under the old URL?
>
> I think that URL change between JSTL 1.0 and 1.1 was an exception, and
> the authors would like to avoid it in the future.
>
> Thus such deployment won't be an error.
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r920633 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Tue Mar 9 03:10:00 2010 New Revision: 920633 URL: http://svn.apache.org/viewvc?rev=920633&view=rev Log: Updated the second patch for bug 48668 Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=920633&r1=920632&r2=920633&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Mar 9 03:10:00 2010 @@ -108,23 +108,9 @@ PATCHES PROPOSED TO BACKPORT: +1: kkolinko, markt, jfclere -1: - 2) Fix for jasper.compiler.Validator - Fix jasper.compiler.Validator behaviour with regards to isELIgnored and - isDeferredSyntaxAllowedAsLiteral options. Do not try parsing EL when - isELIgnored = true. - Make jasper.compiler.ELParser aware about isDeferredSyntaxAllowedAsLiteral option. - Make default values of isDeferredSyntaxAllowedAsLiteral and isELIgnored - be determined by servlet spec version in web.xml or by jsp spec version - in TLD file. - Backport of r919914: - http://people.apache.org/~kkolinko/patches/2010-03-07_tc6_bug48668_r919914.patch - +1: kkolinko - +1: markt with http://svn.apache.org/viewvc?rev=920055&view=rev - -1: - kkolinko: +1 with 920055 - - 3) - http://people.apache.org/~kkolinko/patches/2010-03-07_tc7_48668_Compiler.patch + 2) Fix for jasper.compiler.Validator etc. + http://people.apache.org/~kkolinko/patches/2010-03-09_tc6_bug48668-2.patch + (Backport of r919914,920025,920055,920596) +1: kkolinko -1: @@ -135,13 +121,13 @@ PATCHES PROPOSED TO BACKPORT: +1: markt, jfclere -1: kkolinko: JSP 2.0 spec chapter "Backwards Compatibility with JSP 1.2" (page xx (20 of 478)) does not mention it. So I think it is against the spec. See r920055 thread on d...@. + I reverted it in trunk in r920608. * Improve log messages when a potential leak is detected by including the name of the offending context http://svn.apache.org/viewvc?view=revision&revision=920298 +1: markt, kkolinko -1: - kkolinko: I would prefer contextName to always be the 0th argument of the message * Another french translation problem (Submit by Henri Gomez): +++ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On Mon, Mar 8, 2010 at 2:00 PM, Konstantin Kolinko wrote: > Allow C-T-R for changes to svn properties: > [ ] +1 > [ X ] 0 > Allow C-T-R for any whitespace changes: > [ ] +1 > [ X ] 0 > Allow C-T-R for trivial fixes to English messages that are in resource files > and those that are inline in the code. This includes typos and rephrasing, > but does not include adding/removing message parameters. > Technical issues to beware are mentioned above. > [ X ] +1 > Allow C-T-R for any fixes for non-English resource files. > The files must use 7-bit characters only. Other symbols must be > escaped with \u, as does native2ascii. > [ X ] +1 > Require some indication in the commit message for code that usually is > covered by RTC, that this commit was done using C-T-R rule. > [ ] +1 > [ X ] 0 Yoav - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/09/2010 01:47 AM, Filip Hanik - Dev Lists wrote: > Overall, We'd be better off leaving everything as it is. > 6.0.24 had a huge amount of changes, and also a series of rapid > regressions, and probably more to follow. > To keep the branch stable, we should work in a stable manner, RTC has > worked well for that That is also what I am thinking, more eyes to spot errors warrants a more stable tomcat. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/09/2010 01:47 AM, Filip Hanik - Dev Lists wrote: Overall, We'd be better off leaving everything as it is. 6.0.24 had a huge amount of changes, and also a series of rapid regressions, and probably more to follow. To keep the branch stable, we should work in a stable manner, RTC has worked well for that Asking for a vote on a comment typo or code formatting is simply insane. I don't think that is the purpose of RTC policy. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
