Главная » Spring » Работа с обычным JNDI API Spring

0

Реализация поиска объектов в репозитории JNDI может оказать- ся весьма утомительным занятием. Например, допустим, что нам

требуется выполнить типичную операцию по извлечению объекта javax.sql.DataSource из JNDI. Используя только JNDI API, реализо- вать эту операцию можно было бы, как показано ниже:

InitialContext  ctx  =  null; try  {

ctx  =  new  InitialContext();

DataSource  ds  =

(DataSource)   ctx.lookup("java:comp/env/jdbc/SpitterDatasource");

}  catch  (NamingException  ne)  {

// обработка исключений …

}  finally  {

if(ctx  !=  null)  { try {

ctx.close();

}  catch  (NamingException  ne)  {}

}

}

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

#  Только чтобы отыскать объект DataSource, необходимо создать и

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

# Необходимо перехватить или, по крайней мере, повторно воз-

будить исключение javax.naming.NamingException. Если вы пред- почтете перехватить его, необходимо также предусмотреть соответствующую обработку. Если вы предпочтете повторно возбудить его, обработку вынужден будет выполнить вызываю- щий программный код. Так или иначе, но где-то в приложении должна быть предусмотрена обработка этого исключения.

#  Программный код оказывается тесно связанным с репозитори-

ем JNDI. Программе нужен всего лишь объект DataSource. И не важно, откуда он будет получен, из JNDI или откуда-то еще. Но если программа содержит программный код, подобный это- му, она вынуждена будет извлекать DataSource из JNDI.

# Программный код оказывается тесно связанным с опреде- ленным именем JNDI – в данном случае с java:comp/env/jdbc/ SpitterDatasource. Конечно, имя можно было бы определить в файле свойств, но тогда вам придется добавить еще больше шаблонного кода, чтобы получить имя JNDI из файла.

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

DataSource  ds  =

(DataSource)   ctx.lookup("java:comp/env/jdbc/SpitterDatasource");

Еще большее беспокойство, чем шаблонный код для работы с JNDI, доставляет тот факт, что при таком подходе приложение точно знает, откуда извлекается объект источника данных. Он всегда извлекается из репозитория JNDI. Как показано на рис. 17.2, объект DAO, использующий объект источника данных, оказывается прочно привязанным к JNDI. Это обстоятельство делает практически невоз- можным использование данного программного кода в окружении, где репозиторий JNDI недоступен или его использование нежелательно.

Рис. 17.2. Применение обычного JNDI API

для извлечения зависимостей приводит к образованию тесной связи с JNDI, что осложняет использование программного кода, где JNDI недоступен

Например, представьте, что реализация поиска источника дан- ных включена в класс, подвергающийся модульному тестированию. В идеале объект должен тестироваться в изолированной среде, не- зависимо от каких-либо других объектов. Хотя класс и не зависит от источника данных, извлекаемого из JNDI, он зависит от самого механизма JNDI. То есть модульный тест также оказывается завися-

щим от JNDI, и на момент тестирования сервер JNDI должен быть доступен.

Однако все вышесказанное не отменяет того факта, что иногда

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

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

Итак, источник данных находится в репозитории JNDI. Так как же настроить Spring, чтобы внедрить объект, хранящийся в JNDI?

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии