[Bug 60488] New: NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 Bug ID: 60488 Summary: NPE in Request.parseCookies() Product: Tomcat 9 Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: apa...@ben.eflow.org Target Milestone: - After upgrading to 8.5.9 we have a number of failing tests with this stacktrace: java.lang.NullPointerException at org.apache.catalina.connector.Request.parseCookies(Request.java:3056) at org.apache.catalina.connector.Request.convertCookies(Request.java:3076) at org.apache.catalina.connector.Request.addCookie(Request.java:1733) The request is minimally populated so there are no cookies on it, however, the parseCookies method should not fail. This was broken by rev 1766675 on Oct 26 2016. -- 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 60488] NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 --- Comment #1 from Ben Wolfe --- Created attachment 34529 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34529&action=edit Patch to fix NPE See attached patch to fix this. -- 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 60488] NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 --- Comment #2 from Remy Maucherat --- In that kind of situation, we usually fix the mock object (TesterRequest here) to make it more complete. But it's not failing any Tomcat test, so there's nothing to fix here. You should probably add your own mock object rather than rely on Tomcat's mock objects. -- 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 60488] NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 --- Comment #3 from Ben Wolfe --- The test in my code does this, why should I need to generate mock objects? _request = new Request(); Context context = new StandardContext(); context.setCookieProcessor( new LegacyCookieProcessor() ); _request.getMappingData().context = context; _request.addCookie( new Cookie( "session_id", "s1" ) ); // NPE happens here If I add the cookie before setting the context it passes because of null check in convertCookies(). If I call _request.clearCookies() before addCookie() it works because the cookiesConverted boolean is set to true. -- 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 60488] NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 --- Comment #4 from Remy Maucherat --- Well, if you're using the real org.apache.catalina.connector.Request object, it needs a non null org.apache.coyote.Request coyoteRequest field to work properly (which then takes care of the serverCookies instance being there). Otherwise you have to create a mock object like TesterRequest to have it work right. -- 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 60488] NPE in Request.parseCookies()
https://bz.apache.org/bugzilla/show_bug.cgi?id=60488 --- Comment #5 from Ben Wolfe --- Yes, we do set that too, I just neglected to copy it in: _request.setCoyoteRequest( new org.apache.coyote.Request() ); I did make a mistake, seems its the connector that is null on that line, not the serverCookies. Setting a connector on the request in our test does fix this. Is it possible to have a null connector at this point during normal operation? If not, then we can just chalk this up to more setup being required in testing. And as a sidenote: just because you don't have any tomcat tests failing does not mean it's not a 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 60490] New: Several improvements to the ErrorReportValve
https://bz.apache.org/bugzilla/show_bug.cgi?id=60490 Bug ID: 60490 Summary: Several improvements to the ErrorReportValve Product: Tomcat 8 Version: 8.5.x-trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: 1983-01...@gmx.net Target Milestone: Created attachment 34531 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34531&action=edit Patch for ErrorReportValve Please find attached a patch (against 8.5.x trunk) for the current ErrorReportValve. It is a slightly modified version of my publically available EnhancedErrorReportValve. What has been changed and why: * Properties: ** Translate 'Type' to French and Spanish ** Apply proper case (upper case) for titles and labels according to Chicago Manual of Style ** Add stylistically correct en dash in English, semirraya/raya menor in Spanish and tiret demi-cadratin in French ** Remove all status codes below 400 because they aren't errors and can't be used with this valve anyway due to line 149/150 (Cross-references aren't present to that bundle) ** Remove reference to org/apache/tomcat/util/http/res/LocalStrings.properties, this bundle does not exist any more ** Update all descriptions in English by the most recent versions of today's RFCs (through IANA listings/references) ** Split status codes to reasons and descriptions based on RFCs * Java: ** Import TomcatCSS class for better readablity of the code ** Obtain reason and description from properties ** Align HTML code to HTML5 style ** Change head/title to status code and reason. The user (of a browser) does not care about the server running this webapp. Rather inform the user upfront that an HTTP error has happened and what its phrase is. More details are on the page itself. ** Have statusHeader contain only general information, details are layed out in the body ** Don't show in statusHeader message if showReport is false (applies to the issues above) ** Always include the CSS style because even if showReport is false, it still remains HTML and a few elements are displayed ** Use boolean getters rather than the fields directly ** Use translated label for 'Type' ** Don't abuse div as hr ** Don't use underline and bold, it is considered as bad style ** Omit the message line if there isn't any ** Don't print server info with rootCauseInLogs as it is confusing with the version and duplicates the information with the subsequent line ** Use System.lineSeparator() instead of \n The goal is to clean up old strings, remove duplication and add consistency. -- 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-validate-eoln (in module tomcat-trunk) failed
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-validate-eoln has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 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-validate-eoln : 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-validate-eoln/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate-eoln/gump_work/build_tomcat-trunk_tomcat-trunk-validate-eoln.html Work Name: build_tomcat-trunk_tomcat-trunk-validate-eoln (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml validate-eoln [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/classes:/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 - [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/startup [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/webapps/docs validate-eoln: [javac] Compiling 1 source file to /srv/gump/public/workspace/tomcat-trunk/output/classes [checkeol] Checking line ends in 3061 file(s) [checkeol] Checking line ends in 95 file(s) [checkeol] Done line ends check in 3156 file(s), 18 error(s) found. [checkeol] The following files have wrong line ends: [ [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-none-prolog-none.jspx: uses CRLF on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-none-prolog-utf16be.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-none-prolog-utf16le.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-none-prolog-utf8.jspx: uses CRLF on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16be-prolog-none.jsp: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16be-prolog-none.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16be-prolog-utf16be.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16be-prolog-utf16le.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16be-prolog-utf8.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16le-prolog-none.jsp: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16le-prolog-none.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16le-prolog-utf16be.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16le-prolog-utf16le.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf16le-prolog-utf8.jspx: uses CR on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf8-prolog-none.jspx: uses CRLF on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf8-prolog-utf16be.jspx: uses CRLF on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf8-prolog-utf16le.jspx: uses CRLF on line 1, [checkeol] /srv/gump/public/workspace/tomcat-trunk/test/webapp/jsp/encoding/bom-utf8-prolog-utf8.jspx: uses CRLF on line 1] BUILD FAILED /srv/gump/public
