Среди всех интегрированных Web-систем, появившихся за последние пять лет, Jakarta Struts является одной из самых популярных сред из когда-либо применявшихся Java-разработчиками, поэтому появление ее отпрыска является примечательным событием. Хотя 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).

Оценка Shale

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

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

Наследие Struts

Shale интенсивно использует базу исходного кода Struts и утверждает, что Struts является "родительской" средой, поэтому вам нужно убедиться в ценности Struts, если вы собираетесь поверить в ценность Shale. Первое и самое главное: 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 по многим существенным параметрам, но особо выделяются два из них:

• Struts интегрируется с JSF, в то время как Shale основан на JSF.
• Struts, по существу, - это огромный, сложный процессор запросов; Shale - это набор служб, которые могут комбинироваться так, как вам нравится.

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

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

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

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

В начало

Установка Shale

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

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

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

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

• Java Runtime Environment (JRE) и Java Development Kit (JDK) 1.4 или старше
• Java Servlet API 2.4 или старше
• JSP 2.0 или старше
• JSF 1.1 или старше
• JSP Standard Tag Library (JSTL) 1.1 или старше
• Jakarta Commons BeanUtils 1.7 или старше
• Jakarta Commons Chain 1.0 или старше
• Jakarta Commons Digester 1.7 или старше
• Apache Logging 1.0.4 или старше
• Apache Ant 1.6.3 или старше

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

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

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

• Jakarta Commons Validator 1.2 или старше
• The Spring Framework 1.2.2 или старше
• The Struts Tiles Framework (автономная версия)

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

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

• JSF 1.1 или старше (возможно поставляется с вашим контейнером сервлетов)
• JSTL 1.1 или старше (возможно поставляется с вашим контейнером сервлетов)
• Jakarta Commons BeanUtils 1.7 или старшеr
• Jakarta Commons Chain 1.0 или старше
• Jakarta Commons Digester 1.7 или старше
• Apache Logging 1.0.4 или старше

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

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

1. Загрузка Shale

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

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

• shale-framework-20060204.zip
• shale-dependencies-20060204.zip

Понятно, если вам нужно или вы предпочитаете загружать версию.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-приложение может найти и использовать их. Вы должны выполнить следующие действия:

1. Если у вас нет JSF в контейнере сервлетов, скопируйте shale-framework-20060204/lib/jsf-ri/jsf-api.jar и shale-framework-20060204/lib/jsf-ri/jsf-impl.jar в каталог WEB-INF/lib вашего приложения.
   
   
2. Скопируйте shale-core.jar, shale-clay.jar, shale-tiles.jar и tiles-core.jar из вашего каталога shale-framework-20060204/dist/ в каталог WEB-INF/lib вашего Web-приложения.
   
   
3. Скопируйте следующие Shale-зависимости в каталог WEB-INF/lib вашего Web-приложения:
   • shale-framework-20060204/lib/commons-beanutils/commons-beanutils.jar
   • shale-framework-20060204/lib/commons-chain/commons-chain.jar
   • shale-framework-20060204/lib/commons-digester/commons-digester.jar
   • shale-framework-20060204/lib/commons-logging/commons-logging.jar
   • shale-framework-20060204/lib/commons-validator/commons-validator.jar
   
   
   
4. Если вы используете функциональную возможность Shale интегрирования со средой Spring, скопируйте shale-spring.jar из shale-framework-20060204/dist/ в каталог WEB-INF/ вашего Web-приложения. Выполнив это действие, вы должны быть также уверены, что общий JAR-файл (все в одном) Spring тоже находится в каталоге WEB-INF/lib вашего Web-приложения. Этот JAR-файл, называемый spring.jar, находится в каталоге shale-framework-20060204/lib/shaleframework/, если у вас его еще нет.
   
   
5. Если у вас работает Java 5.0, скопируйте shale-tiger.jar из каталога shale-framework-20060204/dist/ в каталог WEB-INF/lib вашего Web-приложения. Выполните это действие только при работе с Java 5.0; в противном случае ваш контейнер сервлетов и любое Web-приложение, использующее Shale, будут иметь проблемы.

На данном этапе все начинает немного усложняться (да, все это копирование было легкой частью). Однако вместо того, чтобы делать все как можно более сложным, я должен, по крайней мере, попытаться показать вам вариант легкого пути. Действительно, есть легкий путь настроить и запустить 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, который вы можете легко настроить под вашу среду.

# Основная информация о проекте
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-файлов, то можете использовать тот же самый файл компоновки начального Shale-приложения с небольшим изменением. Поскольку вы пока не написали какие-либо 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 компилирует и собирает ваше начальное приложение и создает новый 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.

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

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

В начало

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

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

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

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

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

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

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

# Этот файл содержит примерные настройки свойств, которые вы могли бы использовать 
# для конфигурирования вашей среды для компоновки 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

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

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

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

Ресурсы

Научиться

• Оригинал статьи "All Hail Shale: Shale isn't Struts".
  
  
• "JSF для неверующих: Прояснение неопределенности о JSF" Ричард Хайтауэр (Richard Hightower): Подробное рассмотрение сильных и слабых сторон JavaServer Faces, одной из составных частей Shale.
  
  
• "Ориентированное на использование служб моделирование и архитектура" Али Арсанджани (Ali Arsanjani): Относительно свободный от слухов обзор парадигмы ориентированной на использование служб архитектуры.
  
  
• "В тон с Tapestry" (Брэтт МакЛафлин (Brett McLaughlin), developerWorks, январь 2006): Узнайте больше о Tapestry, одной из дружественных к пользователю интегрированных сред Web-разработки нового поколения (две части).
  
  
• "Интегрирование Struts, Tiles и JavaServer Faces" (Срикант Шеной (Srikanth Shenoy) и Нисин Малья (Nithin Mallya), developerWorks, сентябрь 2003): Интересный взгляд на жизнь до Shale.
  
  
• Домашняя страница Shale: javadocs и дополнительная информация по Shale.
  
  
• Домашняя страница Struts: Предшественник Shale - широко используемая и расширяемая интегрированная среда для Web-разработки.
  
  
• Bugzilla: Текущая информация о состоянии отдельных ошибок или функциональных возможностей в Shale на этом Apache Web-сайте отслеживания ошибок.
  
  
• Раздел Технология Java: десятки статей о каждом аспекте Java-программирования.
  
  

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

• Apache Tomcat: Отличный контейнер сервлетов, идеально работающий с Shale, так же как и со Struts.
  
  
• Jakarta Commons BeanUtils: Предоставляет удобные служебные классы для работы с классами в формате именования JavaBeans.
  
  
• Jakarta Chain: Набор Java-компонентов, реализующий шаблон проектирования "Chain of Responsibility", позволяющий командам или компонентам "соединяться в цепочку" без зависимости друг от друга.
  
  
• Jakarta Digester: Позволяет легко отображать XML на Java, делая возможным простое чтение файлов конфигурации и свойств, представленные в XML.
  
  
• Apache Logging: Службы ведения журналов регистрации событий для различных языков программирования, включая C++, Java, Perl, PHP и PL/SQL.
  
  
• Apache Ant: Java-программа компоновки, используемая для компоновки Shale.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  

Об авторе

Брэт Маклафлин работает с компьютерами со времен Logo (помните маленький треугольник?). За последние несколько лет он стал одним из наиболее известных авторов и программистов сообщества по технологиям Java и XML. Он работал в Nextel Communications над реализацией сложных корпоративных систем, в Lutris Technologies, фактически, над созданием сервера приложений, а с недавнего времени - в O'Reilly Media, Inc., где продолжает писать и редактировать книги по данной тематике. Его готовящаяся книга "Head Rush Ajax" рассматривает инновационный подход "Вперед головой" к изучению Ajax; она пишется совместно с известными соавторами Эриком и Бет Фримэн. Его недавняя книга "Java 5.0 Tiger: Заметки разработчика" является первой доступной книгой по новейшей технологии Java, а его классическая "Java и XML" остается одной из наиболее авторитетных работ по использованию технологий XML в языке программирования Java.

Оценить эту статью

Комментарии

В начало

Содержание

• Оценка Shale
• Установка Shale
• Легкий путь
• Тестирование вашей установки
• Варианты использования Shale
• Примите участие в проекте Shale!
• Working with source code
• В заключение
• Ресурсы
• Об авторе
• Комментарии