Преобразуем XML в JSON с помощью XStream

Иногда возникает задача преобразовать существующий XML-документ в эквивалентное ему JSON-представление. Например, такая задача может возникнуть, если вы разрабатываете AJAX-интерфейс к существующей системе, которая генерирует XML. Дело в том, что из JavaScript гораздо проще оперировать объектами, представленными в формате JSON, нежели XML, просто потому что первый формат - нативный.

Так вот, быстро преобразовать XML в JSON можно с помощью замечательной библиотеки XStream, подробное введение в которую опубликовано в статье xstream - сериализуем Java-класс в XML. В состав данной библиотеки входит драйвер JettisonMappedXmlDriver, отвечающий за быстрое преобразование XML -> JSON. Порядок преобразования следующий:

Когда система тормозит...

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

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

ECF: Взаимодействуем с Twitter с помощью REST API и XStream

Продолжаем беседу об Eclipse Communication Framework. Сегодня мы рассмотрим, как использовать появившийся в версии 3.1 REST API на примере взаимодействия с наиболее популярным сервисом микроблогов - с Twitter.

Поддержка REST была добавлена в ECF этой осенью горячим немецким парнем по имени Holger Staudacher в рамках Google Summer of Code (который я, кстати, считаю гораздо более полезным, нежели Imagine Cup от небезызвестной корпорации). Реализация данной функциональности представленна контейнером ecf.rest.client и базируется на Remote services API.

ECF: Пишем Jabber-бота с использованием Habra API

Сегодня Суровый челябинский программист хочет поделиться исключительно Just for fun'ом, а именно - рассказом о том, как легко и непринужденно написать Jabber-бота с использованием Bot Framework. Наш бот будет принимать команды вида ~karma %username% и воозвращать соответствующую информацию о хабражителе с указанным именем. Для получения данной информации используется Habra API.

Сначала поговорим о содержательной части задачи. Habra API предоставляет возможность получать с помощью GET-запросов по определенному урлу (заданному в формате http://habrahabr.ru/api/profile/%username%) XML-документ с информацией о пользователе или об ошибке, если, например, такой пользователь не зарегистрирован в системе. Понятно, что хотелось бы большего, в частности - получать информацию о месторасположении пользователя или его интересах, а также иметь возможность вытягивать посты целиком или даже публиковать информацию через API. Надеюсь, что хотя бы часть из этого хаброавторы сделают, пока же мы имеем то, что имеем.

Теперь, что касается Bot framework. Данный фреймворк представлен бандлом org.eclipse.ecf.presence.bot и позволяет писать ботов, работающих с поддерживаемыми ECF Messenger-ами (например, Jabber, Skype, Yahoo) и т.н. ChatRoom-ботов, т.е. роботов для IRC-каналов и/или Jabber-конференций. Включает в себя четыре точки расширения, позволяющие регистрировать роботов и обработчики команд. Рассмотрим их подробнее:

Небольшое введение в механизм точек расширения Eclipse

Здравствуйте, уважаемые читатели. Суровый челябинский программист вернулся из земли Египетской, акклиматизировался и готов порадовать вас новой статьей (хотя, конечно, переход от +28 к - 20 это жестоко).

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

Суть заключается в следующем: в корне плагина находится файл plugin.xml, в котором содержатся объявления точек расширения (тег extension-point) - элементов описывающих те места системы, которые можно расширять. В платформе Eclipse RCP определены точки расширения для регистрации своих адаптеров, видов, перспектив, пунктов меню, кнопочек на панели быстрого запуска и т.д. и т.п.

Точка расширения характеризуется уникальным идентификатором (атрибут id, который обычно задают, придерживаясь доменной модели, как и java-пакеты; именем (атрибут name), служащим больше для удобства программиста, и схемой (атрибут scheme) - путем к exsd-файлу, который содержит XScheme, описывающую формат расширения.

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

ECF: Распределенная обработка событий

Продолжаем разговор. Нынешняя заметка будет посвящена проблеме организации распределенной обработки событий с помощью механизмов, которые предоставляет Eclipse Communication Framework.

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

Вся обработка событий в OSGi базируется на интерфейсе EventAdmin. ECF предлагает свою реализацию этого интерфейса - класс DistributedEventAdmin, который расположен в бандле org.eclipse.ecf.remoteservice.eventadmin. К сожалению, данный бандл не входит в поставку ECF 3.0/3.1, поэтому его придется взять на CVS-сервере: pserver://dev.eclipse.org//cvsroot/rt в каталоге org.eclipse.ecf/server-side/bundles/org.eclipse.ecf.remoteservice.eventadmin.

Работает этот механизм так: DistributedEventAdmin представляет собой SharedObject. Как мы уже говорили, такие объекты копируются между ECF-контейнерами и могут обмениваться сообщениями. Соответственно, все вызовы sendEvent и postEvent - это отправка сообщений между репликами объекта DistributedEventAdmin (синхронная и асинхронная, соответственно).

ECF: Средства для взаимодействия команды разработчиков с помощью Eclipse

Мы уже успели поговорить и о том, что такое Eclipse Communication Framework, и о том, как программировать с его помощью. Сегодня рассмотрим графические средства, которые ECF предоставляет для Eclipse (и, соответственно, RCP-приложений).

Под графическими средствами подразумевается перспектива Communications и виды, которые представлены в группах Communications и File Transfer. Прежде всего эти компоненты GUI обеспечивают возможность взаимодействия разработчиков, использующих Eclipse между собой в команде. Однако, обо всем по-порядку.

ECF: Распределяем объекты между OSGi-фреймворками

Сегодня мы рассмотрим еще одну замечательную возможность, которую предоставляет нам Eclipse Communication Framework - обмен копиями объектов между бандлами, запущенными на разных экземплярах OSGi-фреймворка (т.е. на разных JVM), реализованную в виде SharedObject API. Данный механизм основан на понятии "репликация", суть которого применительно к ECF следующая: в контейнер добавляется экземпляр класса, реализующего интерфейс ISharedObject, который становится доступен всем другим контейнерам, подключенным к тому же серверу, что и донор. Фактически, в каждом клиентском контейнере создаются копии исходного объекта, которые называются репликами.

Прежде всего разберемся непосредственно с распределяемым объектом. В ECF реализован базовый класс BaseSharedObject, который содержит реализацию многих полезных возможностей, таких как идентификация, управление конфигурацией, логгирование, отправка и прием сообщений. Рекомендуется все свои распределяемые объекты наследовать от данного класса.

Наиболее интересными для нас методами являются BaseSharedObject#initialize(), описывающий стратегию репликации главного объекта (т.е. того объекта, который собственно копируется, для него метод BaseSharedObject#isPrimary() вернет true) и стратегию десериализации реплик из словаря свойств, и BaseSharedObject#getReplicaDescription(ID receiver), задающий порядок сериализации реплицируемого объекта в словарь свойств. Словарь свойств - это объект класса, реализующего Map<String, Serializable>. ECF умеет передавать объекты между контейнерами только в таком виде. Чем-то данный механизм напоминает словарь свойств события, которым оперирует EventAdmin. Данный механизм предоставляет программисту возможность наиболее гибко управлять процессом репликации своего объекта (например, определять какие поля не нужно копировать вовсе).

Стоит обратить внимание, что каждое реплицируемое поле класса должно иметь тип, реализующий интерфейс Serializable. Дело в том, что для сериализации полей класса ECF использует стандартные средства Java-платформы.

ECF: Обмен данными между бандлами с помощью DataShare API

Проголосуйте за ролик первой Российской команды, принявшей участие в конкурсе Imagine Cup Digital Media.

Суровый челябинский программист снова с вами и сегодня мы поговорим об ином аспекте взаимодействия бандлов нежели вызов сервисов - об обмене сообщениями. Под сообщением в данном случае подразумевается произвольный поток байт. Для обеспечения такого взаимодействия в состав ECF входит DataShare API.

Суть использования данного API заключается в том, что каждый контейнер может создавать сколь угодно много каналов. Каналы с одинаковыми ID являются связанными и по ним осуществляется асинхронный обмен сообщениями. Асинхронность в данном случае обозначает, что контейнер при создании канала регистрирует для этого канала листенер. При получении сообщений от других контейнеров данный листенер срабатывает. Все свободное от обработки сообщений время контейнер может заниматься своими делами.

ECF: Используем Remote Services API

При знакомстве с Eclipse Communication Framework'ом мы отметили, что некоторые его контейнеры поддерживают несколько разнородных API. В частности, R-OSGi и Generiс контейнеры, а так же появившийся в недавно вышедшем ECF 3.1 REST контейнер, поддерживают API вызова удаленных сервисов, т.н. Remote Services API.

Давайте поговорим о том, что можно делать с помощью данного API, а затем о том, как его использовать.

ECF Remote Services API это еще один (наряду с R-OSGi) способ обеспечения работы бандлов в распределенной среде. Точно так же одни бандлы могут выставлять сервисы, доступные другим бандлам на другой JVM (и, естественно, даже на другой машине). Отличие от R-OSGi в том, что данная система, во-первых, не стандартизирована (т.е. это не OSGi подсистема, а часть непосредственно ECF), а, во-вторых, - более гибка, т.к. можно явно указывать, где находятся бандлы, выставляющие сервисы, (т.е. отпадает необходимость в процедуре поиска сервисов) и использовать для обеспечения взаимодействия различные протоколы и реализации (ECF Generic, Active MQ, Weblogic, JavaGroups и даже XMPP).

IAdaptable - одно из основных понятий Eclipse Core

Как я и обещал, постепенно от введения в OSGi мы переходим в сторону рассмотрения непосредственно Eclipse Platform. Впрочем, об Eclipse Rich Client Platform (или даже Eclipse Rich Ajax Platform) речь пока не идет, пока будем знакомиться только с Eclipse Core. Дело в том, что для последующего рассмотрения возможностей того же Eclipse Communication Framework, невозможно оставаться только в рамках платформы OSGi.

Впрочем, это еще не значит, что я не буду больше писать про OSGi вообще (в том числе и про Equinox, как одну из реализаций OSGi).

Давайте, прежде чем перейти к рассмотрению IAdaptable, скажем пару слов об Eclipse Core (в дальнейшем я иногда буду называть его Ядром).

Ядро состоит из следующих основных бандлов:

org.eclipse.core.contenttype - поддерживает определение и управление типами файлового контента (в частности - MIME-типами).

org.eclipse.core.expression - содержит реализацию основанного на XML языка выражений, который используется для декларативного определения точек расширения.

org.eclipse.core.filesystem - общее API работы с файловой системой.

org.eclipse.core.jobs - обеспечивает инфраструктуру параллельного исполнения кода для Eclipse

org.eclipse.core.resource - содержит средства управления ресурсами: проектами, каталогами и файлами.

org.eclipse.core.runtime - обеспечивает основанный на Equinox рантайм для работы всех остальных бандлов и приложений. Является сердцем Eclipse Core.

Так же к Ядру можно отнести org.eclipse.equinox.registry - определяет так называемый реестр точек расширения. Точки расширения - специальные записи на XML-подобном языке, определяющие механизм взаимодействия бандлов. Используются еще с тех пор, когда Eclipse не был основан на OSGi. Как-нибудь поговорим о точках расширения подробнее.

Теперь можно перейти непосредственно к разговору об IAdaptable, определенному в бандле org.eclipse.core.runtime и являющемуся одним из краеугольных механизмов всей платформы.

ECF: Разбираемся с R-OSGi

В недавно вышедшей спецификации OSGi 4.2 декларировано такое новшество, как удаленные сервисы известные ранее, как Distributed OSGi или RFC 119. Давайте рассмотрим эту технологию, применительно к Eclipse Equinox.

RFC 119 реализуется в рамках Equinox с помощью контейнера ecf.r_osgi.peer, реализующего API удаленных сервисов. Для простоты будем рассматривать две Java-машины, на каждой из которых будет запускаться OSGi, причем ту машину, на которой выставляется сервис, назовем хостовой (host), а ту, на которой сервис будет использоваться - клиентской (client).

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

Алгоритм выставления сервиса:

1. Получить экземпляр IContainerManager - сервиса.

2. С помощью полученного ContainerManager создать новый контейнер типа ecf.r_osgi.peer

3. Зарегистрировать свой сервис, установив ему свойство osgi.remote.interfaces, равным * (данные константы определены в интерфейсе IDistributionConstants, как REMOTE_INTERFACES и REMOTE_INTERFACES_WILDCARD, соответственно). Именно это свойство говорит OSGi-платформе о том, что нужно разрешить удаленное использование сервиса.

Алгоритм подключения к сервису:

1. Получить экземпляр IContainerManager - сервиса.

2. С помощью полученного ContainerManager создать новый контейнер типа ecf.r_osgi.peer

3. Создать новый ServiceTracker, задав фильтр, под который попадает удаленный сервис. Согласно спецификации RFC 119 фильтр должен включать условие (" + REMOTE + "=*), где REMOTE - соответствующая константа, определенная в IDistributionConstants.

4. Открыть созданный ServiceTracker и работать с ним так же, как и при использовании обычного сервиса.

Давайте теперь перейдем к рассмотрению примера.

Знакомимся с Eclipse Communication Framework

Как я уже неоднократно говорил, неправильно считать, что Eclipse - это только IDE. Eclipse Foundation разрабатывают прежде всего качественную платформу для построения самых разных приложений. Основным компонентом платформы является Equinox - реализация спецификации OSGi R4. На базе Equinox строятся другие компоненты, такие, как, например, Eclipse Communication Framework, о котором мы сегодня и поговорим.

Не секрет, что большинство создаваемых сегодня приложений работают в сетевой среде. Особенно это характерно для т.н. Enterprise-приложений, для разработки которых в основном Java и используется. Естественно, что такие приложения нуждаются в средствах взаимодействия с локальной сетью и/или Интернетом. Писать такое взаимодействие самому довольно утомительно, поэтому для создания программ, основанных на OSGi (в частности - Eclipse RCP - приложений), был разработан ECF.

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

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

Единый API позволяет не беспокоиться о том, что у нас находиться "на другой стороне" - в случае изменения протокола мы просто меняем создаваемый контейнер, остальной код (в идеале, конечно) менять не требуется. Вторым плюсом такой унификации является легкий переход от одной технологии (например, Apache ActiveMQ, представленный в той же IBM WebSphere) к другой (например, Weblogic от Oracle).

Что касается использования ECF в чисто OSGi-среде, то именно он содержит реализацию Distributed OSGi (RFC 119) для Equinox. Но давайте познакомимся с фреймворком поближе.

Модульная Java, что это?

Позволю себе привести свой перевод статьи Modular Java: What Is It?. Это мой первый более-менее крупный перевод, поэтому иногда наблюдаются отступления от канонического текста, но ногами все равно прошу не пинать.

В последние несколько лет модульность в Java является активно обсуждаемой темой. От (уже утратившего силу) JSR 277 через принятие JSR 291 и продолжаясь в JSR 294 модульность видится как необходимый этап в эволюции Java. Даже новые, основанные на Java языки (такие, как Scala), учитывают модульность. Данная статья, первая в серии о модульной Java, объясняет, что значит модульность и почему об этом нужно беспокоиться.

Вышла новая спецификация OSGi 4.2

Недавно OSGi Alliance выпустил версию 4.2 спецификации OSGi. Некоторые реализации уже частично совместимы с данной версией, например Equinox 3.5 и Apache Felix 2.0. Поэтому, я думаю, сейчас самое время рассмотреть, что нового нам предлагают.

Введение в OSGi. Взаимодействие бандлов. События.

Наконец-то я довольно успешно сдал вступительные экзамены в аспирантуру и появилось время поделиться со своими читателями чем-то новым. В частности - выполнить свое обещание и рассказать про работу с событиями в OSGi-платформе.

Начнем с того, что в спецификации OSGi R4 определены механизмы работы с событиями, такие, как источник события - EventAdmin, обработчик события - EventHandler и непосредственно само событие - Event. Разработка диспетчера событий ложится на плечи создателей конкретной реализации OSGi-платформы. Тем самым, мы, как пользователи платформы, получаем в свое распоряжение уже готовый мощный инструмент для обеспечения взаимодействия бандлов. Осталось только научиться с ним работать.

Событийная модель построения приложения

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

Большинство приложений в процессе своей работы постоянно реагируют на те или иные события. Это может быть щелчок пользователем по иконке, получение http-запроса, получение сигнала от датчика, завершение коммита транзакции и т.д. Реакция приложения проявляется в выполнении некоторых действий (отрисовка окна, отправка http-ответа, отправка сигнала исполнительному устройству, запуск BPEL-процесса и т.д.). Так вот, суть в том, что никто не мешает перенести такое поведение на уровень архитектуры приложения, т.е. организовав не только его внешнее поведение в соответствии с событийной моделью, но и внутреннее строение.

Кто работал с WinAPI или с Java Swing, тот должен быть хорошо знаком с такой моделью построения программы. В приложении есть некоторые агенты - события, которые генерируются в ответ на внешнее воздействие. Есть обработчики событий - код, который непосредственно делает что-то полезное. И есть то, что сводит гору и Магомета - диспетчер событий. Именно он вызывает те или иные обработчики в ответ на возникновение тех или иных событий.

Транзакции и обеспечение правильного порядка асинхронного взаимодействия

Пару слов об истории проблемы. Я - разработчик бизнес-процессов в компании Naumen. Как я уже писал, основная активность бизнес-процесса (BPEL-процесса) - вызов неких сервисов (чаще всего - веб-сервисов). Фактически задача BPEL-процесса сводится к тому, чтобы обеспечить необходимый порядок вызова необходимых сервисов. Впрочем, BPEL взят лишь для примера, мысли, изложенные далее, характерны для взаимодействия любых систем. Так вот, при взаимодействии приложения и бизнес-процесса, а так же бизнес-процесса и приложения, иногда возникают интересные коллизии, вызванные неправильной организацией взаимодействия. Именно об этом я и хочу сегодня поговорить.

Мысли по поводу Deadline

Выдалось немного свободного времени и я решил перечитать замечательную книгу по управлению проектами - Deadline от Тома Демарко.

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

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

Да, конечно, книга по управлению проектами, т.е. таргет-группа прежде всего менеджеры, однако разработчики вынесут для себя много полезной информации. Я для себя вынес следующее (в скобках - мои субъективные комментарии):

Вышел долгожданный релиз Eclipse Galileo

Свершилось! Eclipse Foundation точно по расписанию выпустили релиз Eclipse Galileo.



Вместе с IDE для Java-разработчиков выпущено еще 33 проекта: среды разработки для Ruby, PHP, C/С++, WEB (JavaScript + HTML + CSS), J2EE и т.д. Скачать новый Eclipse можно с официального сайта проекта. Почитать о нововведениях на разных языках можно здесь, а вот здесь лежит красивая обоина.

Я уже скачал и пользуюсь.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

Введение в SOA и BPEL

Уже более полугода я занимаюсь разработкой описаний бизнес-процессов на языке BPEL. За это время удалось кое в чем разобраться, кое что структурировать и осознать. Результатом стала данная статья, впервые опубликованная на HabraHabr. Теперь же я решил привести текст статьи в своем блоге с необходимыми изменениями.

Давайте начнем с понятия "Корпоративная Информационная Система (КИС)." Такая система, как правило, представляет собой набор программного обеспечения разной степени однородности. Т.е. в лучшем случае все необходимое ПО (для организации бухгалтерского, оперативного и складского учетов, документооборота, сервисных служб, call-центра) закупается у одного вендора, в худшем же — полный бардак (что-то по-быстрому набросали сисадмины, что-то купили у Майкрософт, что-то у Naumen, а что-то вообще у 1С).

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

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

Как подружить Hibernate со Spring и обеспечить управление транзакциями через @ннотации

На работе завершена большая и сложная задача и перед началом решения следующей хочется немного отвлечься и поделиться чем-нибудь с вами, уважаемые читатели. Сегодняшний пост будет из серии "для самых маленьких". Давайте поговорим о связке Spring-Hibernate, слое DAO и динамическом управлении транзакциями.

SpringFramework штука довольно сложная и интересная. В частности, в его состав входит package org.springframework.orm.hibernate3, который обеспечивает взаимодействие SpringFramework и Hibernate ORM.

Давайте создадим простое консольное приложение (чтобы не заморачиваться на определение сервлетов и прочего overhead'а), которое что-то пишет в БД.

25-й выпуск The Art of Programming: Введение в OSGi

Давненько я не писал в свой блог, все почивал на лаврах последней статьи. Однако, так жить нельзя, надо двигаться вперед - открывать новые горизонты и все такое. Поэтому я с радостью согласился на приглашение Gamussa и Golodnyj поучаствовать в записи 25-го, юбилейного выпуска подкаста The Art of Programming.

Поговорили довольно интересно и про жизнь, и про Naumen, и про OSGi. Брэнд Суровый челябинский программист становится все более известным в Интернете, что меня очень радует.

Сам подкаст The Art of Programming слушаю с первого выпуска. Мне показалось, что сначала был выбран не самый удачный формат для программистского подкаста: все же диктовать и объяснять код - не самая лучшая идея. Но, со временем, парни нашли свой формат. Получился очень интересный подкаст о Java, экосистеме Java, сопутствующих технологиях и в целом об IT. Также нравятся интервью, например, недавно парни брали интервью у Якова Сироткина - лидера российской JUG. По-моему, TAOP - единственный подкаст о Java на русском языке. Если я ошибаюсь - поправьте.

И конечно же - ссылки:
Golodnyj
gAmUssA

З.Ы. Так же подкаст опубликован на Хаброхабре и вы можете его там плюсовать. Помните! Плюсуя данный подкаст на Хаброхабре, вы помогаете получить инвайт какому-нибудь хорошему человеку.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

Установка и настройка MikTeX 2.7 + PsCyr

Моя первая статья по письмам читателей. Рубрика Верстаем диплом в LaTeX оказалась довольно актуальной, особенно сейчас, когда многие студенты во всю этим занимаются. Самым популярным LaTeX пакетом под Windows является MikTeX, но к сожалению, не все могут его себе установить и настроить. Поэтому, я решил написать об этом небольшую статью.

Инструкция так же актуальна с точностью до путей и для новой версии MikTeX 2.8

Знакомимся: Eclipse Orbit - каталог бандлов, содержащих библиотеки третьих лиц

Я думаю, пора немного отвлечься от теории работы с OSGi и написать о чем-нибудь практическом. Например, об Eclipse Orbit.

Eclipse Orbit - репозиторий бандлов, инкапсулирующих библиотеки сторонних (т.е. не эклипсовских) разработчиков и доступных для использования в Eclipse-проектах. Репозиторий поддерживает последние и вместе с тем старые версии библиотек. Все организовано таким образом, чтобы облегчать нам, разработчикам, сборку и пересборку проектов. Содержимое Orbit можно скачать или собрать из исходников.

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

Понятно, что библиотеки, как правило, зависят друг от друга, например Jetty нужен servlet-api. В Orbit и Jetty и servlet-api представлены отдельными бандлами. Это позволяет не помещать все зависимости в один бандл, ведь тот-же самый servlet-api нужен не только для Jetty. Единственное неудобство - при скачивании не понятно от каких бандлов завист нужный нам. Т.е. единственный способ посмотреть манифест бандла, в котором указана директива Import-Package и догадаться по наименованиям пакетов. Особо ценно здесь то, что имена бандлов в Orbit представлены как раз именем корневого пакета бандла (например, org.mozilla.javascript).

Собственно, это все, что я хотел рассказать об Orbit. Свои вопросы вы как всегда можете задавать в комментариях. Тему OSGi я забрасывать не планирую, ведь тут есть еще столько интересного. Одна разработка eclipse-плагинов чего стоит.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

З.Ы. Если Вы есть во Вконтакте - вступайте в группу Russian Eclipse Community.

Введение в OSGi. Пример использования декларативных сервисов

В прошлой заметке мы познакомились с парадигмой декларативных сервисов. Пришло время рассмотреть пример их использования. Напомню, что мы создали бандл org.beq.equinox.ds.intro, выставляющий сервис SampleRunnable, который умеет стартовать поток и печатать приветствие. Давайте создадим клиент для этого сервиса.

Клиент будет расширять консоль OSGi. Как это делается хорошо написано в статье Explore Eclipse's OSGi console. Если говорить коротко: необходимо реализовать CommandProvider в методе getHelp() описать справочную строку, а в методах _команда - определить логику команд. Т.е. идея такая: мы напишем бандл, который предоставляет сервис, реализующий CommandProvider. В свою очередь данный сервис использует сервис SampleRunnable из бандла org.beq.equinox.ds.intro. Все сервисы будут декларативными.

Введение в OSGi. Декларативные сервисы - первое знакомство

Суровый челябинский программист вновь вышел на тропу войны. В WindowMaker запущена Opera, рядом mpd+sonata играет музло, но самое главное - запущен Eclipse, что как бы намекает. Намекает на то, что пришла пора рассказать читателям про замечательную вещь - декларативные сервисы в OSGi.

Понятно, что прежде чем один бандл будет использовать сервис, другой бандл должен его выставить. Чтобы сервис выставить, бандлу необходимо стартовать - т.е. перейти в состояние ACTIVE. Но зависимости между бандлами могут быть очень сложными (а самое худшее - циклическими), что приводит к очевидным проблемам. Для решения этих проблем некто Humberto Cervantes вместе с Richard Hall написали утилиту под названием Service Binder, которая и предназначалась для автоматического разрешения зависимостей между бандлами. Впоследствии данная утилита развилась в то, что называется Declarative Services (DS). Сами DS являются частью стандарта OSGi 4.0 и выше.

Введение в OSGi. Динамический ServiceTracker. Две стратегии использования сервисов.

В Челябинске опять прекрасная погода, а как там на Брайтон-Бич я не знаю. Суровый челябинский программист снова с вами и мы продолжаем знакомиться с OSGi. В предыдущей заметке мы остановились на вопросе: как сделать так, чтобы наш клиент мог получить информацию от двух сервисов с одинаковыми именами?

Еще раз вернемся к условию нашей задачи. Нам необходимо разработать меню цветов, котороее формировалось бы из палитр, предоставляемых разными бандлами. Мы выбрали такую схему решения: бандлы выставляют ColorizerService'ы, предоставляющие палитры меню. И есть некий бандл, который мы будем называть "центральным", который получает эти палитры от сервисов и объединяет их.

Приступим к реализации? Сначала создадим бандлы с сервисами. Пусть у нас будет два бандла: org.beq.equinox.p1 и org.beq.equinox.p2. Код и манифесты у них будут одинаковыми, отличаться будут лишь массивы цветов и конечно же значения полей Bundle-Name и Bundle-SymbolicName в манифестах. Поэтому сосредоточимся только на одном бандле org.beq.equinox.p1.

Введение в OSGi. Взаимодействие бандлов. Сервисы.

Hello, суровый челябинский программист here. И мы вновь продолжаем наше знакомство с OSGi. В предыдущей заметке мы говорили о взаимодействии бандлов посредством зависимостей. Однако, в OSGi существует и другой - более гибкий - способ обеспечить совместную работу бандлов и имя ему - сервисы.

Впрочем, предлагаю перейти сразу к делу. На рисунке представлена схема взаимодействия сервисов. Один Java-объект, который называется Service, представляет некий интерфейс доступа к себе - контракт сервиса. Другой Java-объект, который называется Client, может взаимодействовать с сервисом, через предоставляемый тем контракт.



Чтобы данное взаимодействие было возможно Client должен найти нужный ему Service и получить к нему доступ. Для этого используется Service Broker, в роли которого предстает OSGi-реестр сервисов. Бандл, предоставляющий сервис, регистрирует его в реестре, а бандл-клиент извлекает сервис оттуда и использует.

Введение в OSGi. Взаимодействие бандлов. Зависимости.

Здравствуйте, уважаемые читатели. Суровый челябинский программист снова здесь и готов продолжить серию статей, представляющих собой введение в замечательное средство построение модульных систем - OSGi.

В прошлый раз мы с вами научились управлять жизненным циклом бандлов из консоли, а также познакомились со средствами Equinox, такими как org.eclipse.equinox.launcher.

Сегодня я предлагаю поговорить о взаимодействии бандлов. Сначала позволю себе немного пофилософствовать.

Понятно, что раз приложение многомодульное, то априори подразумевается какое-то взаимодействие этих самых модулей. И тут разумно поставить 2 вопроса: зачем и как? Ответ на вопрос "зачем" интуитивно понятен. Мы хотим, чтобы наше приложение было расширяемым, т.е. чтобы мы сами или сторонние разработчики могли изменять/наращивать его функционал. Здесь уместно ввести понятие "точка расширения". Точкой расширения (не в терминах Eclipse RCP, а в неком глобальном смысле) мы будем называть то место, в котором приложение позволяет нарастить свой функционал. Например, у нас есть главное меню приложения, в котором определены точки расширения для подменю и пунктов подменю. Это значит, что мы можем добавлять свои подменю, состоящие из пунктов меню. Но не можем, используя данные точки расширения, добавить новое окно. Переходя к бандлам видим, что концептуально здесь все просто: один бандл выставляет (публикует) некие точки расширения, а другой, подключаясь к ним, расширяет возможности первого бандла. Соответственно, третий бандл может еще больше расширить возможности первого и т.д.

Другим интересным вопросом является вопрос "как". Т.е. как определить точку расширения в одном бандле и как ее использовать в другом бандле?

OSGi предлагает несколько способов организации взаимодействия бандлов:

1. Обмен ресурсами. Под ресурсами здесь подразумеваются java-классы, java-пэкеджи, библиотеки и другие файлы. В Eclipse RCP, например, самым распространенным способом определения точек расширения является их регистрация в файлах plugin.xml, впрочем, об этом мы еще поговорим.


2. OSGi-сервисы. Собственно, OSGi и задумывалась, как среда выполнения и взаимодействия сервисов. Суть очень проста - один бандл выставляет сервисы, а другие их используют. Данный способ требует активации бандла, потому что выставление и подключение к сервисам, как правило, осуществляется в активаторе бандла. Активация бандла требует расходов на управление жизненным циклом бандлов, но в тоже время обеспечивает динамичность всей системы.


3. Декларативные сервисы. Некое объединение преимуществ первого и второго способов. Сервисы описываются декларативно в xml-файлах и становятся видимыми другим бандлам. При первом использовании сервиса стартует активатор бандла, сервис становится работоспособным и доступным для использования.


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

Введение в OSGi. Работаем с Equinox - реализацией OSGi R4 от Eclipse Foundation.

В предыдущей статье цикла мы говорили про спецификацию OSGi и ее реализации. В данной заметке попробуем написать простой бандл и поработаем с системой Equinox, которую разрабатывают парни из Eclipse Foundation.

Начнем с разработки нашего первого бандла. Бандл будет состоять из класса-активатора и манифеста. Код класса-активатора следующий:

package org.beq.equinox.hello;



import org.osgi.framework.BundleActivator;

import org.osgi.framework.BundleContext;



public class Activator implements BundleActivator

{

    @Override

    public void start(BundleContext context) throws Exception

    {

        System.out.println("Start plugin activator");

    }



    @Override

    public void stop(BundleContext context) throws Exception

    {

        System.out.println("Stop plugin activator");

    }

}

 

Активатор бандла состоит из двух методов: start(BundleContext context) и stop(BundleContext context). Когда бандл стартует (переходит из состояния RESOLVED в состояние ACTIVE) выполняется метод start. Соответственно, предполагается, что в данном методе будет происходить регистрация сервисов, которые выставляет данный бандл и подключение к сервисам, выставляемым другими бандлами.

Введение в OSGi. Знакомимся с "серебряной пулей" для разработки модульных приложений.

Как говорил небезызвестный герой небезызвестного произведения Н.В. Гоголя "Давненько не брал в руки шашек". Так и я - давненько не радовал своих читателей тематическими постами.

Последнюю неделю активно ковырял внутреннее устройство Eclipse, точнее то, что называется Eclipse as a platform. Не все знают, что Eclipse - это не IDE, это, прежде всего, платформа для разработки приложений различного профиля и уровня сложности. Вот об этом и хочется рассказать.

Что такое OSGi

Начнем рассмотрение снизу вверх. Начиная с версии 3.0 Eclipse перевели на новую основу. Имя ей - OSGi.

OSGi (Open Services Gateway Initiative) - спецификация динамической плагинной (модульной) шины для создания Java-приложений, разрабатываемая консорциумом OSGi Alliance. Круг применений данной спецификации довольно широк: изначально разрабатывалась для создания встроенных систем (в частности, для автомобилей BMW, также в разработке спецификации активно учавствует Siemens), но сейчас на базе OSGi строят многофункциональные десктоп приложения (например, Eclipse SDK) и Enterprise-системы (например, Naumen DMS). Последняя версия спецификации носит номер 4.1 и доступна вот здесь.

Hibernate: это должен помнить каждый

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

- cascade="none" - значение по умолчанию. Hibernate будет игнорировать ассоциации, поэтому разруливать зависимости придется самостоятельно.

- cascade="save-update" говорит Hibernate'у, что разруливать зависимости необходимо при комите транзакции в которой делается save() или update() объекта. Суть разруливания заключается в том, что новые объекты, с которыми есть ассоциации у нашего, будут сохранены до него. Это позволяет обойти constraint-violations.

- cascade="delete" говорит Hibernate'у, что надо разруливать зависимости при удалении объекта.

- cascade="all" обозначает выполнение каскадных операций при save-update и delete.

- cascade="all-delete-orphan" обозначает то же самое, что и cascade="all", но к тому же Hibernate удаляет любые связанные сущности, удаленные из ассоциации (например, из коллекции).

- cascade="delete-orphan" обозначает, что Hibernate будет удалять любые сущности, которые были удалены из ассоциации.


Думаю такая краткая памятка будет полезна не только мне.

Понравилось сообщение - подпишись на блог

Решение проблемы с Lazy loading при использовании Hibernate через Spring

Hibernate поддерживает несколько стратегий загрузки связанных объектов из БД. Одной из самых популярных стратегий является т.н. ленивая загрузка - lazy loading. Предположим, что у нас есть сущность "блог", которая содержит свойство, представляющее собой коллекцию опубликованных постов (коллекцию сущностей типа "пост"). Согласитесь, что незачем выбирать из БД посты, если мы хотим всего лишь получить название блога. Добиться такого поведения нам и помогает ленивая загрузка - коллекция постов будет загружена из БД только, если мы захотим к ней обратиться.

Все операции с БД в Hibernate осуществляются через HibernateSession. В случае ленивой загрузки возможна ситуация, что после получения объекта типа "блог" сессия закроется. Тогда, при попытке обратиться к коллекции постов данного блога мы получим эксепшн. Hibernate не сможит вытянуть эту коллекцию из БД, потому что сессия уже закрыта.