[Bug 63249] Inconsistent log level practices

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63249

AnhT  changed:

   What|Removed |Added

 CC||anu...@163.com

--- Comment #1 from AnhT  ---
Created attachment 36480
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36480&action=edit
Patch fille

Modify the log levels to INFO in file
apache-tomcat-9.0.16-src\java\org\apache\catalina\util\LifecycleMBeanBase.java.

-- 
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 63249] New: Inconsistent log level practices

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63249

Bug ID: 63249
   Summary: Inconsistent log level practices
   Product: Tomcat 9
   Version: 9.0.16
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: anu...@163.com
  Target Milestone: -

There are inconsistent log level practices in similiar situations.
(1)file
path:apache-tomcat-9.0.16-src\java\org\apache\catalina\util\LifecycleMBeanBase.java
//log level:warn
try {
on = new ObjectName(name.toString());

Registry.getRegistry(null, null).registerComponent(obj, on, null);
} catch (MalformedObjectNameException e) {
log.warn(sm.getString("lifecycleMBeanBase.registerFail", obj,
name),
e);
} catch (Exception e) {
log.warn(sm.getString("lifecycleMBeanBase.registerFail", obj,
name),
e);
}
(2)file
path:apache-tomcat-9.0.16-src\java\org\apache\catalina\core\ApplicationFilterConfig.java
//log level:info
try {
oname = new ObjectName(onameStr);
Registry.getRegistry(null, null).registerComponent(this, oname,
null);
} catch (Exception ex) {
log.info(sm.getString("applicationFilterConfig.jmxRegisterFail",
getFilterClass(), getFilterName()), ex);
}
(3)file
path:apache-tomcat-9.0.16-src\java\org\apache\catalina\core\StandardWrapper.java
//log level:info
try {
jspMonitorON = new ObjectName(oname.toString());
Registry.getRegistry(null, null)
.registerComponent(instance, jspMonitorON, null);
} catch (Exception ex) {
log.info(sm.getString("standardWrapper.jspMonitorError",
instance));
}

I think the log level should be consistent in above contexts, so the log level
of first example more likely to be assigned INFO.

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



[GUMP@vmgump-vm3]: Project tomcat-trunk-test-nio (in module tomcat-trunk) failed

2019-03-08 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-test-nio has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 27 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-test-nio :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-test-nio/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on bnd exists, no need to add for property bndlib.jar.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/logs-NIO
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-NIO/logs
 -WARNING- No directory 
[/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-NIO/logs]



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-test-nio/gump_work/build_tomcat-trunk_tomcat-trunk-test-nio.html
Work Name: build_tomcat-trunk_tomcat-trunk-test-nio (Type: Build)
Work ended in a state of : Failed
Elapsed: 25 mins 6 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
-Dbnd.jar=/srv/gump/packages/bnd/bnd-4.0.0/biz.aQute.bnd-4.0.0.jar 
-Dsaaj-api.jar=/srv/gump/packages/saaj-api/saaj-api-1.3.5.jar 
-Djaxrpc-lib.jar=/srv/gump/packages/jaxrpc/geronimo-spec-jaxrpc-1.1-rc4.jar 
-Dtest.temp=output/test-tmp-NIO 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Djava.net.preferIPv4Stack=/srv/gump/public/workspace/tomcat-trunk/true 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-3.1-SNAPSHOT.jar
 -Dexamples.sources.skip=true 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
 
-Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20190309/bin/openssl
 -Dexecute.
 test.nio=true -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar 
-Dbndlib.jar=/srv/gump/packages/bnd/bndlib-4.0.0/biz.aQute.bndlib-4.0.0.jar 
-Dexecute.test.apr=false 
-Dwsdl4j-lib.jar=/srv/gump/packages/wsdl4j/wsdl4j-1.6.3.jar 
-Dtest.reports=output/logs-NIO -Dexecute.test.nio2=false 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar
 -Dtest.relaxTiming=true -Dtest.excludePerformance=true -Dtest.accesslog=true 
-Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-4.1-SNAPSHOT.jar
 -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build

[Bug 63245] Ask for confirmation on UNDEPLOY

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63245

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Mark Thomas  ---
Tomcat provided this for a while back around the time of Tomcat 6.

Opinion was strongly divided on whether there should be a confirmation dialog
or not. It was removed back in 2009 and this is the first request I recall for
it to return.

There are plenty of ways to disable undeploy (e.g. with a security constraint).
Further advice is available from the users@ list if required.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Tagging Tomcat releases with Git

2019-03-08 Thread Mark Thomas
On 08/03/2019 21:54, Konstantin Kolinko wrote:
> Hi!
> 
> The release procedure for Tomcat that we used up to recently is
> documented in the Wiki,
> https://wiki.apache.org/tomcat/ReleaseProcess
> 
> Do we change it now, when Git is used instead of Apache Subversion?
> 
> I see the following issues:
> 
> 1) When preparing a release, one does a tag in Subversion that differs
> from the main branch.
> 
> Technically, with Git it means that one creates a new branch and a tag
> on that branch.
> I think, the process may be the following:
> 
> a) create a "RC" branch locally,
> b) create a tag on that branch,
> c) push only a tag, not the branch to the remote repository.

I'm not even sure you need a branch. It might be as simple as:
- commit changes (remove -dev from version and rtext from changelog)
- tag
- push the tag
- reset back to commit prior to the tag.

I'm planning on tagging early next week so I guess we'll find out then.

> I have never done (c). I usually push a branch with a "with tags"
> flag, so both a branch and tags are pushed. Technically, it is
> possible to push branch with tags and delete the branch from the
> remote repository later.
> 
> 2) Sometimes a release manager does re-tagging.
> 
> It needs testing whether we have the rights to delete a tag, and how
> those deletions are replicated between repositories.

Tags are not protected. It should be possible to delete them.

Updated tags will be replicated but it will be a forced update. That is
probably OK for a tag.

> I think the possible solution that simplifies the things will be
> (1) create the tag on the main branch,
> (2) publish (push) the tag only when the release artifacts have been
> uploaded, so that it is known that the number won't be reused for a
> different set of artifacts.

It should be possible to delay pushing the tag. I'll test this next week.



> (The wiki page misses the "default" suffix from the first file name
> and does not mention the two other files.
> Usually the mvn.properties.default is updated after a release, so it
> already contains the correct version number.)

I'll update the wiki page as I work through the new release process.

Mark

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



[Bug 63246] NullPointerException in AsyncContextImpl

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Mark Thomas  ---
Thanks for the report.

Fixed in:
- trunk for 9.0.17 onwards
- 8.5.x for 8.5.39 onwards
- 7.0.x for 7.0.94 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



[tomcat] branch 7.0.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

2019-03-08 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 4e9bb1c  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
4e9bb1c is described below

commit 4e9bb1c1c6907d90cbbdc415866037521b67b3ef
Author: Mark Thomas 
AuthorDate: Fri Mar 8 22:01:25 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

Fix a potential NullPointerException when calling
AsyncContext.dispatch()
---
 java/org/apache/catalina/core/AsyncContextImpl.java | 11 ---
 webapps/docs/changelog.xml  |  4 
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/catalina/core/AsyncContextImpl.java 
b/java/org/apache/catalina/core/AsyncContextImpl.java
index 489ca80..15c6610 100644
--- a/java/org/apache/catalina/core/AsyncContextImpl.java
+++ b/java/org/apache/catalina/core/AsyncContextImpl.java
@@ -210,7 +210,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 }
 
 @Override
-public void dispatch(ServletContext context, String path) {
+public void dispatch(ServletContext servletContext, String path) {
 synchronized (asyncContextLock) {
 if (log.isDebugEnabled()) {
 logDebug("dispatch   ");
@@ -227,7 +227,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 request.setAttribute(ASYNC_PATH_INFO, request.getPathInfo());
 request.setAttribute(ASYNC_QUERY_STRING, 
request.getQueryString());
 }
-final RequestDispatcher requestDispatcher = 
context.getRequestDispatcher(path);
+final RequestDispatcher requestDispatcher = 
servletContext.getRequestDispatcher(path);
 if (!(requestDispatcher instanceof AsyncDispatcher)) {
 throw new UnsupportedOperationException(
 sm.getString("asyncContextImpl.noAsyncDispatcher"));
@@ -236,6 +236,11 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 (AsyncDispatcher) requestDispatcher;
 final ServletRequest servletRequest = getRequest();
 final ServletResponse servletResponse = getResponse();
+// https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
+// Take a local copy as the dispatch may complete the
+// request/response and that in turn may trigger recycling of this
+// object before the in-progress count can be decremented
+final Context context = this.context;
 Runnable run = new Runnable() {
 @Override
 public void run() {
@@ -252,7 +257,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 this.dispatch = run;
 this.request.getCoyoteRequest().action(ActionCode.ASYNC_DISPATCH, 
null);
 clearServletRequestResponse();
-this.context.decrementInProgressAsyncCount();
+context.decrementInProgressAsyncCount();
 }
 }
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index f6d55d8..de7aeca 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -80,6 +80,10 @@
 thanks to YourKit Java profiler for helping to track down the wasted
 memory and the root causes. (markt)
   
+  
+63246: Fix a potential NullPointerException 
when
+calling AsyncContext.dispatch(). (markt)
+  
 
   
   


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



[tomcat] branch 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

2019-03-08 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new dcfda86  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
dcfda86 is described below

commit dcfda86093a3407ee8ad7837359d1b162134465c
Author: Mark Thomas 
AuthorDate: Fri Mar 8 22:01:25 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

Fix a potential NullPointerException when calling
AsyncContext.dispatch()
---
 java/org/apache/catalina/core/AsyncContextImpl.java | 11 ---
 webapps/docs/changelog.xml  |  4 
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/catalina/core/AsyncContextImpl.java 
b/java/org/apache/catalina/core/AsyncContextImpl.java
index 34392e5..51198b2 100644
--- a/java/org/apache/catalina/core/AsyncContextImpl.java
+++ b/java/org/apache/catalina/core/AsyncContextImpl.java
@@ -180,7 +180,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 }
 
 @Override
-public void dispatch(ServletContext context, String path) {
+public void dispatch(ServletContext servletContext, String path) {
 synchronized (asyncContextLock) {
 if (log.isDebugEnabled()) {
 logDebug("dispatch   ");
@@ -197,7 +197,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 request.setAttribute(ASYNC_PATH_INFO, request.getPathInfo());
 request.setAttribute(ASYNC_QUERY_STRING, 
request.getQueryString());
 }
-final RequestDispatcher requestDispatcher = 
context.getRequestDispatcher(path);
+final RequestDispatcher requestDispatcher = 
servletContext.getRequestDispatcher(path);
 if (!(requestDispatcher instanceof AsyncDispatcher)) {
 throw new UnsupportedOperationException(
 sm.getString("asyncContextImpl.noAsyncDispatcher"));
@@ -206,11 +206,16 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 (AsyncDispatcher) requestDispatcher;
 final ServletRequest servletRequest = getRequest();
 final ServletResponse servletResponse = getResponse();
+// https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
+// Take a local copy as the dispatch may complete the
+// request/response and that in turn may trigger recycling of this
+// object before the in-progress count can be decremented
+final Context context = this.context;
 this.dispatch = new AsyncRunnable(
 request, applicationDispatcher, servletRequest, 
servletResponse);
 this.request.getCoyoteRequest().action(ActionCode.ASYNC_DISPATCH, 
null);
 clearServletRequestResponse();
-this.context.decrementInProgressAsyncCount();
+context.decrementInProgressAsyncCount();
 }
 }
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index f36a7f0..3b2b00d 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -114,6 +114,10 @@
 thanks to YourKit Java profiler for helping to track down the wasted
 memory and the root causes. (markt)
   
+  
+63246: Fix a potential NullPointerException 
when
+calling AsyncContext.dispatch(). (markt)
+  
 
   
   


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



[tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

2019-03-08 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new eb2db58  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
eb2db58 is described below

commit eb2db582dd7cc0e1d3deb271bc19c6236db8a6ba
Author: Mark Thomas 
AuthorDate: Fri Mar 8 22:01:25 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

Fix a potential NullPointerException when calling
AsyncContext.dispatch()
---
 java/org/apache/catalina/core/AsyncContextImpl.java | 11 ---
 webapps/docs/changelog.xml  |  4 
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/java/org/apache/catalina/core/AsyncContextImpl.java 
b/java/org/apache/catalina/core/AsyncContextImpl.java
index 7a86572..4621644 100644
--- a/java/org/apache/catalina/core/AsyncContextImpl.java
+++ b/java/org/apache/catalina/core/AsyncContextImpl.java
@@ -176,7 +176,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 }
 
 @Override
-public void dispatch(ServletContext context, String path) {
+public void dispatch(ServletContext servletContext, String path) {
 synchronized (asyncContextLock) {
 if (log.isDebugEnabled()) {
 logDebug("dispatch   ");
@@ -193,7 +193,7 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 request.setAttribute(ASYNC_PATH_INFO, request.getPathInfo());
 request.setAttribute(ASYNC_QUERY_STRING, 
request.getQueryString());
 }
-final RequestDispatcher requestDispatcher = 
context.getRequestDispatcher(path);
+final RequestDispatcher requestDispatcher = 
servletContext.getRequestDispatcher(path);
 if (!(requestDispatcher instanceof AsyncDispatcher)) {
 throw new UnsupportedOperationException(
 sm.getString("asyncContextImpl.noAsyncDispatcher"));
@@ -202,11 +202,16 @@ public class AsyncContextImpl implements AsyncContext, 
AsyncContextCallback {
 (AsyncDispatcher) requestDispatcher;
 final ServletRequest servletRequest = getRequest();
 final ServletResponse servletResponse = getResponse();
+// https://bz.apache.org/bugzilla/show_bug.cgi?id=63246
+// Take a local copy as the dispatch may complete the
+// request/response and that in turn may trigger recycling of this
+// object before the in-progress count can be decremented
+final Context context = this.context;
 this.dispatch = new AsyncRunnable(
 request, applicationDispatcher, servletRequest, 
servletResponse);
 this.request.getCoyoteRequest().action(ActionCode.ASYNC_DISPATCH, 
null);
 clearServletRequestResponse();
-this.context.decrementInProgressAsyncCount();
+context.decrementInProgressAsyncCount();
 }
 }
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index e89dbe3..cc21008 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -88,6 +88,10 @@
 thanks to YourKit Java profiler for helping to track down the wasted
 memory and the root causes. (markt)
   
+  
+63246: Fix a potential NullPointerException 
when
+calling AsyncContext.dispatch(). (markt)
+  
 
   
   


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



Tagging Tomcat releases with Git

2019-03-08 Thread Konstantin Kolinko
Hi!

The release procedure for Tomcat that we used up to recently is
documented in the Wiki,
https://wiki.apache.org/tomcat/ReleaseProcess

Do we change it now, when Git is used instead of Apache Subversion?

I see the following issues:

1) When preparing a release, one does a tag in Subversion that differs
from the main branch.

Technically, with Git it means that one creates a new branch and a tag
on that branch.
I think, the process may be the following:

a) create a "RC" branch locally,
b) create a tag on that branch,
c) push only a tag, not the branch to the remote repository.

I have never done (c). I usually push a branch with a "with tags"
flag, so both a branch and tags are pushed. Technically, it is
possible to push branch with tags and delete the branch from the
remote repository later.

2) Sometimes a release manager does re-tagging.

It needs testing whether we have the rights to delete a tag, and how
those deletions are replicated between repositories.


I think the possible solution that simplifies the things will be
(1) create the tag on the main branch,
(2) publish (push) the tag only when the release artifacts have been
uploaded, so that it is known that the number won't be reused for a
different set of artifacts.

The specific steps are the following:

1. Edit the following files on the main branch and commit:
build.properties.default
res/maven/mvn.properties.default
webapps/docs/changelog.xml

- remove "dev" suffix
- verify that the version number is correct
- remove "in development" frem the section title in changelog

(The wiki page misses the "default" suffix from the first file name
and does not mention the two other files.
Usually the mvn.properties.default is updated after a release, so it
already contains the correct version number.)

2. Push the commit, to ensure that it can be pushed successfully
without conflicts
and so that this commit is present in the main branch and is visible
in the repository.

At this point subsequent development for the next version of Tomcat is
technically possible. The new commits won't conflict with the changed
files.

3. Do a build.
4. Publish the files to Maven Staging repository
5. Publish the files to Dist.a.o svn repository.

At this point the release artifacts are published, so no re-tagging is possible.

6. Create a tag in Git.
7. Push the tag.
8. Verify that the tag is visible in the repository
9. Send a [VOTE[ e-mail.

10. Update the following files for the next version of Tomcat
build.properties.default
res/maven/mvn.properties.default
webapps/docs/changelog.xml

- Increment the build number in mvn.properties.default
- Increment the build number and add "-dev" suffix in build.properties.default
- Mark the current version as "vote in progress" and a section for the
new version in changelog.xml.

11. Commit and push.

Best regards,
Konstantin Kolinko

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



Re: Tomcat Site Redesign

2019-03-08 Thread Igal @ Lucee.org

All,

On 3/7/2019 3:22 AM, Konstantin Kolinko wrote:


пн, 4 мар. 2019 г. в 09:02, Igal Sapir :

I have uploaded the Tomcat site redesign to a temporary location for review:
http://people.apache.org/~isapir/mockups/tomcat-site/

1. Overall: Thank you for your effort, but I do not like it. At all.


The effort to redesign the website was prompted by conversations with 
team members at TomcatCon in Montreal.


If there is consensus in the team for keeping the layout with a vertical 
menu on the left then I can redesign that.


Best,

Igal






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



Re: GitHub notifications show Mark Thomas as Sender

2019-03-08 Thread Igal Sapir
Oh wait, unless that action was made by Mark.  I saw a few messages in a
row and misunderstood.

Please ignore the previous email.

On Fri, Mar 8, 2019 at 12:58 PM Igal Sapir  wrote:

> I got some GitHub notifications and they have the following header:
>
> From: Mark Thomas 
>
> If someone with permissions can change that please.
>
> Best,
>
> Igal
>
>


Re: GitHub notifications show Mark Thomas as Sender

2019-03-08 Thread Mark Thomas
On 08/03/2019 20:58, Igal Sapir wrote:
> I got some GitHub notifications and they have the following header:
> 
> From: Mark Thomas 
> 
> If someone with permissions can change that please.

That is standard GitHub behaviour. The name is set to the name of
whichever user made the change that you are being notified of.

Mark

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



GitHub notifications show Mark Thomas as Sender

2019-03-08 Thread Igal Sapir
I got some GitHub notifications and they have the following header:

From: Mark Thomas 

If someone with permissions can change that please.

Best,

Igal


[Bug 63235] Defer potentially expensive Charset.availableCharsets() call

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235

--- Comment #11 from Mark Thomas  ---
I've put together an alternative proposal:
https://github.com/apache/tomcat/pull/146

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



[GitHub] [tomcat] markt-asf commented on issue #142: Defer creation of encodingToCharsetCache

2019-03-08 Thread GitBox
markt-asf commented on issue #142: Defer creation of encodingToCharsetCache
URL: https://github.com/apache/tomcat/pull/142#issuecomment-471072264
 
 
   See #146 for an alternative approach


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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



[GitHub] [tomcat] markt-asf opened a new pull request #146: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63235

2019-03-08 Thread GitBox
markt-asf opened a new pull request #146: Fix 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
URL: https://github.com/apache/tomcat/pull/146
 
 
   Implement an alternative Charset caching strategy that does not load all
   Charsets at Tomcat start. This reduces start time by ~30ms and does not,
   based on the performance tests included in this commit, have a negative
   impact on runtime look-ups.
   It does require that the names of all supported Charsets are known to
   Tomcat at compile time. The code has been tested with a range of JVMs
   and a unit test is provided for testing new JVMs.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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



[tomcat] branch 8.5.x updated: Check stream state after wait

2019-03-08 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 60a3af1  Check stream state after wait
60a3af1 is described below

commit 60a3af1738879ec06fac1ecb8a149608782f7cc9
Author: remm 
AuthorDate: Fri Mar 8 18:48:45 2019 +0100

Check stream state after wait

Verify HTTP/2 stream is still writable before assuming a timeout
occurred. The reason for bad behavior is a bit unclear (I see it with
logging on and async IO), but the check is inconsistent.
# Conflicts:
#   webapps/docs/changelog.xml
---
 java/org/apache/coyote/http2/Stream.java | 2 +-
 webapps/docs/changelog.xml   | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Stream.java 
b/java/org/apache/coyote/http2/Stream.java
index 2facca3..065f07b 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -1135,7 +1135,7 @@ public class Stream extends AbstractStream implements 
HeaderEmitter {
 throw new 
IOException(sm.getString("stream.inputBuffer.reset"));
 }
 
-if (inBuffer.position() == 0) {
+if (inBuffer.position() == 0 && isActive() && 
!isInputFinished()) {
 String msg = 
sm.getString("stream.inputBuffer.readTimeout");
 StreamException se = new StreamException(
 msg, Http2Error.ENHANCE_YOUR_CALM, 
getIdAsInt());
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 36c3168..f36a7f0 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -175,6 +175,10 @@
 63223: Correctly account for push requests when tracking
 currently active HTTP/2 streams. (markt)
   
+  
+Verify HTTP/2 stream is still writable before assuming a timeout
+occurred. (remm)
+  
 
   
   


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



[tomcat] branch master updated: Check stream state after wait

2019-03-08 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new a1cb1ac  Check stream state after wait
a1cb1ac is described below

commit a1cb1ac77e3a8fec1b00eb0e944842555da14f7d
Author: remm 
AuthorDate: Fri Mar 8 18:48:45 2019 +0100

Check stream state after wait

Verify HTTP/2 stream is still writable before assuming a timeout
occurred. The reason for bad behavior is a bit unclear (I see it with
logging on and async IO), but the check is inconsistent.
---
 java/org/apache/coyote/http2/Stream.java | 2 +-
 webapps/docs/changelog.xml   | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Stream.java 
b/java/org/apache/coyote/http2/Stream.java
index 32c90b8..3e64329 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -1052,7 +1052,7 @@ class Stream extends AbstractStream implements 
HeaderEmitter {
 throw new 
IOException(sm.getString("stream.inputBuffer.reset"));
 }
 
-if (inBuffer.position() == 0) {
+if (inBuffer.position() == 0 && isActive() && 
!isInputFinished()) {
 String msg = 
sm.getString("stream.inputBuffer.readTimeout");
 StreamException se = new StreamException(
 msg, Http2Error.ENHANCE_YOUR_CALM, 
getIdAsInt());
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 3269e92..e89dbe3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -138,6 +138,10 @@
 Ensure enough buffer space when using TLS with NIO2 by using the main
 read buffer to store additional decrypted data. (remm)
   
+  
+Verify HTTP/2 stream is still writable before assuming a timeout
+occurred. (remm)
+  
 
   
   


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



[Bug 63247] Image doesn't appear - jbig2-imageio not installed

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63247

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 OS||All

--- Comment #1 from Mark Thomas  ---
Bugzilla is not a support forum.

Please use the users@ mailing list.

-- 
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 63247] New: Image doesn't appear - jbig2-imageio not installed

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63247

Bug ID: 63247
   Summary: Image doesn't appear - jbig2-imageio not installed
   Product: Tomcat 9
   Version: 9.0.16
  Hardware: PC
Status: NEW
  Severity: major
  Priority: P2
 Component: Servlet
  Assignee: dev@tomcat.apache.org
  Reporter: matth...@paprika-software.com
  Target Milestone: -

Error on Tomcat 9.0.16 where image doesnt appear in preview with error message
from log: 

Mar 08, 2019 11:19:20 AM org.apache.pdfbox.contentstream.PDFStreamEngine
operatorException
SEVERE: Cannot read JBIG2 image: jbig2-imageio is not installed

-- 
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 63246] New: NullPointerException in AsyncContextImpl

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63246

Bug ID: 63246
   Summary: NullPointerException in AsyncContextImpl
   Product: Tomcat 9
   Version: 9.0.16
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: kaido...@gmail.com
  Target Milestone: -

We're using the tomcat-embedded-core 9.0.16 shipped with spring boot 2.1.3.

We have a some NPE in AsyncContextImpl line 209. (see stacktrace below)
Pretty sure, that it's related to the fix of this bug, as line 209 was changed
there: https://bz.apache.org/bugzilla/show_bug.cgi?id=63003
As this is not happening of every request, I think it is a race condition.

Unfortunately I was not able to reproduce it locally.
But we're using 
org.springframework.boot:spring-boot-starter-web and
org.springframework.boot:spring-boot-starter-webflux together, if that helps.

Please tell me, if I can assist more.

java.lang.NullPointerException: null
at
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:209)
at
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:175)
at
org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:169)
at
org.springframework.security.web.servletapi.HttpServlet3RequestFactory$SecurityContextAsyncContext.dispatch(HttpServlet3RequestFactory.java:291)
at
org.springframework.web.context.request.async.StandardServletAsyncWebRequest.dispatch(StandardServletAsyncWebRequest.java:131)
at
org.springframework.web.context.request.async.WebAsyncManager.setConcurrentResultAndDispatch(WebAsyncManager.java:387)
at
org.springframework.web.context.request.async.WebAsyncManager.lambda$startDeferredResultProcessing$8(WebAsyncManager.java:453)
at
org.springframework.web.context.request.async.DeferredResult.setResultInternal(DeferredResult.java:267)
at
org.springframework.web.context.request.async.DeferredResult.setResult(DeferredResult.java:238)
at
org.springframework.web.servlet.mvc.method.annotation.ReactiveTypeHandler$DeferredResultSubscriber.onComplete(ReactiveTypeHandler.java:465)
at
reactor.core.publisher.StrictSubscriber.onComplete(StrictSubscriber.java:123)
at
reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1508)
at
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.drain(MonoIgnoreThen.java:147)
at
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.ignoreDone(MonoIgnoreThen.java:190)
at
reactor.core.publisher.MonoIgnoreThen$ThenIgnoreInner.onComplete(MonoIgnoreThen.java:240)
at
reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:189)
at
reactor.core.publisher.MonoFlatMap$FlatMapInner.onComplete(MonoFlatMap.java:260)
at
reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:189)
at
reactor.core.publisher.MonoFlatMap$FlatMapInner.onComplete(MonoFlatMap.java:260)
at
reactor.core.publisher.MonoIgnoreElements$IgnoreElementsSubscriber.onComplete(MonoIgnoreElements.java:81)
at
reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136)
at
reactor.core.publisher.FluxRetryPredicate$RetryPredicateSubscriber.onComplete(FluxRetryPredicate.java:107)
at
reactor.core.publisher.MonoCreate$DefaultMonoSink.success(MonoCreate.java:148)
at
reactor.ipc.netty.channel.PooledClientContextHandler.fireContextActive(PooledClientContextHandler.java:87)
at
reactor.ipc.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:608)
at
reactor.ipc.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:138)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at
io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:297)
at
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1436)
at
io.netty.handler.ssl.SslHandler.

[Bug 63245] Ask for confirmation on UNDEPLOY

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63245

paolo.perl...@miliaris.it  changed:

   What|Removed |Added

Summary|Ask confirmation on |Ask for confirmation on
   |UNDEPLOY|UNDEPLOY

-- 
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 63245] New: Ask confirmation on UNDEPLOY

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63245

Bug ID: 63245
   Summary: Ask confirmation on UNDEPLOY
   Product: Tomcat 9
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Manager
  Assignee: dev@tomcat.apache.org
  Reporter: paolo.perl...@miliaris.it
  Target Milestone: -

Since RELOAD and UNDEPLOY buttons are very close together, it would be
advisable to ASK FOR CONFIRMATION when UNDEPLOY button is pressed within the
Manager console.
This could save a lot of pain (especially in production environments).
Also, developers could have used a junction to link their local development
folder to Tomcat's webapps folder (to speed up repetitive deployment operations
on their own machine) so an unintentional undeploy would end up deleting
contents of the original working folder.

Since Manager's presentation logic is wrapped inside catalina.jar it's not easy
to disable undeploy button.

Could you at least provide a confirmation dialog on UNDEPLOY click?

Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63244] CATALINA_PID never get written

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63244

--- Comment #3 from Thomas Opfer  ---
(In reply to Yiftach from comment #2)
> Was it resolved by bug 63041? AFAIK bug 63041 was released in 9.0.16 but I
> can still see the issue.

It will be fixed correctly in the next release, see here:
https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html

Unfortunately, the bug was fixed incorrectly in the past.

-- 
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 63244] CATALINA_PID never get written

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63244

Yiftach  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #2 from Yiftach  ---
Was it resolved by bug 63041? AFAIK bug 63041 was released in 9.0.16 but I can
still see the issue.

-- 
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 63041] shutdown.sh exits non 0 requires KILLSIG from OS

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63041

Mark Thomas  changed:

   What|Removed |Added

 CC||yift...@moogsoft.com

--- Comment #33 from Mark Thomas  ---
*** Bug 63244 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 63244] CATALINA_PID never get written

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63244

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Mark Thomas  ---


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

-- 
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 63244] New: CATALINA_PID never get written

2019-03-08 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63244

Bug ID: 63244
   Summary: CATALINA_PID never get written
   Product: Tomcat 9
   Version: 9.0.16
  Hardware: PC
OS: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: yift...@moogsoft.com
  Target Milestone: -

Since the fix of 53930 when running catalina.sh the catalina_pid_file (and
hence the CATALINA_PID) is written only after the _RUNJAVA command ends
successfully, but since the _RUNJAVA command is the actual server, it should
not complete, so the PID file is not written (and tomcat cannot be run as a
service script). 

I think that replacing the double ampersand with a single ampersand would solve
the problem.

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



[tomcat] branch master updated: Improve handling of overflow

2019-03-08 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 6367351  Improve handling of overflow
6367351 is described below

commit 63673514f29c60dfbaa72665a676c2ce92b6bf75
Author: remm 
AuthorDate: Fri Mar 8 11:30:36 2019 +0100

Improve handling of overflow

Attempt to use the main read buffer as overflow for decrypted data.
Although I could modify the OpenSSL engine to hold it, the default JSSE
engine doesn't want to do it either, so it is not an option. I don't
think this will create thread safety problems, but if it does, will
revert back to requiring additional space in the destination buffers.
---
 java/org/apache/coyote/http2/Http2AsyncParser.java |  6 +
 .../apache/tomcat/util/net/SecureNio2Channel.java  | 29 +++---
 webapps/docs/changelog.xml |  3 ++-
 3 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2AsyncParser.java 
b/java/org/apache/coyote/http2/Http2AsyncParser.java
index 7bd24df..92531bf 100644
--- a/java/org/apache/coyote/http2/Http2AsyncParser.java
+++ b/java/org/apache/coyote/http2/Http2AsyncParser.java
@@ -42,11 +42,7 @@ class Http2AsyncParser extends Http2Parser {
 socketWrapper.getSocketBufferHandler().expand(input.getMaxFrameSize());
 this.upgradeHandler = upgradeHandler;
 header = ByteBuffer.allocate(9);
-int frameBufferSize = input.getMaxFrameSize();
-if (socketWrapper.isSecure()) {
-frameBufferSize += 16676;
-}
-framePaylod = ByteBuffer.allocate(frameBufferSize);
+framePaylod = ByteBuffer.allocate(input.getMaxFrameSize());
 }
 
 
diff --git a/java/org/apache/tomcat/util/net/SecureNio2Channel.java 
b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
index 4ae2509..8c70991 100644
--- a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
+++ b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
@@ -1008,11 +1008,15 @@ public class SecureNio2Channel extends Nio2Channel  {
 long read = 0;
 //the SSL engine result
 SSLEngineResult unwrap;
+ByteBuffer[] dsts2 = dsts;
+int length2 = length;
+boolean processOverflow = false;
 do {
+processOverflow = false;
 //prepare the buffer
 netInBuffer.flip();
 //unwrap the data
-unwrap = sslEngine.unwrap(netInBuffer, dsts, 
offset, length);
+unwrap = sslEngine.unwrap(netInBuffer, dsts2, 
offset, length2);
 //compact the buffer
 netInBuffer.compact();
 if (unwrap.getStatus() == Status.OK || 
unwrap.getStatus() == Status.BUFFER_UNDERFLOW) {
@@ -1038,9 +1042,28 @@ public class SecureNio2Channel extends Nio2Channel  {
 //here we should trap BUFFER_OVERFLOW and call 
expand on the buffer
 //for now, throw an exception, as we 
initialized the buffers
 //in the constructor
-throw new 
IOException(sm.getString("channel.nio.ssl.unwrapFail", unwrap.getStatus()));
+ByteBuffer readBuffer = 
getBufHandler().getReadBuffer();
+boolean found = false;
+for (ByteBuffer buffer : dsts2) {
+if (buffer == readBuffer) {
+found = true;
+}
+}
+if (found) {
+throw new 
IOException(sm.getString("channel.nio.ssl.unwrapFail", unwrap.getStatus()));
+} else {
+// Add the main read buffer in the 
destinations and try again
+dsts2 = new ByteBuffer[dsts.length + 1];
+for (int i = 0; i < dsts.length; i++) {
+dsts2[i] = dsts[i];
+}
+dsts2[dsts.length] = readBuffer;
+length2 = length + 1;
+
getBufHandler().configureReadBufferForWrite();
+processOverflow = true;
+}
 }
-} while (netInBuffer.position() != 0); //continue to

Re: JDK 12: First Release Candidate available

2019-03-08 Thread Rory O'Donnell

Thanks for updating the bug Mark.

I noticed Weijung has proposed a fix, in code review. [1]

Rgds,Rory

[1] 
https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019424.html


On 04/03/2019 09:13, Rory O'Donnell wrote:

Hi Mark,

Can you update the bug , using your JBS account, with the latest 
information you have etc.


I'll check from this end.

Rgds,Rory

On 01/03/2019 21:28, Mark Thomas wrote:

Rory,

We have received a report [1] of users being affected by a known JRE bug
[2]. I've done some local testing and I believe it affects all current
Java versions. We can work-around it but it would be much better if this
was fixed in the JRE. Is there any chance the priority of [2] could be
bumped up?

Thanks,

Mark


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63205
[2] https://bugs.openjdk.java.net/browse/JDK-8157404



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland


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