У меня следующий вопрос, как я понимаю сервлет это java приложение запускаемое на сервере
А какие действия он может там выполнять может ли он слушать порты, писать в файл на сервере...
Может есть интересная литература про сервлеты
Здравствуйте, xan, Вы писали:
xan>У меня следующий вопрос, как я понимаю сервлет это java приложение запускаемое на сервере xan>А какие действия он может там выполнять может ли он слушать порты, писать в файл на сервере... xan>Может есть интересная литература про сервлеты
Сервлет выполняется на сервере и ему можно делать все, вообще можно делать Java приложению. Так что на все ваши вопросы ответ — да.
Здравствуйте, den123, Вы писали:D>Здравствуйте, xan, Вы писали:
xan>>У меня следующий вопрос, как я понимаю сервлет это java приложение запускаемое на сервере xan>>А какие действия он может там выполнять может ли он слушать порты, писать в файл на сервере... xan>>Может есть интересная литература про сервлеты
D>Сервлет выполняется на сервере и ему можно делать все, вообще можно делать Java приложению. Так что на все ваши вопросы ответ — да.
А вот у меня сервера нет, а сервлеты, блин, исполняются. Боюсь что если грамотно написать и подписать applet и настроить сеть, то и в applet-е можно будет исполнять сервлеты.
Это я так. Говорить что сервлеты исполняются на сервере это все равно что говорить что люди живут на планете. То есть условие необходимое но не достаточное. Для выполнения сервлетов нужен специальный сервер, т.н. сервлет контейнер. Где он запущен — на сервере, на PDA или еще где — не важно. Важно что он предоставляет среду для выполнения сервлетов, так называемый контекст. Как реализован этот контекст — зависит от контейнера. Так вот через этот контекст и должны происходить все операции взаимодействия с окружающей средой (операции IO, dispatching и т.д.). Все ваимодействия со средой вне контекста не переносимы между контейнерами.
Насчет слушать порты — оно конечно можно, вероятно, но при этом надо учитывать такие аспекты как настройки безопастности, многопоточность, жизненный цикл сервлета и многое другое. ИМХО — сервлет, это не то место, где надо слушать порты. Слава богу в новых спецификациях введены понятия *Listener и иже с ними. Вот там, если что, и можно начать что-то слушать.
Насчет писать в файл на сервере — файл понятие системнозависемое, и может отсутсвовать на некоторых системах вообще. Контекс поддерживает понятие ресурсов (getResource(java.lang.String path) ). Вот его то и надо использовать для взаимодействия с ресурсами (в том числе и, возможно, файлами).
А вообще сервлет предназначен для обслуживания запросов пользователя по определенному протоколу (чаще всего HTTP). Т.е ты как программист создаешь некое web-приложение и в нем пишешь некий сервлет, который например на запрос "привет" отправлят ответ "а не пошел бы ты, Вася Пупкин". Устанавливаешь приложение в сервлет-контейнере (называется деплоймент), при этом не забыв настроить его как описано в документации. Затем запускаешь сервлет-контейнер (если сервлет-контейнер поддерживает "деплоймнт на ходу" — то можешь просто скопировать твое приложение в нужную папку). И вот пользователь вводит в браузере строку "www.superhost/helloServlet&?helloString=привет" а в ответ ему приходит строка "а не пошел бы ты, Вася Пупкин" . А вся замечательность сервлетов в том, что для каждого такого дебильного запроса не нужно занова запустать программу (то есть создавать новый процесс). Он создатся один раз, при запуске сервлет-контейнера и работает пока он сервлет контейнер не остановишь. А каждый запрс выполняется внутри этого процесса, а как — это тема отдельной статьи, коих в Инете пруд-пруди. (Гугл — рулит).
07.09.04 в 18:38 xan в своём письме писал(а):
> У меня следующий вопрос, как я понимаю сервлет это java приложение > запускаемое на сервере > А какие действия он может там выполнять может ли он слушать порты, > писать в файл на сервере... > Может есть интересная литература про сервлеты
Да это всё и даже больше можно делать.(главное чтоб разрешения были).
На вскидку — неплохие примеры всего этого были например в орейлевской
книжке Java Servlet Programmnig (не найдёшь-мыльни >-) )
> Насчет слушать порты — оно конечно можно, вероятно, но при этом надо > учитывать такие аспекты как настройки безопастности, многопоточность, > жизненный цикл сервлета и многое другое. ИМХО — сервлет, это не то > место, где надо слушать порты. Слава богу в новых спецификациях введены > понятия *Listener и иже с ними. Вот там, если что, и можно начать что-то > слушать.
1) @Listener@ — это случайно не те что были и раньше — LifeCycleListeners?
2) Сокеты слушать можно и нужно, если того требует задача.
Рекомендую посмотреть Java Servlet Programming (orelly). Особенно главу 10
@Applet-Servlet Communication@ — когда я только начинал изучать всё это
дело — эта глава прям-таки открыла мне глаза на мир >.
> А вообще сервлет предназначен для обслуживания запросов пользователя по > определенному протоколу (чаще всего HTTP).
Да — по протоколу — но ПО любому, который тебе нужен и который ты сможешь
реализовать.
> Вобщем RTFM.
Ваистину — всем читать API. (там даже иногда интересные вещи пишут)
Здравствуйте, Alex-AKF, Вы писали:
AA>07.09.04 в 18:38 xan в своём письме писал(а):
>> У меня следующий вопрос, как я понимаю сервлет это java приложение >> запускаемое на сервере >> А какие действия он может там выполнять может ли он слушать порты, >> писать в файл на сервере... >> Может есть интересная литература про сервлеты
AA>Да это всё и даже больше можно делать.(главное чтоб разрешения были). AA>На вскидку — неплохие примеры всего этого были например в орейлевской AA>книжке Java Servlet Programmnig (не найдёшь-мыльни >-) )
AA>1) @Listener@ — это случайно не те что были и раньше — LifeCycleListeners?
Сначала было слово. И слово это было 2 байта.
LifeCycleListeners появились в сервлетах только с версии 2.3
Если ты застал 2.2, то может быть вспомнишь про то, что в спецификации был доступен только HttpSessionBindingListener. Остальные прелести стали появляться потом, в том что я называю "новые спецификации".
AA>2) Сокеты слушать можно и нужно, если того требует задача. AA>Рекомендую посмотреть Java Servlet Programming (orelly). Особенно главу 10 AA>@Applet-Servlet Communication@ — когда я только начинал изучать всё это AA>дело — эта глава прям-таки открыла мне глаза на мир >.
Ну так книга то писалась в далеком 1998, а спецификация 2.3 с "LifeCycleListeners" появилась только в 2000.
Тогда действительно небыло "стандартного" способа запустить поток при старте аппликейшена. Поэтому и приходилось писать сервлет, который при инициализации пускает тред и ставить ему load-on-startup в ОЧЕНЬ маленькое значение.
AA>Да — по протоколу — но ПО любому, который тебе нужен и который ты сможешь AA>реализовать.
А я что сказал Тока нужно чтобы и клиент поддерживал этот протокол. Поэтому он и называется "определенный протокол".
1)Про Listenerы я уточнил — вдруг они чего новго уже выпустили.
2)По поводу запуска потока: что в сервлете, что в listener'e — сути не
меняет — всё изоморфно.
3)Про потокол я уточнил потому, что — не надо зацикливаться на HTTP, что
вот — есть реализация HTTP и всё — мол никакие сокеты нам не нужны. Ещё
раз повторю, что если есть !объективная! необходимость при разработке
своего клиент-серверного решения использовать те же сокеты — надо это
делать.
А ещё из той книжки меня в то время поразило "прикручивание" RMI к классу
(кажись)сервлета.
Мдя — книжка была оч хорошая.
Здравствуйте, Alex-AKF, Вы писали:
AA>1)Про Listenerы я уточнил — вдруг они чего новго уже выпустили. AA>2)По поводу запуска потока: что в сервлете, что в listener'e — сути не AA>меняет — всё изоморфно. AA>3)Про потокол я уточнил потому, что — не надо зацикливаться на HTTP, что AA>вот — есть реализация HTTP и всё — мол никакие сокеты нам не нужны. Ещё AA>раз повторю, что если есть !объективная! необходимость при разработке AA>своего клиент-серверного решения использовать те же сокеты — надо это AA>делать.
AA>А ещё из той книжки меня в то время поразило "прикручивание" RMI к классу AA>(кажись)сервлета. AA>Мдя — книжка была оч хорошая.
Keep It Simple.
Do One Thing, and Do It Well.
(с) Justin Gehtland, Bruce A. Tate
AA>3)Про потокол я уточнил потому, что — не надо зацикливаться на HTTP, что AA>вот — есть реализация HTTP и всё — мол никакие сокеты нам не нужны. Ещё AA>раз повторю, что если есть !объективная! необходимость при разработке AA>своего клиент-серверного решения использовать те же сокеты — надо это AA>делать.
Если клиент работает за файерволом, то может оказаться, что соединение по протоколу HTTP — единственный возможный вариант. И в этом случае удобно использовать сервлеты по их прямому назначению. Соединение по HTTP — относительно медленное, но зато работает везде.
Здравствуйте, Alex-AKF, Вы писали:
AA>3)Про потокол я уточнил потому, что — не надо зацикливаться на HTTP, что AA>вот — есть реализация HTTP и всё — мол никакие сокеты нам не нужны. Ещё AA>раз повторю, что если есть !объективная! необходимость при разработке AA>своего клиент-серверного решения использовать те же сокеты — надо это AA>делать.
AA>А ещё из той книжки меня в то время поразило "прикручивание" RMI к классу AA>(кажись)сервлета. AA>Мдя — книжка была оч хорошая.
Я хотел бы уточнить. RMI запросы к сервлету попадали через метод service(ServletRequest, ServletResponse), или в сервлете просто создавался RMI объект?
Если первый вариант, то возникает вопрос, зачем это может понадобиться, поскольку сервлету скорее всего придется делать маршалинг-демаршалинг параметров, а это довольно неудобно; если же второй -- то интересно, какая нужда заставила это делать именно в сервлете (а не каким-нибудь внешним standalone приложением).
> Я хотел бы уточнить. RMI запросы к сервлету попадали через метод > service(ServletRequest, ServletResponse), или в сервлете просто > создавался RMI объект? > > Если первый вариант, то возникает вопрос, зачем это может понадобиться, > поскольку сервлету скорее всего придется делать маршалинг-демаршалинг > параметров, а это довольно неудобно; если же второй -- то интересно, > какая нужда заставила это делать именно в сервлете (а не каким-нибудь > внешним standalone приложением).
Как я помню (лень смотреть):
1)В той книге — чтоб сэкономить место всю т.н. "бизнесс логику" делали
прямо в сервлете (а может во времена автора это было модно...).
2)Клсасс не толко наследвался от хттпсервлет но и реализовывал какой-то из
RMi интерфейсов
3)В сервлете добавляли реализацию метода (то же что-то такое стандартное,
по работе с registry в RMI).
4)Ну и далее по сценарию — заглушки, то, сё.....
В итоге — одни и те же методы использовлаись и в сервлете и как RMI —
очень интересное решение. (А если "бизнесслогику" вынести в JB и
"скрестить" их с RMI — получиться что-то вроде dummy-EJB своими руками на
веб-контейнере)
Зачем? Ну во первых — это книга и глава про взаимодействие с сервлетом. Во
вторых — решение (с некоторыми доработками) мне кажется оч даже
интересным: когда есть только веб-контейнер,а нужно ещё и реализовать
толстые клиенты — то решение в плане "написание" представляется очень даже
"дешовым". (Хтя сейчас конечно смысл оно свой и теряет — широкое
распространение SOAP и пр xml-based rpc + скоро апачгруп грозились дать
миру полноценный полностью бесплатный сервер приложений)
Почему не @standalone@ -понятия не имею. Могу лишь предположить —
deployment
Здравствуйте, xan, Вы писали:
xan>У меня следующий вопрос, как я понимаю сервлет это java приложение запускаемое на сервере xan>А какие действия он может там выполнять может ли он слушать порты, писать в файл на сервере... xan>Может есть интересная литература про сервлеты
Да, естественно, он (сервлет) может читать/писать файлы на сервере, в выделенном под домен месте, запускать скрипты на сервере. Вот про прослушивание портов не уверен... сдается мне, что не может=) а вот насчет литературы про сервлеты — на www.java.sun.com, в разделе J2EE.
.
