On 23/04/2010 12:30, Rainer Jung wrote:
> On 23.04.2010 12:04, Mark Thomas wrote:
>> On 23/04/2010 10:51, Rainer Jung wrote:
>>> On 22.04.2010 18:51, Mark Thomas wrote:
>>>> On 22/04/2010 17:40, Rainer Jung wrote:
>>>>> Experimenting on the extreme side of things: when trying to use
>>>>> aliases="/=/some/path" I can't get any resource to load:
>>>>>
>>>>> - there is /some/path/test.properties
>>>>> - servletContext().getResourceAsStream("/test.properties") returns
>>>>> null.
>>>>>
>>>>> It works, once I use aliases="/myapp=/some/path" and
>>>>> servletContext().getResourceAsStream("/myapp/test.properties").
>>>>>
>>>>> Is that expected?
>>>>
>>>> Nope. Thats broken.
>>>
>>> I see, it was because you need to remove the trailing slash and for "/"
>>> the trailing slash is the leading one too.
>>>
>>> Now using an alias with "/" naively seems to make not much sense (the
>>> webapps will break unless you move everything there).
>>
>> Indeed. You might as well just change the docBase.
>>
>>> I thought about
>>> using slash in order to overwrite stuff. So the expected behaviour for
>>> an alias using "/" would be to only use the alias results, if something
>>> was actually found under the alias.
>>>
>>> I prepared a patch for that:
>>>
>>> http://people.apache.org/~rjung/patches/BaseDirContext_Alias_20100423a.patch
>>>
>>>
>>> What do you think?
>>
>> I think that this, combined the support for resources in JARs under
>> META-INF/resources is adding too much complexity. Let's keep things
>> simple unless there is a use case the current functionality can't meet.
>
> OK, so should we disallow "/" as an alias, or fix the trailing slash
> thing and let the user live with the resulting behaviour? I'd say it
> then makes more sense to disallow "/" (log a startup error) and document
> that and the hint about docBase. I can make the adjustments if you like
> (and agree).
Agree, disallowing / seems the right way to go here. Go for it!
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
