Re: Resources - Is DirContext the right basis for the API?
On Thu, Sep 27, 2012 at 10:18 AM, Mark Thomas wrote: > > > Costin Manolache wrote: > > >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. > > 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 > >
Re: Resources - Is DirContext the right basis for the API?
On Thu, Sep 27, 2012 at 10:54 AM, Remy Maucherat wrote: > On Thu, 2012-09-27 at 07:34 -0700, Costin Manolache wrote: > > 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. > > Yes, you convinced me to bother with JNDI in order to have a standard > API that others could use if they wanted to integrate. I used it in > Slide, but that was it, so it wasn't useful in the end. Of course, we > had no real idea to know that at the time, and it is possibly because we > didn't bother documenting/advertising it much. > Yes, I was wrong - but I learned a lot in the last 10 years :-) ( and this isn't the only mistake I made ). I still think it's a good idea to have a good abstraction API for resources - and the key is to have it documented/advertised/used and more important implemented for various backends. One way to do this is to make sure it's not very tied to tomcat. Costin > > > 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 ? > > Rémy > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Resources - Is DirContext the right basis for the API?
On Thu, 2012-09-27 at 07:34 -0700, Costin Manolache wrote: > 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. Yes, you convinced me to bother with JNDI in order to have a standard API that others could use if they wanted to integrate. I used it in Slide, but that was it, so it wasn't useful in the end. Of course, we had no real idea to know that at the time, and it is possibly because we didn't bother documenting/advertising it much. > 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 ? Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Is DirContext the right basis for the API?
Costin Manolache wrote: >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. 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
Re: Resources - Is DirContext the right basis for the API?
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 ? Costin
Re: Resources - Is DirContext the right basis for the API?
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? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Is DirContext the right basis for the API?
2012/9/27 Mark Thomas : > On 19/09/2012 20:46, Mark Thomas wrote: >> On 09/09/2012 19:50, Mark Thomas wrote: >>> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt >>> >>> Konstantin has accurately summed up the issues with basing the API on >>> DirContext as: >>> - Unnecessary objects, e.g. NamingException instead of null. >>> >>> - Too many methods. Name vs. String. list() vs. listBindings(). >>> >>> - Limited API. As a workaround, there are non-standard methods that >>>are implemented on BaseDirContext instead, e.g. getRealPath(), >>>doListBindings(..). >>> >>> I do not believe that the resources implementation should be based >>> around DirContext. It adds a lot of unnecessary clutter and complexity >>> to something that is already fairly complex. A comparison of the >>> DirContext based implementation objects with the new implementation >>> demonstrates - in my view - how much simpler this could be. >> >> This is the next issue I'd like to resolve. >> >> Does anyone have any views one way or the other as to whether or not any >> refactoring of the Resources implementation should continue to be based >> around the JNDI DirContext interface? >> >> My own view remains that DirContext adds complexity and clutter to code >> that needs simplicity and clarity. > > There being no arguments against this in the last week, I am going to > move forward on the basis that is issue is resolved and that no-one > feels that DirContext is the right basis for the new resources > implementation. > 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. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Is DirContext the right basis for the API?
On 19/09/2012 20:46, Mark Thomas wrote: > On 09/09/2012 19:50, Mark Thomas wrote: >> This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt >> >> Konstantin has accurately summed up the issues with basing the API on >> DirContext as: >> - Unnecessary objects, e.g. NamingException instead of null. >> >> - Too many methods. Name vs. String. list() vs. listBindings(). >> >> - Limited API. As a workaround, there are non-standard methods that >>are implemented on BaseDirContext instead, e.g. getRealPath(), >>doListBindings(..). >> >> I do not believe that the resources implementation should be based >> around DirContext. It adds a lot of unnecessary clutter and complexity >> to something that is already fairly complex. A comparison of the >> DirContext based implementation objects with the new implementation >> demonstrates - in my view - how much simpler this could be. > > This is the next issue I'd like to resolve. > > Does anyone have any views one way or the other as to whether or not any > refactoring of the Resources implementation should continue to be based > around the JNDI DirContext interface? > > My own view remains that DirContext adds complexity and clutter to code > that needs simplicity and clarity. There being no arguments against this in the last week, I am going to move forward on the basis that is issue is resolved and that no-one feels that DirContext is the right basis for the new resources implementation. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Is DirContext the right basis for the API?
On 09/09/2012 19:50, Mark Thomas wrote: > This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt > > Konstantin has accurately summed up the issues with basing the API on > DirContext as: > - Unnecessary objects, e.g. NamingException instead of null. > > - Too many methods. Name vs. String. list() vs. listBindings(). > > - Limited API. As a workaround, there are non-standard methods that >are implemented on BaseDirContext instead, e.g. getRealPath(), >doListBindings(..). > > I do not believe that the resources implementation should be based > around DirContext. It adds a lot of unnecessary clutter and complexity > to something that is already fairly complex. A comparison of the > DirContext based implementation objects with the new implementation > demonstrates - in my view - how much simpler this could be. This is the next issue I'd like to resolve. Does anyone have any views one way or the other as to whether or not any refactoring of the Resources implementation should continue to be based around the JNDI DirContext interface? My own view remains that DirContext adds complexity and clutter to code that needs simplicity and clarity. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
