Денис Смирнов пишет:
> On Wed, Oct 25, 2006 at 02:43:40PM +0400, Eugene Prokopiev wrote:
>
> EP> Первое: пусть польют меня грязью, но я в данном вопросе сторонник
> EP> недистрибутивного подхода, из Сизифа меня интересует только JDK/JRE.
> EP> Обоснование: продукт должен работать не только в ALT, и не только в
> EP> Linux (даже в качестве IDE я использую Eclipse в Linux, но со мной
> EP> работает один человек в Windows и один еще не определился :) ). Более
> EP> того, мне хочется, чтобы он собирался везде, где нет ничего, кроме JDK.
> EP> Поэтому мне пока проще таскать все необходимые библиотеки с собой, они у
> EP> меня лежат прямо в CVS вместе с исходниками. Я задницей чувствую, что
> EP> когда-нибудь это начнет меня напрягать, когда потребуется гарантировать
> EP> одинаковые версии библиотек в разных проектах, и тогда я буду смотреть
> EP> на maven, а пока мне достаточно ant. Грубые аналогии: ant - это make,
> EP> maven - это hasher/spt :)
>
> Гм. У меня ситуация немного другая -- мне достаточно если он будет
> _работать_ где угодно. Увы, скорее всего то что будет распространяться
> будет распространяться в бинарном виде :(
Этого, по-моему, уже достаточно для отказа от apt для всего, кроме
JDK/JRE, чтобы унифицировать подход к разным платформам
> EP> Далее: CGI в виде отдельных процессов на каждый запрос в Java никто в
> EP> здравом уме делать не станет - это слишком дорого. Основа всех
> EP> технологий - это сервлеты, которые выглядят так:
>
> Правильно ли я понимаю что Tomcat это "штука для запуска сервлетов"? И по
> сути это дает возможности идентичные FastCGI?
да
> EP> Принцип ясен?
>
> То есть класс содержит в себе код обработчики запроса? Ага.
>
> EP> Есть надстройки над этим - template engines типа JSP и Velocity, которые
> EP> позволяют писать в стиле PHP, т.е. html + вставки кода. Кстати, Velocity
> EP> как template engine используется в проектах, которые к web никаким боком.
>
> Добровольно мешать код и данные? Нет уж :)
:)
> EP> Есть надстройки над этими надстройками :) Есть другие надстройки над
> EP> сервлетами. Начать читать можно отсюда -
> EP> http://www.techinfo.net.ru/docs/web/javawebdev.html
>
> Прочитал... жуть! Описано только одно средство (XMLC) которое упрощает
> разработку, а не усложняет %-/
:) так видимо считали все, приступая к разработке очередного кошмара, но
уже своего :)
> Откуда такая XML-мания?
просто XML - это общепринятый способ хранить древовидные данные (если
этих данных немного - т.е. для конфигов почти идеал). Конечно, у Lisp и
Erlang свой путь, может более эффективный по затрате ресурсов, но в Java
и не только путь именно такой, и изобретено уже столько инструментов и
технологий поддержки, что отказываться поздно ...
> EP> <display-name>Hello, World Application</display-name>
> EP> <description>
> EP> This is a simple web application with a source code organization
> EP> based on the recommendations of the Application Developer's Guide.
> EP> </description>
>
> Где используется эта информация?
В Tomcat есть интерфейс администрирования web-приложений: установить,
удалить, запустить, остановить - вот там имя и описание и фигурируют
> EP> build.xml (и вызывающий его build.sh) умеет строить из этого дерева
> EP> файлов war-архив. Этот архив можно разными способами продеплоить в
> EP> Tomcat: например, скопировать его в определенный каталог, который он
> EP> мониторит на предмет появления новых приложений. Будет это приложение
> EP> работать и в других контейнерах вроде Jetty и Resin, а также в тяжелых
> EP> серверах приложений вроде JBoss и Geronimo, которые содержат встроенные
> EP> сервлет-контейнеры (коими являются Tomcat и Jetty :) ).
>
> Я правильно понимаю что минимальный сервлет-контейнер должен уметь "всего
> лишь" каким-либо образом обрабатывать клиентские соединения, подгружать
> сервлеты и передавать данные?
да :)
> То есть можно, например, написать простой
> сервлет-контейнер который будет общаться с тем же nginx через FastCGI.
писать свой - это все-таки перебор, посмотри на Jetty или Embeded Tomcat
- с первым я баловался, встраивая его в свое приложение.
FastCGI и сервлеты - это скорее взаимоисключающие вещи. Я бы на твоем
месте проверил, реально ли (и достаточно ли по производительности - так
на всякий случай) на сервлетах построить тот framework, который ты
хочешь (очень интересно, что у тебя получится :) - как сделаешь, делись
:) ). А если нет, то идти к FastCGI - эта технология, как я понимаю,
вообще перпендикулярна любым языкам и платформам. И при любом выборе
посмотреть в сторону какой-либо реализации IoC и AOP - вероятность того,
что они будет полезны, довольно высока.
> EP> Мне больше нравится Jetty, т.к. он легче, меньше, проще, понятнее ...
> EP> Взять маленький Jetty можно тут -
> EP> http://lib.juga.ru/article/articleview/222/1/0?PrintableVersion=enabled
> EP> Т.е. Apache web server здесь отдыхает. Его подставляют как frontend.
> EP> Можно ли задействовать nginx - не в курсе.
>
> Если он фронтенд как http proxy -- однозначно можно.
>
> EP> Если хочется странного (FastCGI), то пишется обычное java-приложение,
> EP> которое обменивается с web-сервером через сокеты.
>
> Ага.
>
> EP> Такое приложение можно писать, забыв о наличии каких-либо frameworks. Но
> EP> если я знаю, что будет много относительно независимых и взамозаменямых
> EP> модулей (и я узнаю о том, какие конфигурации будут нужны, только на
> EP> этапе внедрения), то я задействую Spring.
> EP> Стартовый класс:
> EP> public class Main {
>
> EP> public static void main(String[] args) throws InterruptedException {
>
> Что означает этот exception?
В Java изначально предполагалось, что каждый метод должен знать, какие
исключения внутри могут приключиться (за исключением unchecked
exceptions). Возможно, это был ответ на позицию M$ при разработке Win32
API, когда было заявлено, что это невозможно узнать в принципе.
Со временем unchecked exceptions расплодились и Spring главный, кто эту
идею фактически похоронил - есть и обоснования, но тут я принимать
чью-либо сторону не берусь.
В данном случае InterruptedException возбуждает sleep(), вызывающий
метод должен либо обработать это исключение сам с помощью try/catch,
либо явно передать наверх.
> EP> Кто скажет, что это не изящно, пусть бросит в меня камень :)
>
> XML... Я так понимаю что редактируется это обычно все отнюдь не руками?
Можно руками, если это уже в production - даже раскраска в редакторе
делает конфиги достаточно читабельными. При разработке XML-редактор
Eclipse очень помогает. Еще больше помогает плагин к нему, который
называется Spring IDE
Да, если ты будешь смотреть в строну Eclipse, учти что тебе нужна
поддержка XML (или в WTP - это один большой архив, или из Callisto - там
ты выбираешь нужные тебе компоненты)
> EP> Да, похоже я исполнил мечту г-на dlaygovta@ :)
>
> :)
>
> EP> Денис, если все это тебе еще интересно, то в качестве оплаты лекции
> EP> прошу написанное причесать и куда нибудь на f.i. выложить :)
>
> Еслп под причесать подразумевается только форматирование -- легко и
> непринужденно. Если редактирование -- ой вряд ли я сейчас с этим
> справлюсь...
Смотри сам ... Если в ближайшее время до изучения и редактирования
дойдет - то ок, а если пока нет, то форматируй выкладывай как есть со
ссылками на архивы
>>>Кстати о. Какие наиболее простые средства a-la flex/bison сейчас есть в
>>>Java?
>
> EP> кажется, именно antlr и есть
>
> Ага...
>
>
>>>Меня String убивает именно тем, что код который на perl том же занимает
>>>несколько символов и понятен -- на Java получается простыня кода :)
>
> EP> В Java есть регулярные выражения - не помогут?
>
> В Java вообще все есть :) Дело в синтаксисе.
Ну так все что есть, есть не в Java, а в JVM/JEE :) И теоретических
препятствий к использованию других языков на этой платформе вроде нет -
попробуй, расскажешь :)
--
С уважением, Прокопьев Евгений