On Thu, Sep 27, 2012 at 10:18 AM, Mark Thomas <ma...@apache.org> wrote:
> > > 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. > I agree, 10 years ago we didn't know this will happen. > >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. > As I said, I think a problem with JNDI is that it ended up not getting used, and it doesn't have too many backends. The new resource API is a step forward - it's cleaner/simpler - but I think having it used (and implemented) outside tomcat would help. Alternative: have an easy way to wrap other APIs, like hadoop. It's well worth comparing with and using hadoop APIs - there are plenty of new storage systems and it seems a useful thing to be able to integrate well and serve from them. > 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 > >
