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/ff4c9cf37872cb96070ba6a2fcbb... 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&am... 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?

Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad(a)coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

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(a)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(a)redhat.com&gt; wrote: > > > On Fri, Sep 14, 2018 at 3:38 PM Brad Wood <bdw429s(a)gmail.com&gt; 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/ff4c9cf37872cb96070ba6a2fcbb... >> 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&am... >> >> 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(a)coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > >