On 24/11/2017 21:49, Konstantin Kolinko wrote: > 2017-11-24 20:44 GMT+03:00 <ma...@apache.org>: >> Author: markt >> Date: Fri Nov 24 17:44:17 2017 >> New Revision: 1816247 >> >> URL: http://svn.apache.org/viewvc?rev=1816247&view=rev >> Log: >> Fix a handful of low severity SpotBugs reports >> - Serialization warnings. Probably ignorable but the fix is simple. >> >> Modified: >> tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java >> tomcat/trunk/java/org/apache/catalina/servlets/WebdavServlet.java >> >> Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1816247&r1=1816246&r2=1816247&view=diff >> ============================================================================== >> --- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java >> (original) >> +++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Fri >> Nov 24 17:44:17 2017 >> @@ -233,7 +233,7 @@ public class DefaultServlet extends Http >> * the platform default is used. >> */ >> protected String fileEncoding = null; >> - private Charset fileEncodingCharset = null; >> + private transient Charset fileEncodingCharset = null; > > Wrong. > This does not fix the issue. Deserialization does not restore this > field, it not it is initialized lazily - it is initialized in init().
That depends on how Servlets are meant to be serialized / deserialized. My assumption was init() would be called after deserialization. That is nothing more than an assumption though. Your e-mail got me thinking - we are Servlets serializable in the first place. I couldn't see an obvious use case. Most of the search results I found led to various forms of the mistaken view that Servlets needed to be serializable for a distributable web application. Essentially folks were mixing up the requirements for session attributes with Servlets. Eventually, I found this: https://coderanch.com/t/358966/java/HttpServlet-implement-Serializable You need to scroll down until you find the quote from James Duncan Davidson back in 2004: <quote> The interfaces specify serializable so that a servlet can be serialized into a .jar file by a tool and reconsituted later by a servlet engine. This behavior however is not yet well specified. </quote> To my knowledge, that behaviour was never specified. > To complete the fix you have to implement a "private void > readObject(java.io.ObjectInputStream in)" > method that calculates this field in the same way as init() does, > or calculate this field lazily on first use. > > (Though I do not know of a use case that involves serializing and > deserializing a Servlet. I guess that deserialization won't be > followed by an init() call.) Given that serialization of a Servlet is never going to happen - or if it does then the behaviour will need to be specified in the Servlet spec - I'm not sure this is worth a further fix. If we do anything - and I'm leaning towards doing nothing at this point - I'd be more inclined to revert the fix and mark it as a false positive. Mark > > See > https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html > > >> /** >> * If a file has a BOM, should that be used in preference to >> fileEncoding? >> > > The second half of this commit (WebdavServlet) is OK. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > 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
