[Bug 63724] New: Compile JSP to class when using Tiles and custom tag fails
https://bz.apache.org/bugzilla/show_bug.cgi?id=63724 Bug ID: 63724 Summary: Compile JSP to class when using Tiles and custom tag fails Product: Tomcat 9 Version: 9.0.21 Hardware: All OS: Mac OS X 10.1 Status: NEW Severity: major Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: guilherm...@gmail.com Target Milestone: - Created attachment 36758 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36758&action=edit stacktrace The commit "Replace custom split(String,String) method with call to String.split by Christopher Schultz on 08/05/19 at 21:55 and git hash f7c41d120c6374a8221b684a5ad5ede3d1621ff4" introduced a bug in the version of Apache Tomcat 9.0.21 where the jsp pages using taglibs within struts tiles template are no longer being parsed properly. I got the latest git version and revert the commit (f7c41d120c6374a8221b684a5ad5ede3d1621ff4) mentioned above. The jsp pages are being parsed properly again. This is bug under jasper.jar / class org.apache.jasper.compiler.JspUtil.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
[tomcat] branch master updated: Describe how Tomcat inherits its cryptographic support from the available libraries.
This is an automated email from the ASF dual-hosted git repository. schultz 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 8d7aba9 Describe how Tomcat inherits its cryptographic support from the available libraries. 8d7aba9 is described below commit 8d7aba9388b4786293cb6c4d8fe1f766a4b12b13 Author: Christopher Schultz AuthorDate: Wed Sep 4 12:25:52 2019 -0400 Describe how Tomcat inherits its cryptographic support from the available libraries. --- webapps/docs/ssl-howto.xml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml index c6b554a..7dff058 100644 --- a/webapps/docs/ssl-howto.xml +++ b/webapps/docs/ssl-howto.xml @@ -102,6 +102,24 @@ client are taking place over a secure connection (because your application needs to be able to ask about this), but it does not participate in the encryption or decryption itself. +Tomcat is able to use any of the the cryptographic protocols that are +provided by the underlying environment. Java itself provides cryptographic +capabilities through https://docs.oracle.com/javase/9/security/java-cryptography-architecture-jca-reference-guide.htm";>JCE/JCA +and encrypted communications capabilities through https://docs.oracle.com/javase/9/security/java-secure-socket-extension-jsse-reference-guide.htm";>JSSE. +Any compliant cryptographic "provider" can provide cryptographic algorithms +to Tomcat. The built-in provider (SunJCE) includes support for various +SSL/TLS versions like SSLv3, TLSv1, TLSv1.1, and so on. Check the documentation +for your version of Java for details on protocol and algorithm support. + +If you use the optional tcnative library, you can use +the https://www.openssl.org/";>OpenSSL cryptographic provider +through JCA/JCE/JSSE which may provide a different selection of cryptographic +algorithms and/or performance benefits relative to the SunJCE provider. +You can also use tcnative to enable the APR +connector which uses OpenSSL for its cryptographic operations. Check the +documentation for your version of OpenSSL for details on protocol and +algorithm support. + - 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: Describe how Tomcat inherits its cryptographic support from the available libraries.
This is an automated email from the ASF dual-hosted git repository. schultz 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 720b8c6 Describe how Tomcat inherits its cryptographic support from the available libraries. 720b8c6 is described below commit 720b8c62971ca498bd050c8f05b0046ced273bc4 Author: Christopher Schultz AuthorDate: Wed Sep 4 12:25:52 2019 -0400 Describe how Tomcat inherits its cryptographic support from the available libraries. --- webapps/docs/ssl-howto.xml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml index c6b554a..7dff058 100644 --- a/webapps/docs/ssl-howto.xml +++ b/webapps/docs/ssl-howto.xml @@ -102,6 +102,24 @@ client are taking place over a secure connection (because your application needs to be able to ask about this), but it does not participate in the encryption or decryption itself. +Tomcat is able to use any of the the cryptographic protocols that are +provided by the underlying environment. Java itself provides cryptographic +capabilities through https://docs.oracle.com/javase/9/security/java-cryptography-architecture-jca-reference-guide.htm";>JCE/JCA +and encrypted communications capabilities through https://docs.oracle.com/javase/9/security/java-secure-socket-extension-jsse-reference-guide.htm";>JSSE. +Any compliant cryptographic "provider" can provide cryptographic algorithms +to Tomcat. The built-in provider (SunJCE) includes support for various +SSL/TLS versions like SSLv3, TLSv1, TLSv1.1, and so on. Check the documentation +for your version of Java for details on protocol and algorithm support. + +If you use the optional tcnative library, you can use +the https://www.openssl.org/";>OpenSSL cryptographic provider +through JCA/JCE/JSSE which may provide a different selection of cryptographic +algorithms and/or performance benefits relative to the SunJCE provider. +You can also use tcnative to enable the APR +connector which uses OpenSSL for its cryptographic operations. Check the +documentation for your version of OpenSSL for details on protocol and +algorithm support. + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63625] Unable to start Tomcat 7.0.96 (stop by 0xc0000005)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63625 --- Comment #22 from Christopher Schultz --- (In reply to Rainer Jung from comment #21) > Probably this one: [snip] > -typedef int (__stdcall *WPUTENV) (const wchar_t *env); > +typedef int (*WPUTENV) (const wchar_t *env); OH. I didn't realize WE were responsible for declaring the prototype of the call. Makes sense, now. -- 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 63724] Compile JSP to class when using Tiles and custom tag fails
https://bz.apache.org/bugzilla/show_bug.cgi?id=63724 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Mark Thomas --- Please provide the simplest possible example (which is probably going to be a WAR file) - including source - that demonstrates this 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
buildbot failure in on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4574 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 8d7aba9388b4786293cb6c4d8fe1f766a4b12b13 Blamelist: Christopher Schultz ,Mark Thomas BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #16 from Mark Thomas --- The 2852*5, 2124, 2852*5, 2124, 2852*5, 2124, 2852*5, 2123, 1, etc pattern occurs (in Chrome at least) with a direct POST request with no libraries present. That points to Chrome being responsible for the 1 byte DATA frame. I'll try and reach out to a contact in the Chrome dev team. -- 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 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #17 from Mark Thomas --- https://bugs.chromium.org/p/chromium/issues/detail?id=1000809 The root cause currently looks to be a combination of how Chrome's buffering interacts with flow control windows that do not have an initial size of n*16k and Tomcat's recently added dislike of small, inefficient DATA frames as potentially abusive. While investigating this issue I have found that Tomcat needs to make some changes to ensure that non-default initial window sizes are communicated to the client as early as possible. I'll commit those after I have completed some more testing. I'm also looking into modifying Tomcat's overhead protection so a single DATA frame with a 1 byte payload isn't seen as abusive. -- 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
