Денис Смирнов пишет: > 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 :) И теоретических препятствий к использованию других языков на этой платформе вроде нет - попробуй, расскажешь :) -- С уважением, Прокопьев Евгений _______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/smoke-room
