You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <co...@gmail.com> on 2012/11/01 00:41:21 UTC
Re: Resources - merging back the changes
Hi Mark,
I synced from HEAD - and noticed that DefaultServlet.PUT now fails with
'403' if the resource already exists.
I'm pretty sure this used to work, and at least for webdav it's supposed to
replace the content.
Is this a bug - or intended (the problem seems to be preResourceExists()
check in StandardRoot.write()) ?
Costin
On Tue, Oct 9, 2012 at 2:27 PM, Mark Thomas <ma...@apache.org> wrote:
> I believe from the various threads on the Resources implementation for
> Tomcat 8 there is agreement that:
>
> - DirContext is not the right basis for the Resources API
> - Refactoring is required to simplify the multiple 'add-ons' and to
> provide a sound basis for overlays (which may slip to Servlet 3.2)
> - Any Resources implementation must provide in-memory caching
>
> The sandbox Resources implementation addresses all of the above and
> passes the Servlet and JSP TCKs as well as all the unit tests.
>
> Given the above, is there any objection to merging the changes made in
> the sandbox back to trunk?
>
> Note that the following TODOs remain:
> - Provide an option to exclude selected resources from the cache
> - Remove the DirContext code
> - Review the use of trailing '/'
> - Determine if a custom URL scheme is required (and implement if it is)
> - Review the interaction of WebappClassLoader and Resources to see if
> there current work-arounds are a) still required b) implemented
> efficiently
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Resources - merging back the changes
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2012 18:25, Mark Thomas wrote:
> On 01/11/2012 05:21, Costin Manolache wrote:
>> On Wed, Oct 31, 2012 at 4:41 PM, Costin Manolache <co...@gmail.com> wrote:
>>
>>> Hi Mark,
>>>
>>> I synced from HEAD - and noticed that DefaultServlet.PUT now fails with
>>> '403' if the resource already exists.
>>> I'm pretty sure this used to work, and at least for webdav it's supposed
>>> to replace the content.
>>> Is this a bug - or intended (the problem seems to be preResourceExists()
>>> check in StandardRoot.write()) ?
>>>
>>
>> Sorry - my mistake reading the code, with a debugger I see
>> preResourceExist() is fine, but DirResourceSet.write() has a check - and
>> from the javadoc the intent seems to be to not overwrite.
>>
>> IMHO it would be better to change the javadoc and implementation to allow
>> overwrites. Alternative is to
>> do a delete before in webdav/default servlet - but I don't see what use
>> case is optimized by not allowing overwrites.
>
> It looks like I didn't include an equivalent of rebind() in the new
> resources implementation. That was an oversight rather than an
> intentional decision. I'll fix that next.
Fixed in r1404724.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Resources - merging back the changes
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2012 05:21, Costin Manolache wrote:
> On Wed, Oct 31, 2012 at 4:41 PM, Costin Manolache <co...@gmail.com> wrote:
>
>> Hi Mark,
>>
>> I synced from HEAD - and noticed that DefaultServlet.PUT now fails with
>> '403' if the resource already exists.
>> I'm pretty sure this used to work, and at least for webdav it's supposed
>> to replace the content.
>> Is this a bug - or intended (the problem seems to be preResourceExists()
>> check in StandardRoot.write()) ?
>>
>
> Sorry - my mistake reading the code, with a debugger I see
> preResourceExist() is fine, but DirResourceSet.write() has a check - and
> from the javadoc the intent seems to be to not overwrite.
>
> IMHO it would be better to change the javadoc and implementation to allow
> overwrites. Alternative is to
> do a delete before in webdav/default servlet - but I don't see what use
> case is optimized by not allowing overwrites.
It looks like I didn't include an equivalent of rebind() in the new
resources implementation. That was an oversight rather than an
intentional decision. I'll fix that next.
Mark
> Costin
>
>
>
>>
>>
>> Costin
>>
>> On Tue, Oct 9, 2012 at 2:27 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>> I believe from the various threads on the Resources implementation for
>>> Tomcat 8 there is agreement that:
>>>
>>> - DirContext is not the right basis for the Resources API
>>> - Refactoring is required to simplify the multiple 'add-ons' and to
>>> provide a sound basis for overlays (which may slip to Servlet 3.2)
>>> - Any Resources implementation must provide in-memory caching
>>>
>>> The sandbox Resources implementation addresses all of the above and
>>> passes the Servlet and JSP TCKs as well as all the unit tests.
>>>
>>> Given the above, is there any objection to merging the changes made in
>>> the sandbox back to trunk?
>>>
>>> Note that the following TODOs remain:
>>> - Provide an option to exclude selected resources from the cache
>>> - Remove the DirContext code
>>> - Review the use of trailing '/'
>>> - Determine if a custom URL scheme is required (and implement if it is)
>>> - Review the interaction of WebappClassLoader and Resources to see if
>>> there current work-arounds are a) still required b) implemented
>>> efficiently
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> 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: Resources - merging back the changes
Posted by Costin Manolache <co...@gmail.com>.
On Wed, Oct 31, 2012 at 4:41 PM, Costin Manolache <co...@gmail.com> wrote:
> Hi Mark,
>
> I synced from HEAD - and noticed that DefaultServlet.PUT now fails with
> '403' if the resource already exists.
> I'm pretty sure this used to work, and at least for webdav it's supposed
> to replace the content.
> Is this a bug - or intended (the problem seems to be preResourceExists()
> check in StandardRoot.write()) ?
>
Sorry - my mistake reading the code, with a debugger I see
preResourceExist() is fine, but DirResourceSet.write() has a check - and
from the javadoc the intent seems to be to not overwrite.
IMHO it would be better to change the javadoc and implementation to allow
overwrites. Alternative is to
do a delete before in webdav/default servlet - but I don't see what use
case is optimized by not allowing overwrites.
Costin
>
>
> Costin
>
> On Tue, Oct 9, 2012 at 2:27 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> I believe from the various threads on the Resources implementation for
>> Tomcat 8 there is agreement that:
>>
>> - DirContext is not the right basis for the Resources API
>> - Refactoring is required to simplify the multiple 'add-ons' and to
>> provide a sound basis for overlays (which may slip to Servlet 3.2)
>> - Any Resources implementation must provide in-memory caching
>>
>> The sandbox Resources implementation addresses all of the above and
>> passes the Servlet and JSP TCKs as well as all the unit tests.
>>
>> Given the above, is there any objection to merging the changes made in
>> the sandbox back to trunk?
>>
>> Note that the following TODOs remain:
>> - Provide an option to exclude selected resources from the cache
>> - Remove the DirContext code
>> - Review the use of trailing '/'
>> - Determine if a custom URL scheme is required (and implement if it is)
>> - Review the interaction of WebappClassLoader and Resources to see if
>> there current work-arounds are a) still required b) implemented
>> efficiently
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>