Доступ к объекту httprequest внутри POJO, вызываемому WebSphere Command/JSP/etc?

Краткая версия: как я могу получить доступ к объекту HttpRequest из кода POJO, который вызывается командой/JSP, выполняемым WebContainer?

  • POJO не знает о CommandContext или HttpRequest (или их кузенах).
  • POJO находится довольно глубоко в стеке выполнения, поэтому изменение сигнатуры метода означает изменение всех сигнатур родительского метода и мест, где эти методы вызываются.

Я также проверил аналогичный пост (мой POJO вызывается WebContainer, и должен быть способ каким-то образом получить доступ к запросу, не проходя через такие обручи): Получение веб-сеанса из POJO вне веб-контейнера

Длинная версия: я пытался найти эту иголку в стоге сена: пытаясь выяснить способ доступа к объекту HttpRequest (или его двоюродным братьям) на сервере приложений WebSphere (на самом деле Commerce) с помощью через текущий поток WebContainer (или любым другим способом, аналогичным получению транзакции через TransactionManager).

Зная, что эти потоки контейнера привязаны к одной исполняемой странице/команде/и т. д., мне было интересно, есть ли способ сделать это без использования WorkArea, стиль ThredLocal, не столь желательные подходы?

Проблема, с которой мы столкнулись, заключается в том, что за эти годы было написано много фрагментов кода, которые не заботились о storeId или langId. Таким образом, вместо того, чтобы исправлять все эти фрагменты кода, мы хотели бы каким-то образом получить доступ к контексту сеанса (с помощью объекта HttpRequest), чтобы мы могли получить CommandContext и/или другие структуры, чтобы узнать наш storeId и langId и другие данные, привязанные к сеансу. .

Любая дополнительная информация требуется, пожалуйста, не стесняйтесь спрашивать.

Один пример фрагмента псевдокода:

public class MyLittleHelper {

. . . 

void unawareMethod() {
  // I know it is really bad practice not to pass the actual objects around...  
  // But hear me out for a sec... 
  // This could be the easiest way of changing things, however bad it looks. 

  // my storeId and langId unaware method now needs to access to storeId and langId

}

. . .
} // end of class

Любая помощь будет принята с благодарностью.


person GunerE    schedule 31.01.2012    source источник
comment
Прошу прощения за путаницу, но вы не хотите использовать ThreadLocal? Или вы спрашиваете, приемлем ли такой подход?   -  person dbreaux    schedule 01.02.2012
comment
Я понимаю путаницу, просто WebSphere не так хорош в использовании ThreadLocal, учитывая природу объединения потоков. Тем не менее, IBM предлагает WorkArea, но я пытаюсь выяснить, есть ли способ получить доступ к вспомогательному методу Static где-нибудь, чтобы найти мой путь к текущему HTTP-запросу, который прикреплен к текущему обслуживающему потоку веб-контейнера.   -  person GunerE    schedule 01.02.2012
comment
Я заинтригован сейчас. У вас есть ссылка на официальное заявление о ThreadLocal в WebSphere? Не похоже, что один запрос будет прыгать между потоками, не так ли? Мы определенно использовали ThreadLocal в WebSphere.   -  person dbreaux    schedule 02.02.2012
comment
На самом деле заявление не напрямую от IBM, хотя проблемы с нехваткой памяти, связанные с использованием ThreadLocal, кажутся общей проблемой. Я думаю об использовании ThreadLocal, поскольку WorkArea кажется излишним ... Тем не менее, я хотел бы увидеть способ доступа, скажем, к объекту HTTP-запроса с использованием WebContainer. Не могу найти способ сделать это до сих пор. Вот ссылка (не IBM): devwebsphere.com/devwebsphere/2005/ 06/dont_use_thread.html   -  person GunerE    schedule 02.02.2012
comment
Автор этой статьи, Билли Ньюпорт, определенно проницателен и знает, о чем говорит. С другой стороны, эта статья очень старая и даже относится к грядущим изменениям Java, которые уже давно прошли. Его предупреждения верны, но мне кажется, что вы можете безопасно использовать ThreadLocal, если вы не ожидаете, что значения будут там между запросами, и если вы очищаете значения до того, как ваш запрос будет завершен.   -  person dbreaux    schedule 03.02.2012