Geronimo! Часть 1: Механизм J2EE 1.4, который мог бы быть

Опции документа Опции документа, требующие включения JavaScript, не отображаются Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: простой

Синг Ли, Автор, Wrox Press

17.05.2005

Разработка Java-программ с открытым исходным кодом прошла длинный путь с тех давних дней, когда разработчики делились GUI-библиотеками. Geronimo - крупномасштабный проект, целью которого является создание сертифицированного сервера J2EE 1.4, основанного на существующих компонентах с открытым исходным кодом. Совершите экскурсию в лабиринты Geronimo вместе с Сингом Ли в качестве проводника. В этой первой части цикла статей (состоящего из двух частей) вы познакомитесь с элегантным дизайном и четкой архитектурой Geronimo.

В августе 2003 года Apache Software Foundation (группа, ответственная за популярный http-сервер Apache) анонсировала планы по созданию сертифицированного J2EE-сервера с открытым исходным кодом - так родился Geronimo. Как совместимый с J2EE сервер, Geronimo является очень большим проектом, охватывающим разнообразный набор функциональных возможностей. В первой части цикла статей я рассмотрю Geronimo с точки зрения пользователя, для того чтобы вы смогли четко оценить область применения проекта. Затем я приведу некоторую терминологию, с которой вы определенно встретитесь при изучении документации по Geronimo или при исследовании исходного кода. И последнее (но не окончательное) - я приведу обзор Geronimo, углубляясь в несколько ключевых концепций, с точки зрения дизайна системы.

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

Выражаю искреннюю благодарность Гейру Магнуссону (Geir Magnusson, Jr.), Джереми Бойнзу (Jeremy Boynes), Дэвиду Дженксу (David Jencks) и Алану Д. Кабрера (Alan D. Cabrera) из команды Geronimo за ценные комментарии черновиков данной статьи.

Geronimo: Совместимый с J2EE 1.4 сервер

Как J2EE-сервер, Geronimo может развертывать и выполнять ваши Web и корпоративные приложения. Для построения приложения вы можете использовать Java ServerPages (JSP-страницы), сервлеты, фильтры и Enterprise JavaBeans (EJB-компоненты). Приложение имеет доступ к внешней RDBMS через коннектор Java Data Access API (JDBC), службе каталогов через Java Naming and Directory Interface (JNDI), к поддерживающей транзакции очереди сообщений через Java Message Service (JMS), к электронной почте через JavaMail и т.д.

Поставленная цель (J2EE сертификация) одновременно является и благословением и проклятием для проекта Geronimo (смотрите вкладку "Плата за J2EE-сертификацию"). Для возможности сертификации Geronimo должен поддерживать все обязательные функциональные возможности, основанные на спецификации J2EE (смотрите раздел "Ресурсы"). Спецификация ссылается на набор других спецификаций, которые тоже имеют свои собственные обязательные требования. Рисунок 1 дает некоторое представление о том, что должен реализовывать Geronimo перед тем как быть представленным для сертификации.

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

На рисунке 1, выделенные жирным шрифтом слова внутри прямоугольников являются названиями конкретных API, слова, выделенные наклонным шрифтом, показывают, как Geronimo реализует их в настоящее время. Вы, вероятно, узнали некоторые из выделенных наклонным шрифтом названий проектов.

В начало

Попурри проектов с открытым исходным кодом

Инфраструктура сервера Geronimo, состоящая из ядра, инструментальных средств и библиотек, спроектирована и написана "с нуля" опытными разработчиками. Но многие составные компоненты являются существующими проектами, выбранными из собственного набора проектов Apache и из других проектов с открытым исходным кодом, лицензии которых совместимым с Apache License (смотрите раздел "Ресурсы" и вкладку "Зачем еще один J2EE-сервер?").

В таблице 1 перечислены другие проекты с открытым исходным кодом, которые в настоящее время включает в себя Geronimo. Такая стратегия "разделяй и властвуй" перенацеливает протестированные и проверенные средства с открытым исходным кодом и значительно уменьшает общий объем разработки для Geronimo.

В начало

Унификация сложной системы

Зачем нужен еще один J2EE-сервер? Существуют и другие J2EE-сервера с открытыми исходными кодами, один даже сертифицирован для J2EE 1.4 (смотрите раздел "Ресурсы"). Однако Geronimo является уникальным из-за поддержки универсальной лицензии Apache License (смотрите раздел "Ресурсы"). Apache License часто рассматривается как наиболее либеральная лицензия среди других альтернатив, основными из которых являются GNU General Public License (GPL) и Lesser General Public License (LGPL). Легальные преимущества этих лицензий обсуждались периодически на протяжении последних десяти лет. По существу, Apache License является единственной лицензией, предоставляющую вам свободу в использовании кода для любых целей, коммерческих или каких-либо еще, с простым подтверждением источника и без связывания себя какими-либо гарантиями по предоставлению улучшений кода.

Сложности системы, изображенной на рисунке 1, вполне достаточно для возникновения головной боли у большинства проектировщиков систем. Но когда вы рассмотрите проекты с открытым исходным кодом, которые нужно интегрировать вместе для формирования Geronimo, необходимость унифицированной модели интеграции станет очевидной.

Идея состоит в создании универсального контейнера служб, который может развертывать и запускать произвольные службы. Например, OpenEJB может работать как служба в этом контейнере для размещения всех сервлетов и JSP. Эта модель не только вносит ясность в интеграцию существующих служб с открытым исходным кодом, но также добавляет способность размещать любую совместимую службу в будущем – включая не J2EE службы, такие как среда приложений Spring (смотрите раздел "Ресурсы").

Дизайн контейнера должен сохранять универсальность для поддержки подключения J2EE и не J2EE служб. Это очень трудная дизайнерская задача. Контейнер должен обрабатывать всю нудную и повторяющуюся работу, которую делать никто не хочет, но это не является таким невыполнимым, если основываться на подключаемых службах. Дизайнеры Geronimo с некоторой помощью спецификации J2EE 1.4 определили три необходимых функциональных области среди всех служб:

• Управляемость
• Управление конфигурацией
• Жизненный цикл службы

Этот список охватывает три главных функции контейнера служб Geronimo. Вы вскоре увидите, как Geronimo реализует эти требования.

В начало

Главные цели: Масштабируемость, управляемость и управление конфигурацией

Беря пример с индустрии телекоммуникаций, дизайнеры Geronimo задались целью обеспечить крупномасштабную управляемость и управление конфигурацией. Термины Операции, Администрирование, Обслуживание и Подготовка к работе (Operations, Administrations, Maintenance and Provisioning - OAM & P) были "хлебом и маслом" для инженеров по системам телекоммуникаций, но они относительно новы для проектировщиков Java-систем. В системах с параллельной работой сотен или тысяч экземпляров служб, в которых процессы сбоя-восстановления происходят ежеминутно, взгляд на то, как что-то работает, администрирует и управляет системой, изменился очень значительно. Например, ручное изменение конфигурационных файлов для каждого экземпляра полностью исключается.

По большому счету вы можете дать следующую команду на выполнение работы кластеру экземпляров Geronimo:

Предоставить Web-приложение "Pet Store" для 50000 клиентов в час в пиковую нагрузку с указанием в Service Level Agreement ограничения не менее 99% времени работы (uptime) и не более пяти секунд на обработку заказа до 15 июня. 15 июня снизить пиковую нагрузку до 10000 клиентов в час, ограничение SLA 80% и 10 секунд на заказ до августа 31. Удалить Web-приложение 1 сентября.

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

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

В начало

Обеспечение управляемости

Первым шагом в создании полезного дизайна контейнера, согласующегося с общим видением Geronimo, является обеспечение управляемости контейнера. Подход команды разработчиков Geronimo к реализации этой цели со временем эволюционировал.

Обход JMX

Естественным направлением для достижения управляемости является создание контейнера на основе Java Management Extensions (JMX). Если каждый экземпляр соответствующего объекта правильно оснащен и является управляемым, то и вся система может быть управляемой и контролируемой внешними средствами, и в ней могут быть реализованы функции масштабирования. Первая версия дизайна ядра Geronimo, изображенная на рисунке 2, явилась результатом такой точки зрения.

О JMX Если вы новичок в JMX, я рекомендую прочитать мой цикл из трех частей по этой важной теме.

На рисунке 2 JMX является основой основ контейнера (ядром), и каждый объект в контейнере является компонентом MBean. Компоненты MBean должны быть полностью оснащены и управляемы. Команда Geronimo выбрала для этой цели MX4J (смотрите раздел "Ресурсы").

Однако на практике команда Geronimo выяснила, что MX4J выходит за рамки требуемого дизайна. Geronimo больше не использовал MX4J в качестве JMX. Он использовал его в общих целях как всеобъемлющую систему для поиска объектов, взаимодействия между объектами, перехвата методов и т.д. По мере продвижения сложность контейнера возрастала, а производительность стала уменьшаться.

Еще одним открытием, которое сделала команда, явилась трудность адаптации существующего кода служб к системе, основанной на централизованном управлении. Прямоугольники сверху ядра JMX на рисунке 2 представляют службы, а вертикальная "вилка" пунктирных линий представляет код, занимающийся вопросами управляемости. Этот код находится на одной линии с дизайном основанной на JMX службы, в то время как код логики является ортогональным (и пересекающимся). Это приводит к тому, что код службы становится трудно написать и поддерживать. Наступило время для изменения планов.

Создание лучшего ядра, стиль IoC

Пересмотренный дизайн ядра Geronimo показан на рисунке 3.

Об IoC Inversion of Control (инверсия управления), также известная как внедрение зависимости, является шаблоном, поддерживаемым контейнерами и средами IoC для достижения разделения действий. Компоненты внутри контейнера могут изолировать зависимости, а эти зависимости можно внедрить в них во время выполнения/развертывания. Это предоставляет контейнеру возможность выбора реализации, эффективно инвертируя управление от компонента контейнеру. Смотрите раздел "Ресурсы" для получения более подробной информации.

Как показано на рисунке 3, реализация JMX больше не является основой ядра. Архитектура ядра основывается на Inversion of Control (инверсия управления) (IoC; смотрите вкладку "Об IoC"). JMX все еще является важной частью ядра (поскольку управляемость все еще имеет большое значение), но переведен рангом ниже и является одной из многих зависимостей, которые могут быть внедрены в службу во время развертывания. Это очень облегчает создание новых служб, поскольку код может быть (и должен) сконцентрирован возле логики службы. Для получения JMX-управляемости необходимо только следовать определенным правилам кодирования для внедрения зависимости IoC. Такой дизайн также упрощает перемещение существующих служб в Geronimo путем создания тонкой надстройки (wrapper) над существующей службой, которая адаптирует ее к IoC-ядру. Обратите внимание, что службы больше не представлены в виде компонентов JMX MBean, а в виде специфичных для Geronimo компонентов GBean, о которых вы узнаете подробнее в следующем разделе.

Этот дизайн может поддерживать полностью не управляемые операции (свободные от JMX), в которых компоненты взаимодействуют непосредственно через ядро. Это обеспечивает "легковесное" решение для тех ситуаций, в которых Geronimo работает как встроенный компонент IDE, программа командной строки или другое специализированное приложение.

В начало

Жаргон Geronimo

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

Модуль

Согласно терминологии J2EE, каждый программный элемент, который может быть развернут на сервере, часто называется модулем (смотрите вкладку "Модули и конфигурации"). Модуль может содержать много Java-классов и компонентов GBean и обычно ассоциируется с одним или несколькими планами развертывания в Geronimo. (Я опишу компоненты GBean и объясню планы развертывания Geronimo в следующем подразделе.) Например, модуль может быть Web-приложением в файле Web-архива (WAR), или корпоративным приложением в файле корпоративного архива (EAR). Модуль - это пользовательская концепция. Внутри ядро Geronimo не видит модулей и работает только с конфигурациями (определяемыми далее).

План развертывания в Geronimo

План развертывания в Geronimo является специфичными для Geronimo метаданными, необходимыми для успешного развертывания модуля (конфигурации). Физически это XML-файл. Он может быть расположен внутри архивов модулей или храниться вне их (где он может управляться и редактироваться при помощи программы развертывания/управления). XML-файл плана развертывания в Geronimo может иметь разные названия в зависимости от типа модуля и его месторасположения. Например, план развертывания в Geronimo для модуля EJB JAR, встроенного в JAR, называется openejb-jar.xml, в то время как план развертывания в Geronimo для EAR-модуля корпоративного приложения называется geronimo-application.xml, когда он встроен в архив. Когда планы развертывания размещаются вне архива, они могут иметь любое название. Geronimo имеет план развертывания по умолчанию для простых типов модулей, например WAR, EAR и JAR.

GBean

Поскольку модуль является способным к развертыванию элементом, GBean является в Geronimo управляемым элементом. Один способный к развертыванию элемент может содержать ноль или более управляемых элементов. Поэтому в Geronimo один модуль может развернуть много компонентов GBean. Не все классы в модуле/конфигурации должны быть компонентами GBean. Только сущности, которые хотят получить обратный вызов для управления жизненным циклом, или сущности, которые хотят экспонировать для JMX управляемые атрибуты и операции, должны являться компонентами GBean. GBean может иметь несколько работающих экземпляров. Geronimo назначает каждому экземпляру уникальное имя при старте GBean. Внутри Geronimo видит только компоненты GBean и конфигурации, модули ему не видны. Модуль - это пользовательское понятие, а GBean - это системное понятие.

Модули и конфигурации Модуль - это фактически понятие J2EE, а не Geronimo. Во время развертывания один или несколько модулей пакетируются вместе в конфигурацию. Ядро Geronimo понимает только конфигурации. Конфигурация - это то, что вы хотите запустить (например, приложение, набор служб или что-то такое же простое, как набор JAR-файлов). Она необходима потому, что вы не хотите все время управлять индивидуальными компонентами. Система обычно имеет кластеры тесно связанных компонентов, которые являются слабо связанными с другими компонентами. Обычно отдельная конфигурация существует для каждой тесно связанной группы.

Конфигурация

Конфигурация представляет собой скомбинированное развертывание одного или нескольких модулей. Внутри Geronimo видит конфигурацию как пакетированное развертывание одного или нескольких компонентов GBean. Ядро Geronimo понимает и обрабатывает конфигурации. Вы можете рассматривать конфигурации как то, что вы собираетесь запустить. В J2EE это может быть корпоративное приложение, а вне J2EE это может быть набор созданных вами пользовательских служб.

Одной из основных идей конфигурации является то, что вы можете сериализировать ее, а затем десериализировать обратно на любой другой системе, на которой работает Geronimo, и получить точно такую же конфигурацию, работающую на другом экземпляре Geronimo. Способность миграции конфигурации очень важна для масштабируемости. Например, представьте запуск 500 экземпляров Geronimo с приложением "Pet Store". С наличием готовой постоянной конфигурации "Pet Store" задача сводится к простому запуску экземпляров с сериализованной конфигурацией.

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

Работа системы Geronimo представляет собой работу многих конфигураций. Конфигурации могут иметь иерархические взаимоотношения. Каждая конфигурация имеет уникальный указанный пользователем конфигурационный идентификатор. В конфигурации можно указать другую конфигурацию в качестве родительской. Дочерняя конфигурация наследует загрузчик классов (classloader) своего предка и, следовательно, имеет доступ ко всем конфигурационным классам предка. Это может быть полезным, например, при необходимости совместного доступа к библиотекам двух отдельно развернутых конфигураций.

В начало

Основные понятия Geronimo

Важные понятия Geronimo, которые я опишу в этом разделе, помогут вам в самостоятельном исследовании Geronimo или его исходного кода.

Жизненный цикл GBean

Компоненты GBean значительно больше компонентов JMX MBean. GBean создает отличный фасад для управляемой службы. Одним из преимуществ GBean является то, что контейнер может управлять жизненным циклом его службы. Контейнер будет вызывать компонент GBean при изменении состояния, если GBean реализует необязательный интерфейс GBeanLifecycle, как показано в листинге 1:

public interface GBeanLifecycle {
    void doStart() throws Exception;
    void doStop() throws Exception;
    void doFail();
}

На рисунке 4 показаны состояния, через которые проходит GBean.

На рисунке 4 вы можете увидеть, что модуль, содержащий GBean, может быть развернут или распределен на целевом объекте. Таким объектом может быть одиночная машина или кластер машин. При распределении на целевом объекте конфигурация GBean проверяется и сохраняется, но не запускается на целевом объекте. При развертывании GBean запускается на целевом объекте.

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

Две ключевые спецификации: JSRs 77 и 78 JSR 77, спецификация "J2EE Management" (управление), описывает модель управления, которая предоставляет возможность управления сервером приложений различными управляющими инструментальными средствами, с использованием различных протоколов. JSR 88, спецификация "J2EE Application Deployment" (развертывание приложений), описывает концепцию компонента DDBean для представления фрагментов дескриптора развертывания. Как вам известно из таблицы 1, эти две спецификации находятся среди обязательных для реализации в J2EE-сервере, для того чтобы выполнить требования J2EE-сертификации.

Между состояниями "запуск" (0) и "остановлен" (3) существуют состояния перехода, которые инициируют обратный вызов (callback) интерфейса GBeanLifecycle. Это соответствует управляемым состояниям JSR 77 (смотрите вкладку "Две ключевые спецификации: JSRs 77 и 78").

Управление конфигурацией

Конфигурации сохраняются в сериализированном формате в хранилище конфигураций. Geronimo поддерживает подключаемые модули для организации хранилища конфигураций. Например, вместо сохранения конфигураций на локальном диске вы можете сохранить их в корпоративной службе каталогов через JNDI-провайдера. Это потенциально может позволить организовать географически распределенные кластеры экземпляров Geronimo для совместного использования конфигураций.

Поскольку Geronimo поддерживает JSR 88 для возможности взаимодействия программ развертывания, значения в хранилище конфигураций, являющиеся текущей параметризацией развернутого модуля, могут редактироваться при помощи совместимых с JSR-88 сторонних программ - в основанном на GUI IDE или через систему управления сетью.

Управление зависимостями

Менеджер зависимостей является жизненно важным компонентом в Geronimo. Частый запуск конкретной конфигурации требует предварительного запуска ее зависимостей. Например, для Web-приложения, которое обращается к JMS и RDBMS через JDBC, необходимо наличие работающих и доступных модулей ActiveMQ и JDBC Connector. Менеджер зависимостей сканирует все дескрипторы развертывания модуля и планы развертывания для определения зависимостей. Работа менеджера зависимостей заключается в гарантировании доступности зависимостей модуля перед его запуском. Зависимости модуля указываются явно внутри плана развертывания в Geronimo.

Связывание компонентов GBean: Ссылки и взаимодействие

На первый взгляд может показаться, что работа контейнера заканчивается после успешного развертывания и запуска GBean. Но это далеко не так. Еще одной важной функциональной задачей контейнера является "связать" ссылки между компонентами GBean, предоставляя им возможность для взаимодействия.

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

Разрешаемые ссылки на другие компоненты GBean доступны через динамически сгенерированные вызывающие прокси-объекты. Это эффективно разрешает компонентам GBean вызывать друг друга без вмешательства ядра. Такое поведение изображено на рисунке 5.

На рисунке 5, GBean 1 вызывает метод компонента GBean 2. GBean 2 является разрешаемой ссылкой, и Geronimo динамически генерирует вызывающий прокси-объект. Он предоставляет возможность непосредственного взаимодействия двух компонентов GBean. В настоящее время Geronimo использует cglib, программу генерирования байт-кода (смотрите раздел "Ресурсы"), для динамического генерирования кода прокси.

В начало

Заключение

Geronimo имеет потенциал стать одним из наиболее притягательных контейнеров для разработки серверных продуктов. Его богатый набор функциональных возможностей, неограниченная лицензия Apache License и преимущества "готового к развертыванию" сервера J2EE 1.4 несомненно понравятся многим разработчикам. Прочитав данную статью, вы теперь знаете о сервере Geronimo, а также то, почему он является важным для разработки программного обеспечения с открытым исходным кодом. Вы исследовали архитектуру Geronimo и познакомились с некоторыми ключевыми понятиями и концепциями. Во второй части цикла будут рассмотрены практические примеры, работающие на реальном сервере.

Ресурсы

• Оригинал статьи The J2EE 1.4 engine that could.
  
  
• Gluecode Software CTO и главный создатель Geronimo Джереми Бойнз (Jeremy Boynes) делится своим видением перспектив Geronimo, направлений Java-программирования и состоянием программного обеспечения с открытым исходным кодом в своем недавнем интервью для developerWorks.
  
  
• Загрузите Gluecode Standard Edition - сервер приложений с открытым исходным кодом, основанный на Apache Geronimo.
  
  
• На официальном сайте проекта Geronimo находятся последние исходные коды и бинарные файлы, активное сообщество подписчиков почтовой рассылки и wiki.
  
  
• Домом Geronimo является Apache Software Foundation, где вы можете прочитать детальный текст последней лицензии Apache License.
  
  
• Текст альтернативных видов лицензий на программное обеспечение с открытым исходным кодом можно найти в Lesser General Public License и General Public License на сайте GNU Project.
  
  
• Изучите более детально Jetty (контейнер сервлетов и JSP-страниц, интегрированный в Geronimo по умолчанию) на сайте проекта.
  
  
• Исследуйте Tomcat - альтернативный контейнер сервлетов и JSP-страниц для Geronimo.
  
  
• Исследуйте возможности OpenEJB - EJB-контейнера в Geronimo.
  
  
• Узнайте детали о проекте ActiveMQ. ActiveMQ используется для реализации очереди сообщений Geronimo через JMS.
  
  
• Derby - это служба реляционной базы данных и JDBC-провайдер, по умолчанию предоставляемый для Geronimo. Посетите Web-сайт проекта Derby, на котором размещена документация, исходный код и активное сообщество пользователей, подписанных на почтовую рассылку.
  
  
• Geronimo интегрирует Axis (универсальный стек Web-служб) для достижения совместимости с WS-I Basic Profile.
  
  
• Одной из целей Geronimo является использование одного и того же набора средств для реализации как EJB, так и "легковесной" POJO-персистентности. Решением является проект TranQL.
  
  
• Команда разработчиков Geronimo плотно работает с группой ObjectWeb для поддержки транзакций. HOWL и JOTM являются ключевыми проектами ObjectWeb, относящимися к Geronimo.
  
  
• Команда разработчиков Geronimo надеется интегрировать Apache Directory Server (кодовое название проекта - Apache Eve) в ближайшем будущем.
  
  
• Для удовлетворения требований управляемости Geronimo использует библиотеку MX4J для реализации JMX.
  
  
• Geronimo использует Apache Scout для реализации совместимости с JAXR for Web services.
  
  
• Geronimo использует отличную библиотеку генерирования кода cglib для установки каналов перехвата (interception pipelines) для ссылок inter-GBean.
  
  
• Универсальный механизм шаблонов Velocity интенсивно используется Geronimo в процессе компоновки и в консольных модулях.
  
  
• Geronimo использует Apache Maven для управления компоновкой кода нескольких проектов и Apache Ant для компоновки индивидуальных проектов. Для контроля версий большинства проектов применяется Subversion, хотя несколько проектов все еще находятся под управлением CVS.
  
  
• Для получения дополнительной информации о Java Management Extensions (JMX) просмотрите цикл статей Синга Ли "От черных ящиков к предприятиям: JMX 1.1" (developerWorks, осень 2002).
  
  
• Дополнительную информацию по шаблону Inversion of Control и по внедрению зависимостей в общем можно найти в среде Apache Jakarta Hivemind, Pico Containe и среде приложений Spring.
  
  
• Вы можете изучить альтернативный сертифицированный сервер J2EE 1.4 с открытым исходным кодом, доступный по лицензии LGPL, на Web-сайте Java Open Application Server (JOnAS).
  
  
• На странице J2EE-спецификаций размещены детальные спецификации J2EE 1.4.
  
  
• Менеджеры, архитекторы и разработчики, использующие Java-технологии, могут открыть окно в J2EE-технологии из цикла J2EE Pathfinder.
  
  
• Прочтите статью "Освобождение Java: Интервью с Джейсоном Хантером (Jason Hunter)" (developerWorks, апрель 2002) для изучения истории участия проектов с открытым исходным кодом в Java Community Process.
  
  
• Подключайтесь к сообществу developerWorks, участвуя в блогах developerWorks.
  
  
• В зоне Java-технологий сайта developerWorks вы найдете статьи по каждому аспекту Java-программирования.
  
  
• Посетите Developer Bookstore для получения исчерпывающего списка технических книг, включающего сотни наименований, относящихся к Java.

Об авторе

		Синг Ли (Sing Li) - активный автор. Он участвовал в написании книг: "Знакомство с JavaServer Pages", "Профессиональное использование Apache Tomcat 5, Pro JSP, третье издание", "Early Adopter JXTA", "Профессиональное использование Jini", "Знакомство с J2ME: От новичка до профессионала, третье издание" и многих других. Он постоянно публикуется в технических журналах и является активным проповедником эволюции VON и P2P. Синг является консультантом и независимым писателем. Связаться с ним можно по электронной почте westmakaha@yahoo.com.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало