DO NOT REPLY [Bug 48869] Intermitten SSL handshake failure | Appears that client (Tomcat) is unable to send the certificate chain back

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48869

hbajaj honeybaj...@rediffmail.com 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

2010-03-08 Thread timw
Author: timw
Date: Mon Mar  8 08:08:46 2010
New Revision: 920225

URL: http://svn.apache.org/viewvc?rev=920225view=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=920225r1=920224r2=920225view=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

2010-03-08 Thread jean-frederic clere
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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48869

Mark Thomas ma...@apache.org 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

2010-03-08 Thread Mladen Turk

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=920225view=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

2010-03-08 Thread Mark Thomas
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

2010-03-08 Thread Mladen Turk

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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48848

--- Comment #5 from Jose Miguel Samper jmigue...@yahoo.es 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

2010-03-08 Thread 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?

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

2010-03-08 Thread jfclere
Author: jfclere
Date: Mon Mar  8 09:36:47 2010
New Revision: 920247

URL: http://svn.apache.org/viewvc?rev=920247view=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=920247r1=920246r2=920247view=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=920110view=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

2010-03-08 Thread Rainer Jung

+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 Whittingtont...@apache.org  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 Jungrainer.j...@kippdata.dewrote:


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

2010-03-08 Thread Bharath Vasudevan
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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 10:14:44 2010
New Revision: 920257

URL: http://svn.apache.org/viewvc?rev=920257view=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=920257r1=920256r2=920257view=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

2010-03-08 Thread Bharath Vasudevan
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 bharath@gmail.comwrote:

 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-03-08 Thread Konstantin Kolinko
2010/3/8 Mark Thomas ma...@apache.org:
 On 07/03/2010 21:26, Konstantin Kolinko wrote:
 2010/3/7 Konstantin Kolinko knst.koli...@gmail.com:
 2010/3/7 Mark Thomas ma...@apache.org:
 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=920055view=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  ma...@apache.org:
 Author: markt
 Date: Sun Mar  7 20:54:01 2010
 New Revision: 920110

 URL: http://svn.apache.org/viewvc?rev=920110view=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);
                     IteratorELNode 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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Mon Mar  8 10:55:28 2010
New Revision: 920265

URL: http://svn.apache.org/viewvc?rev=920265view=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=920265r1=920264r2=920265view=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=920055view=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=920110view=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-03-08 Thread Konstantin Kolinko
2010/3/8 jean-frederic clere jfcl...@gmail.com:
 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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48600

--- Comment #11 from Philippe Prados apa...@prados.fr 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

2010-03-08 Thread jean-frederic clere
On 03/08/2010 12:01 PM, Konstantin Kolinko wrote:
 2010/3/8 jean-frederic clere jfcl...@gmail.com:
 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

2010-03-08 Thread mturk
Author: mturk
Date: Mon Mar  8 11:45:37 2010
New Revision: 920281

URL: http://svn.apache.org/viewvc?rev=920281view=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=920281r1=920280r2=920281view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 12:39:57 2010
New Revision: 920297

URL: http://svn.apache.org/viewvc?rev=920297view=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=920297r1=920296r2=920297view=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 @@
  * br
  * The valid state transitions for components that support Lifecycle are:
  * pre
- *  --
- *  | |
- * 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=920297r1=920296r2=920297view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 12:45:56 2010
New Revision: 920298

URL: http://svn.apache.org/viewvc?rev=920298view=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=920298r1=920297r2=920298view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 12:48:22 2010
New Revision: 920305

URL: http://svn.apache.org/viewvc?rev=920305view=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=920305r1=920304r2=920305view=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=revisionrevision=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

2010-03-08 Thread Mark Thomas
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-03-08 Thread Henri Gomez
2010/3/6 Mark Thomas ma...@apache.org:
 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

2010-03-08 Thread 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 rainer.j...@kippdata.de:
 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

2010-03-08 Thread Henri Gomez
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 henri.go...@gmail.com:
 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 rainer.j...@kippdata.de:
 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

2010-03-08 Thread jfclere
Author: jfclere
Date: Mon Mar  8 16:29:48 2010
New Revision: 920390

URL: http://svn.apache.org/viewvc?rev=920390view=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=920390r1=920389r2=920390view=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=revisionrevision=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

2010-03-08 Thread fhanik
Author: fhanik
Date: Mon Mar  8 16:38:35 2010
New Revision: 920392

URL: http://svn.apache.org/viewvc?rev=920392view=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=920392r1=920391r2=920392view=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=920392r1=920391r2=920392view=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=920392r1=920391r2=920392view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 17:22:33 2010
New Revision: 920410

URL: http://svn.apache.org/viewvc?rev=920410view=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=920410r1=920409r2=920410view=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(
 SetSessionTrackingMode 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 T extends EventListener 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

2010-03-08 Thread Konstantin Kolinko
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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread 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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 17:59:51 2010
New Revision: 920422

URL: http://svn.apache.org/viewvc?rev=920422view=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=920422r1=920421r2=920422view=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
 
-SetString newGroupDNs = new HashSetString(groupMap.keySet());
-while (!newGroupDNs.isEmpty()) {
-SetString newThisRound = new HashSetString(); // Stores 
the groups we find in this iteration
+MapString, String newGroups = new 
HashMapString,String(groupMap);
+while (!newGroups.isEmpty()) {
+MapString, String newThisRound = new HashMapString, 
String(); // Stores the groups we find in this iteration
 
-for (String groupDN : newGroupDNs) {
-filter = roleFormat.format(new String[] { groupDN });
+for (EntryString, String 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=920422r1=920421r2=920422view=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 @@
 listrongroleName/strong - the attribute in a role entry
  containing the name of that role./li
 
+listrongroleNested/strong - enable nested roles. Set to
+ codetrue/code 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 codefalse/code./li
+
 /ul
 
 /li



-
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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 18:01:51 2010
New Revision: 920423

URL: http://svn.apache.org/viewvc?rev=920423view=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=920423r1=920422r2=920423view=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})

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48629

--- Comment #6 from Mark Thomas ma...@apache.org 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

2010-03-08 Thread Henri Gomez
CTR for non code area in TC : +1

2010/3/8 Mladen Turk mt...@apache.org:
 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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 18:58:28 2010
New Revision: 920449

URL: http://svn.apache.org/viewvc?rev=920449view=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=920449r1=920448r2=920449view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 19:00:05 2010
New Revision: 920455

URL: http://svn.apache.org/viewvc?rev=920455view=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=920455r1=920454r2=920455view=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=920422view=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=920449view=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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48661

--- Comment #1 from Mark Thomas ma...@apache.org 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

2010-03-08 Thread Konstantin Kolinko
I propose to relax our RTC policy and use CTR for the types of changes
listed below:

2010/3/8 Konstantin Kolinko knst.koli...@gmail.com:
 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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 19:00:57 2010
New Revision: 920456

URL: http://svn.apache.org/viewvc?rev=920456view=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=920456r1=920455r2=920456view=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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Mon Mar  8 19:42:09 2010
New Revision: 920479

URL: http://svn.apache.org/viewvc?rev=920479view=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=920479r1=920478r2=920479view=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=920422view=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=920449view=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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48685

Mark Thomas ma...@apache.org changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from Mark Thomas ma...@apache.org 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



Re: [VOTE] C-T-R for any translation fixes

2010-03-08 Thread Mladen Turk

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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 20:59:18 2010
New Revision: 920506

URL: http://svn.apache.org/viewvc?rev=920506view=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=920506r1=920505r2=920506view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 21:53:29 2010
New Revision: 920532

URL: http://svn.apache.org/viewvc?rev=920532view=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:getProperty - 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=920532r1=920531r2=920532view=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

2010-03-08 Thread markt
Author: markt
Date: Mon Mar  8 21:55:37 2010
New Revision: 920534

URL: http://svn.apache.org/viewvc?rev=920534view=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=920534r1=920533r2=920534view=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=920449view=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:getProperty - JSP.5.3
+  http://svn.apache.org/viewvc?rev=920532view=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

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=48701

--- Comment #6 from Mark Thomas ma...@apache.org 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

2010-03-08 Thread Rainer Jung

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-03-08 Thread Konstantin Kolinko
2010/3/8 Mladen Turk mt...@apache.org:
 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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Tue Mar  9 00:04:30 2010
New Revision: 920580

URL: http://svn.apache.org/viewvc?rev=920580view=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=920580r1=920579r2=920580view=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.
  *
- * code
+ * pre
  * lt;Context docBase=\webapps\mydocbase
  *   lt;Loader className=org.apache.catalina.loader.VirtualWebappLoader
  *  virtualClasspath=\dir\classes;\somedir\somejar.jar/
  * lt;/Context
- * /code
+ * /pre
  *
  *
  * strongThis 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=920580r1=920579r2=920580view=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.
  *
- * code
+ * pre
  * lt;Context docBase=\webapps\mydocbase
  *   lt;Loader className=org.apache.catalina.loader.VirtualWebappLoader
  *  virtualClasspath=\dir\classes;\somedir\somejar.jar/
  * lt;/Context
- * /code
+ * /pre
  *
  *
  * strongThis 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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Tue Mar  9 00:43:23 2010
New Revision: 920596

URL: http://svn.apache.org/viewvc?rev=920596view=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=920596r1=920595r2=920596view=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

2010-03-08 Thread Filip Hanik - Dev Lists

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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread Filip Hanik - Dev Lists

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 Kolinkoknst.koli...@gmail.com:
   

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=896544r2=896543pathrev=896544diff_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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Tue Mar  9 01:28:14 2010
New Revision: 920608

URL: http://svn.apache.org/viewvc?rev=920608view=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=920608r1=920607r2=920608view=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);
 IteratorELNode 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/

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Tue Mar  9 02:58:50 2010
New Revision: 920632

URL: http://svn.apache.org/viewvc?rev=920632view=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=920632r1=920631r2=920632view=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(p${'00-hello world'}/p)  0);
+assertTrue(result.indexOf(p00-hello world/p)  0);
 assertTrue(result.indexOf(p#{'01-hello world'}/p)  0);
-assertTrue(result.indexOf(p${'02-hello world'}/p)  0);
+assertTrue(result.indexOf(p02-hello world/p)  0);
 assertTrue(result.indexOf(p#{'03-hello world'}/p)  0);
 assertTrue(result.indexOf(p04-hello world/p)  0);
 assertTrue(result.indexOf(p#{'05-hello world'}/p)  0);
@@ -116,9 +116,9 @@ public class TestValidator extends Tomca
 
 String result = res.toString();
 
-assertTrue(result.indexOf(p${'00-hello world'}/p)  0);
+assertTrue(result.indexOf(p00-hello world/p)  0);
 assertTrue(result.indexOf(p#{'01-hello world'}/p)  0);
-assertTrue(result.indexOf(p${'02-hello world'}/p)  0);
+assertTrue(result.indexOf(p02-hello world/p)  0);
 assertTrue(result.indexOf(p#{'03-hello world'}/p)  0);
 assertTrue(result.indexOf(p04-hello world/p)  0);
 assertTrue(result.indexOf(p#{'05-hello world'}/p)  0);
@@ -141,9 +141,9 @@ public class TestValidator extends Tomca
 
 String result = res.toString();
 
-assertTrue(result.indexOf(p${'00-hello world'}/p)  0);
+assertTrue(result.indexOf(p00-hello world/p)  0);
 assertTrue(result.indexOf(p#{'01-hello world'}/p)  0);
-assertTrue(result.indexOf(p${'02-hello world'}/p)  0);
+assertTrue(result.indexOf(p02-hello world/p)  0);
 assertTrue(result.indexOf(p#{'03-hello world'}/p)  0);
 assertTrue(result.indexOf(p04-hello world/p)  0);
 assertTrue(result.indexOf(p#{'05-hello world'}/p)  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=920632r1=920631r2=920632view=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 @@
 attribute
   nameecho/name
   requiredyes/required
+  rtexprvaluetrue/rtexprvalue
 /attribute
   /tag
 

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=920632r1=920631r2=920632view=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 @@
 
   tag
 nameEcho/name
-tagclassorg.apache.jasper.compiler.TestValidator$Echo/tagclass
+tag-classorg.apache.jasper.compiler.TestValidator$Echo/tag-class
 body-contentempty/body-content
 attribute
   nameecho/name
   requiredyes/required
+  rtexprvaluetrue/rtexprvalue
 /attribute
   /tag
 

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=920632r1=920631r2=920632view=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 @@
 attribute
   nameecho/name
   requiredyes/required
+  rtexprvaluetrue/rtexprvalue
 /attribute
   /tag
 

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=920632r1=920631r2=920632view=diff
==
--- tomcat/trunk/test/webapp-2.5/WEB-INF/tags12.tld 

DO NOT REPLY [Bug 47242] request for AJP command line client

2010-03-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=47242

--- Comment #12 from chamith buddhika chamibuddh...@gmail.com 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-03-08 Thread Konstantin Kolinko
2010/3/8 Konstantin Kolinko knst.koli...@gmail.com:
 2010/3/8 Mark Thomas ma...@apache.org:
 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 rtexprvaluetrue/rtexprvalue 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

2010-03-08 Thread kkolinko
Author: kkolinko
Date: Tue Mar  9 03:10:00 2010
New Revision: 920633

URL: http://svn.apache.org/viewvc?rev=920633view=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=920633r1=920632r2=920633view=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=920055view=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=revisionrevision=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

2010-03-08 Thread Yoav Shapira
On Mon, Mar 8, 2010 at 2:00 PM, Konstantin Kolinko
knst.koli...@gmail.com 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

2010-03-08 Thread jean-frederic clere
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

2010-03-08 Thread Mladen Turk

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