Java HTTP Proxy

Question

Я работаю над проектом, в котором мы хотели бы извлечь контент из одного из наших унаследованных приложений, НО, мы хотели бы не показывать "ожидание www.somehostname.com/someproduct / ..." для пользователь.

Мы можем легко добавить другой домен, который указывает на тот же сервер, но у нас все еще есть проблема корневого контекста someproduct в URL. Простое изменение корневого контекста не вариант, так как в унаследованном приложении есть сотни жестко закодированных битов, которые ссылаются на существующий корневой контекст.

Что я хотел бы сделать, так это уметь отправлять запрос в другой корень контекста (скажем, /foo/bar.do), и он действительно должен перейти на /someproduct/bar.do, (но без перенаправления, поэтому браузер по-прежнему показывает /foo/bar.do).

Я нашел несколько опций перезаписи URL, которые делают что-то похожее, но до сих пор кажется, что все они ограничены перехватом / пересылкой запросов только в / из одного корня контекста.

Есть ли какой-нибудь проект, который занимается такими вещами? Мы используем weblogic 10.3 (в устаревшем приложении это weblogic 8). В идеале мы могли бы разместить его как часть нового приложения, но если бы нам пришлось, мы могли бы также добавить что-то к старому приложению.

Или есть какое-то совершенно другое решение, которое бы работало лучше, чем у нас?

Обновление: Я должен упомянуть, что мы уже изначально предлагали использовать apace с mod_rewrite или чем-то подобным, но управление / хостинг дают основание для этого решения. : /

Обновление 2 Дополнительная информация:

Места, где пользователь может видеть старый корень URL / контекста, связаны со страницами / рабочими процессами, которые загружаются из старого приложения в iframe в новом приложении.

Так что на самом деле нет ничего особенного в связи между двумя приложениями, которые может видеть клиент, это обычный старый HTTPS, обрабатываемый браузером.

Answer 1

Я думаю, вы должны сделать это, используя довольно простой пользовательский сервлет.

На высоком уровне вы бы:

• сопоставили сервлет с отображением, подобным/ foo / *
• В реализации сервлета просто возьмите pathInfo запроса и используйте его для отправки запроса на устаревший сайт (используя HttpUrlConnection или эквивалент Apache Commons).
• Передает ответ клиенту (для обработки заголовков может потребоваться некоторая обработка).

Answer 2

Почему бы не использовать weblogic с Apache .

Это очень стандартная настройка, которая также принесет много других преимуществ. Перезапись URL в apache чрезвычайно хорошо поддерживается и документация превосходна.

Не откладывайте настройку, это довольно просто, и вы можете запустить apache на том же компьютере, если это необходимо.

Answer 3

Использование Restlet позволит вам сделать это. Можно использовать объект Redirector . См. здесь и здесь , например.

Answer 4

Если вместо этого вы предоставляете страницу JSP, вы можете использовать этот тег для выполнения запроса на стороне сервера.

Тогда пользователь даже не узнает, что ресурс был внешним.

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

Answer 5

немного больше контекста для API, с которым работает клиент, помог бы здесь найти решение, которое могло бы работать. Вы пытаетесь предоставить совершенно новый API, полностью отличающийся от устаревшего приложения Java EE? Какой артефакт обслуживает API (сервлет, EJB, служба REST)?

Если у вас есть API, предоставляемый другим корпоративным приложением, то, я полагаю, вы просто используете класс Pojo для работы в качестве шлюза к унаследованному приложению, причина которого может быть доступна через корень контекста, отличный от нового приложения-службы. Это решение предполагает, что вы знаете все устаревшие методы API и можете сопоставить их с вызовами нового API.

Для общего решения, в котором вам не нужно беспокоиться о том, какие методы вызываются. Мне любопытно, если прокси-подход действительно может работать. Будут ли учетные данные пользователя также корректно передаваться в устаревшую систему путем перезаписи URL? Придется ли вам переключаться на другого пользователя для устаревших вызовов вместо использования вызывающего абонента? Это возможно с переписыванием URL. Не уверен, что это может работать в безопасном контексте.

Может быть, вы можете предоставить немного больше информации здесь.