По “долгу службы” довелось пощупать интересную технологию, до которой раньше не доходили руки. Думаю, Google App Engine будет интересен не только мне, поэтому начинаю мини-цикл статей о разработке для App Engine. 

После того, как вы впервые войдёте в сервис appengine, вам нужно будет подтвердить свою “личность”. Google вышлет на номер указанного вами телефона SMS с текстом вроде Google App Engine Code: 1234567. Лично мне SMSка дошла меньше чем за минуту (такой способ куда лучше бумажной почты, которую Google использует для Adsense). Такая проверка проводится только для первого создаваемого приложения.

Следующий шаг – зарегистрировать имя-идентификатор для приложения.

Теперь регистрация окончена, приступаем к разработке. App Engine работает на Java 6 и именно эта платформа является рекомендуемой, хоть и Java 5 тоже поддерживается. Я навскидку не смог придумать, что может пойти не так, если приложение скомпилированное на Java 5 запустить на JVM шестой версии, но Google’у виднее.

Скачиваем и распаковываем Google App Engine SDK для Java http://code.google.com/appengine/downloads.html.

Теперь дело за малым – написать простое приложение и отправить на сервер :-)

Тут Google оставил меня без материала для заметки, поскольку минимальный Hello World уже есть в комплекте SDK. Хранится он в папке demos\new_project_template. Тут есть и build.xml и статический контент, и сервлет и даже пара файлов с конфигурацией для самых распространённых logging API: Log4J и JUL (java.util.logging). Скопировав содержимое в папку, где будет жить ваш проект, вы получите отличный каркасс для начала разработки. Единственное, что нужно теперь сделать – указать путь к развёрнутому SDK: либо в параметрах при запуске ant либо прямо в build.xml.

Перед тем, как запустить приложение на локальном “эмуляторе” appengine, давайте посмотрим, что ещё есть в “комплекте”. Кроме стандартного web.xml в WEB-INF лежит файл appengine-web.xml – дополнительная конфигурация для движка appengine:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
 <!-- Replace this with your application id
    from http://appengine.google.com -->
 <application>juriytest</application>
 <version>1</version>
</appengine-web-app>

Как и следует из комментария, в теге application нужно указать id приложения, котрый был зарегистрирован на appengine.

Кроме того в src/META-INF находится файл jdoconfig.xml, который является (неожиданно) конфигурацией для JDO – persistance механизма, который используется в среде appengine. Сейчас его трогать не будем, пускай живёт, hello world и без него запустится.
В проекте есть файл index.html, как пример статичного контента и HelloAppEngineServlet.java, который является привычным сервлетом без экзотики.

Чтобы запустить приложение локально выполняем ant runserver из корня тестового проекта.
Для того, чтобы “доставить” приложение на живую платформу нужно использовать утилиту из SDK: bin\appcfg.cmd

appcfg.cmd update www

www тут – путь к “развёрнутому” проекту. Appengine не поддерживает war файлы, а вместо этого работает с директориями с той же структурой. После того, как build.xml собрал для нас проект в папку www указанной выше командой можно загрузить его на appengine.

Пара полезных моментов и “граблей”.

App Engine сохраняет всё что вы напишите в System.out и System.err в логи. При этом e.printStackTrace в логи упорно не попадает. Немного сбивает с толку.

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

Последние грабли стоили жизни моим нервным клеткам. В конфиге appengine указывается версия проекта. Не надейтесь, что если будет указана версия выше текущей развёрнутой, то новая версия заменит старую. Всё обстоит совершенно не так. Новая версия затирает развёрнутую версию с таким же индексом. Затем, пользователь выбирает, какая из версий будет доступна по умолчанию. То есть, я могу развернуть версии 1, 2, 3. После разворачивания версии 3, пользователи видели только версию 1, пока в интерфейсе администратора не будет указана другая.

На этом пока что всё. В следующей заметке опишу, как заставить app engine работать с groovy.

__________
Спонсор заметки: “Идеал”, раскрутка сайта в Украине

public class A {

	public static void main(String[] args) {
		System.out.println("This is wrong");
	}

	public static void main(String[] args) {
		System.out.println("This is right");
	}
}

2. Написать стандартный Hello World на Java. При этом нельзя использовать ни одной точки с запятой. Закодированные UTF символы тоже использовать нельзя.

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

P.S. За мной уже закрепилась слава человека, обожающего абсолютно бесполезные, с практической точки зрения, задачи. Я пришел к выводу, что для таких “упражнений” слово “задача” совсем не подходит. Все привыкли, что “задачи” это упражнения, которые развивают какие-то практические навыки. К примеру “реализовать генератор случайных чисел на Java” это задачка. А для того, что публикую я, лучше подходит слово “загадка”. Так что вот вам свежая “без окон без дверей полна горница людей”.

Создаем файл /etc/init.d/tomcat такого содержания:

# Tomcat auto-start
#
# chkconfig: - 90 15
# description: Jakarta Tomcat Java Servlets and JSP server

export JAVA_HOME=/usr/java/default
export JRE_HOME=/usr/java/latest
export CATALINA_HOME=/home/vadim/tomcat

case $1 in
start)
  sh $CATALINA_HOME/bin/startup.sh
  ;;
stop)
  sh $CATALINA_HOME/bin/shutdown.sh
  ;;
restart)
  sh $CATALINA_HOME/bin/shutdown.sh
  sh $CATALINA_HOME/bin/startup.sh
  ;;
*)
  echo "Usage: $0  {start|stop|restart}"
  exit 1
  ;;
esac
exit 0

После этого выполняем:
chmod +x /etc/init.d/tomcat
chkconfig tomcat on

Аналогичный init.d-скрипт для запуска nginx

Как сообщает в корпоративном блоге SpringSource Guillaume Laforge (project-manager проекта Groovy), последние несколько недель они работали совместно с командой Google App Engine над “правильным” запуском Groovy на GAE.

Совмесная работа вылилась в набор дополнений в реализацию security-модели Groovy.

Небольшая заметка о том, как запустить Groovy приложение в среде Google App Engine от того же Guillaume Laforge.

P.S. Что-то мне подсказывает что теперь GAE перестанет быть игрушкой для питонистов, а станет упрощенной версией Amazon AWS, тем самым накорню убив остальные Java in Cloud – сервисы а-ля Stax.

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

Недавно я задался вопросом, как организовать загрузку апплета на странице так, чтобы пользователь не увидел экрана загрузки. Вместо него я бы хотел, к примеру, разместить логотип и progress bar (не настоящий, а просто картинку, которая показывает, что процесс идет). Второе обязательное требование: чтобы приложение отображалось, как только GUI прорисован. Мы не хотим заставлять пользователя ждать лишнее время.

Перечитав комментарии http://voituk.kiev.ua/2008/05/28/java-deployment-toolkit/ я решил не использовать стандартный JavaScript от Sun. Я воспользовался альтернативой – скриптом из классного, но не очень известного проекта PulpCore. Этому проекту можно было бы посвятить отдельную заметку, отличная разработка заслуживающая более пристального внимания. После небольшой “доводки напильником” вышло отличное решение, которое я протестировал на тех браузерах, что были у меня под рукой.

Кроме “сокрытия” экрана загрузки, скрипт умеет определять версию JRE (как и аналог от Sun), делать “отложенную загрузку”: апплет загружается после того, как пользователь нажмет на кнопку.

Принцип работы скрипта прост: он определяет браузер и версию Java плагина, генерирует текст HTML элемента, который загружает апплет и отображает сплеш-скрин поверх него. Пользователь видит “правильный” сплеш, а не стандартный экран загрузки Java. Если же версия Java не подходит, отображается сообщение предлагающее пользователю решить эту проблему.

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

Вот пример кода, который отобразит апплет на странице:

	<script type="text/javascript"><!--
		pulpcore_width = 500;
		pulpcore_height = 300;
		pulpcore_archive = "applet-17.jar";
		pulpcore_class = "TestApplet.class";
	//-->
	</script> 

	<div id="game">
		<script type="text/javascript" src="loader.js"></script>
		<noscript><p>To play, enable JavaScript from the Options or Preferences menu.</p></noscript>
	</div>

Примеры скрипта в действии можно посмотреть на сайте проекта PulpCore.

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

На выходных я решил реализовать такое подключение из Java-апплета к серверу. Я хотел, чтобы _оба_ канала (и канал для запросов и канал для ответов) были постоянно открыты. Таким образом задержка передачи сообщений была бы идентична задержке TCP/IP подключения.

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

Вот классический код POST запроса к серверу. Уверен, каждый хоть раз да писал такой:

URL url = new URL("http://somehost.com:8080/do");
URLConnection conn = url.openConnection();
conn.setDoOutput(true);
OutputStream out = conn.getOutputStream();
out.write(data);
out.flush();

InputStream is = conn.getInputStream();
processOutput(is)
out.close();
is.close();

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

URL url = new URL("http://myserver:8080/do");
URLConnection conn = url.openConnection();
conn.setDoOutput(true);
OutputStream out = conn.getOutputStream();

while (работаем) {
	data = // получить данные из очереди, или спать, если очередь пуста
	out.write(data);	

	// Вот это нельзя забыть, а то вдруг данные закешируются :-)
	out.flush();
}

Каково же было мое удивление, когда я понял, что такой код вообще ничего не отправляет! Оказалось, что URLConnection кеширует на клиенте _все_ данные до момента отправки. Самое грустное в этой истории то, что отключить этот “функционал” изысками вроде setUseCaches(false) не выходит.

Неприятное следствие, которое я подтвердил экспериментом. При попытке передать через POST файл, вы элементарно можете получить Error, если размер файла больше оставшегося места в heap. Ведь все содержимое файла будет вначале сохранено в памяти.

Способа полностью обойти эту коварную особенность, похоже, нет. Прелесть URLConnection’а заключается в том, что он позволяет неявно использовать настройки прокси пользователя. То есть, он идеален для апплетов: нет необходимости подписывать апплет, нет необходимости просить пользователя: “выбирите прокси, его тип, введите логин и пароль”. Большинство конечных пользователей просто закроют окно, появись такой диалог на экране.

Если прокси не является проблемой, можно использовать HTTPClient или написать “мини HTTP” используя “чистый” сокет, как показал Rex Young:

URI uri = new URI("http://localhost:8080/FullDuplexHttp/");
Socket socket = new Socket(uri.getHost(), uri.getPort());
OutputStream out = socket.getOutputStream();
out.write(("POST " + path + " HTTP/1.1\r\n").getBytes());
out.write("User-Agent: FullDuplexHttp\r\n".getBytes());
out.write(("Host: " + host + ":" + port + "\r\n").getBytes());
out.write("Transfer-Encoding: chunked\r\n".getBytes());
out.write("\r\n".getBytes());

// Теперь можно отправлять данные

Или же использовать пул открытых подключений к серверу и использовать одно подключение для отправки одного сообщения. IMHO этот вариант легко убьет сервер количеством бесполезных соединений.

Вот полезные ссылки по теме для интересующихся:
http://www.innovation.ch/java/HTTPClient/fullduplex.html – описание области проблемы и вариантов рещения – довольно интересное чтиво.
http://weblogs.java.net/blog/rexyoung/archive/2008/09/turn_a_http_con_1.html – блог Rex Young, который реализовал этот функционал, используя сокеты и chunked transfer encoding.

Сегодня убил некоторое время, отлавливая мерзкий баг. Баг был наглядно продемонстрирован юнит тестом, который, помимо всего прочего, проверял два объекта на эквивалентность. Сами объекты – простые java-бины с парой полей – одно типа int, второе типа String[][]. Код для equals и hashCode поручил сгенерировать eclipse’у. Подвох оказался в том, что метод equals попросту не работал – он всегда возвращал false. При детальном рассмотрении проблема нашлась:

if (!Arrays.equals(fieldTwo, other.fieldTwo))
	return false;

Все ведь просто, Arrays.equals сравнивает типы массива и количество элементов в каждом из них. Затем проверяет эквивалентность поэлементно. Первые две проверки проходят, а вот третья проваливается с треском. Ведь никакие два объекта-массива в java не эквиваленты:

System.out.println(new int[]{1}.equals(new int[]{1})) // Выведет false.

Для проверки эквивалентности многомерных массивов нужно использовать метод deepEquals, который, кстати, находится в том же классе Arrays.

Ради интереса я попробовал сгенерировать код equals и hashCode в IntelliJ IDEA. Idea отказалась учитывать многомерный массив при создании кода equals. По крайней мере, это честнее, чем создавать нерабочий код.

Учитывайте эти грабли, когда в следующий раз будете нажимать кнопочку кодогенератора.

Речь идет о компании Stax Networks, 16 декабря уходящего года запустившей под лозунгом “Java applications in the cloud” свой аналог Google App Engine для Java-разработчиков, который предоставляет завершенную инфраструктуру для разработки, тестирования и развертывания масштабируемых Java WEB-приложений.

Технически решение Stax построено поверх Amazon EC2 и позволяет создавать приложения основанные Servlets/JSP, Struts, GWT, Wicket, JRuby, Jython, Flex, ColdFusion.
В качестве СУБД в данный момент поддерживается только MySQL.

Инфраструктура Stax построена так, чтоб разработчику на этапе написания кода не нужно было думать о том, что находится на уроверь ниже чем Stax.
Управление приложениями и базами данных производится через удобную web-консоль, а локальная разработка и отладка производится привычными методами (я использовал для этого Eclipse и консольную утилиту stax).

Чем ещё интересен данный стартап – так это то, что в данный момент они не взымают плату за использование, аргументируя это тем, что вырабатываю правильную бизнесс-модель.
В итоге попробовать Stax в действии, в отличии от аналогов, можно абсолютно бесплатно и даже не имея кредитной карты.

Что я собственно уже и сделал: написал небольшое приложение, которое выводит список контактов из БД и запустил его в cloud-е на 2х серверах.
Под заголовком “Running Java in Cloud” можно увидеть IP и имя сервера в cloud-e, который обслуживает текущий запрос. И если понажимать F5 – можно заметить, что серверов всего-то 2.

В принципе идея предоставления Platform-as-a-Service (PaaS) далеко не новая, но более или менее популярных решений для Java мне пока не встречалось.

Аналогичные разработки:

• Google App Engine (GAE) – самый известный из подобных app-хостингов.
  Пока поддерживает только Python и хранение данных в нереляционной БД Google BigTable.
• Microsoft Azure – аналогичный GAE сервис от Microsoft. Поддерживает .NET языки.
• Salesforce.com – CRM-хостинг для приложений написанных на проприетарном языке Apex
• Heroku – аналог Stax, построенный на Amazon EC2, но для RubyOnRails приложений
• 10Gen – ещё одна платформа, поддерживающая Python, Ruby и ServerSide JavaScript, а также обьекную СУБД Mongo.

P.S. В комплекте со Stax SDK идет Groovy древней версии 1.5.6

Вариантов, как встроить в свое приложение небольшой HTTP-сервер уйма –
начиная от аскетичного и сложно-развиваемого 10-ти строчного HTTP-сервера на Groovy, заканчивая интеграцией в приложение небольшого сервлет-контейнера Jetty.

Я же хочу предложить что-то среднее между этими двумя вариантами.
Начиная с 6й версии, в составе JRE поставляется пакет “com.sun.net.httpserver”, который содержит реализацию достаточно производительного и гибкого HTTP-сервера, построенного на асинхронной технологии NIO.

С его использованием код самого простого HTTP-сервера умещается в 30 строк Java-кода:

import java.io.IOException;
import java.io.PrintWriter;
import java.net.InetSocketAddress;
import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import com.sun.net.httpserver.HttpServer;

public class HttpServerEx implements HttpHandler {

	public static void main(String[] args) throws IOException {
		HttpServer server = HttpServer.create(new InetSocketAddress(80), 10);
		server.createContext("/", new HttpServerEx());
		server.start();
		System.out.println("Server started\nPress any key to stop...");
		System.in.read();
		server.stop(0);
		System.out.println("Server stoped");
	}

	@Override
	public void handle(HttpExchange exc) throws IOException {
		exc.sendResponseHeaders(200, 0);
		PrintWriter out = new PrintWriter(exc.getResponseBody());
		out.println( "Hello moto!" );
		out.close();
		exc.close();
	}

}

Теперь, думаю, никому не составит труда расширить метод handle() под свои нужды.

Более подробную документацию можно найти тут: Javadoc пакета “Java™ HTTP Server”

К сожалению исходный код пакета доступен только как часть Standard Edition Development Kit Source Release под Java Research License, что вынуждает немного “попотеть” чтоб его добыть.

P.S. За наводку спасибо Dmitriy Kopylenko и его ссылке на реализацию подобного HTTP-сервера на Scala.

Эта заметка посвящена ежегодному событию, которое проходит по инициативе www.javagaming.org – состязанию Java 4k. Правила очень простые – необходимо сделать интересную игру на Java, так чтобы размер архива (jar) с игрой (и всеми ресурсами) не привышал 4 килобайта. Трюки вроде “напишу-ка я на 4 кб загрузчик, который подтянет с сайта мой 50-мегабайтный движок” не проходят.
Естественный вопрос: “что, черт побери, можно написать на 4 килобайта?”. Чтобы на него ответить достаточно взглянуть на игрушки прошлых лет:

Победитель прошлого года, простая, но интересная аркада:

	Spiderball4k
	А эта игра потрясет любого: изометрическая Real-Time стратегия, где есть разные юниты, можно строить здания, добывать ресурсы и воевать с AI! Комментарий к этой работе с форума javagaming выражает основную мысль как нельзя лучше: “Hey, where did you put other 100k?!” T4anks

Есть еще множество интересных игр. В этом году я думаю присоединиться к соревнованию. Надеюсь, времени хватит.