Денис Смирнов пишет: > On Thu, Oct 26, 2006 at 11:47:12AM +0400, Eugene Prokopiev wrote: > > Извиняюсь за поздний ответ, письма на эту тему после прочитывания > откладывал на обдумывание... да слишком на долго отложил. > > >>>Гм. У меня ситуация немного другая -- мне достаточно если он будет >>>_работать_ где угодно. Увы, скорее всего то что будет распространяться >>>будет распространяться в бинарном виде :( > > EP> Этого, по-моему, уже достаточно для отказа от apt для всего, кроме > EP> JDK/JRE, чтобы унифицировать подход к разным платформам > > Я с этим не соглашусь. Пусть у меня будет одна нормальная платформа где > будет удобно работать. А для остальных, так и быть, можно раздавать кашу в > виде пачки jar'ов в одном tgz с боооольшим README на тему "а как с этим > кошмаром взлететь". > > Пользователи же нормальных дистрибутивов смогут использовать пакетный > менеджер. > > >>>То есть класс содержит в себе код обработчики запроса? Ага. >> >>EP>> Есть надстройки над этим - template engines типа JSP и Velocity, которые >>EP>> позволяют писать в стиле PHP, т.е. html + вставки кода. Кстати, Velocity >>EP>> как template engine используется в проектах, которые к web никаким боком. >> >>>Добровольно мешать код и данные? Нет уж :) > > EP> :) > > :) > > >>EP>> Есть надстройки над этими надстройками :) Есть другие надстройки над >>EP>> сервлетами. Начать читать можно отсюда - >>EP>> http://www.techinfo.net.ru/docs/web/javawebdev.html >> >>>Прочитал... жуть! Описано только одно средство (XMLC) которое упрощает >>>разработку, а не усложняет %-/ > > EP> :) так видимо считали все, приступая к разработке очередного кошмара, но > EP> уже своего :) > > Видимо да. Но логика своего кошмара хотя бы самому себе кажется разумной. > А логика чужого кошмара приводит к кошмарам по ночам :) > > >>>Откуда такая XML-мания? > > EP> просто XML - это общепринятый способ хранить древовидные данные (если > EP> этих данных немного - т.е. для конфигов почти идеал). Конечно, у Lisp и > EP> Erlang свой путь, может более эффективный по затрате ресурсов, но в Java > EP> и не только путь именно такой, и изобретено уже столько инструментов и > EP> технологий поддержки, что отказываться поздно ... > > :( > > Люблю конфиги на тикле писать :) > > >> 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> >> >>>Где используется эта информация? > > EP> В Tomcat есть интерфейс администрирования web-приложений: установить, > EP> удалить, запустить, остановить - вот там имя и описание и фигурируют > > Ага, понял. > > >> EP>> build.xml (и вызывающий его build.sh) умеет строить из этого дерева >> EP>> файлов war-архив. Этот архив можно разными способами продеплоить в >> EP>> Tomcat: например, скопировать его в определенный каталог, который он >> EP>> мониторит на предмет появления новых приложений. Будет это приложение >> EP>> работать и в других контейнерах вроде Jetty и Resin, а также в тяжелых >> EP>> серверах приложений вроде JBoss и Geronimo, которые содержат встроенные >> EP>> сервлет-контейнеры (коими являются Tomcat и Jetty :) ). >> >>>Я правильно понимаю что минимальный сервлет-контейнер должен уметь "всего >>>лишь" каким-либо образом обрабатывать клиентские соединения, подгружать >>>сервлеты и передавать данные? > > EP> да :) > > А монстры чем отличаются от этого минимума? Администрирование, возможно > какой-то механизм кэширования, что еще?
О каких монстрах речь? JBoss и Geronimo? Ну тут в двух словах никак. Кратко: это реализация всех стандартов JEE - JMS (асинхронные сообщения - аналог e-mail, но с отказоустойчивостью, транзакциями и т.д.), EJB (RPC, ORM, ...), распределенные транзакции, security, кластеризация ... Собственно Web тут очень небольшая часть. Кстати, я их не использую, мне в качестве контейнера достаточно Spring, куда я при необходимости могу втащить реализацию какой-либо JEE-технологии, вроде JMS (например, ActiveMQ - часть Geronimo, но поддерживает конфигурирование средствами Spring и JBoss). >>>То есть можно, например, написать простой >>>сервлет-контейнер который будет общаться с тем же nginx через FastCGI. > > EP> писать свой - это все-таки перебор, посмотри на Jetty или Embeded Tomcat > EP> - с первым я баловался, встраивая его в свое приложение. > EP> FastCGI и сервлеты - это скорее взаимоисключающие вещи. Я бы на твоем > EP> месте проверил, реально ли (и достаточно ли по производительности - так > EP> на всякий случай) на сервлетах построить тот framework, который ты > EP> хочешь (очень интересно, что у тебя получится :) - как сделаешь, делись > EP> :) ). А если нет, то идти к FastCGI - эта технология, как я понимаю, > EP> вообще перпендикулярна любым языкам и платформам. И при любом выборе > EP> посмотреть в сторону какой-либо реализации IoC и AOP - вероятность того, > EP> что они будет полезны, довольно высока. > > что такое IoC и AOP? IoC мы кратко рассмотрели в примере использования Spring, можно еще здесь почитать - http://www.rsdn.ru/article/java/spring.xml AOP - грубо говоря, препроцессор для выполнения неких действий перед вызовом метода и после него (возможно с модификацией входных и выходных параметров), не ставя в известность об этом факте сам метод. Полезно для разделения основной логики и дополнительной (авторизация, управление транзакциями и т.д.) > Путь с интегрирование Jetty мне нравится. Хотя, с > учетом того что я _знаю_ что у меня будет frontend, собственно код сервера > достаточно простой получается. Самое-самое-самое сложное в этом коде это > разбор запросов :) ну и замечательно, пока этим и стоит ограничиться, даже сервлеты тебе фактически не нужны, а нужны только твои собственные реализации интерфейса Handler >> EP>> public static void main(String[] args) throws >> InterruptedException { >> >>>Что означает этот exception? > > EP> В Java изначально предполагалось, что каждый метод должен знать, какие > EP> исключения внутри могут приключиться (за исключением unchecked > EP> exceptions). Возможно, это был ответ на позицию M$ при разработке Win32 > EP> API, когда было заявлено, что это невозможно узнать в принципе. > > EP> Со временем unchecked exceptions расплодились и Spring главный, кто эту > EP> идею фактически похоронил - есть и обоснования, но тут я принимать > EP> чью-либо сторону не берусь. > > Гм. > > >>>В Java вообще все есть :) Дело в синтаксисе. > > EP> Ну так все что есть, есть не в Java, а в JVM/JEE :) И теоретических > EP> препятствий к использованию других языков на этой платформе вроде нет - > EP> попробуй, расскажешь :) > > Медитирую над синтаксисом того, чего хочу. В общем-то я понял что хочу -- > некий недоlisp. Буду думать. > > Кстати о, куда копать на предмет того как в Java принято писать простые > клиент-серверные приложения? Даже и не знаю ... Может отсюда http://java.sun.com/docs/books/tutorial/networking/index.html Книжка Брюса Эккеля Thinking in Java неплоха, ее электронный перевод отвратителен, а бумажный нормальный Но это слишком низкий уровень, сокеты, потоки и все такое ... Наверное, лучше начать с примеров, идущих с Jetty и с кода самого Jetty. Кстати, у тебя и клиент-сервера как такового не получается, всеми сетевыми делами и даже потоками будет заниматься Jetty, тебе лишь остается правильно структурировать свой внутренний код. > Первое где я могу с ней реально поиграться на > практике, это в том интерфейсике к asterisk managment interface, который > мне все равно скоро писать придется. > > И как _правильно_ запускать Java-сервер через инитскрипты? Я использую http://jakarta.apache.org/commons/daemon/, его же использует Tomcat -- С уважением, Прокопьев Евгений _______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/smoke-room
