Question on SERVLET_SPEC-57 (getSubmittedFileName)
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
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
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 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
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
On Mar 9, 2013, at 3:15 PM, Nick Williams 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 Based on what others had done in the past, I deprecated getFilename and wrapped it around getSubmittedFileName. Patch has been submitted via bug #54658. If I need to remove getFilename instead of deprecating it, I can resubmit my patch if asked. Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
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 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. 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
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
2013/3/10 Nick Williams nicho...@nicholaswilliams.net: 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 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. 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 1. The @Deprecated method needs a @deprecated Javadoc comment as well, explaining what the replacement is. 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()). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
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. 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. 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
Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)
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
