On Wed, Oct 31, 2012 at 4:41 PM, Costin Manolache <cos...@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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >
