Costin Manolache <cos...@gmail.com> wrote:
>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. Given the time the DirContext based resources API was in Tomcat and the lack of wider use suggests that either there is no demand or that the API did not meet the requirements of users that had a requirement for it. >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. They are not entirely self-contained. They could be with some refactoring, but that isn't particularly high on my to do list. The APIs are also very focussed on what a Servlet container requires. They are not general. Again they could be but it isn't a priority for me. >BTW - how does it compare with hadoop FS ? Don't know, haven't looked. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
