2012/9/27 Mark Thomas <ma...@apache.org>: > 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. >
I am sure that DirContext is not the right API to define resources. At best is could be a [deprecated] view/proxy to the actual implementation. The only benefit I see in using this API by someone is that the API itself is defined in javax.* and so one can avoid compile-time dependencies on Tomcat code. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
