From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 26 Feb 2007 01:01:53 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: =?koi8-r?B?y9XM2NTV0s7ZyiDPxtTP0MnL?= Message-ID: <20070225220153.GB10614@mw.local.seiros.ru> References: <20061023082401.GC28347@localhost.localdomain> <20061023181954.GK28465@osdn.org.ua> <20061024015521.GE22262@localhost.localdomain> <453DD5D3.2090904@stc.donpac.ru> <20061024155705.GA3318@localhost.localdomain> <453EFD70.40708@stc.donpac.ru> <20061025083002.GA32347@localhost.localdomain> <453F3FDC.4030304@stc.donpac.ru> <20061025181043.GA1430@localhost.localdomain> <45406800.8000809@stc.donpac.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45406800.8000809@stc.donpac.ru> Subject: Re: [room] =?koi8-r?b?7MXLw8nRINDPIEphdmE=?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?y9XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2007 22:01:54 -0000 Archived-At: List-Archive: 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>> Hello, World Application > EP>> > EP>> This is a simple web application with a source code organization > EP>> based on the recommendations of the Application Developer's Guide. > EP>> >> Где используется эта информация? 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