Создание приложений Ajax с помощью Google Web Toolkit, Apache Derby и Eclipse: Часть 4. Развертывание

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

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

Ноэл Рэппин, старший инженер-программист, Motorola, Inc.

08.02.2008

В трех предыдущих статьях мы с помощью Google Web Toolkit строили простое и функциональное сетевое приложение. В данной статье вы научитесь размещать приложение GWT на сетевом программном сервере Java и получите советы по использованию БД Apache Derby.

В данной статье в качестве примера контейнера сервлетов мы будем использовать широко распространенный и бесплатный Apache Tomcat. Другие контейнеры сервлетов работают приблизительно так же. Развертывать приложения обычно приходится на уже существующий сервер; в противном случае информацию о том, откуда можно загрузить Tomcat, вы найдете в разделе Ресурсы. Если вы работаете в ОС Microsoft® Windows®, то можете воспользоваться довольно простой программой установки. Если ваша система работает под Mac или UNIX®, можете воспользоваться скомпилированной версией, которую надо извлечь в удобное место (обычно /usr/local); после установки переменных среды вы можете приступить к работе.

Компиляция кода вашего клиента

При развертывании вашего приложения GWT на Tomcat надо сделать два основных шага.

1. Собрать все нужные файлы и поместить туда, где Tomcat сможет их увидеть.
2. Ознакомить Tomcat со всеми серверными операциями, которые вы будете вызывать со страницы GWT.

Обратитесь в Ресурсный центр Ajax, ггде вы найдете информацию о модели программирования Ajax, статьи и руководства, форумы, блоги, энциклопедии, информацию о событиях и новостях. Здесь есть все.

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

• Найдите корневой каталог установки Tomcat. Уровнем ниже вы найдете подкаталог webapps. Каждое приложение из контейнера сервлетов Tomcat получает в нем свой каталог. Поэтому создайте в webapps подкаталог slicr. Структуры всех серверных приложений Java соответствуют стандартам для сервлетов, поэтому все работающие с сервлетами программы должны поддерживать одну и ту же структуру.
• Создайте в каталоге slicr подкаталог WEB-INF – обязательно заглавными буквами.
• Поместите в каталог slicr скомпилированные в GWT страницы JavaScript и обычно скомпилированные классы Java. Сначала я покажу, что делать с классами Java.
• Скомпилируйте Java-код как обычно, используя свою интегрированную среду разработки (IDE), Apache Ant или какую-нибудь другую. Далее у вас есть несколько вариантов:
• Быстрее всего – скопировать все дерево файлов .class в подкаталог Tomcat webapps/slicr/WEB-INF/classes, который Tomcat в процессе работы автоматически помещает в переменную classpath вашего каталога webapps.
• Вместо этого вы можете любым подходящим инструментом преобразовать ваши скомпилированные классы в файл JAR и поместить его в каталог webapps/slicer/WEB-INF/lib. Опять же, Tomcat автоматически помещает файл JAR из этого каталога в переменную classpath.

Компиляция файлов вашего клиента GWT

Далее надо скомпилировать и перенести файлы вашего клиента GWT. Поскольку до сих пор вы работали в серверном режиме, этого вам делать не приходилось. Быстрее всего скомпилировать код можно воспользовавшись кнопкой Compile на консоли серверного режима. Но есть еще один достойный внимания путь, более пригодный для автоматизации.

В первой статье этой серии для создания проекта GWT вы использовали сценарий GWT applicationCreator. Тогда я упоминал о еще "нескольких сценариях оболочки", созданных вместе с проектом GWT, однако в подробности не вдавался.

Один из созданных файлов оболочки называется Slicr-compile. В Windows он имеет расширение .cmd. (В общем случае он называется имя вашего проекта-compile.) В зависимости от используемой вами ОС, нажмите на этом файле мышкой или вызовите его из командной строки. Сценарий, поработав некоторое время, выдает примерно следующее:

Таким образом GWT перекомпилирует весь ваш клиентский код Java в код JavaScript. Клиентским кодом по умолчанию считается весь код в каталоге client вашего проекта; однако вы можете сменить этот каталог, добавив в файл .gwt.xml тег <source path=path/>, где path - место с исходными кодами, которое вы хотите добавить. Следует отметить, что если вы добавите собственный путь, путь по умолчанию больше использоваться не будет, и если вы захотите оставить его, вам придется его тоже добавить явным образом.

Обычно компилятор GWT успешно компилирует правильный код Java. Однако некоторые моменты могут привести к проблемам. Вот за чем стоит следить:

• Код клиента GWT должен быть совместим с Java 1.4. Это значит, в нем не должны использоваться обобщенные классы (generics), автобоксинг (autoboxing) и циклы for-each в новом стиле. Совместимость с Java 1.5 ожидается в будущем.
• Поддерживается минимальный набор функций Java Standard Library. Поддерживающиеся библиотечные классы ограничены пакетами java.util и java.lang. Поддерживаются не все эти пакеты. В частности, пакет java.lang.reflect не поддерживается. Как вы уже видели во второй статье, это значит, что такие вещи, как код БД вы должны размещать в других частях своей системы.
• Если вы используете регулярные выражения, то в процессе работы они интерпретируются по правилам JavaScript, а не Java.
• Сериализация Java не поддерживается. Вместо этого используется механизм удаленных процедур GWT, что уже описано в третьей статье.
• По-разному определяются числа с плавающей точкой и длинные целые типы. Требующие четкой семантики вычисления с плавающей точкой должны проводиться на сервере.
• Компилятор GWT игнорирует оператор Java assert. Также игнорируются объявления synchronized, поскольку интерпретатор JavaScript поточность не поддерживает.

Результаты компиляции

Допустим, ваш код Java соответствует вышеуказанным требованиям и компиляция успешно завершена; вы можете ознакомиться с результатами работы компилирующего сценария и исследовать показанный в листинге 1 каталог ./www/com.ibm.examples.Slicr. Некоторые файлы у вас могут называться по-другому.

                
1A0A627040909C0818A7A71B13246DCD.cache.html
1A0A627040909C0818A7A71B13246DCD.cache.xml
587B8CC6CF487EBD41844000481528BF.cache.html
587B8CC6CF487EBD41844000481528BF.cache.xml
64AF143E1C4C5866446137A8C42B4609.cache.html
64AF143E1C4C5866446137A8C42B4609.cache.xml
B01955141995DDAD97AFC2941024CE4E.cache.html
B01955141995DDAD97AFC2941024CE4E.cache.xml
Slicr.html
com.ibm.examples.Slicr.nocache.html
gwt.js
history.html
tree_closed.gif
tree_open.gif
tree_white.gif

Начнем с простого: Slicr.html – созданная вами страница HTML, скопированная сюда из вашего публичного каталога. Сюда помещается все содержимое этого каталога. Три файла .gif, как можно догадаться по их именам, используются GWT при рендеринге элементов дерева. В связи с тем что никаких деревьев в приложении Slicr у вас нет, можно заключить, что GWT всегда дает на выход эти картинки. Еще один файл с осмысленным именем, history.html, содержит код JavaScript для управления состоянием и обеспечения работы кнопки Back. Файлы gwt.js и nocache.html содержат довольно стандартный код для правильного запуска и загрузки вашего приложения GWT.

Остались файлы с длинными шестнадцатеричными именами. Их шесть пар HTML/XML. Открыв наугад один из файлов .html, вы увидите много непонятного кода JavaScript (см. листинг 2).

                
function ob(pb,qb){z();pb.F = qb;return pb;}
function rb(sb,tb,ub){z();sb.D = ub;sb.F = tb;return sb;}
function vb(){}
_ = vb.prototype = new f();_.jb = C;_.hb = E;_.i = 'java.lang.Throwable';
_.j = 1;_.D = null;_.F = null;function wb(xb){mb(xb);return xb;}
function yb(zb,Ab){ob(zb,Ab);return zb;}
function Bb(Cb,Db,Eb){rb(Cb,Db,Eb);return Cb;}

Надеюсь, что тут все ясно. Это то, во что превратился наш прекрасный Java-код при компиляции GWT в код JavaScript. Здесь пять пар HTML/XML, по одной для каждого из основных интерпретаторов браузеров: Firefox/Gecko (старая и новая версии), Windows Internet Explorer, Opera и Safari. Файлы XML управляют отображением типов данных с тем, чтобы каждый из интерпретаторов правильно эти данные использовал. Цель – уменьшить количество отправляемого браузеру текста. Когда пользователь открывает в браузере страницу GWT, шаблонный код JavaScript автоматически находит и загружает в пользовательский браузер правильную версию вашего кода.

Для публикации страниц GWT все эти файлы из каталога www/com.ibm.examples.Slicr должны быть скопированы в каталог Home/webapps/slicr Tomcat-а. Таким образом, мы позаботились о клиенте, и пора обратить внимание на сервер.

В начало

Развертывание серверной стороны

Если вы когда-либо занимались разработкой сервлетов, то эта часть процесса GWT должна быть вам знакома. Написанный нами серверный код – это просто еще один сервлет, и размещать его надо в соответствии со стандартами Servlet standard.

Сначала вам надо скомпилировать весь код Java при помощи обычного, чистого компилятора Java. Имеются два варианта:

• Поместить все файлы .class в каталог Tomcat Home/webapps/WEB-INF/classes.
• Или объединить все файлы .class в файл .jar и поместить его в каталог Tomcat Home/webapps/WEB-INF/lib.

В скомпилированный код должен быть включен клиентский код, который вы уже скомпилировали с помощью GWT – не забывайте, что некоторые из клиентских классов вы используете на сервере для передачи данных.

Кроме того, все используемые вами посторонние библиотеки вы должны поместить в один каталог /lib. В этом каталоге обязательно должен быть поставляющийся с дистрибутивом GWT файл gwt-servlet.jar. В этом файле содержатся все необходимые вашему приложению пользовательские файлы GWT.

Примечание: В оригинальном дистрибутиве GWT этого файла нет. Однако вам все равно стоит обратить внимание на инструкции по развертыванию в интернете, в которых, в частности, даются указания взломать файл gwt-user.jar и удалить из него несовместимые с Tomcat классы сервлетов. Если же у вас обновленный дистрибутив GWT, то этот шаг можно пропустить.

В нашем случае вам также понадобится файл derby.jar, который входит в дистрибутив Derby и содержит необходимые вам классы БД Derby. Если вы хотите переместить БД Derby и не потерять хранящиеся в ней данные, просто возьмите каталог БД slicr, который создала Derby (см. вторую статью серии). (Если вы следовали инструкциям второй статьи, то этот каталог должен находиться в корневом каталоге вашего проекта, вместе с /src.) Не важно, куда вы положите этот каталог, однако его местоположение должна отражать строка в классе ToppingServiceImpl, определяющая JDBC URL Derby:

Я поместил БД Derby в каталог Tomcat webapps/slicr, на тот же уровень, что и каталог WEB-INF, и мой код выглядит следующим образом:

Определение серверных вызовов в файле web.xml

После того, как ваш код стал видимым для контейнера сервлетов Tomcat, вам надо определить все серверные вызовы GWT- приложения в понятных Web-серверу Tomcat терминах. Для этого надо определить эти вызовы в файле Tomcat web.xml как сервлеты. То есть, для каждого вашего сервлета, определенного в файле gwt.xml подобным образом:

вы должны создать в файле web.xml теги <servlet> и <servlet-mapping>. В листинге 3 приведен целиком необходимый для вашего проекта GWT файл web.xml, содержащий оба тега для вашего сервлета ToppngService.

                
<?xml version="1.0" encoding="UTF-8"?> 
<web-app> 
    <servlet> 
        <servlet-name>ToppingService</servlet-name> 
        <servlet-class>
            com.ibm.examples.server.ToppingServiceImpl
        </servlet-class> 
    </servlet> 
    <servlet-mapping> 
        <servlet-name>ToppingService</servlet-name> 
        <url-pattern>/toppings</url-pattern> 
    </servlet-mapping> 
</web-app>    

В файле web.xml два фрагмента информации из файла gwt.xml размещены в двух разных тегах в соответствии с концепцией "давайте-сделаем-в-Java-все-настолько-вербальным—насколько-это-возможно". В теге <servlet> содержится полное имя класса сервлета, а в теге <servlet-mapping> - путь URL, определенный вами в файле GWT. Теги объединены атрибутом servlet-name, в качестве которого вы можете использовать какое любое имя, лишь бы оно было одинаковым для обоих тегов. Однако лучше всего создавать простые и понятные имена, такие как GWT-имя сервиса.

Такой файл, само собой, может быть автоматически создан множеством разных способов, начиная с манипуляций с текстом и заканчивая использованием объектной модели XML Document Object Model (DOM). Создав этот файл, поместите его в каталог Tomcat WEB-INF. Развертывание Slicr завершено, и вы можете приступать к тестированию, запустив Tomcat и набрав адрес URL, который будет похож на http://localhost:8080/slicr/Slicr.html. Если все сделано правильно то вы, совсем как в конце третьей статьи, увидите страницу Slicr.

Проблемы при развертывании

После того, как я подробно описал весь процесс, вы видите, что хотя в нем и много шагов, все они простые. Я рекомендую максимально автоматизировать данный процесс с помощью сценариев, задач Ant или любых других пригодных в данном случае средств. Один пример подобной автоматизации вы найдете в разделе Ресурсы и, кроме того, в различных средах Java-разработки начинает появляться поддержка GWT, в том числе и развертывания. Если развертывание будет осуществляться нажатием одной кнопки, головной боли станет намного меньше.

В начало

Впереди еще много интересного

Share this... Digg this story Post to del.icio.us Slashdot it!

Ресурсы

• Оригинал статьи Build an Ajax application using Google Web Toolkit, Apache Derby, and Eclipse, Part 4: Deployment (EN).
  
  
• Посетите форум Google Groups о GWT.
  
  
• Обратите внимание на официальный блог GWT .
  
  
• Посетите сайт Apache Derby (EN), где вы найдете ресурсы для Derby.
  
  
• В разделе проекта Apache Derby (EN) на developerWorks вы найдете статьи, руководства и прочие ресурсы, которые помогут вам немедленно начать работу с Derby.
  
  
• Узнайте больше о БД IBM® Cloudscape™ (EN), которая создана на основе кода Apache Derby.
  
  
• Посетите раздел Open Source на developerWorks, где вы найдете полные ответы на конкретные вопросы, инструменты и обновления для проектов, которые помогут вам использовать технологии с открытым кодом, совмещая их с продуктами от IBM.
  
  
• Книги на эту и другие технические темы вы найдете в книжном магазине Safari (EN).
  
  
• Семинары и обучение на developerWorks.
  
  

• Загрузите Google Web Toolkit.
  
  
• Добавьте в ваш новый проект с открытым кодом инновации от пробного ПО от IBM , которое можно загрузить с сайта, либо заказать на DVD.
  
  
• Загрузите Tomcat.
  
  
• "Google Web Toolkit" содержит примеры файлов Ant для автоматизации многих описанных в данной статье задач.

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

Об авторе

		Ноэл Рэппин (Noel Rappin) имеет степень доктор философии по графике, визуализации и используемости от Georgia Institute of Technology. Он работает старшим инженером-программистом в Motorola, Inc. Является соавтором книг " wxPython в действии " (Manning Publications, март 2006) и " Основные элементы Jython " (O'Reilly, март 2002).

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

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

В начало