[undertow-dev] Real path default resolution

Brad Wood bdw429s at gmail.com
Fri Sep 14 15:13:16 EDT 2018


Here's the ticket for consideration:

https://issues.jboss.org/browse/UNDERTOW-1413

If you're busy right now and approve the suggestion, I can take a stab at a
pull request when I have some time.

Thanks!

~Brad

*Developer Advocate*
*Ortus Solutions, Corp *

E-mail: brad at coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com



On Fri, Sep 14, 2018 at 1:57 PM Brad Wood <bdw429s at gmail.com> wrote:

> Thanks for the reply Stuart, I'll enter a ticket for it t be looked at.  I
> may be an edge case, but i could certainly benefit from the slightly
> different approach that allows my custom resource manager to do its thing..
>
> Thanks!
>
> ~Brad
>
> *Developer Advocate*
> *Ortus Solutions, Corp *
>
> E-mail: brad at coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com
>
>
>
> On Fri, Sep 14, 2018 at 12:48 AM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>>
>>
>> On Fri, Sep 14, 2018 at 3:38 PM Brad Wood <bdw429s at gmail.com> wrote:
>>
>>> I'm using Undertow for the deployment of Adobe ColdFusion and Lucee
>>> Server sites, which for historical reasons and convenience, keeps two
>>> separate folders for the WAR/web-inf and the actual web root where content
>>> is served from.
>>>
>>> In your typical J2EE setup, the real path "/" is the parent of
>>> "/WEB-INF" but that is not the case for me and we use a custom resource
>>> manager with great success to handle the correct resolution of paths in the
>>> server.
>>>
>>> We have one issue however in the event of path resolution for non
>>> existent files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist
>>> yet the first time a server comes up.  Since it doesn't exist, my custom
>>> resource manager (who knows where the real WEB-INF lives) returns null as
>>> it should which leaves it up to this line of code:
>>>
>>> https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbbaa6df291e390/servlet/src/main/java/io/undertow/servlet/spec/ServletContextImpl.java#L389
>>> to "guess" where the file would exist if it were to be created.  Since
>>> it roots it in the real path of "/", it guessing incorrectly in my case and
>>> the result is I have folders and files created in the wrong directory.
>>>
>>> This is rather tricky since my custom resource manager would tell the
>>> servlet context exactly where "/WEB-INF" is if it were to ask that
>>> question, but since it asks for "/", a different answer is given.
>>> Interestingly enough, had the example provided in the final comment of this
>>> ticket been followed, it would work for me since it progressively attempts
>>> to resolve the path while peeling back directories one at a time until it
>>> finds one that exists.
>>>
>>> https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13036336
>>>
>>> There's no comment on the ticket as to why that solution wasn't used,
>>> but I would presume to avoid additional disk hits.  I'm looking for ways
>>> that I can still control how /WEB-INF is resolved with my custom resource
>>> manager, even for non-existent paths.  Save the progressive searching I
>>> mentioned in the previous paragraph, the only other solution I can think of
>>> is for the servlet contexts' getRealPath() to detect when a non existent
>>> path begins with /WEB-INF and asking the resource manager to resolve
>>> /WEB-INF in that case instead of / so it can get a more specific answer.
>>>
>>> Thoughts?
>>>
>>
>> I am ok with the solution in UNDERTOW-373, the main reason why it was not
>> followed was because it just did not seem necessary, as with the default
>> resource managers the result is basically the same, but if there is a use
>> case for it I am happy to adopt this approach.
>>
>> Stuart
>>
>>
>>>
>>> Thanks!
>>>
>>> ~Brad
>>>
>>> *Developer Advocate*
>>> *Ortus Solutions, Corp *
>>>
>>> E-mail: brad at coldbox.org
>>> ColdBox Platform: http://www.coldbox.org
>>> Blog: http://www.codersrevolution.com
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180914/e42b98b8/attachment.html 


More information about the undertow-dev mailing list