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

[Eugene Prokopiev <prokopiev@stc.donpac.ru>]

Денис Смирнов пишет:
> 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

-- 
С уважением, Прокопьев Евгений