Re: Tagging mod_jk 1.2.38

[Rainer Jung]

On 24.02.2014 07:49, Mladen Turk wrote:
> Hi,
> I plan to tag mod_jk 1.2.38 tomorrow and start release process

+1, thanks.

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1571190 - /tomcat/jk/trunk/native/scripts/build/unix/config.guess

[mturk]

Author: mturk
Date: Mon Feb 24 09:09:25 2014
New Revision: 1571190

URL: http://svn.apache.org/r1571190
Log:
Update GNU's config.guess to the one used with APR

Modified:
tomcat/jk/trunk/native/scripts/build/unix/config.guess

Modified: tomcat/jk/trunk/native/scripts/build/unix/config.guess
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/scripts/build/unix/config.guess?rev=1571190&r1=1571189&r2=1571190&view=diff
==
--- tomcat/jk/trunk/native/scripts/build/unix/config.guess (original)
+++ tomcat/jk/trunk/native/scripts/build/unix/config.guess Mon Feb 24 09:09:25 
2014
@@ -1,14 +1,12 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
-#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-#   2011, 2012 Free Software Foundation, Inc.
+#   Copyright 1992-2013 Free Software Foundation, Inc.
 
-timestamp='2012-02-10'
+timestamp='2013-06-10'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
+# the Free Software Foundation; either version 3 of the License, or
 # (at your option) any later version.
 #
 # This program is distributed in the hope that it will be useful, but
@@ -22,19 +20,17 @@ timestamp='2012-02-10'
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
 # configuration script generated by Autoconf, you may include it under
-# the same distribution terms that you use for the rest of that program.
-
-
-# Originally written by Per Bothner.  Please send patches (context
-# diff format) to  and include a ChangeLog
-# entry.
+# the same distribution terms that you use for the rest of that
+# program.  This Exception is an additional permission under section 7
+# of the GNU General Public License, version 3 ("GPLv3").
 #
-# This script attempts to guess a canonical system name similar to
-# config.sub.  If it succeeds, it prints the system name on stdout, and
-# exits with 0.  Otherwise, it exits with 1.
+# Originally written by Per Bothner.
 #
 # You can get the latest version of this script from:
 # 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
+#
+# Please send patches with a ChangeLog entry to config-patc...@gnu.org.
+
 
 me=`echo "$0" | sed -e 's,.*/,,'`
 
@@ -54,9 +50,7 @@ version="\
 GNU config.guess ($timestamp)
 
 Originally written by Per Bothner.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-Free Software Foundation, Inc.
+Copyright 1992-2013 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -138,6 +132,27 @@ UNAME_RELEASE=`(uname -r) 2>/dev/null` |
 UNAME_SYSTEM=`(uname -s) 2>/dev/null`  || UNAME_SYSTEM=unknown
 UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
 
+case "${UNAME_SYSTEM}" in
+Linux|GNU|GNU/*)
+   # If the system lacks a compiler, then just pick glibc.
+   # We could probably try harder.
+   LIBC=gnu
+
+   eval $set_cc_for_build
+   cat <<-EOF > $dummy.c
+   #include 
+   #if defined(__UCLIBC__)
+   LIBC=uclibc
+   #elif defined(__dietlibc__)
+   LIBC=dietlibc
+   #else
+   LIBC=gnu
+   #endif
+   EOF
+   eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'`
+   ;;
+esac
+
 # Note: order is significant - the case branches are not exclusive.
 
 case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
@@ -200,6 +215,10 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
echo "${machine}-${os}${release}"
exit ;;
+*:Bitrig:*:*)
+   UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'`
+   echo ${UNAME_MACHINE_ARCH}-unknown-bitrig${UNAME_RELEASE}
+   exit ;;
 *:OpenBSD:*:*)
UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
echo ${UNAME_MACHINE_ARCH}-unknown-openbsd${UNAME_RELEASE}
@@ -302,7 +321,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
echo arm-acorn-riscix${UNAME_RELEASE}
exit ;;
-arm:riscos:*:*|arm:RISCOS:*:*)
+arm*:riscos:*:*|arm*:RISCOS:*:*)
echo arm-unknown-riscos
exit ;;
 SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
@@ -801,6 +820,9 @@ EOF
 i*:CYGWIN*:*)
echo ${UNAME_MACHINE}-pc-cygwin
exit ;;
+*:MINGW64*:*)
+   echo ${UNAME_MACHINE}-pc-mingw64
+   exit ;;
 *:MINGW*:*)
echo ${UNAME_MACHINE}-pc-mingw32
exit ;;
@@ -852,21 +874,21 @@ EOF
exit ;;
 *:GNU

svn commit: r1571191 - /tomcat/jk/trunk/native/scripts/build/unix/config.sub

[mturk]

Author: mturk
Date: Mon Feb 24 09:10:22 2014
New Revision: 1571191

URL: http://svn.apache.org/r1571191
Log:
Update GNU's config.sub to the one used with APR

Modified:
tomcat/jk/trunk/native/scripts/build/unix/config.sub

Modified: tomcat/jk/trunk/native/scripts/build/unix/config.sub
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/scripts/build/unix/config.sub?rev=1571191&r1=1571190&r2=1571191&view=diff
==
--- tomcat/jk/trunk/native/scripts/build/unix/config.sub (original)
+++ tomcat/jk/trunk/native/scripts/build/unix/config.sub Mon Feb 24 09:10:22 
2014
@@ -1,24 +1,18 @@
 #! /bin/sh
 # Configuration validation subroutine script.
-#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-#   2011, 2012 Free Software Foundation, Inc.
-
-timestamp='2012-04-18'
-
-# This file is (in principle) common to ALL GNU software.
-# The presence of a machine in this file suggests that SOME GNU software
-# can handle that machine.  It does not imply ALL GNU software can.
-#
-# This file is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
+#   Copyright 1992-2013 Free Software Foundation, Inc.
+
+timestamp='2013-10-01'
+
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
 # (at your option) any later version.
 #
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, see .
@@ -26,11 +20,12 @@ timestamp='2012-04-18'
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
 # configuration script generated by Autoconf, you may include it under
-# the same distribution terms that you use for the rest of that program.
+# the same distribution terms that you use for the rest of that
+# program.  This Exception is an additional permission under section 7
+# of the GNU General Public License, version 3 ("GPLv3").
 
 
-# Please send patches to .  Submit a context
-# diff and a properly formatted GNU ChangeLog entry.
+# Please send patches with a ChangeLog entry to config-patc...@gnu.org.
 #
 # Configuration subroutine to validate and canonicalize a configuration type.
 # Supply the specified configuration type as an argument.
@@ -73,9 +68,7 @@ Report bugs and patches to 

svn commit: r1571196 - /tomcat/trunk/webapps/docs/security-howto.xml

[markt]

Author: markt
Date: Mon Feb 24 09:28:24 2014
New Revision: 1571196

URL: http://svn.apache.org/r1571196
Log:
Fix typos

Modified:
tomcat/trunk/webapps/docs/security-howto.xml

Modified: tomcat/trunk/webapps/docs/security-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/security-howto.xml?rev=1571196&r1=1571195&r2=1571196&view=diff
==
--- tomcat/trunk/webapps/docs/security-howto.xml (original)
+++ tomcat/trunk/webapps/docs/security-howto.xml Mon Feb 24 09:28:24 2014
@@ -55,11 +55,11 @@
 the Tomcat process and provide that user with the minimum necessary
 permissions for the operating system. For example, it should not be 
possible
 to log on remotely using the Tomcat user.
-File permissions should also be suitable restricted. Taking the Tomcat
+File permissions should also be suitably restricted. Taking the Tomcat
 instances at the ASF as an example (where auto-deployment is disabled and
 web applications are deployed as exploded directories), the standard
 configuration is to have all Tomcat files owned by root with group Tomcat
-and whilst owner has read/write priviliges, group only has read and world
+and whilst owner has read/write privileges, group only has read and world
 has no permissions. The exceptions are the logs, temp and work directory
 that are owned by the Tomcat user rather than root. This means that even if
 an attacker compromises the Tomcat process, they can't change the



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1571197 - /tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml

[markt]

Author: markt
Date: Mon Feb 24 09:29:25 2014
New Revision: 1571197

URL: http://svn.apache.org/r1571197
Log:
Fix typos

Modified:
tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml

Modified: tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml?rev=1571197&r1=1571196&r2=1571197&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml Mon Feb 24 09:29:25 
2014
@@ -55,11 +55,11 @@
 the Tomcat process and provide that user with the minimum necessary
 permissions for the operating system. For example, it should not be 
possible
 to log on remotely using the Tomcat user.
-File permissions should also be suitable restricted. Taking the Tomcat
+File permissions should also be suitably restricted. Taking the Tomcat
 instances at the ASF as an example (where auto-deployment is disabled and
 web applications are deployed as exploded directories), the standard
 configuration is to have all Tomcat files owned by root with group Tomcat
-and whilst owner has read/write priviliges, group only has read and world
+and whilst owner has read/write privileges, group only has read and world
 has no permissions. The exceptions are the logs, temp and work directory
 that are owned by the Tomcat user rather than root. This means that even if
 an attacker compromises the Tomcat process, they can't change the



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 56158] Socket.send kills JVM

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56158

mailtoa...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from mailtoa...@gmail.com ---
I have convinced my sysadmins to upgrade the tomcat and could not reproduce the
problem. Thanks for your help!

BTW: It's sad that there is no official pkg distribution. That would have made
that discussion a lot easier.

-- 
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

buildbot failure in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-7-trunk/builds/1781

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1571197
Blamelist: markt

BUILD FAILED: failed compile_1

sincerely,
 -The Buildbot

svn commit: r1571242 - /tomcat/trunk/java/org/apache/el/parser/ELParser.jjt

[markt]

Author: markt
Date: Mon Feb 24 11:13:26 2014
New Revision: 1571242

URL: http://svn.apache.org/r1571242
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56179
Supporting lambda expressions requires additional lookaheads to ensure the 
correct grammar is used.

Modified:
tomcat/trunk/java/org/apache/el/parser/ELParser.jjt

Modified: tomcat/trunk/java/org/apache/el/parser/ELParser.jjt
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/parser/ELParser.jjt?rev=1571242&r1=1571241&r2=1571242&view=diff
==
--- tomcat/trunk/java/org/apache/el/parser/ELParser.jjt (original)
+++ tomcat/trunk/java/org/apache/el/parser/ELParser.jjt Mon Feb 24 11:13:26 2014
@@ -112,7 +112,7 @@ void Semicolon() : {}
  */
 void Assignment() : {}
 {
-LOOKAHEAD(3) LambdaExpression() |
+LOOKAHEAD(4) LambdaExpression() |
 Choice() ( LOOKAHEAD(2)  Assignment() #Assign(2) )*
 }
 
@@ -323,7 +323,7 @@ void MethodParameters() #MethodParameter
  */
 void NonLiteral() : {}
 {
-LOOKAHEAD(3) LambdaExpressionOrInvocation()
+LOOKAHEAD(5) LambdaExpressionOrInvocation()
 |  Expression() 
 | LOOKAHEAD(( )?  ) Function()
 | Identifier()



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1571245 - in /tomcat/trunk: java/org/apache/el/parser/ELParser.java test/org/apache/el/parser/TestELParser.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Feb 24 11:18:37 2014
New Revision: 1571245

URL: http://svn.apache.org/r1571245
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56179
Re-generate parser
Add some test cases

Modified:
tomcat/trunk/java/org/apache/el/parser/ELParser.java
tomcat/trunk/test/org/apache/el/parser/TestELParser.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/el/parser/ELParser.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/parser/ELParser.java?rev=1571245&r1=1571244&r2=1571245&view=diff
==
--- tomcat/trunk/java/org/apache/el/parser/ELParser.java (original)
+++ tomcat/trunk/java/org/apache/el/parser/ELParser.java Mon Feb 24 11:18:37 
2014
@@ -222,7 +222,7 @@ public class ELParser/*@bgen(jjtree)*/im
  * Assignment
  */
   final public void Assignment() throws ParseException {
-if (jj_2_2(3)) {
+if (jj_2_2(4)) {
   LambdaExpression();
 } else {
   switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
@@ -1529,7 +1529,7 @@ public class ELParser/*@bgen(jjtree)*/im
  * For Grouped Operations, Identifiers, and Functions
  */
   final public void NonLiteral() throws ParseException {
-if (jj_2_6(3)) {
+if (jj_2_6(5)) {
   LambdaExpressionOrInvocation();
 } else {
   switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
@@ -2084,7 +2084,7 @@ public class ELParser/*@bgen(jjtree)*/im
 finally { jj_save(7, xla); }
   }
 
-  private boolean jj_3R_40() {
+  private boolean jj_3R_41() {
 Token xsp;
 xsp = jj_scanpos;
 if (jj_scan_token(39)) {
@@ -2094,47 +2094,53 @@ public class ELParser/*@bgen(jjtree)*/im
 return false;
   }
 
-  private boolean jj_3R_39() {
-if (jj_3R_43()) return true;
+  private boolean jj_3R_30() {
+if (jj_3R_22()) return true;
+return false;
+  }
+
+  private boolean jj_3R_40() {
+if (jj_3R_44()) return true;
 Token xsp;
 while (true) {
   xsp = jj_scanpos;
-  if (jj_3R_44()) { jj_scanpos = xsp; break; }
+  if (jj_3R_45()) { jj_scanpos = xsp; break; }
 }
 return false;
   }
 
-  private boolean jj_3R_106() {
-if (jj_3R_35()) return true;
+  private boolean jj_3R_107() {
+if (jj_3R_36()) return true;
 return false;
   }
 
-  private boolean jj_3R_104() {
-if (jj_3R_106()) return true;
+  private boolean jj_3R_105() {
+if (jj_3R_107()) return true;
 return false;
   }
 
-  private boolean jj_3R_42() {
+  private boolean jj_3R_43() {
 if (jj_scan_token(COMMA)) return true;
+if (jj_3R_38()) return true;
 return false;
   }
 
-  private boolean jj_3R_33() {
-if (jj_3R_39()) return true;
+  private boolean jj_3R_34() {
+if (jj_3R_40()) return true;
 Token xsp;
 while (true) {
   xsp = jj_scanpos;
-  if (jj_3R_40()) { jj_scanpos = xsp; break; }
+  if (jj_3R_41()) { jj_scanpos = xsp; break; }
 }
 return false;
   }
 
-  private boolean jj_3R_36() {
+  private boolean jj_3R_37() {
 if (jj_scan_token(COMMA)) return true;
 return false;
   }
 
-  private boolean jj_3R_34() {
+  private boolean jj_3R_35() {
 Token xsp;
 xsp = jj_scanpos;
 if (jj_scan_token(41)) {
@@ -2144,26 +2150,26 @@ public class ELParser/*@bgen(jjtree)*/im
 return false;
   }
 
-  private boolean jj_3R_98() {
+  private boolean jj_3R_99() {
 if (jj_scan_token(START_SET_OR_MAP)) return true;
 Token xsp;
 xsp = jj_scanpos;
-if (jj_3R_104()) jj_scanpos = xsp;
+if (jj_3R_105()) jj_scanpos = xsp;
 if (jj_scan_token(RBRACE)) return true;
 return false;
   }
 
-  private boolean jj_3R_103() {
-if (jj_3R_35()) return true;
+  private boolean jj_3R_104() {
+if (jj_3R_36()) return true;
 return false;
   }
 
   private boolean jj_3R_29() {
-if (jj_3R_33()) return true;
+if (jj_3R_34()) return true;
 Token xsp;
 while (true) {
   xsp = jj_scanpos;
-  if (jj_3R_34()) { jj_scanpos = xsp; break; }
+  if (jj_3R_35()) { jj_scanpos = xsp; break; }
 }
 return false;
   }
@@ -2175,31 +2181,31 @@ public class ELParser/*@bgen(jjtree)*/im
 return false;
   }
 
-  private boolean jj_3R_97() {
+  private boolean jj_3R_98() {
 if (jj_scan_token(LBRACK)) return true;
 Token xsp;
 xsp = jj_scanpos;
-if (jj_3R_103()) jj_scanpos = xsp;
+if (jj_3R_104()) jj_scanpos = xsp;
 if (jj_scan_token(RBRACK)) return true;
 return false;
   }
 
-  private boolean jj_3R_38() {
-if (jj_3R_37()) return true;
+  private boolean jj_3R_39() {
+if (jj_3R_38()) return true;
 Token xsp;
 while (true) {
   xsp = jj_scanpos;
-  if (jj_3R_42()) { jj_scanpos = xsp; break; }
+  if (jj_3R_43()) { jj_scanpos = xsp; break; }
 }
 return false;
   }
 
-  private boolean jj_3R_30() {
-if (jj_3R_35()) return true;
+  private boolean jj_3R_31() {
+if (jj_3R_36()) return true;
 Token xsp;
 while (true) {
   xsp = j

[Bug 56179] ParseException for EL expression "${((test == true))}"

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56179

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Thanks for the report. The parser was getting confused by the unnecessary
brackets and thought it was looking at a lambda expression. I have updated the
parser to fix this and an additional related issue as well as adding some test
cases to confirm the fix.

The fix will be included in 8.0.4 onwards.

-- 
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

buildbot success in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-trunk/builds/5532

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/trunk] 1571196
Blamelist: markt

Build succeeded!

sincerely,
 -The Buildbot

[Bug 56158] Socket.send kills JVM

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56158

--- Comment #4 from Christopher Schultz  ---
ASF can't support all the Linux distros, AIX, Solaris, the BSDs, Amiga, etc. We
do have an official package. It can be re-packaged by 3rd-party maintainers
(both Debian/apt and CentOS/yum have packages). They just tend to lag behind
because Tomcat does not issue patches for specific issues.

-- 
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

[Bug 56179] ParseException for EL expression "${((test == true))}"

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56179

--- Comment #2 from Holger Stenzhorn  ---
Great! Thanks for the quick fix.

-- 
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: Jasper Improvements

[Mark Thomas]

On 24/02/2014 02:10, Greg Wilkins wrote:
> On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes  wrote:
> 
>> I have been thinking about improvements to Jasper as well around better 
>> support for Servlet
>> 3.0 concepts. One area would be decoupling it from Tomcat, bootstrapping 
>> using an SCI as hinted
>> in ContextConfig. I'd also be interested in improving the Ant task as well, 
>> such as support
>> for pre-compiling a separate package that would be treated as a web fragment 
>> (including web.xml-less
>> pre-compilation, generating a web-fragment.xml rather than a web.xml snippet 
>> or potentially
>> eliminating the XML entirely if the generated code can be annotated with 
>> @WebServlet).
> 
> 
> Jeremy et al,
> 
> The Jetty project has been considering switching to directly consume the
> apache version of Jasper JSP.
> 
> However, there are some tomcat dependencies in jasper that means we cannot
> directly consume the jar produced by the apache project.We had assumed
> that there would be little interest here to make jasper separable so we had
> begun our own effort at github.  However, when I gave a heads up to
> priv...@tomcat.apache.org, I was pointed at Jeremy's email.  So if
> there is some interest here, then it would definitely be better to do this
> within apache rather than via an intermediate repository.

My own view is that I'm happy to look at each of the issues you raise.
I'd like the Tomcat code to be easy to re-use by other folks so if there
are changes we can make that simplify this then I am in favour of those.
That said, there is a balance to be struck. If the changes are very
invasive or impact performance then I'd be less likely to support them.

> What we have done so far is to create a github project at github:
> https://github.com/jetty-project/jasper-jsp. This project mounts the
> tomcat github repo as a subtree and removes everything that is not el,
> jasper or a used utility.   We've then changed a few hard tomcat
> dependencies to produce a container neutral version of jasper, which we
> then consume and specialise within a build of the jetty project (not yet at
> eclipse).  We have this working at the moment, but have not yet done any
> releases, so there are no indelible maven artefacts yet.  Nor have we done
> the IP clearance work to officially consume such an artefact within the
> eclipse project.
> 
> The changes that we made to make jasper neutral were:

Are we just talking about Tomcat 8 here?

>- Modified JuliLog LogFactory to use a ServiceLoader to find an
>implementation of Log.  Within the jetty project we add an impl of the Juli
>Log that logs to the jetty log and we set that as a service in our own jars
>META-INF.   Note that judging by some of the comments in the classes, there
>is not much desire to make logging discoverable?

Discoverable in the Commons Logging sense of the term is not something I
am a fan of. At the risk of opening a huge can of worms would now be a
good time to review the choice to implement JULI? There have been some
significant changes in the Java logging landscape since then. Would now
be a good time to switch to log4j2, slf4j, something else?

How would such a switch impact potential downstream users like Jetty?

>- We have replaced the InstanceManager with a pretty simple
>non-container version.   It does not do post construct or pre destroy, but
>don't think these are needed for Jasper.  I guess rather than replace the
>top level InstanceManager, it would be better to have a Jasper Instance
>manager that could be instantiated as the container specific version,
>perhaps also with a ServiceLoader?

The InstanceManagerFactory was intended to provide downstream users with
a way of injecting their own InstanceManager into Jasper. Is that not
sufficient? If not, what would you like to change?

>- We changed the jasper ServletContainerInitialiser to allow some
>pluggability of the scanner and we turned off ServiceLoader for it so that
>we can provide our own extension of it.

If I am looking at the right commit on GitHub, that change looks
reasonable to me.

>- We made the Tld scanning check for a prescanned list so that we can do
>the TLD discovery in our own scanning (rather than do another scan) and
>push those into jasper.   A  neutral version of Jasper could make scanning
>container specific and then most of the dependencies on tomcat utils could
>be removed.

No objections to this in principle.

>- We would also like to add the META-INF magic to make the resulting
>jars more OSGi consumable.

+1

See https://issues.apache.org/bugzilla/show_bug.cgi?id=52381

I'm more than happy to see the necessary OSGi info go into the JARs.
What has been missing to date is an automated way to make this happen.
No-one in the Tomcat devs appears to have the knowledge of a) what is
required and b) how it might be auto-generated. The offers of help so
far hav

[GitHub] tomcat pull request: Update service.bat

[Humbedooh]

Github user Humbedooh commented on the pull request:

https://github.com/apache/tomcat/pull/3#issuecomment-35882751
  
Should this pull request be closed then?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. To do so, please top-post your response.
If your project does not have this feature enabled and wishes so, or if the
feature is enabled but not working, please contact infrastructure at
infrastruct...@apache.org or file a JIRA ticket with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GitHub] tomcat pull request: Update service.bat

[Rainer Jung]

On 24.02.2014 13:47, Humbedooh wrote:
> Github user Humbedooh commented on the pull request:
> 
> https://github.com/apache/tomcat/pull/3#issuecomment-35882751
>   
> Should this pull request be closed then?

Test reply demanded by Humbedooh - please ignore.

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [GitHub] tomcat pull request: Update service.bat

[Rainer Jung]

top-post requested by Humbedohh - test, please ignore.

On 24.02.2014 13:47, Humbedooh wrote:
> Github user Humbedooh commented on the pull request:
> 
> https://github.com/apache/tomcat/pull/3#issuecomment-35882751
>   
> Should this pull request be closed then?
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. To do so, please top-post your response.
> If your project does not have this feature enabled and wishes so, or if the
> feature is enabled but not working, please contact infrastructure at
> infrastruct...@apache.org or file a JIRA ticket with INFRA.
> ---
> 
> -
> 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: r1571355 - in /tomcat/trunk: java/org/apache/jasper/compiler/TagLibraryInfoImpl.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Feb 24 17:10:59 2014
New Revision: 1571355

URL: http://svn.apache.org/r1571355
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56177
Handle dependency tracking for TLDs when using JspC with a tag library JAR that 
is located outside of the web application.

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java?rev=1571355&r1=1571354&r2=1571355&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java Mon 
Feb 24 17:10:59 2014
@@ -22,6 +22,7 @@ import java.io.StringWriter;
 import java.net.URI;
 import java.net.URISyntaxException;
 import java.net.URL;
+import java.net.URLConnection;
 import java.util.ArrayList;
 import java.util.Collection;
 import java.util.HashSet;
@@ -133,10 +134,36 @@ class TagLibraryInfoImpl extends TagLibr
 // Add the dependencies on the TLD to the referencing page
 PageInfo pageInfo = ctxt.createCompiler().getPageInfo();
 if (pageInfo != null) {
+// If the TLD is in a JAR, that JAR may not be part of the web
+// application
 String path = tldResourcePath.getWebappPath();
-// Add TLD (jar==null) / JAR (jar!=null) file to dependency list
-pageInfo.addDependant(path, ctxt.getLastModified(path));
+if (path != null) {
+// Add TLD (jar==null) / JAR (jar!=null) file to dependency 
list
+pageInfo.addDependant(path, ctxt.getLastModified(path));
+}
 if (jar != null) {
+if (path == null) {
+// JAR not in the web application so add it directly
+URL jarUrl = jar.getJarFileURL();
+long lastMod = -1;
+URLConnection urlConn = null;
+try {
+urlConn = jarUrl.openConnection();
+lastMod = urlConn.getLastModified();
+} catch (IOException ioe) {
+throw new JasperException(ioe);
+} finally {
+if (urlConn != null) {
+try {
+urlConn.getInputStream().close();
+} catch (IOException e) {
+// Ignore
+}
+}
+}
+pageInfo.addDependant(jarUrl.toExternalForm(),
+Long.valueOf(lastMod));
+}
 // Add TLD within the JAR to the dependency list
 String entryName = tldResourcePath.getEntryName();
 try {

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1571355&r1=1571354&r2=1571355&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Mon Feb 24 17:10:59 2014
@@ -99,6 +99,11 @@
 56179: Fix parsing of EL expressions that contain 
unnecessary
 parentheses. (markt)
   
+  
+56177: Handle dependency tracking for TLDs when using JspC
+with a tag library JAR that is located outside of the web application.
+(markt)
+  
 
   
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 56177] JSPC: NPE at org.apache.jasper.servlet.JspCServletContext.getResource(JspCServletContext.java:344)

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56177

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Thomas  ---
Thanks for the report. This has been fixed in 8.0.x and will be included in
8.0.4 onwards.

-- 
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

[Bug 56181] RemoteIpValve & RemoteIpFilter: HttpServletRequest.getRemoteHost() returns IP instead of hostname with enableLookups=true and x-forwarded-for header

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56181

--- Comment #2 from Mark Thomas  ---
I don't see any reason to differentiate between proxied and non-proxied
clients.

-- 
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: Jasper Improvements

[Jeremy Boynes]

On Feb 23, 2014, at 5:55 PM, Greg Wilkins  wrote:

> On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes  wrote:
> 
>> I have been thinking about improvements to Jasper as well around better 
>> support for Servlet
>> 3.0 concepts. One area would be decoupling it from Tomcat, bootstrapping 
>> using an SCI as hinted
>> in ContextConfig. I'd also be interested in improving the Ant task as well, 
>> such as support
>> for pre-compiling a separate package that would be treated as a web fragment 
>> (including web.xml-less
>> pre-compilation, generating a web-fragment.xml rather than a web.xml snippet 
>> or potentially
>> eliminating the XML entirely if the generated code can be annotated with 
>> @WebServlet).
> 
> 
> Jeremy et al,

Hi Greg,

> 
> The Jetty project has been considering switching to directly consume the
> apache version of Jasper JSP.
> 
> However, there are some tomcat dependencies in jasper that means we cannot
> directly consume the jar produced by the apache project.We had assumed
> that there would be little interest here to make jasper separable so we had
> begun our own effort at github.  However, when I gave a heads up to
> priv...@tomcat.apache.org, I was pointed at Jeremy's email.  So if
> there is some interest here, then it would definitely be better to do this
> within apache rather than via an intermediate repository.

My original interest was partly academic in that Servlet 3.0 implies the JSP 
engine should be pluggable and I was wondering if it actually could. I was also 
interested in where we could take the JSP engine in light of other developments 
in server-side template engines especially the JavaScript-based ones (e.g. 
Handlebars, Dust). I hadn’t originally envisioned Jetty picking this up but 
would be happy to help.

The work I’ve done to date has all been in trunk (Tomcat 8.x) and IMO is 
disruptive enough that it would not be wise to attempt a back port into Tomcat 
7.x. It focused on decoupling Catalina from Jasper i.e. removing any need for 
Jasper-specific initialization in Catalina. I think that is mostly complete, 
with Jasper’s SCI now handling bootstrap of the JSP engine. There is still some 
work to do setting up the JSP servlet (the *.jsp[x] mapping) as in Tomcat that 
is defined by the default web.xml. It would be easy enough for the SCI to 
register a servlet and mapping but Jasper would ideally have a configuration 
mechanism for it that does not require modification to container or application 
web.xml files.

> What we have done so far is to create a github project at github:
> https://github.com/jetty-project/jasper-jsp. This project mounts the
> tomcat github repo as a subtree and removes everything that is not el,
> jasper or a used utility.   We've then changed a few hard tomcat
> dependencies to produce a container neutral version of jasper, which we
> then consume and specialise within a build of the jetty project (not yet at
> eclipse).  We have this working at the moment, but have not yet done any
> releases, so there are no indelible maven artefacts yet.  Nor have we done
> the IP clearance work to officially consume such an artefact within the
> eclipse project.

I’ve not had a chance to take a look yet but will this evening.

> 
> The changes that we made to make jasper neutral were:
> 
>   - Modified JuliLog LogFactory to use a ServiceLoader to find an
>   implementation of Log.  Within the jetty project we add an impl of the Juli
>   Log that logs to the jetty log and we set that as a service in our own jars
>   META-INF.   Note that judging by some of the comments in the classes, there
>   is not much desire to make logging discoverable?

>   - We have replaced the InstanceManager with a pretty simple
>   non-container version.   It does not do post construct or pre destroy, but
>   don't think these are needed for Jasper.  I guess rather than replace the
>   top level InstanceManager, it would be better to have a Jasper Instance
>   manager that could be instantiated as the container specific version,
>   perhaps also with a ServiceLoader?

I thought pre- and post- construct were now necessary parts of tag lifecycle?

This seemed to me to be one of the areas where the Servlet API was lacking. It 
provides bean factories for the Servlet components but does not make a 
general-purpose bean factory available to frameworks like JSP. In a JavaEE 
world with CDI available, I think Jasper could use the CDI BeanFactory to 
create JSP-servlet and tag instances but that is not something available in a 
standalone Servlet environment.

>   - We changed the jasper ServletContainerInitialiser to allow some
>   pluggability of the scanner and we turned off ServiceLoader for it so that
>   we can provide our own extension of it.
>   - We made the Tld scanning check for a prescanned list so that we can do
>   the TLD discovery in our own scanning (rather than do another scan) and
>   push those into jasper.   A  neutral version of Jasper could m

Re: Git

[Jeremy Boynes]

Setting aside Maven and Gradle, did we reach any consensus on Git?

On Jan 26, 2014, at 5:34 PM, Costin Manolache  wrote:

> Gradle is becoming the standard build tool for android.
> I didn't like it at first - I don't really see the point of groovy - but
> it's still better than 'programming'
> in ant, and you don't have to touch any XML. You can use any ant task from
> gradle - best to think of it as a non-xml ant file, with reasonable
> defaults and less typing for the most common operations.
> 
> Git is best.
> 
> Costin
> 
> 
> On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat  wrote:
> 
>> 2014/1/21 Yoav Shapira 
>> 
>>> Also +1 to separating the git vs svn discussion from the build system
>>> discussion (Maven, Ant, whatever.) (Side note: been using gradle
>>> recently, fun.)
>>> 
>> 
>> +1
>> 
>> Never used that Gradle yet though.
>> 
>> Rémy
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Bug 56147] Problem Invoking overloaded methods using EL

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56147

--- Comment #3 from ujj...@gmail.com ---
Thank you.

-- 
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

[Bug 56183] New: pkcs12 windows and AprLifecycleListener

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56183

Bug ID: 56183
   Summary: pkcs12 windows and AprLifecycleListener
   Product: Tomcat 7
   Version: 7.0.47
  Hardware: Other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: mikej...@hotmail.com

Essentially an out-of-the-box install, I am receiving a reproducable error in a
Windows environment. I set the severity as an enhancement because there is a
simple workaround that doesn't introduce any severity of risk that I'm aware
of.

Replicating an install from a RedHat Linux machine to a Windows Server 2008 R2
machine, I'm getting the following error when I start the service up:

SEVERE: Failed to initialize end point associated with ProtocolHandler [...]
java.lang.Exception: Connector attribute SSLCertificateFile must be defined
when using SSL with APR

If I comment out:



>From the server.xml the service boots up normally. (assuming it's now using
JSSE SSL)


You can reproduce this by doing a default install, and attempting to make a
connector that uses a pkcs12 keystore. Mine was an exported star cert from a
Windows box that I exported into a pfx.(star cert purchased from COMODO) 

The exact setup works fine on the linux box without any issues.

I have talked to a few Colleagues and they all can reproduce the error in their
environments.

Please let me know if I'm missing any pertinent information.

I would look to fix the code, but that is way above my expertise at this time.
Mike.

-- 
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: Git

[sebb]

AIUI SVN will still be mandated by Infra for
- release publishing
- site publishing

Release publishing should not cause an issue.

However site publishing may perhaps be tricker to do from a GIT repo;
might need to consider leaving site docs in SVN.

On 24 February 2014 17:43, Jeremy Boynes  wrote:
> Setting aside Maven and Gradle, did we reach any consensus on Git?
>
> On Jan 26, 2014, at 5:34 PM, Costin Manolache  wrote:
>
>> Gradle is becoming the standard build tool for android.
>> I didn't like it at first - I don't really see the point of groovy - but
>> it's still better than 'programming'
>> in ant, and you don't have to touch any XML. You can use any ant task from
>> gradle - best to think of it as a non-xml ant file, with reasonable
>> defaults and less typing for the most common operations.
>>
>> Git is best.
>>
>> Costin
>>
>>
>> On Tue, Jan 21, 2014 at 7:49 AM, Rémy Maucherat  wrote:
>>
>>> 2014/1/21 Yoav Shapira 
>>>
 Also +1 to separating the git vs svn discussion from the build system
 discussion (Maven, Ant, whatever.) (Side note: been using gradle
 recently, fun.)

>>>
>>> +1
>>>
>>> Never used that Gradle yet though.
>>>
>>> Rémy
>>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1571438 - in /tomcat/site/trunk: docs/whichversion.html xdocs/whichversion.xml

[markt]

Author: markt
Date: Mon Feb 24 20:59:47 2014
New Revision: 1571438

URL: http://svn.apache.org/r1571438
Log:
Update 8.0x. status

Modified:
tomcat/site/trunk/docs/whichversion.html
tomcat/site/trunk/xdocs/whichversion.xml

Modified: tomcat/site/trunk/docs/whichversion.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whichversion.html?rev=1571438&r1=1571437&r2=1571438&view=diff
==
--- tomcat/site/trunk/docs/whichversion.html (original)
+++ tomcat/site/trunk/docs/whichversion.html Mon Feb 24 20:59:47 2014
@@ -376,17 +376,14 @@ to that, it includes the following impro
 
 
 
-Tomcat 8 is currently in an alpha state. Regular (at least monthly) release
-candidates are being made available for testing. All the specifications are
-feature complete as of 8.0.0-RC1. The remaining work includes:
+Tomcat 8 is currently in a beta state. Regular (at least monthly) releases
+are being made. All the specifications are feature complete as of 8.0.0-RC1. 
The
+remaining work includes:
 
 
   
-Complete the work to have Jasper initialized and configured purely via a
-  ServletContainerInitializer.
-  
-Address missing functionality identified in the new resources
-  implementation.
+Updating the dependencies to a release version of Commons DBCP 2 when
+  available.
 
 
 

Modified: tomcat/site/trunk/xdocs/whichversion.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/whichversion.xml?rev=1571438&r1=1571437&r2=1571438&view=diff
==
--- tomcat/site/trunk/xdocs/whichversion.xml (original)
+++ tomcat/site/trunk/xdocs/whichversion.xml Mon Feb 24 20:59:47 2014
@@ -149,14 +149,12 @@ to that, it includes the following impro
 extension features provided in earlier versions.
 
 
-Tomcat 8 is currently in an alpha state. Regular (at least monthly) release
-candidates are being made available for testing. All the specifications are
-feature complete as of 8.0.0-RC1. The remaining work includes:
-
-  Complete the work to have Jasper initialized and configured purely via a
-  ServletContainerInitializer.
-  Address missing functionality identified in the new resources
-  implementation.
+Tomcat 8 is currently in a beta state. Regular (at least monthly) releases
+are being made. All the specifications are feature complete as of 8.0.0-RC1. 
The
+remaining work includes:
+
+  Updating the dependencies to a release version of Commons DBCP 2 when
+  available.
 
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 56184] New: Async servlet doesn't work asyncroniously

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56184

Bug ID: 56184
   Summary: Async servlet doesn't work asyncroniously
   Product: Tomcat 7
   Version: 7.0.50
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: gkis...@yandex.ru

Also tested at Tomcat 8.03

In apache-tomcat-7.0.50 I've changed connector according
http://blog.yamanyar.com/2013/09/dont-forget-to-use-nio-if-you-are-doing.html

Async servlet is very simple:

@WebServlet(asyncSupported = true, value = "/sendMailAsync")
public class SendMailServletAsync extends SendMailServlet {

private static final ExecutorService EXE = Executors.newFixedThreadPool(500);

@Override
protected void doProcess(HttpServletRequest request, HttpServletResponse
response, Map params) throws IOException, ServletException {
final AsyncContext ac = request.startAsync(); // obtain async context
Runnable worker = new Runnable() {
@Override
public void run() {
try {
Thread.sleep(5000);   // wait 5 sec
logger.info("Finish");
} catch (Exception e) {
logger.error("Exception during process async request", e);
} finally {
ac.complete();
}
}
};

EXE.execute(worker);
logger.info("Async request in progress");
}

Test was done by apache ab

Results for sync and async servlets is the same:

Requests per second:19.68 [#/sec] (mean)

-- 
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: Jasper Improvements

[Greg Wilkins]

On 24 February 2014 22:48, Mark Thomas  wrote:

> On 24/02/2014 02:10, Greg Wilkins wrote:
> > The Jetty project has been considering switching to directly consume the
> > apache version of Jasper JSP.
> That said, there is a balance to be struck. If the changes are very
> invasive or impact performance then I'd be less likely to support them.
>

+1.   Totally understand that only changes that make sense for the whole
project should be pushed back.   Even if it is not 100% of what we need, if
it is close we might be able to consume by repackaging apache jars rather
than rebuilding.



> Are we just talking about Tomcat 8 here?
>
>
For our part yes.  We are only doing this for new releases and not back
porting.




> >- Modified JuliLog LogFactory to use a ServiceLoader to find an
> >implementation of Log.  Within the jetty project we add an impl of
> the Juli
> >Log that logs to the jetty log and we set that as a service in our
> own jars
> >META-INF.   Note that judging by some of the comments in the classes,
> there
> >is not much desire to make logging discoverable?
>
> Discoverable in the Commons Logging sense of the term is not something I
> am a fan of. At the risk of opening a huge can of worms would now be a
> good time to review the choice to implement JULI? There have been some
> significant changes in the Java logging landscape since then. Would now
> be a good time to switch to log4j2, slf4j, something else?
>
> How would such a switch impact potential downstream users like Jetty?
>

I'm always amazed at how hard logging is for projects like ours that have
to work with everybody else's logging expectations.   At Jetty, we've
chosen not to use any common logging framework, but to have a thin facade
over stderr or slf4j - more or less what you've done with Juli. I know
this can end up with a facade over a facade over a facade over a logging
framework, but isn't there a golden rule that no problem cannot be solved
without another layer of delegation?

For us working with however you make Juli pluggable (even if it is
replacing the LogFactory class), will be easier than if you pick a specific
framework.



>
> The InstanceManagerFactory was intended to provide downstream users with
> a way of injecting their own InstanceManager into Jasper. Is that not
> sufficient? If not, what would you like to change?
>

Hmm will review that again and get back to you.


> If there is interest here, then we could prepare a git pull request of our
> changes (against the apache github clone), or would we need to remember
our
> svn and submit a diff against that?

As long as a diff arrives in a format we can review it, it doesn't
> really matter how that diff is generated or how it reaches is. Pull
> requests should be fine. We need to get infra to hook them up to our dev
> list. I'll try and create that request today. If we don't notice a PR
> after a few days feel free to ping us on the dev list.
>


We'll prepare some PR in the next week.



> If anyone from Jetty is going to be at ApacheCon, we are holding a
> Tomcat Summit on the Friday.
>

I don't think so this year.

thanks for your consideration.



-- 
Greg Wilkins 
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

RE: Jasper Improvements

[Caldarale, Charles R]

> From: Greg Wilkins [mailto:gr...@intalio.com] 
> Subject: Re: Jasper Improvements

> isn't there a golden rule that no problem cannot be solved
> without another layer of delegation?

David Wheeler: "All problems in computer science can be solved by another level 
of indirection."

Kevlin Henney: "...except for the problem of too many layers of indirection."

Also look at RFC 1925.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Crash in java.util.zip.Deflater.deflateBytes

[Seán Coffey]

Thanks for the pointers. I have seen most of the bugs you reference. 
I've taken a few of the testcases mentioned also but haven't reproduced 
the crash. The crashes I've seen occur in the zlib deflate_slow 
function. Ideally the JVM shouldn't crash but given the various factors 
at play, it seems like the JNI layer isn't able to handle all scenarios. 
JDK 6 is built with zlib 1.1.3 libraries. I'd certainly investigate 
further if I had a reproducer.


https://issues.apache.org/bugzilla/show_bug.cgi?id=53725 looks 
interesting given that it's fixed in tomcat 7.0.30 and the crashes I've 
seen are on tomcat 7.0.29.A. I realise the initial report states an 
IOException is seen but wonder if the data could manifest in other ways 
so as to cause SEGV for the native deflate calls.


regards,
Sean.

On 19/02/14 17:51, Mark Thomas wrote:

On 19/02/2014 17:03, Seán Coffey wrote:

Hi,

I work in the JDK team and have a few reports of the JVM crashing in
lead on calls from the Apache Coyote stack. A typical trace looks like :

Good to see Oracle taking an interest in this bug.


Is anyone on this list aware of similar issues ?

 From memory, there have been a number of reports over several years. A
quick search of the archives found this which looks to be the same issue:
http://tomcat.markmail.org/thread/i5u4sokqczmryzql

This might be related:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55737

There are probably more.

As far as I recall bugs in the FlushableGZIPOutputStream have resulted
in corrupted output rather than a JVM crash:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52121
https://issues.apache.org/bugzilla/show_bug.cgi?id=53725

To re-iterate a point I have made elsewhere on this topic,
FlushableGZIPOutputStream is not doing anything it shouldn't. It isn't
playing games with reflection to access internals. It is a straight
sub-class of GZIPOutputStream and everything it is doing is via the
published API for GZIPOutputStream. There is no way that anything that
that sub-class does should be capable of triggering a JVM crash.
FlushableGZIPOutputStream may have a bug that may be triggering the
crash but the fact that a crash occurs at all is a clear JVM bug.



The above issue was
seen with JDK 6 and Tomcat 7.0.29.A. Was there any instances of multiple
threads accessing the same stream concurrently ?

In all of the instances I have seen there shouldn't have been more than
one thread accessing the stream but it is possible for an application to
retain a reference to a stream which can result in multiple threads
accessing the same stream.

Mark


-
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

[Bug 56181] RemoteIpValve & RemoteIpFilter: HttpServletRequest.getRemoteHost() returns IP instead of hostname with enableLookups=true and x-forwarded-for header

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56181

Yann Nicolas  changed:

   What|Removed |Added

 CC||yann...@gmail.com

--- Comment #3 from Yann Nicolas  ---
The only reason to differentiate between proxied and non-proxied clients is if
you want to do reverse DNS lookup only for proxied clients and not for the
non-proxied clients (if for example we know it is always the Load Balancer or
the Proxy IP) for performance reasons.

-- 
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 mod_jk 1.2.38

[Andrew Carr]

Very excited


On Mon, Feb 24, 2014 at 3:00 AM, Rainer Jung  wrote:
> On 24.02.2014 07:49, Mladen Turk wrote:
>> Hi,
>> I plan to tag mod_jk 1.2.38 tomorrow and start release process
>
> +1, thanks.
>
> Rainer
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>



-- 
With Regards,
Andrew Carr

e. andrewlanec...@gmail.com
w. andrew.c...@openlogic.com
h. 4235255668
c. 4239489852
a. 101 Francis Drive, Greeneville, TN, 37743

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Jasper Improvements

[Violeta Georgieva]

Hi Greg,


2014-02-24 3:55 GMT+02:00 Greg Wilkins :
>
> On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes  wrote:
>
> > I have been thinking about improvements to Jasper as well around better
support for Servlet
> > 3.0 concepts. One area would be decoupling it from Tomcat,
bootstrapping using an SCI as hinted
> > in ContextConfig. I'd also be interested in improving the Ant task as
well, such as support
> > for pre-compiling a separate package that would be treated as a web
fragment (including web.xml-less
> > pre-compilation, generating a web-fragment.xml rather than a web.xml
snippet or potentially
> > eliminating the XML entirely if the generated code can be annotated
with @WebServlet).
>
>
> Jeremy et al,
>
> The Jetty project has been considering switching to directly consume the
> apache version of Jasper JSP.
>
> However, there are some tomcat dependencies in jasper that means we cannot
> directly consume the jar produced by the apache project.We had assumed
> that there would be little interest here to make jasper separable so we
had
> begun our own effort at github.  However, when I gave a heads up to
> priv...@tomcat.apache.org, I was pointed at Jeremy's email.  So if
> there is some interest here, then it would definitely be better to do this
> within apache rather than via an intermediate repository.
>
> What we have done so far is to create a github project at github:
> https://github.com/jetty-project/jasper-jsp. This project mounts the
> tomcat github repo as a subtree and removes everything that is not el,
> jasper or a used utility.   We've then changed a few hard tomcat
> dependencies to produce a container neutral version of jasper, which we
> then consume and specialise within a build of the jetty project (not yet
at
> eclipse).  We have this working at the moment, but have not yet done any
> releases, so there are no indelible maven artefacts yet.  Nor have we done
> the IP clearance work to officially consume such an artefact within the
> eclipse project.
>
> The changes that we made to make jasper neutral were:
>
>- Modified JuliLog LogFactory to use a ServiceLoader to find an
>implementation of Log.  Within the jetty project we add an impl of the
Juli
>Log that logs to the jetty log and we set that as a service in our own
jars
>META-INF.   Note that judging by some of the comments in the classes,
there
>is not much desire to make logging discoverable?
>- We have replaced the InstanceManager with a pretty simple
>non-container version.   It does not do post construct or pre destroy,
but
>don't think these are needed for Jasper.  I guess rather than replace
the
>top level InstanceManager, it would be better to have a Jasper Instance
>manager that could be instantiated as the container specific version,
>perhaps also with a ServiceLoader?
>- We changed the jasper ServletContainerInitialiser to allow some
>pluggability of the scanner and we turned off ServiceLoader for it so
that
>we can provide our own extension of it.
>- We made the Tld scanning check for a prescanned list so that we can
do
>the TLD discovery in our own scanning (rather than do another scan) and
>push those into jasper.   A  neutral version of Jasper could make
scanning
>container specific and then most of the dependencies on tomcat utils
could
>be removed.
>- We would also like to add the META-INF magic to make the resulting
>jars more OSGi consumable.

We should be very careful when adding the OSGi meta data to the tomcat
artifacts. Something that is stopping me from adding it right now, is that
the different projects add different OSGi meta data specific to the
concrete project. For example I don't think that the way that is used in
Gemini Web/Virgo is sufficient for Jetty.


Regards
Violeta

> As a project, Jetty has no desire to fork jasper.  Rather we just want to
> re-bundle it in a way that can be consumed by the jetty project at eclipse
> and to use our own sanning/discovery/configuration mechanisms.  We wish to
> be bug for bug compatible and if we did find/fix a bug, our preference
> would be to contribute back to apache. Also happy to contribute back
> changes to improve start time (eg by avoiding duplicate jar scans).
>
> We totally understand that making jasper consumable by jetty will not be a
> high priority for the tomcat project and that even minor changes to jar
> packaging can be disruptive. However, if it is desirable for other
reasons,
> then we'd certainly be keen to lend a hand and I think most(all?) of our
> committers are already apache committers on some project or other.
>
> Anyway, we'll hold off making any indelible maven artefacts from our
github
> project for a while, so that if something does happen within apache we can
> erase what we have done already.
>
> If there is interest here, then we could prepare a git pull request of our
> changes (against the apache github clone), or would we need 

Connectors, blocking, and keepalive

[Christopher Schultz]

All,

I'm looking at the comparison table at the bottom of the HTTP connectors
page, and I have a few questions about it.

First, what does "Polling size" mean?

Second, under the NIO connector, both "Read HTTP Body" and "Write HTTP
Response" say that they are "sim-Blocking"... does that mean that the
API itself is stream-based (i.e. blocking) but that the actual
under-the-covers behavior is to use non-blocking I/O? It is important to
make that distinction since the end user (the code) can't tell the
difference? Unless there is another thread pushing the bytes back to the
client for instance, the request-processing thread is tied-up performing
I/O whether it's doing blocking I/O or non-blocking I/O, right?

Third, under "Wait for next Request", only the BIO connector says
"blocking". Does "Wait for next Request" really mean
wait-for-next-keepalive-request-on-the-same-connection? That's the only
thing that would make sense to me.

Fourth, the "SSL Handshake" says non-blocking for NIO but blocking for
the BIO and APR connectors. Does that mean that SSL handshaking with the
NIO connector is done in such a way that it does not tie-up a thread
from the pool for the entire SSL handshake and subsequent request?
Meaning that the thread(s) that handle the SSL handshake may not be the
same one(s) that begin processing the request itself?

Lastly, does anything change when Websocket is introduced into the mix?
For example, when a connection is upgraded from HTTP to Websocket, is
there another possibility for thread-switching or anything like that? Or
is the upgrade completely-handled by the request-processing thread that
was already assigned to handle the HTTP request? Also, (forgive my
Websocket ignorance) once the connection has been upgraded for a single
request, does it stay upgraded or is the next (keepalive) request
expected to be a regular HTTP request that can also be upgraded? In the
event that the request "stays upgraded", does the connection go back
into the request queue to be handled by another thread, or does the
current thread handle subsequent requests (e.g. BIO-style behavior,
regardless of connector).

I'm giving a talk at ApacheCon NA comparing the various connectors and
I'd like to build a couple of diagrams showing how threads are
allocated, cycled, etc. so the audience can get a better handle on where
the various efficiencies are for each, as well as what each
configuration setting can accomplish. I think I should be able to
re-write a lot of the Users' Guide section on connectors (a currently
mere 4 paragraphs) to help folks understand what the options are, why
they are available, and why they might want to use one over the other.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[Bug 56184] Async servlet doesn't work asyncroniously

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56184

Grigory  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Grigory  ---
Sorry, performance depends of ab concurrency level
ab -n 1000 -c 100 http://127.0.0.1:8080/web/sendMailAsync give ~20r/s
ab -n 1000 -c 500 http://127.0.0.1:8080/web/sendMailAsync give ~100r/s

-- 
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

[Bug 56184] Async servlet

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56184

Grigory  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Summary|Async servlet doesn't work  |Async servlet
   |asyncroniously  |

--- Comment #2 from Grigory  ---
My test show that Async servlet performance depends mostly of thread pool size
and could be achieved by configuring 
Executor name="tomcatThreadPool" and

Connector executor="tomcatThreadPool"

So, async servlet is useful only for Commet, if for long calculation we could
just configure tomcatThreadPool?

-- 
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

[Bug 56185] New: Jasper to compile compile complicated EL expression

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56185

Bug ID: 56185
   Summary: Jasper to compile compile complicated EL expression
   Product: Tomcat 8
   Version: 8.0.3
  Hardware: PC
Status: NEW
  Severity: regression
  Priority: P2
 Component: EL
  Assignee: dev@tomcat.apache.org
  Reporter: serge@gmail.com

The following jsp fails to compile: 
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>

Hello world

If I simplify test expression to: (myBean.int1 > 1 and myBean.myBool) or
(myBean.myBool and myBean.int1 > 1) i.e. replace (myBean.myBool or
myBean.myBool1) with myBean.myBool, then compilation will work.

It looks like Jasper cannot compile EL expressions with depth that is higher
than a certain value (4?)

Exception as follows
org.apache.jasper.JasperException: /testCompile.jsp (line: 26, column: 0)
"${(myBean.int1 > 1 and myBean.myBool) or ((myBean.myBool or myBean.myBool) and
myBean.int1 > 1)}" contains invalid expression(s): javax.el.ELException: Failed
to parse the expression [${(myBean.int1 > 1 and myBean.myBool) or
((myBean.myBool or myBean.myBool) and myBean.int1 > 1)}]
   
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42)
   
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:276)
.

Works properly in Tomcat 6 and Tomcat 7.

-- 
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