Apache Cocoon 2.0

Cocoon 2 development has reached "beta quality"

То, что на /cocoon стали отдавать инфу о втором, еще не говорит о релизе.

2Havoc: А это устаревшая страничка :) В разделе "новости" (http://xml.apache.org/news.html):

Cocoon 2.0 released

The Apache Cocoon team is proud to announce the release of Cocoon 2.0. The distribution is available from the download pages.

В разделе "дистрибутивы" (http://xml.apache.org/cocoon/dist/) можно брать и скачивать.

Ты его пробовал?
Я пока на 1.8 сижу.

Ага - поставил на Tomcat 4, только вот сравнить мне к сожалению не с чем - последний раз юзал Cocoon 1.3 (в основном имею дело с JSP и сервлетами). Но первое впечаьление вполне приятное - всевозможные PDF, SVG et cetera на лету генерятся довольно шустро... В общем с удовольствием в нем поковыряюсь, хотя по работе и не требуется.

А как нонеча там с русскими буковками?
Года полтора не смотрел :)

Интересно, ИМНО для чего люди его используют. Под какие задачи.

Подо что его используют это понятно - есть много способов, как снять шкуру
с убитой кошки. xml/xslt - один из них. Меня другое волнует - доколе это безобразие
будет творится с апачем? Я имею в виду впихивание в этот бедный бинарник любой мелочи,
которая отлично может быть реализована самостоятельно, без опоры на какой-то
один загнивающий и вместе с тем перегруженный фичами вебсервер. Ну почему нужно
делать одну большую дурно пахнущую солянку? Где unix way с его маленькими прогами,
исполняющими одну функцию и кооперирующими между собой? Скажем, есть stunnel. Зачем
спаривать apache и ssl по типу два-в-одном? Есть fcgi. Опять непонятно, для чего
спаривать apache с конкретно perl или php... Бинарник расбухает; из-за одной фичи, нужной
для одного виртуального хоста необходимо держать эти огромные процессы для
99% простых http-запросов или плодить эти апачи с разными конфигурациями.
Ненавижу этот сборный коктейль.

> А как нонеча там с русскими буковками?

При указании правильной кодировки (например <?xml version="1.0" encoding="KOI8-R"?>) русские буквы с ходу кое-где появились (например в SVG), но не везде - надо подробнее разбираться. Изначально проблема с русскими буквами была в даже не в самом Cocoon, а в Servlet API и его реализациях. Только в Servlet API 2.3 (которую поддерживают последние Tomcat и Resin) появилась наконец возможность устанавливать кодировку не только для responce, но и для request, а вообще про все это есть хорошая статья Сергея Астахова "Русские буквы и не только" (http://www.javable.com/docs/jav_cyrlet/).

2Korwin:

> Интересно, ИМНО для чего люди его используют. Под какие задачи.

Например, есть на сервере какой-то текстовый контент, имеющий некотурую логическую структуру и стуктура эта выражена через XML-разметку (контент может быть как статическим, так и динамически добываемым например из SQL-сервера). Сервер может раздавать этот контент клиентам разных типов, используя разные стили для преобразования XML в разный HTML для разных браузеров, WAP WML, SVG, PDF и так далее - во то, что клиент в состоянии обработать.

2anonymous (*) (2001-12-01 05:10:22.0):

Наверное не в курсе - Apache Cocoon не является модулем HTTP-сервера Apache, а является набором сервлетов и билиотек, который можно использовать на любом сервере, поддерживающем сервлеты. У Apache Software Foundation много хороших разработок помимо HTTP-сервера. И кстати, если говорить о модулях (за который видимо был принят Cocoon), то многие из них можно не компилировать статически вместе с "разбухающим бинарником", а устанавливать динамически. Или не устанавливать - кому что больше нравится :)

>многие из них можно не компилировать статически вместе с "разбухающим бинарником",
Нет, это проблему не решает абсолютно. Тормозит он с динамикой еще больше,
памяти отжирает в любом случае.

>Я имею в виду впихивание в этот бедный бинарник любой мелочи

Каким хреном это связано с коконом?

> Я имею в виду впихивание в этот бедный бинарник любой мелочи

Apache Cocoon - сервлет. В бинарнике апача он не живет и вобще на апач особо не завязан.

> Скажем, есть stunnel. Зачем спаривать apache и ssl по типу два-в-одном?

Ради эффективности.

> Опять непонятно, для чего спаривать apache с конкретно perl или php...

Ради эффективности

> Бинарник расбухает; огромные процессы для 99% простых http-запросов

Заведи себе thttpd и горяй через него всю статику, а через apache - динамику. Плодить апачей вещь не очень разумная.

Cocoon 2 лично я испробовал при создании сайта под мобильные девайсы.

Можно конечно код самому ручками написать, а можно подойти более профессионально - используя XML\XSLT. Разные Applciation Servers типа JRun, WebSphere, iPlanet имеют кое-какую поддержку этой фичи, но уж очень они толстые и дорогие. Нам же удалось сделать решение на комбинации уже готового и бесплатного Кокуна и своих маленьких доработок: в результате сайт способен генерить контент (из XML) и имиджи (из SVG) из единых сорцов под 5 различных типов мобильных девайсов, начиная от мобильных телефонов, до PDA, причем с поддержкой русского, английского и японского.

Только, скажу я вам, капризная эта штука - пререлиз Кокун. Шаг влево, шаг вправо с изменениями конфигов, и он сваливается в непонятные ошибки. Чичас скачаю релиз, буду щупать.

Если у кого-то есть вопросы - пишите alex@intadev.com.

2alex@intadev.com URL не кинешь посмотреть? А возможно исползовать этот поект, но без Java. Все сейчас написано на Perl и C?

кокун вообще-то чисто Java-приложение - набор сервлетов. если вам известно что-то аналогичное на Perl/C, то назовите. Только Java как то привлекательнее - уж очень платформенно независимая - хощь на WIN, хошь на Unix, хощь на Linux. И втыкается в связку с IIS, Apache, Tomcat на любой платформе и не жужжит. Правда ресурсов жрет немеряно.

посмотреть мона на w3.inadev.com , если сервер не перезагружают - это девелоперская машина.

Одно плохо, для запуска под юнихами ему фреймбуфер нужен, если SVG гонять.

а чем это мне грозит?

> кокун вообще-то чисто Java-приложение - набор сервлетов. если вам
> известно что-то аналогичное на Perl/C, то назовите. Только Java как то
> привлекательнее - уж очень платформенно независимая - хощь на WIN,
> хошь на Unix, хощь на Linux. И втыкается в связку с IIS, Apache,
> Tomcat на любой платформе и не жужжит. Правда ресурсов жрет немеряно.
Ну так и Perl и C платформенно независимые если писать с учетом пиреносимости, а не выпендриваться. А то что Java полностью платформенно независимая - сказки. Если какой нибудь серьезный проект, но надо под каждую платформу переделывать малехо.

К тому же боевые сервера каждый день не меняют платформу и тут переносимость несколько боком может вылезти.

Под переносимостью я имел в виду - что разработку я могу вести на виндах под виндовым томкатом, выкладывать на линукс под линуксовый томкат, а деплоить на iPlanet, работающий на сане под солярисом - и везде все будет одинаково - и менять даже запятые не придется (ну это я приврал конечно..))). Но удобно же? вон мелкософт по тому же пути лезет со своим .NET.

Перл уж слишком монстрообразен, чтобы грузить его всякий раз при обработке - он же интерпретатор, значит при выполнении он всегда на один шаг позади от Java.

А Си - говорят от компилятора зависит, поди там разберись в чем разница компилятора под линухом и под саном.

Ну как пример еще - скажем нужно серверный скрипт на Си написать. Ваш первый вопрос, под какую платформу? А второй - под какой сервер? Ведь ISAPI и NSAPI имеют разные интерфейсы. Выходит вам под два разных сервера придется писать два разных кода. Вы написали программу, к вам приходит покупатель вы свою программу ему нахваливаете, а потом выясняется, что у него оказывается не IIS, а Netscape Web Server. Упс, сколько вам времени придется перелопачивать ваш код? Как вы будете поддерживать две версии?

А так имеем сервлет на Java. Покупатель приходит и спрашивает, а на виндах работать будет? Будет, отвечаем мы. А на виндах под IIS будет? Будет, отвечаем мы. На на Apache в спарке с JRun на Солярисе будет? Будет, отвечаем мы. А на iPlanet под AIX будет? Будет, отвечаем мы.

Клиент в обмороке, мы - при бабках.

2 anonymous:
> а чем это мне грозит?

В принципе ничем, кроме съедания лишних ресурсов.
Иксы на сервере как-то некошерно :)

2 Korwin:
>А то что Java полностью платформенно независимая - сказки. Если
>какой нибудь серьезный проект, но надо под каждую платформу
>переделывать малехо.

Это смотря какой проект. Сервлеты и EJB нафиг переделывать не нужно.
Разве что у EJB возможно потребуется добавить xml файлик в архив, специфичный для некоторого EJB контейнера. Код не меняется и даже не перекомпилируется.

>К тому же боевые сервера каждый день не меняют платформу и тут
>переносимость несколько боком может вылезти.

Сервера то не меняют, но в данном случае разработчики могут работать под чем им удобно, а не только под той же платформой, что и сервер.

Ну если писать на C под CGI интерфейс, то тут все путем :-)
К тому же если использовать стандартные библиотеки и те которые нормально переносятся, то проблем нет. Конечно CGI интерфейс медленнее API конкретного сервера, но унивесален. :-)

С остальным согласен. Но я где-то читал, что для обработки каждого сервлета Java загружает каждый раз копию Java Virtual Machine, т.е. разницы с подгрузкой интерпретатора Perl никакой :-( Это так?

А про интерпретатор Perl - есть mod_cgi, fast_perl модули и прочее. К тому же есть компилятор перловский (правда работает скорее как враппер :-((

интересно, каким раком иксы связаны с фреймбуфером? если кокону нужен fb, то причём здесь X?

2Korwin:

> ...Но я где-то читал, что для обработки каждого сервлета Java загружает каждый раз копию Java Virtual Machine, т.е. разницы с подгрузкой интерпретатора Perl никакой :-( Это так?

Это не так. Сервлет один раз загружается в память и используется для обработки всех запросов к серверу, при этом его код в процессе обработки запросов еще и оптимизируется. В отличие от классического CGI, где на каждый запрос к серверу запускается отдельный процесс, что естественно требует времени и ресурсов сервера. Поэтому классическое CGI-приложение, даже написанное на C, существенно менее эффективно, чем сервлет. Кроме того, классический CGI усложняет жизнь разработчику, если при обработке параллельных запросов требуются синронизация, обмен данными между запросами, поддержка HTTP-сессий... Современные фирменные API (ISAPI от Microsoft, NSAPI от Netscape и т. д.) частично решают эти проблемы, но до открытого кроссплатформенного стандарта Servlet API им (ИМХО :) далеко. А если рассматривать ситуацию более комплексно, то сервлеты (и тесно связанные с ними JSP) без проблем интегрируются в сложные программные комплексы. построенные с применением различных тезнологий, основанных на платформе J2EE, поэтому при построении корпоративных систем уровня предприятия классический CGI уже давно уступил место современным технологиям.

2thread. В таком случае это действительно интересно. Не подкините названия книг (желательно русскоговорящих :-) про сервлеты или URL для более подробного изучения. А то я работал только с апплетами и был не очень доволен Java в таком контексте.

Заранее спасибо.

2Korwin: Из русскоговорящих мне понравилось описание книги

М. Холл, Сервлеты и JavaServer Pages, 2001 (http://www.javable.com/docs/books/piterpress/servlets_jsp/)

Саму книгу, к сожалению, не читал.

Есть перевод (судя по качеству компьютерный :) учебника по сервлетам http://java.mchook.net/tutorial/servlet/

Много полезных ресурсов и ссылок на http://www.javable.com/docs/, а "домашняя страничка" технологии - http://java.sun.com/products/servlet/

Марти Холл рулит. Его книжку нужно купить обязательно (перевода нету к сожалению). Ну или почитать ее фрагменты на его сайте

http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/

там и про сервлеты и про сервер-страницы. Где то в рунете я даже нашел перевод на русский, но закладку не сделал, о чем жалею. Там также немножко про custom tags. Custom Tags так меня вообще очаровали.

В приницпе мне переключиться с ASP на JSP было просто. Моя машинка для работы с этой бедой: win2k Prof, Eng, 215Mb RAM - тянет вполне нормально.