tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Date Sat, 16 Jun 2012 21:42:36 GMT
On 16/06/2012 19:18, Mark Thomas wrote:
> 
> 
> Konstantin Kolinko <knst.kolinko@gmail.com> wrote:
> 
>> 2012/6/16 Mark Thomas <markt@apache.org>:
>>> 
>>>> URLs are needed per Servlet API, so they cannot be removed.
>>>> Does our "jndi" schema need DirContext as underlying
>>>> implementation?
>>> 
>>> Our jndi scheme was used to provide access to resources. I
>>> believe
>> all
>>> of that will now go.
>>> 
>>>> I noticed the following commit in archives: 
>>>> http://svn.apache.org/viewvc?view=revision&revision=1137646 so
>>>> we have to deal with such schema combinations as "jar:jndi:".
>>> 
>>> No we won't. We only hadf to deal with URLs like that because we 
>>> generated them.
>>> 
>> 
>> How are you going to implement ServletContext.getResource(String):
>> URL
>> 
>> without a custom URL scheme  (be it named "jndi" or somehow else)?
>> 
>> For file resources it might be possible to produce the "actual"
>> URL pointing to a JAR entry or to a file (leaving aside the
>> question of whether it exposes too much details),  but you cannot
>> do so with directories,  as entries in a directory can be assembled
>> from several sources.
> 
> My intention was to use the URL for the actual resource. For
> directories, I'll use the first matching dir I find although I need
> to re-read the spec and Javadoc to make sure there aren't any nasty
> surprises waiting to trip me up.

Having re-read the specification and Javadoc, I don't see anything of
concern. Additional pairs of eyes wouldn't hurt though.

How to handle getResource() for a directory that exists in one or more
overlays and/or the main WAR is an interesting question. I'll be sure to
raise it within the Servlet EG when we get back to that question.

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message