tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Resources - Is DirContext the right basis for the API?
Date Thu, 27 Sep 2012 18:48:29 GMT
On Thu, Sep 27, 2012 at 10:18 AM, Mark Thomas <markt@apache.org> wrote:

>
>
> Costin Manolache <costin@gmail.com> wrote:
>
> >On Thu, Sep 27, 2012 at 2:14 AM, Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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