tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Donahue - OETX <>
Subject RE: Baked-in context paths
Date Tue, 05 Nov 2013 19:23:24 GMT
>-----Original Message-----
>From: Milo Hyson []
>Subject: Baked-in context paths
>As suggested, I'm bringing this issue to the list so that I might understand the
>thinking behind an argued best practice. In
> it is said that the
>correct way for a Tomcat application to construct internally-referencing URLs is
>to include the context path so as to avoid relative linking. Given as justification
>was the following article:
>The problem is the article seems to be describing issues that are general in
>nature and not specific to relative linking. For instance, incorrect links are
>incorrect links regardless of the form they take. Testing should catch such things
>before live deployment.
>I've used relative linking for years in many different systems without issue, so
>I'm left wondering why baking-in the context path is considered proper.
>- Milo Hyson
>Chief Scientist
>CyberLife Labs, Inc.


I saw your post in the HTTPD forums and since no one wanted to talk about it there, I was
hoping you would post here.  

I can think of one way relative URLS are needed.  In JSF, if you put resources under WEB-INF,
and one resource references another under WEB-INF, I don't think that making a full request
to the resource will work.

Example: (man I hope this format stays in tact...)

|- yourapp
|--- WEB-INF
|----- templates
|------- template_index.xhtml  - template_index.xtml references the header footer and content
pages in the same template directory such as: <ui:include src="header.xhtml"/>
|------- header.xhtml
|------- footer.xhtml
|------- ...etc
|- index.xhtml  - index.xhtml is a facelets template with a line such as:  <ui:composition

I guess it just depends on how you build the site, but if you are doing it in Java under Tomcat,
some users here prefer that web apps be fully contained.  What if you want to move this web
app to another server on another domain?  Would you not have to refactor all of the fully
qualified URLs in your app?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message