tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Resources - Is DirContext the right basis for the API?
Date Thu, 27 Sep 2012 09:09:11 GMT
2012/9/27 Mark Thomas <markt@apache.org>:
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message