[room] Лекция по Java

Пн Фев 26 01:01:53 MSK 2007

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