51

I'm writing a Java web app using Spring MVC. I have a background process that goes through the database and finds notifications that must be e-mailed to my users. These e-mail messages need to include hyperlinks to the application. This seems like a fairly common pattern for a web app, but I'm having trouble.

How do I derive my application's fully qualified URL, with server name and context path? I don't have access to any of the methods in HttpServletRequest because I'm running this as a background process, not in response to a web request. The best I can do is get access to ServletContext.

Currently I'm putting the base URL into a configuration file and reading it at startup, but this application is going to be licensed and deployed to customers' application servers, and if possible I'd like them not to have to configure this manually.

Josh Hinman
  • 6,745
  • 7
  • 38
  • 47
  • Why can't you use a relative URL? – Eddie Mar 24 '09 at 00:30
  • 7
    Relative to what? This is being sent out in an e-mail. – Josh Hinman Mar 24 '09 at 00:31
  • Ah, if it's being sent out in an EMail, then of course you need a full path. I thought maybe this was part of Servlet -- something that started a background task. – Eddie Mar 24 '09 at 00:35
  • This is driving me nuts too, it's all very fine to try to make things relative, but you have to be able to publish a full path in some situations. I'm currently struggling with a stupid system that demands a full path for configuring its servlet of all things. That's awful in my view because it prevents creating a relocatable WAR. I was hoping that a good answer to this question would let me patch it from the outside though. – Toby Eggitt Nov 19 '13 at 21:47

4 Answers4

33

It is not recommended to dynamically prepare the URL at run time, especially based on ServletRequest. This is primarily because you have no idea of the URL that users would be using to access the application - the application server could be behind a web server, a firewall or a load balancer. To keep it short, one cannot predict network topologies.

Your current technique of fetching the URL from the property file is good enough to resolve the said issue. Maybe you should look at providing an administrative console to manage the URL appearing in mails, especially if there is an admin console in place, or if there are related options that should go into one.

Edit: My last point echoes what Tony has spoken of.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
8

Why just not have a setup web page that comes up the first time the application is run if the configuration file does not exist (in WEB-INF folder for example. Using ServletContext, you can call getRealPath and get the real path of a File and see if it exists(). If it does, redirect to the app start page, if it does not, open the admin page).

The best you cam do with ServletContext is read some settings from web.xml, and get the context path, only the HttpRequest can give you the FQ URL.

Tony BenBrahim
  • 7,040
  • 2
  • 36
  • 49
  • 5
    To all the people downvoting: The user is hitting www.acme.com which is an F5 firewall/reverse proxy, which connects to an internal load balancer at http://loadbalancer.internal.acme.com, and eventually hits your webserver at http://appserver3.internal.acme.com. The last thing you want to do is to (re)direct a user to a page on http://appserver3.internal.acme.com. The answer given is the correct answer, you cannot do any better. – Tony BenBrahim Feb 03 '15 at 10:14
3

I think you can use something like:

String host = InetAddress.getLocalHost().getCanonicalHostName();
String appUrl = String.format("http://%s:%s%s", host, port, contextPath);

with port and contextPath from ServletContext.

O.Wozniak
  • 31
  • 4
1

Servlet 2.5 added getContextPath() to ServletContext. Updating EE dependency versions definitely should resolve your issue.

More info here:

Community
  • 1
  • 1
gavenkoa
  • 45,285
  • 19
  • 251
  • 303
  • 3
    Context path doesn't return a fully qualified url. For example if your full url is www.google.com/v7, then getContextPath() will return "/v7". So to help anyone else, this doesn't answer the question, although could still potentially be helpful to folks reading the wrong question trying to get the context path. – TheJeff May 19 '20 at 19:09
  • 1
    @TheJeff Load balancers & proxies should be mentioned. They make getting *protocol/host/port meaningless*. You can jump parsing proprietary headers but only `getContextPath()` **part is reliable**, unless there are some rewriting on the way )) – gavenkoa May 20 '20 at 11:00