Java HTTP Proxy

Question

I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.

We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.

What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).

I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.

Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.

Or, is there some completely different solution that would work better that we haven't though of?

Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/

Update 2 More information:

The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.

So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.

Answer 1

Why not front weblogic with Apache.

This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.

Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.

Answer 2

Hi TM,

a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy JEE app? What artifact is serving the API (Servlet, EJB, REST service)?

If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.

For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.

Maybe you can provide a bit more information here.

cheers Michael

Answer 3

I think you should be able to do this using a fairly simple custom servlet.

At a high level, you'd:

• Map the servlet to a mapping like /foo/*
• In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
• Pipe the response to the client (some processing may be necessary to handle the headers).

Answer 4

If you instead serve out a JSP page you can use the tag to do the request server side.

Then the user will not even know that the resource was external.

http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html

Answer 5

Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.