date:20130807

On 07/08/2013 06:19, Konstantin Kolinko wrote:
 2013/8/6 Mark Thomas ma...@apache.org:

 Feel free to make as much or as little use of this:
 http://wiki.apache.org/tomcat/ReleaseProcess

 If anything isn't clear, let me know.
 
 The following is missing:
 
 1. At which point in time the Maven artifacts are being released from
 the staging repository, and how?
 
 I guess you do it it shortly after svn mv dev-release, a day before
 the announcement.

Yes. Added.

 https://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/res/maven/README.txt
 says
 [[[
 3 - include the repository in the VOTE thread
 4 - in https://repository.apache.org/index.html#stagingRepositories release it
 ]]]
 
 I think 4 actually releases the artifacts. (Thus a step is missing:
 wait for the vote to pass).

I've split the instructions between the two steps.

 2. Bump version number preparing for the next release.
 http://svn.apache.org/viewvc?view=revisionrevision=1500094

Added.

 3. Add release date to changelog.xml
 (The same date as in announcement at tomcat.apache.org/index.html)
 http://svn.apache.org/viewvc?view=revisionrevision=158

Added. Recently I have been using the date the files were copied to dist
rather than the date I announce.

 4. Add version number in Bugzilla.

Added.

Mark

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

Re: Fixing bug 55365

On 07/08/2013 08:02, Rainer Jung wrote:
 On 07.08.2013 00:26, Rainer Jung wrote:
 For completeness I checked out r932968 and am now running the TCK under
 security manager. I'll report the original failures that the patch
 should have fixed later on Wednesday.
 
 Indeed I get lots of failures in the servlet TCK (JSP and EL are OK)
 with r932968.
 
 Unfortunately I don't see much root cause information in the logs apart from
 
 Caused by: java.lang.NoSuchMethodException:
 org.apache.catalina.core.ApplicationContext.addServlet()
 at java.lang.Class.getMethod(Class.java:1607)
 at
 org.apache.catalina.core.ApplicationContextFacade.invokeMethod(ApplicationContextFacade.java:717)
 at
 org.apache.catalina.core.ApplicationContextFacade.doPrivileged(ApplicationContextFacade.java:694)
 ... 39 more
 
 
 which points to the class ApplicationContextFacade changed by me in r932969.
 
 I can't debug now the exact cause for the other old servlet TCK failures
 but I guess the info that we need to rerun the TCK after undoing some of
 the ApplicationContextFacade changes might be sufficient right now.

OK. Thanks for running those tests.

Mark


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

Use (or not) of @SuppressWarnings

For trunk we have been running a policy of zero warnings in the code.
This has helped to highlight issues as code is edited as any warnings
are immediately clear. Obviously, this depends on what warnings are enabled.

Currently, we use Eclipse's Ignore unavoidable generic type problems.
Recently a couple of issues has been highlighted with this:
1. Other IDEs might not have this setting.
2. javac does not have this setting
3. Some of the problems Eclipse excludes are avoidable (well, sort of
avoidable as avoiding them requires using JRE methods that themselves
have @SuppressWarnings annotations).

In favour of the current situation is that it reduces clutter in the
code base slightly.

While I am all for reducing clutter in the code base, there do appear to
be good reasons for disabling the Ignore unavoidable generic type
problems. and using @SuppressWarnings instead.

Personally, I am happy with the current settings but not unhappy to
change. I guess that makes me +0 on changing. What does everyone else think?

Mark

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

[Bug 55372] Bind JPDA_ADDRESS by default to localhost

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

--- Comment #3 from Michael Osipov 1983-01...@gmx.net ---
(In reply to Mark Thomas from comment #2)
 Or just change JPDA_ADDRESS back to 8000 in setenv.sh
 
 This has been applied to trunk and will be in 8.0.0-RC2 onwards. I'll also
 add a note to the migration page.

Looks good but your did leave out the catalina.bat and
res/ide-support/netbeans/README.txt. Was that intentional? Though, I do not
know how to port forward a port with RDP.

-- 
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 55372] Bind JPDA_ADDRESS by default to localhost

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

--- Comment #4 from Mark Thomas ma...@apache.org ---
(In reply to Michael Osipov from comment #3)
 (In reply to Mark Thomas from comment #2)
  Or just change JPDA_ADDRESS back to 8000 in setenv.sh
  
  This has been applied to trunk and will be in 8.0.0-RC2 onwards. I'll also
  add a note to the migration page.
 
 Looks good but your did leave out the catalina.bat and

That was an oversight. I'll fix that shortly.

 res/ide-support/netbeans/README.txt. Was that intentional? Though, I do not
 know how to port forward a port with RDP.

netbeans I know nothing about.

-- 
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: r1511204 - /tomcat/trunk/bin/catalina.bat

Author: markt
Date: Wed Aug  7 07:53:09 2013
New Revision: 1511204

URL: http://svn.apache.org/r1511204
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55372
Make listening on localhost only be the default when enabling jpda.

Modified:
tomcat/trunk/bin/catalina.bat

Modified: tomcat/trunk/bin/catalina.bat
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.bat?rev=1511204r1=1511203r2=1511204view=diff
==
--- tomcat/trunk/bin/catalina.bat (original)
+++ tomcat/trunk/bin/catalina.bat Wed Aug  7 07:53:09 2013
@@ -64,7 +64,7 @@ rem   JPDA_TRANSPORT  (Optional) JPDA tr
 rem   command is executed. The default is dt_socket.
 rem
 rem   JPDA_ADDRESS(Optional) Java runtime options used when the jpda 
start
-rem   command is executed. The default is 8000.
+rem   command is executed. The default is localhost:8000.
 rem
 rem   JPDA_SUSPEND(Optional) Java runtime options used when the jpda 
start
 rem   command is executed. Specifies whether JVM should suspend
@@ -212,7 +212,7 @@ if not %JPDA_TRANSPORT% ==  goto got
 set JPDA_TRANSPORT=dt_socket
 :gotJpdaTransport
 if not %JPDA_ADDRESS% ==  goto gotJpdaAddress
-set JPDA_ADDRESS=8000
+set JPDA_ADDRESS=localhost:8000
 :gotJpdaAddress
 if not %JPDA_SUSPEND% ==  goto gotJpdaSuspend
 set JPDA_SUSPEND=n



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

Re: jaasrealm regression

On 06/08/2013 08:51, Romain Manni-Bucau wrote:
 Hi
 
 it seems we can now configure jaasrealm to use a jaas config file from the
 webapp. That's great but it would need to fallback to old behavior (jaas
 system property to find its location) by default otherwise apps using an
 older tomcat are broken.
 
 wdyt?

What makes you think it doesn't fall-back to the old behaviour if no
webapp specific file is specified?

Here is the commit:
http://svn.apache.org/viewvc?view=revisionrevision=1498498

Mark


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

Re: jaasrealm regression

2013-08-07 Thread Romain Manni-Bucau

well maybe it does (surely since that's the LoginContext behavior) but
error is not obvious at all.

I didn't got time to dig deeper into it but i think you are right and the
main issue is the error message which should be more explicit saying
configFile was not set and system property is missing or wrong.

wdyt?

PS: i changed of JVM version too, maybe LoginContext was modified, i didn't
check this neither.

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/8/7 Mark Thomas ma...@apache.org

 On 06/08/2013 08:51, Romain Manni-Bucau wrote:
  Hi
 
  it seems we can now configure jaasrealm to use a jaas config file from
 the
  webapp. That's great but it would need to fallback to old behavior (jaas
  system property to find its location) by default otherwise apps using an
  older tomcat are broken.
 
  wdyt?

 What makes you think it doesn't fall-back to the old behaviour if no
 webapp specific file is specified?

 Here is the commit:
 http://svn.apache.org/viewvc?view=revisionrevision=1498498

 Mark


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

Re: jaasrealm regression

On 07/08/2013 10:21, Romain Manni-Bucau wrote:
 well maybe it does (surely since that's the LoginContext behavior) but
 error is not obvious at all.
 
 I didn't got time to dig deeper into it but i think you are right and the
 main issue is the error message which should be more explicit saying
 configFile was not set and system property is missing or wrong.

What error message?

 wdyt?

I think you need to be a lot clearer about what the problem is. A good
problem definition should include:
- what you did from a clean install
- what happened that you didn't expect to happen
- what didn't happen that you expected to happen

So far your messages on this topic make little sense to someone who is
not sat in front of your computer and has no knowledge of what you have
tested and how.

Mark

 
 PS: i changed of JVM version too, maybe LoginContext was modified, i didn't
 check this neither.
 
 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*
 
 
 
 2013/8/7 Mark Thomas ma...@apache.org
 
 On 06/08/2013 08:51, Romain Manni-Bucau wrote:
 Hi

 it seems we can now configure jaasrealm to use a jaas config file from
 the
 webapp. That's great but it would need to fallback to old behavior (jaas
 system property to find its location) by default otherwise apps using an
 older tomcat are broken.

 wdyt?

 What makes you think it doesn't fall-back to the old behaviour if no
 webapp specific file is specified?

 Here is the commit:
 http://svn.apache.org/viewvc?view=revisionrevision=1498498

 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 55372] Bind JPDA_ADDRESS by default to localhost

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

--- Comment #5 from Michael Osipov 1983-01...@gmx.net ---
(In reply to Mark Thomas from comment #4)
 [..]
  res/ide-support/netbeans/README.txt. Was that intentional? Though, I do not
  know how to port forward a port with RDP.
 
 netbeans I know nothing about.

This is a user guide. Nothing crucial but examples should resemble the
catalina.sh settings.

-- 
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: jaasrealm regression

2013-08-07 Thread Romain Manni-Bucau

ok, sorry

i basically just set up a simple war sample using tomee maven plugin (but
for the part we speak about only tomcat is relevant). This sample was using
JAASRealm with the default LoginModule of tomee (properties one if you
care).

IIRC before when the setup was wrong you get an error message saying the
jaas file is not found or not correctly set. When i first tested with a
wrong path i didn't get it but my login just failed.

The point is IMO tomcat impl totally relies on JAAS for error cases. Since
there is an init phase (getConfig()) i think it could check the config a
bit more to log an explicit error message (it should check configFile of
course but the jaas system property too).

Is it clearer?

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/8/7 Mark Thomas ma...@apache.org

 On 07/08/2013 10:21, Romain Manni-Bucau wrote:
  well maybe it does (surely since that's the LoginContext behavior) but
  error is not obvious at all.
 
  I didn't got time to dig deeper into it but i think you are right and the
  main issue is the error message which should be more explicit saying
  configFile was not set and system property is missing or wrong.

 What error message?

  wdyt?

 I think you need to be a lot clearer about what the problem is. A good
 problem definition should include:
 - what you did from a clean install
 - what happened that you didn't expect to happen
 - what didn't happen that you expected to happen

 So far your messages on this topic make little sense to someone who is
 not sat in front of your computer and has no knowledge of what you have
 tested and how.

 Mark

 
  PS: i changed of JVM version too, maybe LoginContext was modified, i
 didn't
  check this neither.
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
  2013/8/7 Mark Thomas ma...@apache.org
 
  On 06/08/2013 08:51, Romain Manni-Bucau wrote:
  Hi
 
  it seems we can now configure jaasrealm to use a jaas config file from
  the
  webapp. That's great but it would need to fallback to old behavior
 (jaas
  system property to find its location) by default otherwise apps using
 an
  older tomcat are broken.
 
  wdyt?
 
  What makes you think it doesn't fall-back to the old behaviour if no
  webapp specific file is specified?
 
  Here is the commit:
  http://svn.apache.org/viewvc?view=revisionrevision=1498498
 
  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

svn commit: r1511212 - /tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java

Author: markt
Date: Wed Aug  7 08:47:35 2013
New Revision: 1511212

URL: http://svn.apache.org/r1511212
Log:
No functional change.
Move some longer lines around prior to some functional changes.

Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java

Modified: 
tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java?rev=1511212r1=1511211r2=1511212view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java 
Wed Aug  7 08:47:35 2013
@@ -448,8 +448,9 @@ public class ApplicationContextFacade im
 public FilterRegistration.Dynamic addFilter(String filterName,
 Filter filter) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (FilterRegistration.Dynamic) doPrivileged(
-addFilter, new Class[]{String.class, Filter.class}, new 
Object[]{filterName, filter});
+return (FilterRegistration.Dynamic) doPrivileged(addFilter,
+new Class[]{String.class, Filter.class},
+new Object[]{filterName, filter});
 } else {
 return context.addFilter(filterName, filter);
 }
@@ -460,8 +461,8 @@ public class ApplicationContextFacade im
 public FilterRegistration.Dynamic addFilter(String filterName,
 Class? extends Filter filterClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (FilterRegistration.Dynamic) doPrivileged(
-addFilter, new Object[]{filterName, 
filterClass.getName()});
+return (FilterRegistration.Dynamic) doPrivileged(addFilter,
+new Object[]{filterName, filterClass.getName()});
 } else {
 return context.addFilter(filterName, filterClass);
 }
@@ -515,8 +516,9 @@ public class ApplicationContextFacade im
 public ServletRegistration.Dynamic addServlet(String servletName,
 Servlet servlet) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (ServletRegistration.Dynamic) doPrivileged(
-addServlet, new Class[]{String.class, Servlet.class}, 
new Object[]{servletName, servlet});
+return (ServletRegistration.Dynamic) doPrivileged(addServlet,
+new Class[]{String.class, Servlet.class},
+new Object[]{servletName, servlet});
 } else {
 return context.addServlet(servletName, servlet);
 }
@@ -527,8 +529,8 @@ public class ApplicationContextFacade im
 public ServletRegistration.Dynamic addServlet(String servletName,
 Class? extends Servlet servletClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (ServletRegistration.Dynamic) doPrivileged(
-addServlet, new Object[]{servletName, 
servletClass.getName()});
+return (ServletRegistration.Dynamic) doPrivileged(addServlet,
+new Object[]{servletName, servletClass.getName()});
 } else {
 return context.addServlet(servletName, servletClass);
 }



-
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

2013-08-07 Thread 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/4793

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

Buildslave for this Build: bb-vm_ubuntu

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

Build succeeded!

sincerely,
 -The Buildbot

Re: Fixing bug 55365

On 07/08/2013 08:43, Mark Thomas wrote:
 On 07/08/2013 08:02, Rainer Jung wrote:
 On 07.08.2013 00:26, Rainer Jung wrote:
 For completeness I checked out r932968 and am now running the TCK under
 security manager. I'll report the original failures that the patch
 should have fixed later on Wednesday.

 Indeed I get lots of failures in the servlet TCK (JSP and EL are OK)
 with r932968.

 Unfortunately I don't see much root cause information in the logs apart from

 Caused by: java.lang.NoSuchMethodException:
 org.apache.catalina.core.ApplicationContext.addServlet()
 at java.lang.Class.getMethod(Class.java:1607)
 at
 org.apache.catalina.core.ApplicationContextFacade.invokeMethod(ApplicationContextFacade.java:717)
 at
 org.apache.catalina.core.ApplicationContextFacade.doPrivileged(ApplicationContextFacade.java:694)
 ... 39 more


 which points to the class ApplicationContextFacade changed by me in r932969.

 I can't debug now the exact cause for the other old servlet TCK failures
 but I guess the info that we need to rerun the TCK after undoing some of
 the ApplicationContextFacade changes might be sufficient right now.
 
 OK. Thanks for running those tests.

I think I have a fix for this. I am going to commit it to trunk and
7.0.x and then run the servlet 3.0 TCK on 7.0.x/trunk just to make sure.

Mark


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

svn commit: r1511217 - /tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java

Author: markt
Date: Wed Aug  7 09:16:31 2013
New Revision: 1511217

URL: http://svn.apache.org/r1511217
Log:
When using a security manager always use the same method inside the 
doPrivileged call as triggered the call. This fixes an startup failure when 
running 8.0.x under a security manager as it uses a listener that does not have 
a zero arg constructor.

Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java

Modified: 
tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java?rev=1511217r1=1511216r2=1511217view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java 
Wed Aug  7 09:16:31 2013
@@ -462,7 +462,8 @@ public class ApplicationContextFacade im
 Class? extends Filter filterClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 return (FilterRegistration.Dynamic) doPrivileged(addFilter,
-new Object[]{filterName, filterClass.getName()});
+new Class[]{String.class, Class.class},
+new Object[]{filterName, filterClass});
 } else {
 return context.addFilter(filterName, filterClass);
 }
@@ -530,7 +531,8 @@ public class ApplicationContextFacade im
 Class? extends Servlet servletClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 return (ServletRegistration.Dynamic) doPrivileged(addServlet,
-new Object[]{servletName, servletClass.getName()});
+new Class[]{String.class, Class.class},
+new Object[]{servletName, servletClass});
 } else {
 return context.addServlet(servletName, servletClass);
 }
@@ -630,7 +632,8 @@ public class ApplicationContextFacade im
 public void addListener(Class? extends EventListener listenerClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 doPrivileged(addListener,
-new Object[]{listenerClass.getName()});
+new Class[]{Class.class},
+new Object[]{listenerClass});
 } else {
 context.addListener(listenerClass);
 }
@@ -652,7 +655,8 @@ public class ApplicationContextFacade im
 public T extends EventListener void addListener(T t) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 doPrivileged(addListener,
-new Object[]{t.getClass().getName()});
+new Class[]{EventListener.class},
+new Object[]{t});
 } else {
 context.addListener(t);
 }
@@ -683,9 +687,7 @@ public class ApplicationContextFacade im
 @Override
 public void declareRoles(String... roleNames) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-//FIXME
-doPrivileged(declareRoles,
-new Object[]{roleNames});
+doPrivileged(declareRoles, new Object[]{roleNames});
 } else {
 context.declareRoles(roleNames);
 }



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

svn commit: r1511219 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ApplicationContextFacade.java

Author: markt
Date: Wed Aug  7 09:18:31 2013
New Revision: 1511219

URL: http://svn.apache.org/r1511219
Log:
No functional change. Fix long lines.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)

tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1511212

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java?rev=1511219r1=1511218r2=1511219view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
 Wed Aug  7 09:18:31 2013
@@ -448,8 +448,9 @@ public class ApplicationContextFacade im
 public FilterRegistration.Dynamic addFilter(String filterName,
 Filter filter) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (FilterRegistration.Dynamic) doPrivileged(
-addFilter, new Class[]{String.class, Filter.class}, new 
Object[]{filterName, filter});
+return (FilterRegistration.Dynamic) doPrivileged(addFilter,
+new Class[]{String.class, Filter.class},
+new Object[]{filterName, filter});
 } else {
 return context.addFilter(filterName, filter);
 }
@@ -460,8 +461,8 @@ public class ApplicationContextFacade im
 public FilterRegistration.Dynamic addFilter(String filterName,
 Class? extends Filter filterClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (FilterRegistration.Dynamic) doPrivileged(
-addFilter, new Object[]{filterName, 
filterClass.getName()});
+return (FilterRegistration.Dynamic) doPrivileged(addFilter,
+new Object[]{filterName, filterClass.getName()});
 } else {
 return context.addFilter(filterName, filterClass);
 }
@@ -515,8 +516,9 @@ public class ApplicationContextFacade im
 public ServletRegistration.Dynamic addServlet(String servletName,
 Servlet servlet) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (ServletRegistration.Dynamic) doPrivileged(
-addServlet, new Class[]{String.class, Servlet.class}, 
new Object[]{servletName, servlet});
+return (ServletRegistration.Dynamic) doPrivileged(addServlet,
+new Class[]{String.class, Servlet.class},
+new Object[]{servletName, servlet});
 } else {
 return context.addServlet(servletName, servlet);
 }
@@ -527,8 +529,8 @@ public class ApplicationContextFacade im
 public ServletRegistration.Dynamic addServlet(String servletName,
 Class? extends Servlet servletClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-return (ServletRegistration.Dynamic) doPrivileged(
-addServlet, new Object[]{servletName, 
servletClass.getName()});
+return (ServletRegistration.Dynamic) doPrivileged(addServlet,
+new Object[]{servletName, servletClass.getName()});
 } else {
 return context.addServlet(servletName, servletClass);
 }



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

svn commit: r1511221 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ApplicationContextFacade.java webapps/docs/changelog.xml

Author: markt
Date: Wed Aug  7 09:23:07 2013
New Revision: 1511221

URL: http://svn.apache.org/r1511221
Log:
When using a security manager always use the same method inside the 
doPrivileged call as triggered the call.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)

tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1511217

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java?rev=1511221r1=1511220r2=1511221view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContextFacade.java
 Wed Aug  7 09:23:07 2013
@@ -462,7 +462,8 @@ public class ApplicationContextFacade im
 Class? extends Filter filterClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 return (FilterRegistration.Dynamic) doPrivileged(addFilter,
-new Object[]{filterName, filterClass.getName()});
+new Class[]{String.class, Class.class},
+new Object[]{filterName, filterClass});
 } else {
 return context.addFilter(filterName, filterClass);
 }
@@ -530,7 +531,8 @@ public class ApplicationContextFacade im
 Class? extends Servlet servletClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 return (ServletRegistration.Dynamic) doPrivileged(addServlet,
-new Object[]{servletName, servletClass.getName()});
+new Class[]{String.class, Class.class},
+new Object[]{servletName, servletClass});
 } else {
 return context.addServlet(servletName, servletClass);
 }
@@ -630,7 +632,8 @@ public class ApplicationContextFacade im
 public void addListener(Class? extends EventListener listenerClass) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 doPrivileged(addListener,
-new Object[]{listenerClass.getName()});
+new Class[]{Class.class},
+new Object[]{listenerClass});
 } else {
 context.addListener(listenerClass);
 }
@@ -652,7 +655,8 @@ public class ApplicationContextFacade im
 public T extends EventListener void addListener(T t) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
 doPrivileged(addListener,
-new Object[]{t.getClass().getName()});
+new Class[]{EventListener.class},
+new Object[]{t});
 } else {
 context.addListener(t);
 }
@@ -683,9 +687,7 @@ public class ApplicationContextFacade im
 @Override
 public void declareRoles(String... roleNames) {
 if (SecurityUtil.isPackageProtectionEnabled()) {
-//FIXME
-doPrivileged(declareRoles,
-new Object[]{roleNames});
+doPrivileged(declareRoles, new Object[]{roleNames});
 } else {
 context.declareRoles(roleNames);
 }

Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1511221r1=1511220r2=1511221view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Aug  7 09:23:07 2013
@@ -101,6 +101,12 @@
 bug55333/bug: Correct a regression in the fix for bug55071/bug.
 (markt)
   /fix
+  fix
+When using a security manager, ensure that calls to the ServletContext
+that are routed via an codeAccessController.doPrivileged/code block
+do not result in a call to a different underlying method on the
+ServletContext. (markt)
+  /fix
 /changelog
   /subsection
   subsection name=Coyote



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

Re: jaasrealm regression

On 07/08/2013 10:33, Romain Manni-Bucau wrote:
 ok, sorry
 
 i basically just set up a simple war sample using tomee maven plugin (but
 for the part we speak about only tomcat is relevant). This sample was using
 JAASRealm with the default LoginModule of tomee (properties one if you
 care).
 
 IIRC before when the setup was wrong you get an error message saying the
 jaas file is not found or not correctly set. When i first tested with a
 wrong path i didn't get it but my login just failed.

I've just been through the JRE source and the code path is identical
between:
- prior to this fix
- post this fix with no web-app specific config.

Therefore, any error message you got before, you will get now.

 The point is IMO tomcat impl totally relies on JAAS for error cases. Since
 there is an init phase (getConfig()) i think it could check the config a
 bit more to log an explicit error message (it should check configFile of
 course but the jaas system property too).
 
 Is it clearer?

Yes. What you describe is an enhancement request. Personally, I'd ensure
that any exception that is thrown by LoginConfig is visible to in the
Tomcat logs (if it isn't already) rather than adding additional checks
to getConfig(). Obviously the user will just see a failed login.

Mark

 
 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*
 
 
 
 2013/8/7 Mark Thomas ma...@apache.org
 
 On 07/08/2013 10:21, Romain Manni-Bucau wrote:
 well maybe it does (surely since that's the LoginContext behavior) but
 error is not obvious at all.

 I didn't got time to dig deeper into it but i think you are right and the
 main issue is the error message which should be more explicit saying
 configFile was not set and system property is missing or wrong.

 What error message?

 wdyt?

 I think you need to be a lot clearer about what the problem is. A good
 problem definition should include:
 - what you did from a clean install
 - what happened that you didn't expect to happen
 - what didn't happen that you expected to happen

 So far your messages on this topic make little sense to someone who is
 not sat in front of your computer and has no knowledge of what you have
 tested and how.

 Mark


 PS: i changed of JVM version too, maybe LoginContext was modified, i
 didn't
 check this neither.

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*



 2013/8/7 Mark Thomas ma...@apache.org

 On 06/08/2013 08:51, Romain Manni-Bucau wrote:
 Hi

 it seems we can now configure jaasrealm to use a jaas config file from
 the
 webapp. That's great but it would need to fallback to old behavior
 (jaas
 system property to find its location) by default otherwise apps using
 an
 older tomcat are broken.

 wdyt?

 What makes you think it doesn't fall-back to the old behaviour if no
 webapp specific file is specified?

 Here is the commit:
 http://svn.apache.org/viewvc?view=revisionrevision=1498498

 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


 


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

[Bug 55365] Server fails to start with security on due to websocket classes

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

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

   What|Removed |Added

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

-- 
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 55365] Server fails to start with security on due to websocket classes

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

--- Comment #2 from Mark Thomas ma...@apache.org ---
This has been fixed in trunk (along with some related issues) and will be
included in 8.0.0-RC2. It has also been back-ported to 7.0.x where it will be
included in 7.0.43 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

Re: Fixing bug 55365

2013-08-07 Thread Konstantin Kolinko

2013/8/6 Mark Thomas ma...@apache.org:
 Rainer (or anyone else that can figure this out),

 I am in the process of fixing [1] and find myself having to revert some
 of one of your commits [2]. My concern is that I can't figure out what
 problem [2] was meant to solve and how it solves it.

 The problem is that the WsSessionListener does not have a zero-arg
 constructor. There is a statement in Servlet 3.1 section 11.3.1 that
 indicates that it should, be that looks to be out-dated and aimed at
 web.xml configuration (where a zero arg constructor is obviously required).

 Mark

 [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55365
 [2] http://svn.apache.org/viewvc?view=revisionrevision=932969



Looking at [2],

+classCache.put(addFilter, new Class[]{String.class, String.class});

in Servlet 3.0 there are 3 different methods with the same name

public FilterRegistration.Dynamic addFilter(String filterName,
String className) {

public FilterRegistration.Dynamic addFilter(String filterName,
Filter filter) {

public FilterRegistration.Dynamic addFilter(String filterName,
Class? extends Filter filterClass) {

Using classCache for their argument types is a bit confusing.
Thus one method of the three there should use  doPriviledged(...,
Object[]) and benefit from caching and two others should use
doPriviledged(..., Class[], Object[]) and bypass the cache.

From r1511217 I think you have already figured this.

Best regards,
Konstantin Kolinko

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

Re: jaasrealm regression

2013-08-07 Thread Romain Manni-Bucau

you are probably right but having the check the path you specified doesn't
exist is quite easy and would be a nice enhancement  (it is common to
think the config is right when it is wrong).

*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/8/7 Mark Thomas ma...@apache.org

 On 07/08/2013 10:33, Romain Manni-Bucau wrote:
  ok, sorry
 
  i basically just set up a simple war sample using tomee maven plugin (but
  for the part we speak about only tomcat is relevant). This sample was
 using
  JAASRealm with the default LoginModule of tomee (properties one if you
  care).
 
  IIRC before when the setup was wrong you get an error message saying the
  jaas file is not found or not correctly set. When i first tested with a
  wrong path i didn't get it but my login just failed.

 I've just been through the JRE source and the code path is identical
 between:
 - prior to this fix
 - post this fix with no web-app specific config.

 Therefore, any error message you got before, you will get now.

  The point is IMO tomcat impl totally relies on JAAS for error cases.
 Since
  there is an init phase (getConfig()) i think it could check the config a
  bit more to log an explicit error message (it should check configFile of
  course but the jaas system property too).
 
  Is it clearer?

 Yes. What you describe is an enhancement request. Personally, I'd ensure
 that any exception that is thrown by LoginConfig is visible to in the
 Tomcat logs (if it isn't already) rather than adding additional checks
 to getConfig(). Obviously the user will just see a failed login.

 Mark

 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
  2013/8/7 Mark Thomas ma...@apache.org
 
  On 07/08/2013 10:21, Romain Manni-Bucau wrote:
  well maybe it does (surely since that's the LoginContext behavior) but
  error is not obvious at all.
 
  I didn't got time to dig deeper into it but i think you are right and
 the
  main issue is the error message which should be more explicit saying
  configFile was not set and system property is missing or wrong.
 
  What error message?
 
  wdyt?
 
  I think you need to be a lot clearer about what the problem is. A good
  problem definition should include:
  - what you did from a clean install
  - what happened that you didn't expect to happen
  - what didn't happen that you expected to happen
 
  So far your messages on this topic make little sense to someone who is
  not sat in front of your computer and has no knowledge of what you have
  tested and how.
 
  Mark
 
 
  PS: i changed of JVM version too, maybe LoginContext was modified, i
  didn't
  check this neither.
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
  2013/8/7 Mark Thomas ma...@apache.org
 
  On 06/08/2013 08:51, Romain Manni-Bucau wrote:
  Hi
 
  it seems we can now configure jaasrealm to use a jaas config file
 from
  the
  webapp. That's great but it would need to fallback to old behavior
  (jaas
  system property to find its location) by default otherwise apps using
  an
  older tomcat are broken.
 
  wdyt?
 
  What makes you think it doesn't fall-back to the old behaviour if no
  webapp specific file is specified?
 
  Here is the commit:
  http://svn.apache.org/viewvc?view=revisionrevision=1498498
 
  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
 
 
 


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

Re: Fixing bug 55365

On 07/08/2013 12:11, Konstantin Kolinko wrote:
 From r1511217 I think you have already figured this.

I hadn't figured out the classcache was the root cause but I had figured
out the fix.

It does mean a very small performance hit but I'm not concerned about
that at this point as this is web application init code.

Mark


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

Re: [VOTE] Release Apache Taglibs 1.2.0-RC1

2013-08-07 Thread sebb

On 2 August 2013 20:32, Jeremy Boynes jboy...@apache.org wrote:
A proposed release candidate Apache Taglibs 1.2.0-RC1 is now available for
voting.

This is release candidate for an implementation of JSTL 1.2 and can be
obtained from the staging repo at:
https://repository.apache.org/content/repositories/orgapachetomcat-053/

The source distribution can be obtained from:

https://repository.apache.org/content/repositories/orgapachetomcat-053/org/apache/taglibs/taglibs-standard/1.2.0-RC1/

The proposed 1.2.0-RC1 candidate is:
[X] Broken - do not release
[ ] Alpha - can be released as 1.2.0-RC1 alpha

This is the first release in a long time, and the first since switching to
Maven. If there are issues, please list all concerns so they can be addressed.

Please include the SVN tag and revision number in all vote e-mails.

Otherwise it's not possible to check provenance of the the source files.
Nor can one check if there are files missing from the source archive
(or accidentally added).

A link to the KEYS file should also be included so the sigs can be checked.

The NOTICE file says:

Apache Tomcat Standard Taglib
Copyright 2001-2012 The Apache Software Foundation

This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).

The year should possibly be updated to 2013.

developed by MUST be changed to developed at

The NOTICE files in the META-INF jar directories don't have the full
name of the component. The name must include the Apache Tomcat
Standard Taglib prefix. However, the NOTICE files do say developed
at.

There are several files without AL headers.

Several source files contain the SVN tag $Date$.
This is generated using the local timezone, so the source archive will
be different depending where it is generated. Best to avoid $Date$; if
you want a date, use $Id$ instead, though $Revision$ should be
sufficient.

The source archive top-level directory includes the suffix RC1; that is unusual.

The file JSTLVariableStackTest.java does not have svn:eolstyle native set.
The file ParamSupport.java is marked as executable in SVN props.

Thanks
Jeremy

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

[Bug 55357] Cannot deserialize session when it contains Externalizable objects (using PersistentManager)

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

maxime.fala...@gmail.com changed:

   What|Removed |Added

 OS||All

--- Comment #1 from maxime.fala...@gmail.com ---
My workaround to make it working is to add
Thread.currentThread().setContextClassLoader(classLoader) in the JDBCStore
(between line 644 and 645 in method load(String):Session) :

if (classLoader != null)
   Thread.currentThread().setContextClassLoader(classLoader);
   ois = new CustomObjectInputStream(bis, classLoader);
} else {
   ois = new ObjectInputStream(bis);
}

Maybe add a try catch to catch the SecurityException thrown by the
setContextClassLoader method.

-- 
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: Use (or not) of @SuppressWarnings

2013-08-07 Thread Nick Williams


On Aug 7, 2013, at 2:41 AM, Mark Thomas wrote:

 For trunk we have been running a policy of zero warnings in the code.
 This has helped to highlight issues as code is edited as any warnings
 are immediately clear. Obviously, this depends on what warnings are enabled.
 
 Currently, we use Eclipse's Ignore unavoidable generic type problems.
 Recently a couple of issues has been highlighted with this:
 1. Other IDEs might not have this setting.
 2. javac does not have this setting
 3. Some of the problems Eclipse excludes are avoidable (well, sort of
 avoidable as avoiding them requires using JRE methods that themselves
 have @SuppressWarnings annotations).
 
 In favour of the current situation is that it reduces clutter in the
 code base slightly.
 
 While I am all for reducing clutter in the code base, there do appear to
 be good reasons for disabling the Ignore unavoidable generic type
 problems. and using @SuppressWarnings instead.
 
 Personally, I am happy with the current settings but not unhappy to
 change. I guess that makes me +0 on changing. What does everyone else think?

(Non-binding)

As stated earlier, I am fundamentally opposed to the concept of using an 
IDE-specific setting to decide how a project writes code. This practically 
forces all developers to use that IDE exclusively for that project. If I'm 
writing Tomcat code in IntelliJ IDE and I create a warning, I have no idea 
whether I should correct the warning or not, because I have no idea what 
Eclipse has to say about it.

I do, however, know that the warning will show up when I compile, and I think 
that's what matters most. We should make efforts to eliminate all warnings that 
show up when we compile, whether Eclipse calls them unavoidable or not.

My $0.02.

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

[Bug 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #2 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30687
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30687action=edit
part 1 of 25

Sorry about the huge war file. It contains only one jar, but this is necessary
to demonstrate the affect.
(I beleave that the remaining jar file has no place inside my webapp; this is
an internal question inside my company. But the question is: Why does Jasper
crash?)

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #3 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30688
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30688action=edit
part 2 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #4 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30689
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30689action=edit
part 3 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #5 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30690
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30690action=edit
part 4 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #6 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30691
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30691action=edit
part 3 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #7 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30692
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30692action=edit
part 6 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #8 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30693
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30693action=edit
part 7 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #9 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30694
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30694action=edit
part 8 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #10 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30695
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30695action=edit
part 9 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #11 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30696
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30696action=edit
part 10 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #12 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30697
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30697action=edit
part 11 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #13 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30698
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30698action=edit
part 11 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

Ingolf Knopf iknopf.bxu...@csc-dd.de changed:

   What|Removed |Added

  Attachment #30691|part 3 of 25|part 5 of 25
description||

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

Ingolf Knopf iknopf.bxu...@csc-dd.de changed:

   What|Removed |Added

  Attachment #30698|part 11 of 25   |part 12 of 25
description||

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #14 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30699
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30699action=edit
part 13 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #15 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30700
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30700action=edit
part 14 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #16 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30701
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30701action=edit
part 15 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #17 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30702
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30702action=edit
part 16 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #18 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30703
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30703action=edit
part 17 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #20 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30705
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30705action=edit
part 19 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #19 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30704
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30704action=edit
part 18 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #21 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30706
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30706action=edit
part 20 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #22 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30707
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30707action=edit
part 21 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #23 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30708
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30708action=edit
part 22 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #24 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30709
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30709action=edit
part 23 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #26 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30711
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30711action=edit
part 25 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #25 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Created attachment 30710
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=30710action=edit
part 24 of 25

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

Ingolf Knopf iknopf.bxu...@csc-dd.de changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #27 from Ingolf Knopf iknopf.bxu...@csc-dd.de ---
Please concat all my attachments into 1 war file an deploy it.

Good luck!

-- 
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: Use (or not) of @SuppressWarnings

2013-08-07 Thread Jeremy Boynes

On Aug 7, 2013, at 12:41 AM, Mark Thomas ma...@apache.org wrote:

 For trunk we have been running a policy of zero warnings in the code.
 This has helped to highlight issues as code is edited as any warnings
 are immediately clear. Obviously, this depends on what warnings are enabled.
 
 Currently, we use Eclipse's Ignore unavoidable generic type problems.
 Recently a couple of issues has been highlighted with this:
 1. Other IDEs might not have this setting.
 2. javac does not have this setting
 3. Some of the problems Eclipse excludes are avoidable (well, sort of
 avoidable as avoiding them requires using JRE methods that themselves
 have @SuppressWarnings annotations).
 
 In favour of the current situation is that it reduces clutter in the
 code base slightly.
 
 While I am all for reducing clutter in the code base, there do appear to
 be good reasons for disabling the Ignore unavoidable generic type
 problems. and using @SuppressWarnings instead.
 
 Personally, I am happy with the current settings but not unhappy to
 change. I guess that makes me +0 on changing. What does everyone else think?

I would prefer to use @SuppressWarnings for this rather than an IDE setting as 
that keeps the information in the code.
A stronger +1 for changing.
--
Jeremy


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Use (or not) of @SuppressWarnings

2013-08-07 Thread Brian Burch


On 07/08/13 14:14, Nick Williams wrote:


On Aug 7, 2013, at 2:41 AM, Mark Thomas wrote:


For trunk we have been running a policy of zero warnings in the code.
This has helped to highlight issues as code is edited as any warnings
are immediately clear. Obviously, this depends on what warnings are enabled.

Currently, we use Eclipse's Ignore unavoidable generic type problems.
Recently a couple of issues has been highlighted with this:
1. Other IDEs might not have this setting.
2. javac does not have this setting
3. Some of the problems Eclipse excludes are avoidable (well, sort of
avoidable as avoiding them requires using JRE methods that themselves
have @SuppressWarnings annotations).

In favour of the current situation is that it reduces clutter in the
code base slightly.

While I am all for reducing clutter in the code base, there do appear to
be good reasons for disabling the Ignore unavoidable generic type
problems. and using @SuppressWarnings instead.

Personally, I am happy with the current settings but not unhappy to
change. I guess that makes me +0 on changing. What does everyone else think?


(Non-binding)

As stated earlier, I am fundamentally opposed to the concept of using an 
IDE-specific setting to decide how a project writes code. This practically 
forces all developers to use that IDE exclusively for that project. If I'm 
writing Tomcat code in IntelliJ IDE and I create a warning, I have no idea 
whether I should correct the warning or not, because I have no idea what 
Eclipse has to say about it.

I do, however, know that the warning will show up when I compile, and I think that's what 
matters most. We should make efforts to eliminate all warnings that show up when we 
compile, whether Eclipse calls them unavoidable or not.

My $0.02.


OK, I'll add my non-binding penny.

I use netbeans exclusively. I get warnings about import order from 
almost every tc source file. Periodically I scratch around looking for 
the rules template so I can change them to conform with the ant 
checkstyle rules, which are happy with the current import order. So far, 
no luck, so I live with netbeans nagging and resist the temptation to 
let it re-order the imports for me.


I think ant should compile without warnings. I think we should all put 
up with whatever our ide's bleat about... or figure out how to coerce 
them to follow the external/common build code style rules.



Nick
-
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 55314] Provide option to allow programmatic deployment of server (WebSocket) endpoint at runtime

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

--- Comment #7 from Mark Thomas ma...@apache.org ---
I've done some refactoring locally. Would the following method on
WsServerContainer meet you requirements?

public void doUpgrade(
HttpServletRequest request,
HttpServletResponse response,
ServerEndpointConfig sec,
MapString,String pathParams)
throws ServletException, IOException

-- 
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: [Bug 55372] Bind JPDA_ADDRESS by default to localhost

2013-08-07 Thread Brian Burch


On 07/08/13 09:32, bugzi...@apache.org wrote:

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

--- Comment #5 from Michael Osipov 1983-01...@gmx.net ---
(In reply to Mark Thomas from comment #4)

[..]

res/ide-support/netbeans/README.txt. Was that intentional? Though, I do not
know how to port forward a port with RDP.


netbeans I know nothing about.


This is a user guide. Nothing crucial but examples should resemble the
catalina.sh settings.


The appropriate section of the netbeans README is:

   The external Tomcat instance must be started with its jvm enabled for
   debugging by adding extra arguments to JAVA_OPTS, e.g.
   -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

This paragraph is (I think) ide-agnostic, and refers to setting up the 
server for debugging by any local or remote client.


I use nix and my catalina.sh is started by /etc/init.d/tomcatX, which 
primes JAVA_OPTS when I want debugging. I've just checked catalina.sh 
and noticed there are four JPDA_* parameters too.


My first thought is to leave the README alone. Anyone wanting to use 
netbeans to debug tomcat on a different host ought not to be spoon-fed. 
On the other hand, given the comment is related to a change where by 
default tc will not listen on any interface except lo, perhaps I should 
say so in the README. How far is far enough? wdyt?


Brian


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

[Bug 55367] cannot compile JSPs while Vaadin webapp is deployed

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

--- Comment #28 from Mark Thomas ma...@apache.org ---
There is a 1MB upload limit in Bugzilla for a reason. It is not there just to
provide a few hoops to jump through if you want to upload a larger file. In
future, if you hit a limit on *any* ASF service ask rather than trying to
circumvent it. Circumventing limits is the sort of behaviour that gets accounts
disabled and IP addresses blocked.

-- 
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 55367] cannot compile JSPs while Vaadin webapp is deployed

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #29 from Mark Thomas ma...@apache.org ---
That JAR file has no place in a web application as it includes a copy of the
Jasper, the JSP compiler that is part of Apache Tomcat. That conflicts with the
version included with Tomcat and JSP compilation breaks.

Tomcat is protected from things like this iff the security manager is enabled.

A quick look at Vaadin's web site suggests this JAR is not intended for server
side user anyway. The name vaadin-client-compiler-7.0.7.jar is also a broad
hint it is not intended for server-side use.

-- 
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: r1511434 - /tomcat/trunk/bin/catalina.sh

Author: markt
Date: Wed Aug  7 18:44:32 2013
New Revision: 1511434

URL: http://svn.apache.org/r1511434
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45428
Trigger a thread dump to aid diagnostics if Tomcat fails to stop in a timely 
manner.

Modified:
tomcat/trunk/bin/catalina.sh

Modified: tomcat/trunk/bin/catalina.sh
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?rev=1511434r1=1511433r2=1511434view=diff
==
--- tomcat/trunk/bin/catalina.sh (original)
+++ tomcat/trunk/bin/catalina.sh Wed Aug  7 18:44:32 2013
@@ -461,7 +461,8 @@ elif [ $1 = stop ] ; then
 fi
 if [ $SLEEP -eq 0 ]; then
   if [ $FORCE -eq 0 ]; then
-echo Tomcat did not stop in time. PID file was not removed.
+echo Tomcat did not stop in time. PID file was not removed. To 
aid diagnostics a thread dump has been written to standard out.
+kill -3 `cat $CATALINA_PID`
   fi
 fi
 SLEEP=`expr $SLEEP - 1 `



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

svn commit: r1511436 - in /tomcat/tc7.0.x/trunk: ./ bin/catalina.sh webapps/docs/changelog.xml

Author: markt
Date: Wed Aug  7 18:49:37 2013
New Revision: 1511436

URL: http://svn.apache.org/r1511436
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45428
Trigger a thread dump to aid diagnostics if Tomcat fails to stop in a timely 
manner.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/bin/catalina.sh
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1511434

Modified: tomcat/tc7.0.x/trunk/bin/catalina.sh
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/bin/catalina.sh?rev=1511436r1=1511435r2=1511436view=diff
==
--- tomcat/tc7.0.x/trunk/bin/catalina.sh (original)
+++ tomcat/tc7.0.x/trunk/bin/catalina.sh Wed Aug  7 18:49:37 2013
@@ -461,7 +461,8 @@ elif [ $1 = stop ] ; then
 fi
 if [ $SLEEP -eq 0 ]; then
   if [ $FORCE -eq 0 ]; then
-echo Tomcat did not stop in time. PID file was not removed.
+echo Tomcat did not stop in time. PID file was not removed. To 
aid diagnostics a thread dump has been written to standard out.
+kill -3 `cat $CATALINA_PID`
   fi
 fi
 SLEEP=`expr $SLEEP - 1 `

Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1511436r1=1511435r2=1511436view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Aug  7 18:49:37 2013
@@ -224,6 +224,11 @@
   /subsection
   subsection name=Other
 changelog
+  add
+bug45428/bug: Trigger a thread dump written to standard out if
+Tomcat fails to stop in a timely manner to aid diagnostics. This is 
only
+available on platforms that use codecatalina.sh/code. (markt)
+  /add
   fix
 bug55204/bug: Correct namespace used in Servlet 2.4 test web 
 application. Patch provided by Jeremy Boynes. (markt)



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

Re: Use (or not) of @SuppressWarnings

2013-08-07 Thread Konstantin Kolinko

2013/8/7 Brian Burch br...@pingtoo.com:

 I use netbeans exclusively. I get warnings about import order from almost
 every tc source file. Periodically I scratch around looking for the rules
 template so I can change them to conform with the ant checkstyle rules,
 which are happy with the current import order. So far, no luck, so I live
 with netbeans nagging and resist the temptation to let it re-order the
 imports for me.



Imports order is not IDE-specific. It is enforced via checkstyle.

The order of import groups should be configurable in your IDE.

I have never used NetBeans, but there is a screenshot of configuration dialog:
http://plugins.netbeans.org/data/images/1307540397_organizeImports.png

Best regards,
Konstantin Kolinko

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

[Bug 45428] warn if the tomcat stop doesn't complete

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Catalina|Catalina
Version|6.0.16  |7.0.42
 Resolution|--- |FIXED
Product|Tomcat 6|Tomcat 7
   Target Milestone|default |---

--- Comment #1 from Mark Thomas ma...@apache.org ---
This has been fixed in trunk and will be included in 8.0.0-RC2 onwards.

This has been back-ported to 7.0.x and will be included in 7.0.43 onwards.

The enhancement only applies to platforms that usr catalina.sh.

A thread dump is triggered if the stop command fails to complete in a timely
manner. Note that detetcing a failure to stop requires that $CATALINA_PID is
set.

This will not be back-ported to 6.0.x.

-- 
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 55381] New: Issue with the Non Blocking API TestNonBlockingAPI test

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

Bug ID: 55381
   Summary: Issue with the Non Blocking API  TestNonBlockingAPI
test
   Product: Tomcat 8
   Version: trunk
  Hardware: PC
OS: Mac OS X 10.4
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: dmik...@gopivotal.com

Looking at the the NBReadServlet class included in TestNonBlockingAPI, the
class appears to be directly calling the ReadListener.onDataAvailable() method.

@WebServlet(asyncSupported = true)
public class NBReadServlet extends TesterServlet {
   private static final long serialVersionUID = 1L;
   public volatile TestReadListener listener;
   @Override
   protected void service(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
   // step 1 - start async
   AsyncContext actx = req.startAsync();
   actx.setTimeout(Long.MAX_VALUE);
   actx.addListener(new AsyncListener() {
   // removed for brevity 
   });
   // step 2 - notify on read
   ServletInputStream in = req.getInputStream();
   listener = new TestReadListener(actx);
   in.setReadListener(listener);

   listener.onDataAvailable();
   }
}

In Section 3.7 of the spec it says...

The onDataAvailable method is invoked on the ReadListener when data is
available to read from the incoming request stream. The container will invoke
the method the first time when data is available to read. The container will
subsequently invoke the onDataAvailable method if and only if isReady method on
ServletInputStream, described below, returns false.

...which leads me to believe that the container should be calling
onDataAvailable and not the servlet.

If the line listener.onDataAvailable() is removed from the test, then the
test will hang and ReadListener.onDataAvailable() is never called.


The same is true with the NBWriteServlet in TestNonBlockingAPI and the
WriteListener.onWritePossible() method.  The NBWriteServlet is calling this
method directly, while the spec seems to indicate that it should be called by
the container.

void onWritePossible(). When a WriteListener is registered with the
ServletOutputStream, this method will be invoked by the container the first
time when it is possible to write data. The container will subsequently invoke
the onWritePossible method if and only if isReady method on
ServletOutputStream, described below, returns false.

Thanks

-- 
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: r1511448 - in /tomcat/trunk: java/org/apache/catalina/connector/Connector.java webapps/docs/changelog.xml webapps/docs/config/ajp.xml webapps/docs/config/http.xml webapps/docs/config/syste

Author: markt
Date: Wed Aug  7 19:20:51 2013
New Revision: 1511448

URL: http://svn.apache.org/r1511448
Log:
Part of fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=48550
Change the default URIEncoding for all connectors to UTF-8.

Modified:
tomcat/trunk/java/org/apache/catalina/connector/Connector.java
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/config/ajp.xml
tomcat/trunk/webapps/docs/config/http.xml
tomcat/trunk/webapps/docs/config/systemprops.xml

Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=1511448r1=1511447r2=1511448view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Wed Aug  7 
19:20:51 2013
@@ -24,6 +24,7 @@ import java.util.Locale;
 
 import javax.management.ObjectName;
 
+import org.apache.catalina.Globals;
 import org.apache.catalina.LifecycleException;
 import org.apache.catalina.LifecycleState;
 import org.apache.catalina.Service;
@@ -77,6 +78,11 @@ public class Connector extends Lifecycle
 } finally {
 this.protocolHandler = p;
 }
+
+if (!Globals.STRICT_SERVLET_COMPLIANCE) {
+URIEncoding = UTF-8;
+URIEncodingLower = URIEncoding.toLowerCase(Locale.ENGLISH);
+}
 }
 
 

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1511448r1=1511447r2=1511448view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Aug  7 19:20:51 2013
@@ -169,6 +169,10 @@
   scode
 Refactor char encoding/decoding using NIO APIs. (remm)
   /scode
+  update
+Change the default URIEncoding for all connectors from ISO-8859-1 to
+UTF-8. (markt)
+  /update
 /changelog
   /subsection
   subsection name=Jasper

Modified: tomcat/trunk/webapps/docs/config/ajp.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/ajp.xml?rev=1511448r1=1511447r2=1511448view=diff
==
--- tomcat/trunk/webapps/docs/config/ajp.xml (original)
+++ tomcat/trunk/webapps/docs/config/ajp.xml Wed Aug  7 19:20:51 2013
@@ -226,8 +226,10 @@
 
 attribute name=URIEncoding required=false
   pThis specifies the character encoding used to decode the URI bytes,
-  after %xx decoding the URL. If not specified, ISO-8859-1 will be used.
-  /p
+  after %xx decoding the URL. If not specified, UTF-8 will be used unless
+  the codeorg.apache.catalina.STRICT_SERVLET_COMPLIANCE/code
+  a href=systemprops.htmlsystem property/a is set to 
codetrue/code
+  in which case ISO-8859-1 will be used./p
 /attribute
 
 attribute name=useBodyEncodingForURI required=false

Modified: tomcat/trunk/webapps/docs/config/http.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1511448r1=1511447r2=1511448view=diff
==
--- tomcat/trunk/webapps/docs/config/http.xml (original)
+++ tomcat/trunk/webapps/docs/config/http.xml Wed Aug  7 19:20:51 2013
@@ -225,8 +225,10 @@
 
 attribute name=URIEncoding required=false
   pThis specifies the character encoding used to decode the URI bytes,
-  after %xx decoding the URL. If not specified, ISO-8859-1 will be used.
-  /p
+  after %xx decoding the URL. If not specified, UTF-8 will be used unless
+  the codeorg.apache.catalina.STRICT_SERVLET_COMPLIANCE/code
+  a href=systemprops.htmlsystem property/a is set to 
codetrue/code
+  in which case ISO-8859-1 will be used./p
 /attribute
 
 attribute name=useBodyEncodingForURI required=false

Modified: tomcat/trunk/webapps/docs/config/systemprops.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/systemprops.xml?rev=1511448r1=1511447r2=1511448view=diff
==
--- tomcat/trunk/webapps/docs/config/systemprops.xml (original)
+++ tomcat/trunk/webapps/docs/config/systemprops.xml Wed Aug  7 19:20:51 2013
@@ -288,6 +288,9 @@
   
licodeorg.apache.tomcat.util.http.br/ServerCookie.ALWAYS_ADD_EXPIRES/code/li
   
licodeorg.apache.tomcat.util.http.br/ServerCookie.FWD_SLASH_IS_SEPARATOR/code/li
   
licodeorg.apache.tomcat.util.http.br/ServerCookie.STRICT_NAMING/code/li
+  liThe codeURIEncoding/code attribute of any
+  a href=http.htmlHTTP connector/a or
+  a href=ajp.htmlAJP connector/aelement./li
   liThe coderesourceOnlyServlets/code attribute of any

[Bug 48550] Update examples and default server.xml to use UTF-8

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

--- Comment #9 from Mark Thomas ma...@apache.org ---
Part 1 of the 4 tasks in the description has been completed for trunk (a.k.a
8.0.x)

-- 
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: r1511453 - /tomcat/trunk/webapps/examples/WEB-INF/web.xml

Author: markt
Date: Wed Aug  7 19:37:39 2013
New Revision: 1511453

URL: http://svn.apache.org/r1511453
Log:
Part of fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=48550
Enable the character encoding filter for the examples web-app with UTF-8.

Modified:
tomcat/trunk/webapps/examples/WEB-INF/web.xml

Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1511453r1=1511452r2=1511453view=diff
==
--- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original)
+++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Wed Aug  7 19:37:39 2013
@@ -48,11 +48,11 @@
 
filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter-class
 init-param
 param-nameencoding/param-name
-param-valueEUC_JP/param-value
+param-valueUTF-8/param-value
 /init-param
 init-param
 param-nameignore/param-name
-param-valuetrue/param-value
+param-valuefalse/param-value
 /init-param
 /filter
 
@@ -87,12 +87,10 @@
 
 !-- Example filter mapping to apply the Set Character Encoding filter
  to *all* requests processed by this web application --
-!--
 filter-mapping
 filter-nameSet Character Encoding/filter-name
 url-pattern/*/url-pattern
 /filter-mapping
---
 
 !--
 filter-mapping



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

svn commit: r1511463 - in /tomcat/trunk/webapps/examples/jsp: cal/cal1.jsp cal/cal2.jsp jsp2/el/functions.jsp jsp2/el/implicit-objects.jsp

Author: markt
Date: Wed Aug  7 20:00:51 2013
New Revision: 1511463

URL: http://svn.apache.org/r1511463
Log:
Part of fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=48550
Make sure JSPs that could output UTF-8 mark the content as UTF-8. I think I 
found all the places where this needed to be changed.

Modified:
tomcat/trunk/webapps/examples/jsp/cal/cal1.jsp
tomcat/trunk/webapps/examples/jsp/cal/cal2.jsp
tomcat/trunk/webapps/examples/jsp/jsp2/el/functions.jsp
tomcat/trunk/webapps/examples/jsp/jsp2/el/implicit-objects.jsp

Modified: tomcat/trunk/webapps/examples/jsp/cal/cal1.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/jsp/cal/cal1.jsp?rev=1511463r1=1511462r2=1511463view=diff
==
--- tomcat/trunk/webapps/examples/jsp/cal/cal1.jsp (original)
+++ tomcat/trunk/webapps/examples/jsp/cal/cal1.jsp Wed Aug  7 20:00:51 2013
@@ -14,6 +14,7 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 --%
+%@page contentType=text/html; charset=UTF-8 %
 HTML
 HEADTITLE
 Calendar: A JSP APPLICATION

Modified: tomcat/trunk/webapps/examples/jsp/cal/cal2.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/jsp/cal/cal2.jsp?rev=1511463r1=1511462r2=1511463view=diff
==
--- tomcat/trunk/webapps/examples/jsp/cal/cal2.jsp (original)
+++ tomcat/trunk/webapps/examples/jsp/cal/cal2.jsp Wed Aug  7 20:00:51 2013
@@ -14,6 +14,7 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 --%
+%@page contentType=text/html; charset=UTF-8 %
 HTML
 HEADTITLE
 Calendar: A JSP APPLICATION

Modified: tomcat/trunk/webapps/examples/jsp/jsp2/el/functions.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/jsp/jsp2/el/functions.jsp?rev=1511463r1=1511462r2=1511463view=diff
==
--- tomcat/trunk/webapps/examples/jsp/jsp2/el/functions.jsp (original)
+++ tomcat/trunk/webapps/examples/jsp/jsp2/el/functions.jsp Wed Aug  7 20:00:51 
2013
@@ -14,6 +14,7 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 --%
+%@page contentType=text/html; charset=UTF-8 %
 %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %
 %@ taglib prefix=my uri=http://tomcat.apache.org/jsp2-example-taglib%
 

Modified: tomcat/trunk/webapps/examples/jsp/jsp2/el/implicit-objects.jsp
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/jsp/jsp2/el/implicit-objects.jsp?rev=1511463r1=1511462r2=1511463view=diff
==
--- tomcat/trunk/webapps/examples/jsp/jsp2/el/implicit-objects.jsp (original)
+++ tomcat/trunk/webapps/examples/jsp/jsp2/el/implicit-objects.jsp Wed Aug  7 
20:00:51 2013
@@ -14,6 +14,7 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 --%
+%@page contentType=text/html; charset=UTF-8 %
 %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; %
 
 html



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

svn commit: r1511468 - /tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java

Author: markt
Date: Wed Aug  7 20:07:15 2013
New Revision: 1511468

URL: http://svn.apache.org/r1511468
Log:
Part of fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=48550
Make sure Servlets that could output UTF-8 mark the content as UTF-8. I think I 
found all the places where this needed to be changed. The other possible places 
involve HTTP headers so must be ISO-8859-1.

Modified:
tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java

Modified: tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java?rev=1511468r1=1511467r2=1511468view=diff
==
--- tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java (original)
+++ tomcat/trunk/webapps/examples/WEB-INF/classes/SessionExample.java Wed Aug  
7 20:07:15 2013
@@ -49,7 +49,7 @@ public class SessionExample extends Http
   HttpServletResponse response)
 throws IOException, ServletException
 {
-response.setContentType(text/html);
+response.setContentType(text/html;charset=UTF-8);
 
 PrintWriter out = response.getWriter();
 out.println(html);



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

svn commit: r1511469 - /tomcat/trunk/webapps/docs/changelog.xml

Author: markt
Date: Wed Aug  7 20:09:56 2013
New Revision: 1511469

URL: http://svn.apache.org/r1511469
Log:
Update changelog

Modified:
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1511469r1=1511468r2=1511469view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Aug  7 20:09:56 2013
@@ -209,6 +209,9 @@
 application to include details of the configured SSL ciphers suites for
 each connector. (markt)
   /add
+  update
+bug48550/bug: Update exmaple web applications to use UTF-8. (markt)
+  /update
 /changelog
   /subsection
   subsection name=Tribes



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

[Bug 48550] Update examples and default server.xml to use UTF-8

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

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

   What|Removed |Added

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

--- Comment #10 from Mark Thomas ma...@apache.org ---
This has been fixed for trunk a.k.a 8.0.x and will be included in 8.0.0-RC2
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 55383] New: Improve markup and design of Tomcat's HTML pages

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

Bug ID: 55383
   Summary: Improve markup and design of Tomcat's HTML pages
   Product: Tomcat 8
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Documentation
  Assignee: dev@tomcat.apache.org
  Reporter: prei...@web.de

Hi,

I think there is room for improvements in markup and style of Tomcat's HTML
pages (e.g. to meet current HTML5 [1] standards and not using obsolete
features) in Tomcat 8.
The ROOT index.jsp has alredy greatly been improved by pidster.

There are some other occurences of HTML in Tomcat's source that I think can be
improved:
• Tomcat's error pages
• Examples webapp
• Probably also the Tomcat website (http://tomcat.apache.org/)


Some things that I think of being improvable are:

1) Use always Full Standards Mode instead of Quirks Mode or Almost
Standards Mode, as the Quirks mode is kind of a relict that browsers implement
to be able to display Websites that were written for IE = 5, which had serious
layout errors. However, current Websites should always use Standards Mode as
described in the HTML5 spec [1].
  This means that for HTML documents (text/html), always use the recommended
doctype !DOCTYPE html. For XHTML documents (application/xhtml+xml), a
doctype is not needed (as there is only Full Standards Mode), but should be
used if making polyglot documents [2].
  Note: Placing a DOCTYPE after a HTML comment (like it is done at pidster's
proposal here: http://people.apache.org/~pidster/tomcat/site/) will force IE 9
and older to use Quirks Mode; however, IE 10 and newer will use Full Standards
Mode in such case. This can be tested by using IE's F12 developer tools.

2) Don't use obsolete HTML elements or attributes, like the ones which are
replaced by CSS as they were purely used for styling and not markup (e.g.
bgcolor or align attributes, font element etc.)

3) A table element should only be used for showing real tables, not for
layouting purposes [3], like currently done at the Tomcat Website.

4) Use new HTML5 elements for structuring HTML content, like nav (marking a
navigation section), header, footer; time datetime=... for marking a
date with a machine-readable format and so on.
  HTML5 also allows to declare microdata in HTML markup using some new
attributes like itemscope, itemtype etc [9]. E.g. one can use microdata
format provided by http://schema.org/ which should be recognized by Search
Engines like Google, Bing, Yahoo and Yandex (but I don't know if this will be
useful to the Tomcat website).
  However, if we still want to support IE versions older than IE9, then care
must be taken when using new HTML elements, because IE = 8 have a special
parsing method of unknown elements compared to IE9 and other browsers. E.g., if
you have 
  myElement class=myHeaderHi!/myElement
  then the DOM in IE 9/10/11 and other browsers like Firefox represents exactly
that piece of HTML, so if they don't know what a myElement element is, they
will still use the CSS defined for class myHeader to format it. However in IE
8 and older, the DOM will look like 
  myElement/myElementHi!/myElement//myElement
  (this is not valid HTML, but the DOM actually has a element with the name
myElement and one with the name /myElement), so it will not make use of the
CSS defined for that element.  

5) Maybe also historical practices like putting CSS or Javascript into comments
(style type=...!-- .myClass {...} --/style) can be abandoned, as that
was only required for very old browsers that did not know style or script
elements, to prevent the content of such elements from appearing in a document
as text. However, I cannot think of a still supported browser that would not
recognize such elements.
  Note: For XHTML, this approach is actually wrong, because a XML parser will
treat a comment inside of a style element like a comment, which means that the
browser only sees a empty style element. There are ways to make things work if
the document should be both a HTML and a XHTML document [4], but I don't think
it makes sense (see 7) ).

6) Encodings can be set on HTML pages using meta charset=UTF-8,
alternatively to meta http-equiv=Content-Type value=text/html;
encoding=UTF-8. I think the shorter form makes more sense because the
Content-Type can only be set externally (by a Header or using a file extension)
before a browser begins with parsing the document. It seems that even IE7
supports the short variant.
  Notice that this is for HTML only; for XHTML, the encoding can specified in
the XML header declaration (?xml version=1.0 encoding=UTF-8?).
  Note: For the sake of polyglot documents (see 7) ), it is allowed that a
XHTML document also includes a meta charset=UTF-8 / - but UTF-8 is the
only permitted value in this case [8]. Then, also a XML declaration may not be
used as it is forbidden in

svn commit: r1511497 - /tomcat/trunk/java/org/apache/juli/OneLineFormatter.java

Author: markt
Date: Wed Aug  7 21:11:15 2013
New Revision: 1511497

URL: http://svn.apache.org/r1511497
Log:
Improve the one line formatter so it outputs the correct thread ID even when 
using the async log writer.

Modified:
tomcat/trunk/java/org/apache/juli/OneLineFormatter.java

Modified: tomcat/trunk/java/org/apache/juli/OneLineFormatter.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/OneLineFormatter.java?rev=1511497r1=1511496r2=1511497view=diff
==
--- tomcat/trunk/java/org/apache/juli/OneLineFormatter.java (original)
+++ tomcat/trunk/java/org/apache/juli/OneLineFormatter.java Wed Aug  7 21:11:15 
2013
@@ -19,6 +19,12 @@ package org.apache.juli;
 
 import java.io.PrintWriter;
 import java.io.StringWriter;
+import java.lang.management.ManagementFactory;
+import java.lang.management.ThreadInfo;
+import java.lang.management.ThreadMXBean;
+import java.util.LinkedHashMap;
+import java.util.Map;
+import java.util.Map.Entry;
 import java.util.logging.Formatter;
 import java.util.logging.LogRecord;
 
@@ -34,6 +40,27 @@ public class OneLineFormatter extends Fo
 
 private static final String LINE_SEP = 
System.getProperty(line.separator);
 private static final String ST_SEP = LINE_SEP +  ;
+private static final String UNKONWN_THREAD_NAME = Unknown thread with ID 
;
+private static final Object threadMxBeanLock = new Object();
+private static volatile ThreadMXBean threadMxBean = null;
+private static final int THREAD_NAME_CACHE_SIZE = 1;
+private static ThreadLocalLinkedHashMapInteger,String threadNameCache =
+new ThreadLocalLinkedHashMapInteger,String() {
+
+@Override
+protected LinkedHashMapInteger,String initialValue() {
+return new LinkedHashMapInteger,String() {
+
+private static final long serialVersionUID = 1L;
+
+@Override
+protected boolean removeEldestEntry(
+EntryInteger, String eldest) {
+return (size()  THREAD_NAME_CACHE_SIZE);
+}
+};
+}
+};
 
 /* Timestamp format */
 private static final String timeFormat = dd-MMM- HH:mm:ss;
@@ -79,7 +106,13 @@ public class OneLineFormatter extends Fo
 // Thread
 sb.append(' ');
 sb.append('[');
-sb.append(Thread.currentThread().getName());
+if (Thread.currentThread() instanceof AsyncFileHandler.LoggerThread) {
+// If using the async handler can't get the thread name from the
+// current thread.
+sb.append(getThreadName(record.getThreadID()));
+} else {
+sb.append(Thread.currentThread().getName());
+}
 sb.append(']');
 
 // Source
@@ -122,4 +155,47 @@ public class OneLineFormatter extends Fo
 }
 buf.append(frac);
 }
+
+
+/**
+ * LogRecord has threadID but no thread name.
+ * LogRecord uses an int for thread ID but thread IDs are longs.
+ * If the real thread ID  (Integer.MAXVALUE / 2) LogRecord uses it's own
+ * ID in an effort to avoid clashes due to overflow.
+ * p
+ * Words fail me to describe what I think of the design decision to use an
+ * int in LogRecord for a long value and the resulting mess that follows.
+ */
+private static String getThreadName(int logRecordThreadId) {
+MapInteger,String cache = threadNameCache.get();
+String result = null;
+
+if (logRecordThreadId  (Integer.MAX_VALUE / 2)) {
+result = cache.get(Integer.valueOf(logRecordThreadId));
+}
+
+if (result != null) {
+return result;
+}
+
+if (logRecordThreadId  Integer.MAX_VALUE / 2) {
+result = UNKONWN_THREAD_NAME + logRecordThreadId;
+} else {
+// Double checked locking OK as threadMxBean is volatile
+if (threadMxBean == null) {
+synchronized (threadMxBeanLock) {
+if (threadMxBean == null) {
+threadMxBean = ManagementFactory.getThreadMXBean();
+}
+}
+}
+ThreadInfo threadInfo =
+threadMxBean.getThreadInfo(logRecordThreadId);
+result = threadInfo.getThreadName();
+}
+
+cache.put(Integer.valueOf(logRecordThreadId), result);
+
+return result;
+}
 }



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

svn commit: r1511501 - in /tomcat/trunk: conf/logging.properties java/org/apache/juli/FileHandler.java webapps/docs/changelog.xml

Author: markt
Date: Wed Aug  7 21:14:55 2013
New Revision: 1511501

URL: http://svn.apache.org/r1511501
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52092
Switch to the AsyncLogWriter and OneLineFormatter by default

Modified:
tomcat/trunk/conf/logging.properties
tomcat/trunk/java/org/apache/juli/FileHandler.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/conf/logging.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/conf/logging.properties?rev=1511501r1=1511500r2=1511501view=diff
==
--- tomcat/trunk/conf/logging.properties (original)
+++ tomcat/trunk/conf/logging.properties Wed Aug  7 21:14:55 2013
@@ -13,33 +13,33 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-handlers = 1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 
4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
+handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
2localhost.org.apache.juli.AsyncFileHandler, 
3manager.org.apache.juli.AsyncFileHandler, 
4host-manager.org.apache.juli.AsyncFileHandler, java.util.logging.ConsoleHandler
 
-.handlers = 1catalina.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler
+.handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
java.util.logging.ConsoleHandler
 
 
 # Handler specific properties.
 # Describes specific configuration info for Handlers.
 
 
-1catalina.org.apache.juli.FileHandler.level = FINE
-1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
-1catalina.org.apache.juli.FileHandler.prefix = catalina.
-
-2localhost.org.apache.juli.FileHandler.level = FINE
-2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
-2localhost.org.apache.juli.FileHandler.prefix = localhost.
-
-3manager.org.apache.juli.FileHandler.level = FINE
-3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
-3manager.org.apache.juli.FileHandler.prefix = manager.
-
-4host-manager.org.apache.juli.FileHandler.level = FINE
-4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
-4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
+1catalina.org.apache.juli.AsyncFileHandler.level = FINE
+1catalina.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
+1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina.
+
+2localhost.org.apache.juli.AsyncFileHandler.level = FINE
+2localhost.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
+2localhost.org.apache.juli.AsyncFileHandler.prefix = localhost.
+
+3manager.org.apache.juli.AsyncFileHandler.level = FINE
+3manager.org.apache.juli.AsyncFileHandler.directory = ${catalina.base}/logs
+3manager.org.apache.juli.AsyncFileHandler.prefix = manager.
+
+4host-manager.org.apache.juli.AsyncFileHandler.level = FINE
+4host-manager.org.apache.juli.AsyncFileHandler.directory = 
${catalina.base}/logs
+4host-manager.org.apache.juli.AsyncFileHandler.prefix = host-manager.
 
 java.util.logging.ConsoleHandler.level = FINE
-java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
 
 
 
@@ -48,13 +48,13 @@ java.util.logging.ConsoleHandler.formatt
 
 
 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
-org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 
2localhost.org.apache.juli.FileHandler
+org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 
2localhost.org.apache.juli.AsyncFileHandler
 
 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level 
= INFO
-org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
 = 3manager.org.apache.juli.FileHandler
+org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
 = 3manager.org.apache.juli.AsyncFileHandler
 
 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
 = INFO
-org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
 = 4host-manager.org.apache.juli.FileHandler
+org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
 = 4host-manager.org.apache.juli.AsyncFileHandler
 
 # For example, set the org.apache.catalina.util.LifecycleBase logger to log
 # each component that extends LifecycleBase changing state:

Modified: tomcat/trunk/java/org/apache/juli/FileHandler.java
URL:

[Bug 52092] Please make AsyncFileHandler and OneLineFormatter the default for logging.properties

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

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

   What|Removed |Added

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

--- Comment #2 from Mark Thomas ma...@apache.org ---
Fixed in trunk a.k.a. 8.0.x and will be included in 8.0.0-RC2 onwards.

An added complication was correctly reporting the thread name when using the
AsyncFileHandler.

-- 
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 55383] Improve markup and design of Tomcat's HTML pages

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

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

   What|Removed |Added

 CC||d...@smart.net

--- Comment #1 from Mark Thomas ma...@apache.org ---
*** Bug 16579 has been marked as a duplicate of this bug. ***

-- 
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 16579] documentation page layout/style breaks wrapping to fit browser window

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Mark Thomas ma...@apache.org ---
The duplicate has a better description and some clear action points so lets
track progress there.

*** This bug has been marked as a duplicate of bug 55383 ***

-- 
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 55383] Improve markup and design of Tomcat's HTML pages