You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2013/03/09 22:15:56 UTC

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Nick Williams <ni...@nicholaswilliams.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Mar 9, 2013, at 4:57 PM, Mark Thomas wrote:

> Nick Williams <ni...@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 <ni...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Mark Thomas <ma...@apache.org>.
Nick Williams <ni...@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 <ni...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/3/10 Nick Williams <ni...@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 <ni...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Nick Williams <ni...@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 <ni...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

Posted by Mark Thomas <ma...@apache.org>.
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 <ni...@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-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org