tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Resources - Is DirContext the right basis for the API?
Date Thu, 27 Sep 2012 14:34:26 GMT
On Thu, Sep 27, 2012 at 2:14 AM, Mark Thomas <> 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 ?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message