This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have a servlet (parent) that needs to invoke another servlet (child) that resides on the same appserver (Could be Tomcat, Websphere or Weblogic). The way we build the URL now to reach the child servlet is to build the URL up by pulling the protocol, host and port out of the request object when the parent servlet executes. Since the child is on the same appserver, we use the same host/port and protocol. The host is always going to be local, so we could just use localhost instead of a getHost() call.
This code works fine, but some clients have started to use a load balancer and if the LB is not configured to pass through the client's address in the request object, what happens is we wind up getting back the IP/port of the LB instead of the app server and our servlet request will fail.
As a solution, we could change to use "localhost" instead of calling srcURL.getHost(), however how would we resolve the port? For instance, the port Tomcat is listening on is not guaranteed to be 8080 and can be changed by the user (same with other appservers). Is there a way to dynamically determine what port the app server is using without requiring the user to have to tell the servlet or by getting it out of the request object?
My problem is the opposite, I don't know the context root.
My Java servlet needs to invoke another Java servlet that resides on the same app server. I can use localhost, but how would I know what port to use? Our customers using our servlets aren't always using 8080 and may be using Websphere or Weblogic and are free to change the port to whatever they want.
What we are doing now is looking at the Request object that was passed to the first servlet, then extracting the host, port and protocol from that to create the URL to find the 2nd servlet. The problem is some customers are now using Load Balancers which pass in the host, port and protocol relative to the load balancer and not relative to our app server which causes us problems. Since I know we are local, I know localhost will work, but I don't know if the port has changed and I can't rely on the Request object to give me the port.
Bear recommended using a relative path, but I can't seem to make that work when creating the URL I need to invoke the 2nd servlet.
Joined: May 16, 2009
I am sure that the HttpServletRequest have some methods retrieve the URL and the URI from a particular request object.
But if you talk about the second servlet, then you MUST know the port where it was deployed.
DNS server could have being the solution, to resolve this inconsistency/change in the address (port no).
But since it seems there is no DNS server to resolve this, your have no alternative than to create a mechanism to conform that
the URI is valid before processing a request.
Because you're creating a HTTP connection to the 2nd servlet, you need the port number. But if that servlet resides in the same application (or even same domain) as your servlet, using RequestDispatcher could be handier, no port number needed (but you still need to know the relative path from the context path to that 2nd servlet)
And context root is available at ServletContext.getContextPath()
And if all solutions fail, you can always ask your client to input the correct address of the 2nd servlet in some database table.