On Mar 9, 2013, at 4:57 PM, Mark Thomas wrote: > Nick Williams <nicho...@nicholaswilliams.net> wrote: > >> >> On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote: >> >>> Renaming the method is fine. >>> >>> We don't change the API for the sake of it but if there is a need to >> then it is fine. >>> >>> Mark >> >> Look at you top-posting. :-P > > :-) > > Sorry. Mobile client wasn't configured properly.
A likely story. > > >> You replied just as I was. I deprecated getFilename and wrapped it >> around getSubmittedFileName and submitted patch via bug #54658. >> >> Let me know if I should just remove it and re-submit patch. > > No need. We can backport it to 7.0.x with the deprecation and then remove it > in 8.0.x after. > > Note Konstantin's comments though. Done and updated patch submitted. > 1. The @Deprecated method needs a @deprecated Javadoc comment as well, > explaining what the replacement is. Done. > > 2. o.a.c.manager.HTMLManagerServlet.extractFilename() would better be > replaced with a call to the new API. > > (BTW, the current code there is the same as in Part.getFilename()). Done. Hurray for removing duplicated code! > > Mark >> >> Nick >> >>> >>> Nick Williams <nicho...@nicholaswilliams.net> wrote: >>> >>>> I'm implementing the Part#getSubmittedFileName method introduced in >>>> SERVLET_SPEC-57 [1]. >>>> >>>> o.a.c.core.ApplicationPart already has a getFilename method that >>>> accomplishes this that is not part of the interface but IS public. >> This >>>> method is used only in o.a.c.connector.Request (once), but that's >> easy >>>> to change. The concern is that renaming this method might break >>>> applications that depend on the old method name (despite the fact >> that >>>> using Tomcat proprietary code makes their application non-portable). >> Is >>>> it a problem to rename this method in a new major version, or should >>>> Part have both methods, with one calling the other? >>>> >>>> [1] http://java.net/jira/browse/SERVLET_SPEC-57 >>>> >> --------------------------------------------------------------------- >>>> 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 > > > > --------------------------------------------------------------------- > 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
