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> да :) А монстры чем отличаются от этого минимума? Администрирование, возможно какой-то механизм кэширования, что еще? >> То есть можно, например, написать простой >> сервлет-контейнер который будет общаться с тем же nginx через FastCGI. EP> писать свой - это все-таки перебор, посмотри на Jetty или Embeded Tomcat EP> - с первым я баловался, встраивая его в свое приложение. EP> FastCGI и сервлеты - это скорее взаимоисключающие вещи. Я бы на твоем EP> месте проверил, реально ли (и достаточно ли по производительности - так EP> на всякий случай) на сервлетах построить тот framework, который ты EP> хочешь (очень интересно, что у тебя получится :) - как сделаешь, делись EP> :) ). А если нет, то идти к FastCGI - эта технология, как я понимаю, EP> вообще перпендикулярна любым языкам и платформам. И при любом выборе EP> посмотреть в сторону какой-либо реализации IoC и AOP - вероятность того, EP> что они будет полезны, довольно высока. что такое IoC и AOP? Путь с интегрирование Jetty мне нравится. Хотя, с учетом того что я _знаю_ что у меня будет frontend, собственно код сервера достаточно простой получается. Самое-самое-самое сложное в этом коде это разбор запросов :) > 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 принято писать простые клиент-серверные приложения? Первое где я могу с ней реально поиграться на практике, это в том интерфейсике к asterisk managment interface, который мне все равно скоро писать придется. И как _правильно_ запускать Java-сервер через инитскрипты? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- Может все-таки /etc/menu-methods/{icewm,fvwm2} поправить, чем пересобирать весь GNOME и KDE ? -- zerg in #1772 _______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/smoke-room
