Хочу сделать то же, что можно сделать в Struts:
Обрабатываю запрос в сервлете (как обрабатывал бы в action'е), кладу в request атрибуты (данные из базы) и вывожу данные с использованием JSP и JSTL.
В Struts всё понятно, куда что прописывается, чтобы всё заработало.
Но как в Struts устроен изнутри тот момент, в котором подключается JSP, - не понятно.

Хочется обойтись без фреймворка, сделать всё на сервлетах и JSP, но не знаю, как сделать связь между сервлетом и JSP аналогичным образом, как сделано в Struts.
Просто сделать редирект из сервлета на JSP-страницу не покатит - так нельзя передать атрибуты request'а.

Подскажите, кто знает, покакому принципу устроена описанная фича в Struts?

ты прав, надо класть в сессию в этом случае.

альтернативой редиректу служат forwarding и including. в этом случае ты из сервлета "просишь" контейнер запустить другой сервлет или jsp. это происходит полностью на ерверной стороне и клиент об этом никак не узнает.
это делается с помощью объекта RequestDispatcher и в этом слуае вызываемому сервлету передается request и можно в нем передать атрибуты.



это то, что тебе надо? если да, то более подробно про получение диспетчера (есть еще метод getNameDispatcher) и использование (есть forward и include ) можешь спросить здесь же или в API docs.

PS у меня есть курс по struts, может, он тебе поможет, в блоге.


Это сообщение отредактировал(а) ekr - 3.6.2007, 09:41

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



Об этом я думал.
Просто не знаю, действительно ли для web-юзера все эти форварды будут невидимыми, будет ли адрес в строке оставаться прежний, будет ли код HTTP-ответа 200, а не 301, и будут ли сохраняться атрибуты request'а.

Через диспетчер - невидимые. То есть ответ будет 200
Если через response.sendRedirect(), то будет не помню какой точно, но какой-то из 3xx

годится ) 
одно окно - одна сессия (если, конечно, не постараться сделать обратное).
сессионный идентификатор передается или с помощью url-rewriting (как параметр запроса), или в cookie.

посмотри в доках метод response.encodeUrl()



абсолютно верно. 

 То есть написать свой фреймворк.
 Неопонятно зачем  , но если очень хочется, то имеет смысл посидеть пару дней над исходниками struts или sun-овской реализации jsf, понять как это работает. Там есть ответы на все твои вопросы + ответы на вопросы, которые ты еще не задал, но обязательно задаш.

А где в доках можно это прочитать? Хочу развеять большие сомнения.



Дописывать URL - не вариант. Я с поисковиками дружить хочу.



Лень тратить время и изучать новую версию Struts, WebWork или Spring. На фоне того, что мне ещё кое-что из Java-технологий попутно вспоминать приходится после долгого перерыва, - закопаюсь.



В исходниках Struts покопался первым делом.
После этого осталось непонятным, как клиентом будут восприниматься редиректы (какой код ответа). Тут уже подсказали, и я ещё раз проверю.

Kak ustroen frejmwork. Naprimer struts.
1)Mapping.Sostojashij iz binov i actinov
2)ActionServlet. Katorij lovit vse zaposri naprimer s preffiksom *.do.
Tak vot kogda startuet frejmwork sna4ala parsitsja xml. Sodajutsja spiski binov i actionov.Katorie svazani drug stdrugom.
Glavnaja fi4a frejmworka eto kogda ti zapolnil formu nazhal submit i kakimto volshebnim sposobom dannie peretekli v bean.Vopros kak. Navreno daragoj drug ti zamteil 4to vo mogih frejmworkah ispolzuetsja liba: jakarta bean utils. Eto liba evljaetsja obvjortkoj dlja java reflection. Tak vot tam est' krutoj metod: populate (HahMap, Object). Tak vot dannie polu4enie iz requesta mozhno polu4it' :
HahMap map = request.getParameterMap();
BeanUtiuls.populate(map,object_bean).
I etot metod nasitit tvoj bean 4rez setXXX. Vot abtractnij fejmwork. Esli ne ponjatno pishi.

Это сообщение отредактировал(а) Tony - 4.6.2007, 19:12

достаточно просто проверить )


недооцениваешь современные поисковики ) не волнуйся, они нормально разберуться.
к тому же, метод response.encodeUrl() автоматически использеут cookies, если они поддерживаются, и начинает использовать url-rewriting только в обратном случае.

Сейчас проверил и убедился, что и форварды работают без перекидывания юзера по другому URL, и атрибуты request'а сохраняются.