On 19/09/2012 20:46, Mark Thomas wrote: > On 09/09/2012 19:50, Mark Thomas wrote: >> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt >> >> Konstantin has accurately summed up the issues with basing the API on >> DirContext as: >> - Unnecessary objects, e.g. NamingException instead of null. >> >> - Too many methods. Name vs. String. list() vs. listBindings(). >> >> - Limited API. As a workaround, there are non-standard methods that >> are implemented on BaseDirContext instead, e.g. getRealPath(), >> doListBindings(..). >> >> I do not believe that the resources implementation should be based >> around DirContext. It adds a lot of unnecessary clutter and complexity >> to something that is already fairly complex. A comparison of the >> DirContext based implementation objects with the new implementation >> demonstrates - in my view - how much simpler this could be. > > This is the next issue I'd like to resolve. > > Does anyone have any views one way or the other as to whether or not any > refactoring of the Resources implementation should continue to be based > around the JNDI DirContext interface? > > My own view remains that DirContext adds complexity and clutter to code > that needs simplicity and clarity.
There being no arguments against this in the last week, I am going to move forward on the basis that is issue is resolved and that no-one feels that DirContext is the right basis for the new resources implementation. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
