Здравствуй, Shale!

Чем никак не является Shale, так это красиво упакованным, хорошо документированным, всесторонне протестированным продуктом с автоматическим инсталлятором и изысканным управляющим интерфейсом. Теперь узнайте о том, чем же он является, – Брэтт МакЛафлин раскрывает заслуженную мощь этого наследника фреймворка Struts.

Часть 1. Shale – это не Struts

Среди всех Web-фреймворков, появившихся за последние пять лет, Jakarta Struts является одним из самых популярных, поэтому появление его отпрыска является примечательным событием. Хотя Shale пока еще не самый популярный фреймворк (или даже не самый известный), его родословная впечатляет. Еще больше впечатляет тот факт, что Shale не просто значительное обновление либо новая версия Struts, а полная переработка основных принципов Struts, объединенная с новейшими представлениями о Web-разработке.

Как вы узнаете в этой серии из пяти статей, отход Shale от Struts – это палка о двух концах. С одной стороны, Shale является чрезвычайно хорошо продуманным наследником Struts. Создатели Shale учли как слабые, так и сильные стороны фреймворка Struts и создали фреймворк следующего поколения, стоящий своего предшественника. С другой стороны, как вы вскоре увидите, Shale (с его новым подходом к разработке) полностью отличается от Struts!

Вместо того чтобы стать еще одной новой версией Struts, Shale довольно значительно выходит за пределы Struts. Он заключает в себе и построен на основе последних самых значительных разработок в Web-программировании на Java, включая JSP Standard Tag Library (JSTL) и JavaServer Faces (JSF). Shale полностью заслуживает рассмотрения отдельно от Struts, и в этой серии статей я отдам этой фреймворку должное. Я начну с обзора отличий Shale от Struts и расскажу об установке Shale и тестировании вашей установки. Я сделаю некоторые выводы относительно того, как втянуться в проектирование при помощи Shale (которая является фреймворком с открытыми исходными кодами), а также дам практические рекомендации для этого. Цель этой серии – показать вам, как установить, собрать и использовать Shale (изредка я буду ссылаться на ее предшественника – фреймворк Struts).

Вы должны просмотреть на Web-сайте Shale (см. раздел "Ресурсы") короткое, но полное описание происхождения названия Shale. В двух словах, в основе названия Shale (сланец, пласт) лежит идея, что фреймворки Web-разработки лучше всего работают как слабосвязанные "слои" функциональности. Каждый слой, в основном, не зависит от остальных и имеет очень узкую специализацию. Аналогию этих слоев вы обнаружите в геологии: например, береговые линии сформированы, в основном, из пластов (shale). Так и был назван новый фреймворк!

Оценка Shale

Любой новый фреймворк Web-разработки, который пытается протиснуться в такую довольно плотно занятую (в настоящее время) нишу, подвергается довольно серьезной критике. Хорошей новостью является то, что Shale выдерживает такую критику. Плохой новостью может быть то, что поскольку Shale является полной переработкой Struts, вам придется переделывать, повторно тестировать и переписывать весь ваш Struts-код.

Отсюда следует логичный вопрос: зачем переходить на Shale? Чтобы дать ответ, я сначала объясню, что делает Shale замечательным фреймворком, а затем рассмотрю две основные причины, почему она не была выпущена как следующая основная версия фреймворка Struts. Это даст вам лучшее представление о том, что вы на самом деле получаете от Shale, и поможет определиться, стоит ли переходить на этот фреймворк следующего поколения.

Наследие Struts

Shale интенсивно используется исходный код Struts. Утверждается, что фреймворк Struts является "родителем" Shale, и если вы собираетесь уверовать в Shale, вам сперва придется поверить в ценности Struts. Первое и самое главное: огромное значение Struts состоит в том, что он является одним из первых настоящих фреймворков для Web-разработки. Web-сайт Struts и Shale сообщает, что первый код был внесен в CVS-репозиторий Struts в июне 2000, а Struts 1.0 был выпущен в конце 2001. В то время, когда многие разработчики ломали головы (и руки) над тем, как работать с JavaServer Pages (JSP) и развивающейся спецификацией сервлетов, Struts предложил Model 2, легкий в использовании подход к созданию основанных на сервлетах и JSP-страницах Web-приложений. Другими словами, Struts дал Web-разработчикам возможность разрабатывать надежные Web-приложения без необходимости быть экспертом в протоколировании, распределенных вычислениях, JDBC, сервлетах, JSP-страницах, JNDI, RMI и целой куче других API и акронимов.

Следующей ценностью Struts является его сохраняющаяся мощь: почти шесть лет после написания тех первых строк кода Struts остается одним из самых популярных фреймворков для Web-разработки. О ней все еще говорят, все еще пишут и используют так же часто, как любого из ее молодых конкурентов, и даже более часто, чем большинство из них. Причины популярности Struts состоят в том, что этот фреймворк полнофункционален, хорошо документирован, прекрасно поддерживается и прост в использовании, разработке и администрировании. Тысячи разработчиков отвечают на вопросы в списках рассылки Struts, а десятки тысяч работают в Struts и сообщают о проблемах, что способствует, таким образом, их быстрому исправлению.

Наконец, Struts развивается. В то время как многие фреймворки остановились в развитии после быстрого старта (это истинно как для коммерческих продуктов, так и для продуктов с открытым кодом), Struts постоянно предлагал новые функциональные возможности. После загрузки Struts вы получаете устойчивую систему проверки корректности как часть основного дистрибутива, легкую интеграцию с JavaServer Faces, большую библиотеку тегов и развивающуюся архитектуру Model 2, которая привносит последние идеи в области распределенных n-уровневых приложений. Кроме того (просто если вам интересно), Struts поддерживает новые парадигмы в программировании, например, IoC (Inversion of Control – инверсия управления). Struts естественно интегрируется с WebWork и фреймворком Spring, обеспечивающими более легкий способ освоения новых подходов к Web-разработке.

В двух словах, вам будет тяжело найти что-либо, чего вы не сможете сделать или для чего не сможете найти поддержку в Struts. Тогда возникает следующий очевидный вопрос: зачем надо было начинать разработку Shale? В голову приходят две основные причины: одна состоит в малоизвестной правде о новых версиях программного обеспечения, а другая – в хорошо известной слабости основы Struts. Давайте рассмотрим обе причины.

Обзор, пересмотр, доработка, версия

Чтобы понять, почему Shale не просто новая версия Struts, вы должны сначала понять одну или несколько вещей о новых версиях программного обеспечения. Большинство пользователей ищут новую версию программы ради нового набора функциональных возможностей. Чем дальше новая версия отстоит от последней версии, тем больше новых функций ожидают пользователи. То есть, программное обеспечение, переместившееся от версии 2.1 к 2.2, должно иметь некоторые новые функциональные возможности, но программное обеспечение, сменившее номер версии с 2.2 на 3.0, должно иметь много новых функциональных возможностей. Вот почему новые версии и редакции таких больших продуктов, как Microsoft Word, или таких операционных систем, как Windows и Mac OS X, находятся под столь пристальным наблюдением – в каждой новой версии пользователи ожидают увидеть растущий набор функциональных возможностей.

Уделяя столько внимания функциональным возможностям, большинство пользователей не понимает, что наибольшую ценность для них реально составляет обратная совместимость. Хотя каждый хочет иметь новую крутую функцию в Excel, лучшую интеграцию с iTunes в Panther, или лучшую поддержку XUL в Gnome, но все заорали бы благим матом, если бы их существующие программы и файлы неожиданно стали неработоспособны в более новых версиях. В этом случае новые функциональные возможности не стоили бы и ломаного гроша.

Это же справедливо и для Struts. По большей части каждая новая версия Struts добавляет новые функциональные возможности, одновременно сохраняя обратную совместимость с предыдущими версиями. Кроме того, имеется требование поддержки старых версий Java-платформы и спецификации Servlet, поскольку ранние инсталляции работают на данных платформах. Оба этих требования (обратная совместимость и поддержка старых версий Java API) были бы серьезным ограничением для Shale. В частности, JSF API становится центральной технологией в развивающемся Web, по крайней мере, на платформе Java. Struts поддерживает JSF, в то время как Shale полностью зависит от нее – что абсолютно невозможно для Struts, учитывая необходимость обратной совместимости.

Наконец, запуск нового проекта (Shale) одновременно с продолжением работы над существующим (Struts) имеет определенные преимущества. Если бы Struts просто обновился до версии 2.0 (или 3.0, или 4.0) и реализовал функциональность Shale, не обращая внимания на обратную совместимость, миграция на новую версию стала бы большой головной болью для многих пользователей, а некоторые вообще перестали бы использовать Struts. Даже при продолжении поддержки старой версии кода, было бы очень затруднительно убедить разработчиков потратить время на исправление ошибок и добавление хотя бы минимальных функциональных возможностей в "устаревшей" версии программного обеспечения.

По всем этим причинам имеет смысл сделать Shale совершенно новым проектом, построенным на новом исходном коде.

Ориентированная на службы архитектура Shale

Последняя причина того, что Shale не является просто новой версией Struts, не имеет ничего общего с логистикой: она имеет отношение к способности фреймворка использовать новые подходы к Web-разработке. Shale отличается от Struts по многим существенным параметрам, но особо выделяются два из них:

Последствия зависимости Shale от JSF значительны и (как ни странно), главным образом, позитивны. Я рассмотрю некоторые из них в следующих статьях данной серии. На втором из этих двух различий стоит остановиться немного подробнее перед тем, как двинуться дальше.

Если вы много работали со Struts, то понимаете, что это, по существу, большой процессор запросов, позволяющий вам получать запросы и давать указания фреймворку, как обрабатывать каждый запрос. Вы можете указать, какое действие выполнить, какую модель использовать, что показать пользователю, какие правила проверки корректности применить, какие формы отобразить… Struts является полностью настраиваемым. Однако в основе всего этого лежит процессор запросов, который выполняет каждый запрос. Этот процессор является самой важной (и самой сложной) частью Struts, поскольку он должен либо выполнить сам, либо делегировать кому-то практически каждый этап обработки запроса. В коде Struts нет практически ничего не соприкасающегося с процессором запросов.

В результате Struts трудно изменить каким-либо фундаментальным способом. Если вы захотите кардинально изменить способ обработки запросов или порядок этапов их обработки, то столкнетесь с приводящей в уныние задачей: нужно будет существенно переписать исходный код Struts. Изменение поведения процессора запросов в небольшой степени возможно, но, по большей части, это закрытая система. Это одна из ключевых проблем (если, по крайней мере, вам нужна эта степень гибкости в Web-среде), которую пытается решить Shale.

В Shale нет центрального компонента, аналогичного процессору запросов Struts, Shale – это просто большой набор служб. Вы можете комбинировать эти службы почти любым способом – каждая служба слабо связана с остальными. Используя четко определенный набор интерфейсов (которые иногда являются интерфейсными Java-классами, а иногда просто соглашениями между компонентами), легко переконфигурировать поведение Shale. Это делает фреймворк расширяемым, гибким и даже сообразительным. Вы можете легко его изменять, практически без каких-либо усилий расширять и быстро адаптировать под новые приемы программирования. Подобное слабое связывание компонентов или служб часто называется ориентированной на службы архитектурой (service-oriented architecture), или SOA. Конечно, это во многом модное словечко, но это же не вина Shale!

Установка Shale

Вы можете понять отличие Shale от Struts логически и концептуально, но реально почувствовать разницу между этими двумя замечательными фреймворками можно, только поработав с ними. Как это ни утомительно, но работа с любым Web-фреймворком начинается с его загрузки и установки. Хорошей новостью является то, что из этого процесса можно почерпнуть много полезного. Проекты и продукты, являющиеся тяжелыми в установке и настройке, часто таковы и в конфигурировании, развертывании и (хуже всего) в поддержке и работе с ними. Хотя процесс установки редко имеет определяющее значение для оценки фреймворка, он, несомненно, должен быть частью этой оценки. В данном разделе вы научитесь вручную устанавливать Shale, почувствуете ухабы и точно определите, что вам нужно на вашей системе для запуска Shale.

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

Предварительные требования

Список предварительных условий и требований для Shale довольно обширен. Как и в случае с большинством проектов, имеющих отношение к Apache и Jakarta, установка Shale зависит от нескольких других проектов Jakarta. Вот полный список того, что потребуется для запуска Shale:

Apache Ant используется только для сборки Shale, но вы все равно захотите иметь (и, возможно, уже имеете) на вашей системе версию Ant, если собираетесь разрабатывать Java-программы. Если вы хотите отслеживать ошибки в Shale, вам понадобится FindBugs 0.8.5 или выше и JUnit 3.8.1 или выше. Поскольку я в первой части рассматриваю только установку и использование Shale, вам не нужно пока беспокоиться о FindBugs или JUnit, если, конечно, вы не захотите добавить эти проекты в комплект заранее.

Дополнительные компоненты и их зависимости

Как и в случае Struts, существует несколько дополнительных (add-ons) компонентов (часто называемых в мире Shale необязательными Shale-компонентами), которые имеют свои собственные зависимости:

Если этот список кажется несколько длинным и пугающим, ничего не поделаешь! Shale использует множество низкоуровневых библиотек, вспомогательных классов, служебных компонентов и классов из других проектов. Если бы нужно было отдельно загружать каждый компонент, настраивать Shale на работу с каждым из них, и собирать их все в нечто, готовое для развертывания, то только самые преданные разработчики посмотрели бы на Shale второй раз. Кроме того, поскольку Shale все еще довольно молод, процесс получения этих зависимостей и их настройки пока немного непроработан; однако, он вполне выполним и не требует столь серьезных дополнительных усилий, как вы бы могли подумать.

Добро пожаловать на передний край!

Если вы никогда раньше не работали с проектом, распространяемым с открытыми исходными кодами, либо если вы работали со стабильными и зрелыми версиями таких проектов, загрузка ежесуточных сборок (builds) может вас немного нервировать. Хотя в них нет ничего радиоактивного или существенно опасного, они определенно немного более изменчивы, чем стабильные версии, доступные для большинства более зрелых технологий и проектов.

Учтите, что большинство ежесуточных сборок автоматизированы; в определенное время суток эти сборки создаются из текущего дерева исходных кодов проекта. Даже если какой-либо разработчик исправляет серьезную ошибку в коде, процесс ежесуточной сборки все равно успешно создает новый снимок кода и делает его доступным для скачивания из любой точки земного шара. Это означает, что сегодняшняя сборка может работать замечательно, а одна из последующих – намертво зависать. Поэтому будьте осторожны и терпеливы. Если что-то не работает в имеющейся у вас сборке, очень возможно, что это будет исправлено в завтрашней. Это передний край разработки, поэтому наличие ухабов на дороге является естественным.

Во-первых, выполняя Web-разработку какого-либо вида (при помощи любого фреймворка), вы должны уже иметь некоторые из этих зависимостей. То есть, этот список намного более покладистый, чем кажется на первый взгляд. Например, любой Web-разработчик уже должен иметь JRE и JDK, так же как и движок сервлетов, например, Jakarta Tomcat. Если у вас есть движок сервлетов, то вы должны иметь и Servlet API, а так же JSP-процессор. Добавьте сюда и тот факт, что большинство движков сервлетов (по крайней мере, их самые свежие версии) содержат копию JSTL, а многие поставляются в настоящее время и с JSF. И, наконец, большинство разработчиков, вероятно, уже имеют Ant на своих машинах. Поэтому список быстро сокращается до следующего:

Учитывая, что Tapestry, на самом деле, делает доступным все свои зависимости в виде отдельной загрузки, проблема "слишком много зависимостей" быстро перестает быть проблемой.

Теперь, когда вы более ясно представляете происходящее, давайте выполним действия по загрузке, установке и настройке Shale и ее зависимостей.

1. Загрузка Shale

Для загрузки Shale зайдите на домашнюю страницу проекта Shale. Вы обнаружите раздел "Shale Download" со ссылкой на ежесуточные сборки Shale. Эта ссылка приведет вас на сайт, выглядящий примерно так, как изображено на рисунке 1.

Для запуска Shale нужно загрузить два файла – "framework" и "dependencies". Например, для написания данной статьи я загрузил следующие два файла:

Если вы предпочитаете загружать версию .tar.gz, выберите ее вместо версии .zip. Поскольку работа над Shale продолжается, и пока еще нет готовой версии, лучше попробовать загрузить самую свежую ежесуточную сборку (с самой новой датой).

После загрузки распакуйте оба архива. Для самого фреймворка будет создана папка с названием, аналогичным shale-framework-20060204/, а для архива зависимостей – папка lib/. Переместите папку shale-framework-20060204/ туда, где вы храните свои Java-проекты. Я, например, переместил shale-framework-20060204/ в каталог /usr/local/java. Затем перейдите в подкаталог lib/ каталога Shale, то есть, в каталог с названием, аналогичным shale-framework-20060204/lib/.

2. Добавление Shale-библиотек в Web-приложение

Следующим шагом является добавление всех JAR-файлов и библиотек Shale в место, где ваше Web-приложение может найти и использовать их. Вы должны выполнить следующие действия:

С этого момента все начинает немного усложняться (да, все это копирование было легкой частью). Возможно, вместо того, чтобы делать все самым сложным способом, я должен, по крайней мере, попытаться показать вам вариант легкого пути. Действительно, есть легкий путь настроить и запустить Shale на вашей системе; теперь, когда вы имеете представление о сложности ручной настройки Shale, стоит взглянуть на этот "сокращенный" подход.

Легкий путь

Снова зайдите на сайт Shale и загрузите приложение "starter", называющееся как-то вроде shale-starter-20060204.zip. Распакуйте этот архив, и у вас будет создан каталог shale-starter/. Это практически настроенное Shale Web-приложение, предназначенное для того, чтобы помочь вам обойти все эти копирования и настройки, подробно описанные в предыдущем разделе. Прежде всего, вы должны переименовать каталог shale-starter/, дав ему название, которое вы собираетесь использовать для вашего приложения; например, вы могли бы использовать название first-shale/. Перейдите в каталог first-shale/, и вы увидите несколько файлов и подкаталогов.

В каталоге first-shale/ создайте новый файл build.properties. Этот файл позволит настроить способ сборки Shale-приложения и гарантировать соответствие вашей среде. В листинге 1 приведено содержимое базового файла build.properties, который вы можете легко настроить под ваше окружение.

Листинг 1. Пример build.properties для начального Shale-приложения

# Основная информация о проекте
project.copyright=My project, Copyright © 2006
project.name=My First Shale Application
project.vendor=IBM DeveloperWorks
project.vendor.id=com.ibm.dw

# Java-пакет и путь к контексту для движка сервлетов
project.package=com.ibm.dw.firstShale
project.path=first-shale

# Каталог для дистрибутива Shale - измените для вашей системы
shale.dir=/usr/local/java/shale-framework-20060204

# Каталог для всех ваших библиотек - измените для вашей системы
lib.dir=/usr/local/java/shale-framework-20060204/lib

После настройки этих свойств вы можете просто запустить ant. Начинается сборка Shale-приложения и (если вы правильно настроили ваши пути) создается приложение. Если возникают проблемы, сценарий компиляции отобразит сообщения об ошибках; они очень подробны, поэтому у вас не должно быть каких-либо сложностей с исправлением каких-либо ошибок.

В конце процесса сборки будет создан новый каталог target/. Перейдите в этот каталог, и вы увидите подкаталог с названием first-app (либо с другим названием, которое вы указали в build.properties в качестве имени вашего проекта). Большинство движков сервлетов позволяет копировать всю эту структуру каталогов в свой каталог webapps/. Например, используя Tomcat, я скопировал весь каталог first-shale, созданный сценарием сборки, в /usr/local/java/tomcat/webapps.

Сборка WAR-файла

Если вы используете движок сервлетов, требующий от вас предоставления WAR-файлов, то можете использовать тот же самый Ant-файл сборки с небольшим изменением. Поскольку вы пока не написали какие-либо Java-файлы для Shale-приложения, сценарий сборки выдаст ошибки при запросе WAR-файла (JavaScript-команда в build.xml ищет файлы, но не находит их). Чтобы решить эту проблему, откройте build.xml и найдите строку, начинающуюся с "javadoc" и выглядящую примерно так:

<!-- ===================== Generate Documentation ======================== -->


  <target         name="javadocs" depends="compile"
           description="Create JavaDocs">

    <mkdir         dir="${build.docs.dir}"/>

    <javadoc
            sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${project.copyright}">
      <classpath refid="compile.classpath"/>
    </javadoc>

    <copy        todir="${build.docs.dir}">
      <fileset     dir="${src.java.dir}"
              includes="**/*.gif"/>
    </copy>

  </target>

Теперь просто закомментируйте задание javadoc:

  <!-- ===================== Generate Documentation ======================== -->


  <target         name="javadocs" depends="compile"
           description="Create JavaDocs">

    <mkdir         dir="${build.docs.dir}"/>
<!--
    <javadoc
            sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${project.copyright}">
      <classpath refid="compile.classpath"/>
    </javadoc>
-->
    <copy        todir="${build.docs.dir}">
      <fileset     dir="${src.java.dir}"
              includes="**/*.gif"/>
    </copy>

  </target>

Это отчасти хак, и он не понадобится, когда вы начнете разрабатывать Java-код Shale-приложения. Но пока он делает свое дело. Сохраните измененный build.xml и выполните команду ant dist. Ant cкомпилирует и соберет ваше начальное приложение, и создает новый WAR-файл в каталоге dist/. Например, я запустил ant dist и получил dist/first-shale-0.1.war. Теперь вы можете скопировать этот WAR-файл в каталог webapps/ вашего движка сервлетов.

Тестирование вашей установки

Если вы забрались так далеко (независимо от того, какой способ установки вы избрали), то должны быть способны запустить движок сервлетов и обратиться к вашему Shale-приложению по адресу http://your.host.name/first-shale. Например, выполняя на локальной машине Tomcat, вы обращаетесь по адресу http://localhost:8080/first-shale. Если все работает нормально, вы должны увидеть простую страницу, аналогичную изображенной на рисунке 2.

Сейчас все это может показаться стрельбой из пушки по воробьям, но учтите, что, открывая и изменяя простой файл build.properties, вы смогли избежать большой и утомительной работы по копированию и настройке. Вы обнаружите, что начинать с пустого начального Shale-приложения – это почти всегда самый легкий способ начать работать над Shale-приложением. Когда вы начнете разрабатывать Shale-приложения, то будете использовать пустое начальное приложение.

Варианты использования Shale

Это почти все о загрузке и установке, но потратьте немного времени на загрузку WAR-приложения с вариантами использования Shale, доступного с главного Web-сайта загрузки Shale. Найдите файл с названием, аналогичным shale-usecases-20060204.war. Загрузите этот WAR-файл и поместите его в каталог webapps/ вашего движка сервлетов, а затем перейдите к WAR. В моей системе я перешел в http://localhost:8080/shale-usecases-20060204/, и мой экран выглядел так, как показано на рисунке 3.

Потратьте некоторое время на исследование этих вариантов использования; это приложение содержит хорошие примеры таких возможностей Shale, как Validator и Remoting, а также простое Ajax-приложение. Вы можете получить представление о том, что способно делать даже самое простое Shale-приложение, просматривая эти варианты использования.

При этом будьте внимательны: некоторые из вариантов использования все еще находятся в процессе разработки, и в зависимости от того, когда вы загрузили вашу сборку, может оказаться, что некоторые варианты не совсем рабочие. Вы можете загрузить это приложение позднее и увидеть, было ли что-нибудь исправлено. Даже с этими небольшими проблемами приложение с вариантами использования является отличным способом получить представление о Shale.

Примите участие в проекте Shale!

Большинство Web-разработчиков никогда не идут дальше использования в разработке своих Web-приложений существующего фреймворка (например, Shale, Struts или Spring). В этом подходе определенно нет ничего плохого, но если вы хотите разобраться во фреймворке и используемых в нем технологиях, то нет альтернативы самостоятельному погружению в сам фреймворк.

В случае с Shale (как и со Struts), исследуя внутренности фреймворка, вы узнаете больше о сервлетах и Web-разработке, чем когда-либо могли себе представить. Это также крайне полезно, если вы надумаете использовать в проектах какие-либо из Shale-зависимостей. Если вы интересуетесь ведением логов из вашего Java-приложения, работа с Shale познакомит вас с проектом Apache Logging намного более эффективно, чем любая статья. То же самое можно сказать о работе с проектами Jakarta Commons BeanUtils, Chain или Digester. Это отличные инструменты, полезные для любого Web-разработчика, поэтому, потратив несколько недель или месяцев на Shale, вы приобретете отличный опыт работы в этих областях.

Поскольку данная статья является первой в серии по углубленному изучению Shale, было бы неправильно, если бы я не обсудил точки входа (и некоторые препятствия) для участия в проекте Shale.

Дополнительные зависимости

Я уже упоминал, что если вы хотите работать с Shale самостоятельно на уровне кода, то должны иметь копию Ant, а также проект FindBugs и интегрированный фреймворк тестирования JUnit. Несмотря на ошибочное представление о неорганизованности и непрофессионализме проектов с открытыми исходными кодами, вы обнаружите, что каждая ошибка, проблема и функциональная возможность, связанная с Shale-разработкой, регистрируется в базе данных FindBugs, и каждый фрагмент кода, регистрируемый в репозитории Subversion, должен быть протестирован.

Переход к исходным текстам (где исходники?)

К сожалению, процессы разработки Shale не слишком хорошо документированы. Поэтому вам придется проявить немного изобретательности, если вы хотите работать с исходным кодом Shale напрямую. По большей части приведенных здесь инструкций по загрузке Shale достаточно и для загрузки исходных кодов Shale. Ежесуточные сборки содержат весь исходный код Shale, и каждый каталог с кодом содержит файл build.xml.

Вы должны скопировать файл build.properties.sample в корневой каталог Shale, в файл с названием build.properties (удалите ".sample" в конце оригинального имени файла), и отредактировать этот файл под вашу систему. В листинге 2 показано, как выглядит пример этого файла (многие комментарии удалены для краткости):

Листинг 2. Пример build-файла Shale

# Этот файл содержит примерные настройки свойств 
# для конфигурирования вашей среды для сборки Struts Shale Library из 
# исходного кода. Для использования этого файла скопируйте его в 
# "build.properties" и 
# измените необходимые значения.

# Корневой каталог, в который вы распаковали версию Shale Frameworke.
root.dir=${basedir}

# Полный путь к каталогу, в котором у вас размещается 
# распакованный двоичный дистрибутив JavaServer Faces Reference Implementation
jsfri.dir=/usr/local/jsf-1_1_01

findbugs.outputFile=${root.dir}/find-bugs.html
lib.dir=${root.dir}/lib
jsf.home = ${lib.dir}/myfaces
jsf-api.jar = ${jsf.home}/myfaces-api.jar
jsf-impl.jar = ${jsf.home}/myfaces-impl.jar

# Абсолютный или относительный путь к дистрибутиву Apache Struts  
struts.home = /usr/local/jakarta-struts

spring.home=${lib.dir}/springframework
findbugs.home = /usr/local/findbugs-0.8.6

MyFaces или JavaServer Faces?

MyFaces – это Apache-проект с открытым исходным кодом. Это реализация JSF API фирмы Sun, но она обладает всей открытостью и преимуществами, присущими другим Java-проектам Apache Foundation. Вы можете использовать MyFaces как замену рекомендованной реализации Sun JSF. MyFaces является предпочтительной реализацией JSF для использования с Shale.

Вы должны изменить большинство из путей, указанных в этом build-файле для соответствия вашей системе. ${basedir} по умолчанию указывает на каталог, из которого вы запускаете Ant, поэтому, если вы запускаете Ant из корневого каталога Shale, у вас тут все в порядке. Но другие пути придется заменить значениями, соответствующие вашей системе. Например, если рекомендованная реализация JSF у вас размещена в каталоге c:/java/jsf-1_1_02, используйте это значение для каталога jsfri.dir. Большая часть путей по умолчанию рассчитана на использование MyFaces (см. "MyFaces или JavaServer Faces"), но, естественно, вы можете использовать реализацию Sun JSF, изменив эти пути соответствующим образом. Вы также должны задать пути к Struts, Spring (что необязательно и не требуется для ядра Shale) и к проекту FindBugs.

Ant в действии

После корректной настройки этого файла вы можете запустить Ant из корневого каталога Shale. Однако сначала вы должны выполнить команду ant download-dependencies. Как вы, конечно, знаете, Shale имеет много зависимостей, и использование Ant для автоматизации загрузки этих зависимостей сбережет много времени и избавит вас от разочарований. Сценарий для Ant также управляет настройкой путей, связывающих Shale с этими зависимостями. Вы должны также запустить ant copy-jsf-ri для обработки некоторых специфичных для JSF заданий (подробности на самом деле не существенны, и Ant позаботится об этом за вас).

Перед сборкой главной версии Shale вы должны выполнить команду ant clean для удаления старых выходных файлов. Хотя это означает, что общее время сборки будет больше, но в то же время это гарантирует, что весь ваш код будет собран должным образом. Наконец, выполните команду ant release, которая выполняет сборку Shale с нуля. После завершения Ant-сценария (это занимает некоторое время) вы будете иметь полный дистрибутив Shale, собранный из исходных кодов.

Несколько слов о рассылках

Проекты с открытыми исходными кодами практически полностью поддерживаются по электронной почте (плюс поддержка в системе отслеживания ошибок Apache, ссылку на которую вы найдете в разделе "Ресурсы"). В этом отношении Shale не отличается от них, хотя она все еще использует списки рассылки Struts. Вопросы по использованию Shale вы должны посылать по электронной почте на user@struts.apache.org. Но если вы начинаете реально изменять код Shale, то должны посылать письма по адресу dev@struts.apache.org. В обоих случаях предваряйте строки вашей темы словом "[shale]", чтобы было понятно, что вы задаете вопросы, относящиеся к Shale, а не к Struts. Shale должна обзавестись собственными списками рассылки через несколько месяцев, поскольку она становится независимым проектом.

На очереди несколько пожеланий, в частности при отправке письма в список рассылки для разработчиков: не спешите. Беспокойные, неясные или показывающие отсутствие мысли письма часто воспринимаются не очень хорошо. Вы также наверняка получите грубый ответ, если пошлете куда-нибудь письмо со строками "Я хочу изучить Shale, вышлите мне, пожалуйста, несколько примеров приложений". Хотя это, может быть, и глупое предостережение, но оно обосновано; списки рассылки для разработчиков всегда заполнены спамом и подобного рода запросами, и они не воспринимаются. В общем, потратьте время на тщательную формулировку вашего вопроса, указывайте, какую платформу и какие версии программного обеспечения вы используете, и отразите, что вы попытались сделать очевидные шаги. Ваш запрос будет встречен с уважением и пониманием, а ответы на запрос покажут это. Не нужно бояться списка рассылки для разработчиков, но нужно проявлять уважение.

В заключение

Если эта часть статьи что-то и показала, то лишь то, что Shale предназначен не для всех. Shale определенно не является красиво упакованным, хорошо документированным и протестированным продуктом с автоматической программой установки и приятным интерфейсом управления, чего, возможно, ожидают многие Web-разработчики в век Tapestry. Хотя все это (за исключением красиво упакованной коробки) может появиться в следующей версии фреймворка, сегодняшняя Shale (на начало 2006) находится в процессе разработки, а сайт Shale говорит о ней в основном как о проекте в "альфа"-стадии. Многие используемые в ней компоненты являются стабильными и зрелыми, но сама Shale пока еще очень молодая разработка. Если вы чувствуете себя не очень комфортно, работая с небольшой головной болью и с некоторым замешательством, то, возможно, захотите подождать еще год или около того, прежде чем перейти на этот фреймворк.

С другой стороны, если вы – Java-разработчик, стремящийся оставаться на переднем крае Web-разработки, то вы действительно должны исследовать проект Shale. Он немного не отточен и определенно потребует некоторых дополнительных усилий для корректной настройки и работы, но зато обладает всеми задатками исключительно популярного Web-фреймворка. Shale на самом деле основывается на традициях Struts, предлагая при этом нечто совершенно новое, и уже только из-за этого его стоит изучить. Shale также заслуживает участия большего числа опытных или активных разработчиков, заинтересованных в том, чтобы стать участниками проекта с открытым исходным кодом.

Если вы уже готовы сделать решительный шаг, в этой серии есть намного больше информации, чем рассмотренные здесь установка и базовая настройка! Дальше я объясню принципы, стоящие за Shale, и как их применить для написания Shale-приложений. Вы также совершите экскурсию по минимальному Shale-приложению и узнаете, как использовать его в качестве стартовой площадки для ваших собственных приложений.

Часть 2. Структура каталогов Shale изнутри

В первой части этой серии я представил Shale и объяснил, чем она отличается от своего предшественника Struts. Я рассмотрел концептуальную основу Shale и показал вам, как установить и настроить ее в вашей среде разработки. Также я рассмотрел некоторые из возможных недостатков Shale (а именно то, что она находится на стадии разработки), но сделал вывод, что для пытливых разработчиков, обучающихся по ходу работы, Shale является чрезвычайно многообещающим новым фреймворком.

Теперь я начну использовать этот принцип (обучения по ходу) на практике и подробно рассмотрю анатомию Shale-приложения. Я начну с разбора так называемого начального Shale-приложения (которое, как вы быстро поймете, является чем-то большим, нежели шаблон), чтобы вы четко видели, что именно эта технология дает разработчику Web-приложений. Вы будете использовать начальное приложение для создания своего собственного примера приложения, которое затем будете использовать для исследования многочисленных файлов и каталогов, из которых состоит даже самое элементарное Shale-приложение. Попутно я покажу вам, куда помещаются JSP-страницы и Java-классы, а также объясню, как Shale упрощает процесс создания полнофункциональных и специализированных Web-приложений.

Начало работы с Shale

Как вы уже узнали, самым простым способом начать создавать Shale-приложение является использование начального Shale-приложения в качестве шаблона и последующее его изменение. Поскольку данная статья сильно привязана к практике, первое, что вы должны сделать, – запустить начальное приложение прямо сейчас. Изучение различных компонентов начального приложения (через структуру каталогов приложения) и способов их совместного функционирования поможет в создании вашего собственного Shale-приложения.

Фактически всегда неплохой идеей является начинать проект разработки Shale-приложений с начального приложения. Я рассмотрел в пошаговом режиме процесс настройки начального Shale-приложения в моей последней статье, поэтому предполагаю, что вы уже сделали эту подготовительную работу. Вы должны скопировать начальное Shale-приложение в каталог вашей среды разработки под названием "first-shale". Код в каталоге first-shale является вашим личным начальным приложением, которое вы будете использовать для изучения структуры Shale-приложения.

Структура основного каталога

Предположив, что у вас есть собственное приложение (first-shale), скопированное с начального Shale-приложения. Рассмотрим структуру его каталогов. Вы обнаружите массу файлов. Если вы не знаете точно, что делает каждый компонент, файл и каталог, приложение может выглядеть устрашающим – по крайней мере, на первый взгляд. На рисунке 4 показана структура каталогов; как видите, в начальном приложении есть много всего.

Итак, начнем изучение структуры каталогов начального Shale-приложения.

Файлы, связанные с компоновкой

Первыми двумя файлами в корневом каталоге начального приложения являются build.xml и default.properties. Если вы когда-либо использовали среду компоновки Ant, то эти файлы вам знакомы. По существу, build.xml указывает Ant, что делать. В случае начального Shale-приложения он дает Ant знать, какие файлы компилировать, и как создать WAR-дистрибутив, а также файлы, используемые вашим контейнером сервлетов (который я подробнее рассмотрю чуть позже).

Файл default.properties является шаблоном для указания месторасположения нескольких Shale-зависимостей. Да, это означает, что вы, по существу, имеете файл шаблона (default.properties) внутри приложения-шаблона (начальное Shale-приложение). Я не буду углубляться в детали default.properties, потому что рассматривал его в первой статье данной серии (см. раздел "Ресурсы"). Короче говоря, вы копируете этот файл в новый файл build.properties, настраиваете его под вашу среду и затем используете Ant для компоновки проекта. Во время работы Ant использует указанные вами в build.properties месторасположения для создания Shale-дистрибутива.

Каталоги зависимостей

Далее вы видите два пустых каталога: ext/ и lib/. Они пусты преднамеренно, поэтому не думайте, что вам чего-то не хватает. При компоновке Shale-приложения и настройке файла build.properties вы должны указать, где среда Shale и ваш контейнер сервлетов должны искать зависимости. Фактически, вы можете указать два типа зависимостей:

Файл build.properties предоставляет путь для указания зависимостей среды исполнения (используя свойство lib.dir) и зависимости среды компиляции, которые не нужны в WAR-конфигурации развертывания для среды исполнения (используя свойство ext.dir). Если хотите, можете просто разместить ваши зависимости в соответствующих каталогах:

Эти два каталога служат исключительно для этих целей.

Документация

LICENSE.TXT, NOTICE.txt и README.txt – это файлы документации. Они подробно описывают условия, при которых вы можете использовать Shale, и разрешенные модификации фреймворка. Они также предоставляют простые инструкции по настройке и компоновке Shale-приложения. Эти файлы стоит прочитать один раз, но, сделав это, вы сможете пользоваться их указаниями в дальнейшем.

Исходный код

Назначение последнего каталога, src/, должно быть довольно очевидно: он содержит исходный код начального Shale-приложения. В нем немного файлов, но он содержит массу подкаталогов. В результате его структура выглядит сложнее, чем она есть на самом деле. На рисунке 5 показана полная, развернутая структура каталога с исходными кодами.

Понятно, что самые интересные компонентов начального Shale-приложения расположены в каталоге src/. По мере разработки все более сложных Shale-приложений ваши каталоги src/ будут все больше заполняться вашими собственными Java-классами и JSP-страницами. Поэтому освойте работу в структуре src/ начального Shale-приложения – вам это поможет во время разработки собственных приложений.

Создание приложения

Теперь, после знакомства со структурой каталогов начального приложения, вы готовы подробно узнать о том, как выглядят Shale-приложения после компоновки. В предыдущем разделе вы увидели, где размещается исходный код Shale-приложения. В данном разделе вы узнаете, как этот исходный код компонуется в Web-приложение, и где размещаются все скомпилированные Java-файлы, JSP-страницы и соответствующие зависимости.

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

Компоновка начального приложения

Из предыдущей статьи вы должны помнить, как компонуется начальное приложение, но я, все же, приведу краткий обзор:

Добавление к дереву исходных файлов

Ранее я упоминал, что вы легко можете добавить ваши собственные JSP-страницы в каталог src/web/ начального Shale-приложения. Затем все JSP-страницы из этого каталоге автоматически добавятся в процесс компоновки. Это же относится и к исходным Java-файлам. В каталоге src/ есть подкаталог java/. Просто поместите ваши исходные Java-файлы в этот каталог, и они будут скомпилированы.

Если вы еще не вполне уверены в достоинствах использования начального Shale-приложения, процесс компоновки должен доказать вам, насколько это полезно. Редактируя единственный файл build.properties, вы можете скомпоновать ваше собственное приложение практически без усилий. Даже при работе с Ant (система компоновки, используемая для начального Shale-приложения) вы должны настраивать все каталоги, зависимости и правила, вовлеченные в компоновку Web-приложения. Но при использовании начального Shale-приложения вы можете потратить ваше время на написание JSP-страниц и Java-классов, поместить эти файлы в нужное место, выполнить команду ant – и все.

Когда дело доходит до размещения файлов Java-классов, общим правилом является использование структуры каталогов, соответствующей структуре пакетов Java-классов. Например, если ваш класс называется Song, и он находится в пакете com.nathanson.music, вы должны поместить файл Song.java в структуру каталога src/java/com/nathanson/music. Это не меняет способ компиляции файла системой Java (javac просто просматривает директиву package в начале файла Song.java), но это позволяет хорошо организовать код.

Сравнение исходного кода и двоичного кода

Помните о том, что исходные файлы (или исходный код) – это ваши .java-файлы, а не .class-файлы. В общем случае .java-файлы называются исходным кодом, а компилированные .class-файлы называются двоичным кодом. Каталог src/ Shale предназначен для размещения исходного кода. Каталог target/ (о котором я вскоре расскажу) предназначен для двоичного кода.

Каталог target/

После выполнения команды ant и компоновки вашего приложения вы должны увидеть новый каталог target/. Этот каталог содержит все файлы, скомпонованные из исходного кода, находящегося в каталоге src/. Фактически, каталог target/ содержит "разбитый на части WAR". WAR-файлы представляют собой просто JAR-файлы с небольшой дополнительной конфигурационной информацией, скомпонованные таким образом, чтобы все контейнеры сервлетов могли развернуть в себе приложение. Если вы возьмете WAR-файл и развернете (то есть разархивируете) его, то получите структуру каталогов каталога target/ (скоро я объясню, как на самом деле создать WAR).

Лучший способ узнать, куда помещаются исходные файлы Shale-приложения, – посмотреть в каталог src/ начального приложения. Аналогично, лучший способ понять, как выглядит развернутое Shale-приложение, – проверить каталог target/. Сначала я рассмотрю, куда Shale помещает различные файлы во время процесса компоновки, а затем покажу вам, как они настраиваются для развертывания приложения.

Внутри каталога target/

Сразу после завершения работы программы Ant откройте созданный каталог target/. Содержимое этого каталога должно выглядеть аналогично изображенному на рисунке 6.

Это похоже на структуру каталога src/, показанную на рисунке 5. Как и в каталоге src/, здесь хранится стандартная структура Web-приложения, включающая Java-классы и JSP-страницы. Хотя вы можете заметить несколько добавлений и то, что файлы немного перемешаны.

Главный каталог приложения

Почти все в каталоге target/ расположено в подкаталоге first-shale/. Название этого каталога может быть другим на вашей системе, если вы указали другой путь к проекту в файле build.properties. Как бы он ни назывался, в листинге 3 приведено содержимое файла, используемого для компоновки приложения:

Листинг 3. Пример файла build.properties

# Основная информация о проекте
project.copyright=My project, Copyright © 2006
project.name=My First Shale Application
project.vendor=IBM DeveloperWorks
project.vendor.id=com.ibm.dw

# Java-пакет и путь к контексту для контейнера сервлетов
project.package=com.ibm.dw.firstShale
project.path=first-shale

# Каталог для Shale-дистрибутива - измените его для вашей системы
shale.dir=/usr/local/java/shale-framework-20060204

# Каталог для всех ваших библиотек - измените его для вашей системы
lib.dir=/usr/local/java/shale-framework-20060204/lib

Вы можете использовать любое имя в качестве пути к вашему проекту. Сценарии компоновки в Shale (которые используют Ant) просто используют имя, указанное вами для каталога, создаваемого в target/.

Файл манифеста

Оставшаяся часть статьи в основном рассказывает на содержимом каталога target/, но перед дальнейшим его исследованием вы должны знать о содержимом каталога, созданного непосредственно в target/. Каталог META-INF/ содержит единственный файл MANIFEST.MF, содержимое которого приведено в листинге 4:

Листинг 4. Файл MANIFEST.MF

Extension-Name: com.ibm.dw.firstShale
Specification-Vendor: The Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor-Id: com.ibm.dw
Implementation-Vendor: IBM DeveloperWorks
Implementation-Version: 0.1

Сравните содержимое этого файла с листингом 3 и информацией, введенной в файл build.properties, и вы сразу заметите некоторые связи. MANIFEST.MF берет название пакета, название фирмы-разработчика и ее ID из build.properties.

При сборке WAR-файла для развертывания в контейнере сервлетов этот манифест включается в WAR, идентифицируя его содержимое. Ели вы используете для работы с контейнером сервлетов какие-либо GUI-средства, они могут прочитать файл MANIFEST.MF и позволить вам (или другим администраторам) узнать, что находится в WAR.

В общем случае, вы никогда не должны вручную изменять MANIFEST.MF; вместо этого, если вам необходимо изменить его значения, обновите build.properties и просто повторно скомпонуйте приложение. Если бы вы изменили MANIFEST.MF самостоятельно (без изменения build.properties) и впоследствии повторно скомпоновали проект, все ваши изменения были бы утеряны. Управляя всем содержимым target/ при помощи build.properties и каталога src/, вы можете гарантировать, что развертываемое вами приложение всегда согласовано с разработанным вами кодом и авторской информацией об этом коде, указанной в build.properties.

Два каталога META-INF

На самом деле в target/ существует два разных подкаталога META-INF/. Это target/META-INF/, который содержит файл манифеста, использующийся для создания WAR-файла для всего Web-приложения, и target/first-shale/META-INF/, который содержит файлы с лицензией и примечаниями, предоставляющими некоторую общую информацию о Shale-приложении. Будьте внимательны и не путайте эти два каталога. Кроме имени у них нет ничего общего.

Типичное Web-приложение

Если вы уже писали какие-либо Web-приложения (используя интегрированные среды, например Struts, или кодируя JSP-страницы и сервлеты самостоятельно), то уже знакомы с основной структурой Web-приложения. Аналогичную структуру можно найти в каталоге target/first-shale/, где для вас не должно быть сюрпризом наличие каталогов META-INF/ и WEB-INF/.

Все JSP-файлы, размещенные в каталоге src/web/, теперь размещаются в корневом каталоге Web-приложения. Файлы index.jsp, welcome.jsp и messages.jspf (три JSP и относящиеся к JSP файлы, находившиеся в каталоге src/web/) вы найдете непосредственно в target/first-shale/.

Корневой каталог (first-shale/) – это каталог, в котором должны размещаться все JSP-файлы; однако, если нужно добавить в приложение JSP-страницы, не помещайте их просто в этот каталог. Вместо этого поместите дополнительные JSP-страницы в каталог src/web/ и перекомпилируйте приложение. Я говорил это раньше и скажу еще раз: одно из самых важных правил при программировании в Shale (как и при любом Web-программмировании) – сохранять синхронизацию дерева исходных файлов и дерева развертывания. Если все изменения производятся в структуре каталога src/, никаких проблем не будет.

Расположение Java-классов

Ваши Java-классы лежат в каталоге target/first-shale/WEB-INF/classes/. Это не удивительно, так как это – стандартное размещение Java-классов в любом Web-приложении. Все скомпилированные Java .class-файлы вложены в структуру каталога, соответствующую структуре пакета. То есть, класс WelcomeBean, находящийся в пакете org.apache.shale.blank, размещается в classes/org/apache/shale/blank в WelcomeBean.class.

Сохраняется разделение между исходным кодом и двоичным кодом: в структуре каталога classes/ нет .java-файлов. И не должно быть! Вместо них здесь хранятся только компилированные Java-файлы; вы должны (аналогично JSP-страницам) помещать новые исходные Java-файлы в подкаталог java/ каталога src/ и давать возможность сценариям компоновки Shale компилировать ваш Java-код.

Сценарий компоновки также копирует все файлы свойств, имеющиеся в каталоге src/java/; например, в каталоге target/ лежит файл Bundle.properties (вернитесь к рисунку 6), поскольку этот файл помещен в структуру каталога src/java/. Это позволяет вам размещать файлы, которые могут понадобиться вашим Java-классам, вместе с исходными Java-файлами, и знать, что они будут доступны в структуре компоновки приложения.

Зависимости

Каталог lib/, находящийся в каталоге target/first-shale/WEB-INF/, содержит все библиотеки, которые нужны для выполнения приложения. Как упоминалось ранее, Shale имеет огромное количество зависимостей:

Одной из ключевых возможностей начального Shale-приложения является то, что оно во время компоновки заботится об этих зависимостях вместо вас. Пока я не буду отвлекаться на рассмотрение того, что делают эти зависимости. Вы узнаете о них по мере использования в конкретных программных задачах или контекстах. Однако отмечу, что далее предполагается, что вы используете начальное приложение, и что все зависимости находятся на месте. Если вы хотите создать Shale-приложение действительно с нуля (без использования начального приложения в качестве шаблона), то должны добавить все зависимости самостоятельно. Это еще одна причина всегда начинать разработку с начального Shale-приложения!

Удаление JAR-файлов

Если вы не собираетесь использовать некоторые из возможностей Shale, то можете удалить соответствующие им JAR-файлы. Например, если вы не планируете когда-либо использовать среду Tiles с Shale, то можете удалить shale-tiles.jar из каталога WEB-INF/lib/. Хотя, вы ничего не выиграете, удалив JAR-файлы (кроме, возможно, уменьшения пространства, занимаемого развертываемым вами WAR-файлом), поэтому, это не является хорошей идеей. Сохранение файлов на своих местах гарантирует, что вы получите все что нужно, когда решите использовать Tiles или любое другое дополнение, требующее присутствия JAR-файла.

В начальном приложении зависимости хранятся в каталоге WEB-INF/lib/, все в виде JAR-файлов. Опять же, это стандартное расположение JAR-файлов в Web-приложениях. Там же вы найдете Shale-библиотеки shale-core.jar, а также несколько расширений, позволяющих Shale работать с другими интегрированными средами, например, Spring (shale-spring.jar), Clay (shale-core.jar), Tiles (shale-tiles.jar) и Java 5.0 Tiger (shale-tiger.jar). Другими словами, у вас уже есть практически все библиотеки, которые когда-либо могут понадобиться при разработке Web-приложений с использованием Shale. Это было легко, не правда ли?

Развертывание приложения

Исходный код приложения расположен в нужном месте, и вы скомпоновали ваше приложение. Конечным результатом этих двух шагов является структура каталогов (в каталоге target/ вашего основного каталога first-shale/), которая содержит все файлы, необходимые для развертывания вашего приложения в контейнере сервлета. Однако поддержание порядка среди всех этих файлов и копирование полных каталогов не слишком удобно, да и небезопасно. К счастью, Shale предоставляет более удобные средства для развертывания приложения.

Создание WAR-файла

Я уже показывал в предыдущей статье, как создать WAR-файл, но все же кратко напомню:

После выполнения этих шагов у вас появится еще один новый каталог, на этот раз с названием dist/. Содержимое данного каталога показано на рисунке 7.

Самым заметным файлом здесь является first-shale-0.1.war, который назван согласно значениям, указанным в build.properties (см. листинг 3). Каталог dist/ содержит информацию о лицензии и файл readme, а также исходный код. Это облегчает упаковку всего каталога dist/ в ZIP-файл, если вам понадобится перенести приложение на другую машину.

Развертывание WAR-файла

После создания WAR-файла реальное развертывание приложения является очень простым делом. Просто возьмите файл и поместите его в каталог Web-приложений вашего контейнера сервлетов. Этот каталог обычно называется как-то похоже на webapps/. Контейнер сервлетов разархивирует WAR-файл (что приведет к созданию структуры каталогов, аналогичной показанной в target/) и развернет приложение. С этого момента все готово для использования вашего приложения.

В заключение

В данной статье вы познакомились с анатомией Shale-приложения. Вы узнали назначение каждого каталога (и почти каждого файла в каждом каталоге) Shale-приложения. Вы должны ясно понимать содержимое каталога исходных кодов Shale-приложения и получаемого развернутого WAR-файла.

Лучшее, что можно сделать до прочтения моей следующей статьи, – использовать полученную информацию на практике. Если у вас есть Web-приложение, которое вы хотели сконвертировать в Shale-приложение, сделайте это. Начните с перемещения всех его JSP-страниц и Java-файлов в структуру каталогов Shale. Просто помните о том, что все ваши JSP-страницы нужно поместить в src/web/, а все Java-классы – в src/java/. Затем вы можете скомпоновать ваше приложение и развернуть его.

Да, игра с каталогами – это не то же самое, что использование Shale-компонентов, но вы уже работаете с инфраструктурой Shale-приложения, что является большим шагом в нужном направлении (достаточно большим, поскольку объяснение того, где Shale размешает все свои файлы в исходной и развертываемой форме, потребовало написания целой статьи). В следующей статье я сделаю еще один шаг и покажу, как писать код, взаимодействующий с Shale. Я начну с JSP-страниц, а затем познакомлю вас с некоторыми тегами Shale. А пока поиграйте с начальным приложением. Измените его и протестируйте, но помните о необходимости сохранения синхронизации дерева исходных кодов с деревом, предназначенным для развертывания!

Ресурсы

Получить продукты и технологии

Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.

Технология Клиент-Сервер 2007'2

Здравствуй, Shale!

Автор: Брэт Маклафлин

Опубликовано: 14.06.2007

Начало работы с абсолютно новой реализацией фреймворка Struts

Часть 1. Shale – это не Struts

Оценка Shale

Наследие Struts

Обзор, пересмотр, доработка, версия

Ориентированная на службы архитектура Shale

Установка Shale

Предварительные требования

Дополнительные компоненты и их зависимости

Добро пожаловать на передний край!

1. Загрузка Shale

2. Добавление Shale-библиотек в Web-приложение

Легкий путь

Листинг 1. Пример build.properties для начального Shale-приложения

Сборка WAR-файла

Тестирование вашей установки

Варианты использования Shale

Примите участие в проекте Shale!

Дополнительные зависимости

Переход к исходным текстам (где исходники?)

Листинг 2. Пример build-файла Shale

MyFaces или JavaServer Faces?

Ant в действии

Несколько слов о рассылках

В заключение

Часть 2. Структура каталогов Shale изнутри

Начало работы с Shale

Структура основного каталога

Файлы, связанные с компоновкой

Каталоги зависимостей

Документация

Исходный код

Создание приложения

Компоновка начального приложения

Добавление к дереву исходных файлов

Сравнение исходного кода и двоичного кода

Каталог target/

Внутри каталога target/

Главный каталог приложения

Листинг 3. Пример файла build.properties

Файл манифеста

Листинг 4. Файл MANIFEST.MF

Два каталога META-INF

Типичное Web-приложение

Расположение Java-классов

Зависимости

Удаление JAR-файлов

Развертывание приложения

Создание WAR-файла

Развертывание WAR-файла

В заключение

Ресурсы

Получить продукты и технологии