Re: [VOTE] Release Apache Tomcat 8.5.4
Am 6. Juli 2016 11:42:47 MESZ, schrieb Mark Thomas : >The proposed Apache Tomcat 8.5.4 release is now available for voting. > >The major changes compared to the 8.5.3 release are: > >- Correct a regression in the embedded packaging > >- Add the ability to control the degree of concurrency when processing > HTTP/2 connections > >- Update to Tomcat Native 1.2.8 > > >It can be obtained from: >https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.4/ >The Maven staging repo is: >https://repository.apache.org/content/repositories/orgapachetomcat-1090/ >The svn tag is: >http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_4/ > >The proposed 8.5.4 release is: >[ ] Broken - do not release >[ ] Alpha - go ahead and release as 8.5.4 >[ ] Beta - go ahead and release as 8.5.4 >[x] Stable - go ahead and release as 8.5.4 Regards, Felix > >- >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
[VOTE][RESULT] Release Apache Tomcat 9.0.0.M9
The following votes were cast: Binding: +1: markt, kfujino, mgrigorov, remm, fschumacher Non-Binding: +1: Huxing Zhang The vote therefore passes. Thanks to everyone who contributed to this release. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r14373 - /dev/tomcat/tomcat-9/v9.0.0.M9/ /release/tomcat/tomcat-9/v9.0.0.M9/
Author: markt Date: Tue Jul 12 19:26:40 2016 New Revision: 14373 Log: 9.0.0.M9 release vote passed Added: release/tomcat/tomcat-9/v9.0.0.M9/ - copied from r14372, dev/tomcat/tomcat-9/v9.0.0.M9/ Removed: dev/tomcat/tomcat-9/v9.0.0.M9/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59832] SLS/TLS 8.5.3 upgrade from 8.0.32 using NIO2 encoding
https://bz.apache.org/bugzilla/show_bug.cgi?id=59832 --- Comment #6 from Mark Thomas --- You are the only person reporting this issue. No one else in the Tomcat dev community is able to reproduce this. If the issue can't be reproduced, and the problem description is not specific enough to identify the problem via code analysis (and this issue is a long way from being able to do that) then the issue can't be fixed. NIO2 + TLS is working across a range of platforms. It is covered by the unit tests which are run automatically on serveral flavours of Unix by the CI systems as well as on OSX and Windows by committers at least every release including every 8.5.x release. There are significant differences between 8.0.x and 8.5.x since the connectors were refactored and a number of new features added. It is possible that there is a bug in the NIO2 implementation. It is also possible that the changes have exposed a bug in your application. Until you provide the rest of the Tomcat dev community with a means of reproducing this problem this is going to remain in the NEEDINFO state. Typically, such issues are transitioned to RESOLVED / WORKSFORME if no steps to reproduce are provided after several months. An additional concern is that you changed the connector configuration between 8.0.x and 8.5.x. That should not have been necessary. Tomcat should have translated the settings for you. This may be a separate issue but it may also be a symptom of this issue. Asking you questions to narrow down the source of the problem, including asking for a minimal test case, is perfectly reasonable and your refusal is not going to motivate anyone to help you. You have access to a system that demonstrates the problem. The remainder of the Tomcat dev community does not. You are in a position to remove components from the application until you have the minimal set that demonstrates the issue. The remainder of the Tomcat dev community is not. The Tomcat dev community wants to help you fix this issue but that isn't going to be possible if you continue to refuse to provide a test case or answer the questions we ask. -- 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
[VOTE][RESULT] Release Apache Tomcat 8.5.4
The following votes were cast: Binding: +1: remm, mgrigorov, fschumacher Non-Binding: +1: Huxing Zhang The vote therefore passes. Thanks to everyone who contributed to this release. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r14374 - /dev/tomcat/tomcat-8/v8.5.4/ /release/tomcat/tomcat-8/v8.5.4/
Author: markt Date: Tue Jul 12 20:03:27 2016 New Revision: 14374 Log: 8.5.4 release vote passed Added: release/tomcat/tomcat-8/v8.5.4/ - copied from r14373, dev/tomcat/tomcat-8/v8.5.4/ Removed: dev/tomcat/tomcat-8/v8.5.4/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1752341 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Jul 12 20:08:37 2016 New Revision: 1752341 URL: http://svn.apache.org/viewvc?rev=1752341&view=rev Log: Add M9 release date 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=1752341&r1=1752340&r2=1752341&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Jul 12 20:08:37 2016 @@ -63,7 +63,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59832] SLS/TLS 8.5.3 upgrade from 8.0.32 using NIO2 encoding
https://bz.apache.org/bugzilla/show_bug.cgi?id=59832 --- Comment #7 from Steve Mekkelsen Madden --- Created attachment 34034 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34034&action=edit exception with NIO2 & protocol tags missing exception thrown when using NIO2 and not specifying the SSLPROTOCOL OR SSLENABLEDPROTOCOLS in the SSLHOSTCONFIG tag. -- 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 59832] SLS/TLS 8.5.3 upgrade from 8.0.32 using NIO2 encoding
https://bz.apache.org/bugzilla/show_bug.cgi?id=59832 --- Comment #8 from Steve Mekkelsen Madden --- Thank for you the response. I've been testing this all day and trying to figure out a way to reproduce it and was able to reproduce and resolve the problem. But as you pointed out, yes I was forced to change the connector to what I provided to the more expanded version for it to startup without any errors. A symptom of a different issue - probably so since it should just work, but what I found today was this: https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2_(deprecated). Not sure why I couldn't earlier, but it does show that the arguments have been deprecated (possibly too harshly??). After changing my connector to: The application no longer complained about the xml returned. Note: the only change was adding sslProtocol and sslEnabledProtocols to the SSLHostConfig option. Without those two added, this is what I see which kind of makes sense now that I found where the problem is. These parameters were in the previous version, but I took it too literally about being deprecated and part of SSLHostConfig thinking I no longer needed it. I've attached it as saxparseexception.txt. So the bug I believe can be qualified now as if the two arguments are not included and you specify NIO2, it breaks the app. However, with NIO you don't need the two arguments and it still works. -- 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: r1752343 - /tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Jul 12 20:25:18 2016 New Revision: 1752343 URL: http://svn.apache.org/viewvc?rev=1752343&view=rev Log: Add 8.5.4 release date Modified: tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml?rev=1752343&r1=1752342&r2=1752343&view=diff == --- tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Tue Jul 12 20:25:18 2016 @@ -63,7 +63,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
isAsyncStarted=true on ERROR dispatch
hi- Starting with Tomcat 8.0.35 when an async request times out, in a subsequent error dispatch request.isAsyncStarted() returns true. Previously it returned false. The Servlet spec says: If this request has been dispatched using one of the AsyncContext.dispatch methods since it was put in asynchronous mode, or a call to AsynContext.complete is made, this method returns false. No explicit mention of ERROR dispatches but I'd assume once the request that called startAsync is done, it won't return true any more. For what it's worth Jetty still return false on the ERROR dispatch. Here is a repro project [1]. Before creating a ticket I wanted to check if this is expected behavior or an unintended side effect of other changes? Rossen [1] https://github.com/spring-projects/spring-framework-issues/tree/master/SPR-1
Re: leak if jspServlet.destroy() fails
Hi all,
is (jsp) generated code for tags suffering from the same kind of issue? For
a c:out I get:
private boolean
_jspx_meth_c_005fout_005f0(javax.servlet.jsp.PageContext
_jspx_page_context)
throws java.lang.Throwable {
javax.servlet.jsp.PageContext pageContext = _jspx_page_context;
javax.servlet.jsp.JspWriter out = _jspx_page_context.getOut();
// c:out
org.apache.taglibs.standard.tag.rt.core.OutTag
_jspx_th_c_005fout_005f0 =
(org.apache.taglibs.standard.tag.rt.core.OutTag)
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.get(org.apache.taglibs.standard.tag.rt.core.OutTag.class);
_jspx_th_c_005fout_005f0.setPageContext(_jspx_page_context);
_jspx_th_c_005fout_005f0.setParent(null);
// /fail.jsp(30,0) name = value type = null reqTime = true required
= true fragment = false deferredValue = false expectedTypeName = null
deferredMethod = false methodSignature = null
_jspx_th_c_005fout_005f0.setValue((java.lang.Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${'
, &'}", java.lang.Object.class,
(javax.servlet.jsp.PageContext)_jspx_page_context, null));
int _jspx_eval_c_005fout_005f0 = _jspx_th_c_005fout_005f0.doStartTag();
if (_jspx_th_c_005fout_005f0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
return true;
}
_005fjspx_005ftagPool_005fc_005fout_0026_005fvalue_005fnobody.reuse(_jspx_th_c_005fout_005f0);
return false;
}
Wonder if the reuse() shouldn't be in a finally block - in particular
for custom tags. Wdyt?
Romain Manni-Bucau
@rmannibucau | Blog
| Old Wordpress Blog
| Github |
LinkedIn | Tomitriber
| JavaEE Factory
2016-07-01 19:25 GMT+02:00 Mark Thomas :
> On 01/07/2016 17:28, Romain Manni-Bucau wrote:
> > Think org.apache.jasper.runtime.TagHandlerPool#release can be affected
> too
> > - I'm not sure where it is called in the codebase but the pattern is the
> > same.
>
> I've doing a review of all calls to destroyInstance() now. There is at
> least one further issue as well as the tag one you spotted.
>
> Mark
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Wordpress Blog
> > | Github <
> https://github.com/rmannibucau> |
> > LinkedIn | Tomitriber
> > | JavaEE Factory
> >
> >
> > 2016-07-01 18:10 GMT+02:00 Romain Manni-Bucau :
> >
> >> +1
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau | Blog
> >> | Old Wordpress Blog
> >> | Github
> >> | LinkedIn
> >> | Tomitriber
> >> | JavaEE Factory
> >>
> >>
> >> 2016-07-01 18:06 GMT+02:00 Mark Thomas :
> >>
> >>> On 01/07/2016 16:41, Romain Manni-Bucau wrote:
> Hello guys,
>
> if a jspDestroy() throws an Exception then the instance manager is not
> called which can lead to some leaks depending the implementation (see
> org.apache.jasper.servlet.JspServletWrapper#destroy)
>
> Would it be possible to have a way to release/cleanup the jsp context
> through the instance manager or to call destroyInstance properly?
> >>>
> >>> I think wrapping the call to destroy in a try/catch would be the way to
> >>> go. It would be worth a check to see if there are any other places
> where
> >>> similar issues could occur with JSPs.
> >>>
> >>> 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 59832] SLS/TLS 8.5.3 upgrade from 8.0.32 using NIO2 encoding
https://bz.apache.org/bugzilla/show_bug.cgi?id=59832 --- Comment #9 from Steve Mekkelsen Madden --- more testing and my last comment about it now working is false. The prolog content error is prevalent in each transaction I do even with the two additional parameters. What wasn't working on the OPEN of the instance, is broken when I try to save/update the instance. So it's confusing that this works perfectly fine in 8.0.32 using the old style connector parameters, but in 8.5.3 the old style doesn't work and the new tags in it while allows tomcat to start our application, doesn't allow us to do anything useful. But the new format and just changing the protocol to NIO works perfectly. This is all confusing how this works - please bear with me while I wrap my head around it. I do understand and appreciate you're trying to help, believe me. Are you looking for a zipped up copy of Tomcat minus our application or the exact changes I've made in the few xml files so that it could be replicated in-house? As a software company, I have to be conscious of security and NDA's for our application but will provide what I can. Do you want access (url) to a system that shows the error including the logfiles? Just curious how much access would be needed for help? 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
