On Thu, Sep 27, 2012 at 2:14 AM, Mark Thomas <ma...@apache.org> wrote:
> On 27/09/2012 10:09, Konstantin Kolinko wrote: > > 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. > > The only reason I can see for avoiding Tomcat dependencies is > portability. There is no guarantee that other containers will provide > the same interface. There is, however, a reason for other containers not > to provide the same interface - the Servlet API already provides a > standard, container neutral, portable way to access resources. > > Is there another use case where avoiding compile time dependencies might > be useful? > One use for a resource API is if it provides different backends - like Hadoop filesystem abstraction does. Than you could serve from hdfs/db/etc, and someone could use the same api in deploy tools or general programs. One of the unrealized benefits with JNDI was that it may provide many backends - LDAP, DB, etc - that would be directly usable in tomcat. If the new resources can be implemented as a self-contained dependency, i.e. don't require the entire tomcat - someone could use them in other apps. BTW - how does it compare with hadoop FS ? Costin
