Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe02.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Dealing with application names in a JEE web app References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 52 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Mon, 23 May 2011 22:01:54 UTC Organization: Public Usenet Newsgroup Access Date: Mon, 23 May 2011 19:01:55 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4498 On 11-05-23 04:11 PM, markspace wrote: > Hi all, > > I'm delving more heavily into JSP/Servlets and JSF at the moment. I've > found something that looks like a questionable design issue by the JEE > folks at Sun (now Oracle, of course) and I'd like to pick your brains > about how you might deal with it. > > Basically, when developing a JEE web app, the application name gets > inserted into every URL and associated path. If my app is named > TechDarwinia, for example, then all URLS look like this: > > http://localhost:8080/TechDarwinia/ > http://localhost:8080/TechDarwinia/faces/readPost.xhtml > http://localhost:8080/TechDarwinia/rsrc/css/style.css > > The problem is of course that the web app could be renamed anything by > the deployer/sysop, and I've got strings hard coded to that app name > TechDarwinia. > > So how do folks write their apps so that they can handle being deployed > under different names? [ SNIP ] That "application name" is simply the web context root. A J2EE/Java EE application server can host more than one web application, and that context root in the request URLs is how the app server knows how to pass the request to Web App A and not Web App B. You (anyone in the ops chain) have complete control over what the web context root is, in the application.xml. With respect to your complaint about relative URLs, in response to Lew's suggestion to that effect, I don't think *any* system handles arbitrary movement of web resources (HTML, JSP, XHTML etc). Regardless of how a controller parses the resource path described by the URL (URL parts corresponding to directories in a filesystem hierarchy, or something different like grabbing resources out of a DB) there still has to be a definite mapping. This isn't even a J2EE/Java EE thing: it's a web app thing right across the board. For your other problem, since the resource locations aren't changing, and you are using Faces (Facelets), you have access to JSF EL implicit objects. In a situation like this I use (off the top of my head) #{facesContext.externalContext.requestContextPath} so for example #{facesContext.externalContext.requestContextPath}/rsrc/css/style.css AHS