html5

Кто правильно ищет - тот всегда находит

Сайт http://trade.mikoyan.ru поможет быстро найти место с самой вкусной колбасой России. :))
Торговая география Микояновского мясокомбината позволяет приобрести его продукцию в 1000 разных мест по всей Москве.
Вы сможете выбрать ближайший к вам магазин по округу города Москвы или ближайшей станции метро.



[еще картинки]
html5

Управляемые бины Managed Beans

Управляемые бины Managed Beans

Центральной проблемой в дизайне web-приложений является разделение уровня представления и уровня бизнес-логики. В технологии JSF такое разделение достигается с помощью бинов (beans). JSF-страницы ссылаются на свойства бинов, а логика программы закладывается в код реализации этих бинов. Поскольку бины играют такую фундаментальную роль в JSF-программировании, есть смысл рассмотреть их более подробно, чтобы не путать с Enterprise JavaBeans.

Согласно спецификации JavaBeans (которая доступна по адресуhttp://java.sun.com/products/javabeans), бин Java — это допускающий многократное использование программный компонент, которым можно манипулировать в инструментах-конструкторах. Данное определение является слишком общим и в действительности бины используются для многих других целей.

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

Обратите внимание! “Bean”(бин) дословно переводится как «боб». Все дело в том, что слово “Java” в США ассоциируется не только с островом Ява, но и с популярной маркой кофе, а кофе, как известно, готовиться из кофе-бобов, которые и формируют его вкус. Кого-то эта аналогия забавляет, кото-то раздражает, но главное, что термин «бин» уже довольно прочно закрепился и вряд ли будет заменен каким-либо другим.

[Spoiler (click to open)]

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

В технологии JSF бины применяются для сохранения состояния web-страниц. Создание бинов и манипулирование ими осуществляются под управлением реализации JSF, которая выполняет следующее:


  1. Создание и уничтожение бинов по мере необходимости (этим объясняется происхождение термина «управляемые бины»)

  2. Считывание свойств бина при отображении web-страницы

  3. Задание свойств бина при отправке формы

Рассмотрим в качестве примера поле формы для ввода пароля:

<h:inputSecret value=”#{user.password}” />

Реализация JSF должна определить местонахождение класса бина для бина с именем user. В этом примере класс UserBean объявлен следующим образом:

@ManagedBean(name=”user”)
@SessionScoped
public class UserBeans implements Serializable { … }

Атрибут name в аннотации @ManagedBean можно опустить. В таком случае имя бина формируется из имени класса путем приведения первой буквы к нижнему регистру. В частности, если в приведенном выше примере будет исключено выражение (name=”user”), то бин получит имя userBean.

Обратите внимание! Аннотация @ManagedBean находится в пакете javax.faces.bean. платформа Java 6 EE определяет в пакете javax.annotation другую аннотацию @ManagedBean, которая не работает с JSF.

Впервые встретив выражение с именем user, реализация JSFсоздает объект класса UserBean. Этот объект продолжает существовать на протяжении всего сеанса: это означает, что все запросы, исходящие от одного и того же клиента, продолжают оставаться действительными до явного завершения сеанса или его прекращения по тайм-ауту. На протяжении всего сеанса имя бина user ссылается на ранее созданный объект.

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

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

Вполне очевидно, что JSF-разработчику не приходится писать код Java для создания бина user и манипулирования им. Реализация JSF создает бины и обращается к ним в соответствии с тем, как описано выражениями на страницах JSF.

html5

Аутентификация на основе jdbcRealm в GlassFish 3

доступ на основе jdbcRealm в GlassFish 3

Разграничение прав доступа к разным частям сайта — один из самых важных этапов в разработке. Управление доступом должно быть гибким и надежным, чтобы в любой момент можно было быстро и без риска изменить правила пользования ресурсом. Все это может обеспечить аутентификация на основе jdbcRealm, который содержит в себе гибкость и настраиваемость базы данных и надежность использования от сервера приложений GlassFish.

jdbcRealm однозначно удобнее, продвинутее, управляемее и переносимее в сравнении со стандартными методами аутентификации: BASIC(базовая аутентификация), DIGEST(аутентификация на основе дайджеста), FORM(аутентификация на основе форм)и CLIENT-CERT(аутентификация на основе клиентского сертификата).jdbcRealm = гибкость базы * надежность сервера.

Давайте сформулируем задачу и требования, которые мы хотим реализовать.

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

Требования: нам нужны три группы пользователей — администратор(admin), модератор(moder) и гость(guest). В любую из этих групп может входить неограниченное количество пользователей. Администратору доступны все уровни, модераторам — свой и гостевой, гостям — только свой. Шифрование паролей в базе данных — на основе MD5(чтобы можно было осуществлять шифрование на основе sql-запроса не заморачиваясь на java-код). Все страницы требующие прав доступа — только в защищенной зоне HTTPS. База дынных: MySQL, MyISAM.

Итак, поехали.

html5

Области действия бинов Bean Scopes

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

При определении бина необходимо определить его область действия. Три области действия являются общими для управляемых бинов JSF и CDI.


  • Область действия сеанса:  SessionScoped

  • Область действия запроса:  RequestScoped

  • Область действия приложения:  ApplicationScoped

В версии JSF 2.0 дополнительно предусмотрены область действия просмотра ViewScoped и пользовательские области действия CustomScoped. Эти области действия не поддерживаются в технологии CDI — вместо этого в ней предусмотрена намного более полезная область действия диалога  ConversationScoped.

Обратите внимание! Аннотации для управляемых бинов JSF находятся в пакете javax.faces.bean, а аннотации для бинов CDI — в пакете javax.enterprise.context.

Область действия сеанса — SessionScoped

Уточним, что HTTP-протокол не поддерживает состояния. Браузер отправляет запрос серверу, сервер возвращает ответ, а затем ни браузер, ни сервер не берет на себя никаких обязательств хранить в памяти какие-либо сведения об этой транзакции. Такая простая организация работы вполне подходит для извлечения однозначно определяемых сведений, но не применима для серверных приложений.

[Spoiler (click to open)]

Поэтому контейнеры сервлетов дополняют HTTP-протокол средствами отслеживания сеансов, под которыми подразумеваются повторные подключения одного и того же клиента. Самый простой способ отслеживания сеансов заключается в применении cookie-файлов, то есть пар «ключ-значение», которые сервер отправляет клиенту, чтобы получать их обратно при следующих запросах.

Если на клиенте не запрещены cookie-файлы, то сервер при каждом последюущем запросе получает идентификатор сеанса.

Процесс отслеживания сеансов с помощью cookie-файлов полностью прозрачен для web-разработчика, а если клиент не принимает cookie-файлы, то стандартные теги JSF обеспечивают перезапись URL-адресов автоматически.

Область действия сеанса сохраняется со времени установки сеанса и до времени его завершения. Сеанс завершается после того, как web-приложение вызывает метод invalidate применительно к объекту HttpSession или по истечению тайм-аута сеанса.

Область действия запроса — RequestScoped

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

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

В область действия запроса часто помещают данные, относящиеся в сообщениям об ошибках и состоянии. Эти данные вычисляются при отправке клиенту данных формы и отображаются при подготовке ответа к выводу на экран. Аналогично с этим, тег f:loadBundle помещает в область действия запроса переменную связки, которая необходима только на этапе подготовки ответа к отображению в том же запросе.

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

Обратите внимание! Только бины, находящиеся в области действия запроса, являются однопотоковыми, поэтому, по самой своей сути, потокобезопасными. Это может показаться удивительным, но бины, находящиеся в области действия сеанса, однопотоковыми не являются. Например, ничто не мешает пользователю отправлять ответы одновременно из нескольких окон браузера. Каждый из ответов будет обрабатываться отдельным потоком запроса. Если необходимо обеспечить потокобезопасноть, используя бины с областью действия сеанса, то невозможно обойтись без механизмов блокировки.

Область действия приложения — ApplicationScoped

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

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

@ManagedBean(eager=true)

Атрибут eager впервые был введен в действие в версии JSF 2.0

Область действия диалога — ConversationScoped

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

Область действия диалога использовать несложно.  Для этого достаточно придерживаться ряда простых правил:


  • Использовать бин CDI, поскольку область действия диалога — это средство CDI, а не JSF

  • Использовать аннотацию @ConversationScoped

  • Добавить следующую переменную экземпляра:
    private @Inject Conversation conversation;
    эта переменная экземпляра будет автоматически инициализирована вместе с объектом Conversation при создании бина

  • Вызывать метод conversation.begin(), чтобы перевести бин в более широкую область действия — из области действия запроса в область действия диалога

  • Вызывать метод conversation.end(), чтобы удалить бин из области действия диалога

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

package ru.model;
import javax.inject.Named;
import javax.enterprise.context.ConversationScoped;
import java.io.Serializable;
import javax.enterprise.context.Conversation;
import javax.inject.Inject;
@Named(value = "dialogBean")
@ConversationScoped
public class DialogBean implements Serializable {
   @Inject Conversation conversation;
   private int currentIndex;
   public void setAnswer(String newValue) {
       try {
           if(currentIndex == 0) this.conversation.begin();
           // a lot of your code here
           if(currentIndex == 0) this.conversation.begin();
       } catch(NumberFormatException e){}
   }
   public DialogBean() {
   }
}

Область действия просмотра — ViewScoped

Область действия просмотра была впервые введена в версии JSF 2.0. Бин в области действия просмотра сохраняется до тех пор, пока отображается одна и та же страница JSF. После того как пользователь откроет другую страницу, бин выходит из области действия просмотра.

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

Пользовательские области действия — CustomScoped

В конечном счете область действия — это просто карта, которая связывает имена с объектами. Основным признаком, по которому область действия одного типа отличается от другого, является срок существования соответствующей карты. Сроками существования четырех стандартных областей действия JSF:


  1. Сеанс  :  SessionScoped

  2. Приложение  :  ApplicationScoped

  3. Просмотр  :  ViewScoped

  4. Запрос  :  RequestScoped

управляет реализация JSF. А с выходом версии JSF 2.0 появилась возможность создавать пользовательские области действия — карты, сроками существования которых можно управлять самостоятельно. Бин помещается в такую карту с помощью следующей аннотации:

@CustomScoped(“#{expr}”)

Здесь используется выражение #{expr}, вычисление которого приводит к получению карты для области действия. При этом ответственность за удаление объектов из карты возлагается на приложение.

html5

Работа с правками файлов в GitHub и NetBeans

В предыдущей статье мы залили часть файлов своего проекта на GitHub. Причем сделали это непосредственно из NetBeans — безо всяких приблуд = принцип одного окна, так сказать :)

Теперь же пришел черед узнать — как обмениваться правками вносимыми в файлы: как локально, так и на GitHub-е. То есть: можно изменить файл непосредственно на сервисе GitHub — для этого там есть редактор —  а затем применить эти правки к локальному файлу , а можно исправить файл на локальном компьютере — а затем залить на GitHub.

Особо стоит отметить, что создание/удаление директорий также может быть применено в оде стороны. Только запомните: пустые директории не создаются и не заливаются на GitHub! В нужной, но еще не заполненной директории должен быть хотя бы один файлик с минимальным содержанием...

Итак, поехали...

[Spoiler (click to open)]

Сценарий первый: правка файла непосредственно на GitHub с помощью их встроенного on-line редактора файлов.


  • переходим на нужную ветку, в нужную директорию и к нужному файлу

  • нажимаем кнопочку Edit справа и редактируем наш файл как считаем нужным

  • заполняем поля Commit summary и Extended description, нажимаем кнопку CommitChanges

  • открываем NetBeans

  • клик правой клавишей по проекту и выбор в меню: Git — ветвь — переключиться на ветвь - на локальном компе у вас должна быть ветка с таким же названием и содержимым как на GitHub

  • клик правой клавишей по проекту и выбор в меню: Git —удаленный — вытянуть = в появившемся окне указываем удобноевам удаленное имя репозитория, URL к нему, логи и пароль, жмем кнопку Далее и на новой вкладке выбираем ту ветку, которую мы правили в редакторе на GitHub (ее придется запомнить), жмем кнопку готово - IDE зальет файлы с сервиса и заменит ими файлы на локальном компьютере

  • все! мы применили к локальным файлам изменения сделанные на GitHub

Сценарий второй: правка файла на локальном компьютере.


  • открываем NetBeans

  • клик правой клавишей по проекту и выбор в меню: Git — ветвь — переключиться на ветвь и выбираем ту ветвь с которой хотим работать - на локальном компе у вас должна быть ветка с таким же названием и содержимым как на GitHub

  • редактируем нужный нам файл так как хотим

  • клик правой клавишей по проекту и выбор в меню: Git — фиксировать и в верхнее поле вписываем комментарий по поводу своих изменений

  • кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — удаленный — вытолкнуть и далее как описано тут в пункте №9 - если в окне, где выбирается ветка на удаленном репозитории напротив нужной ветки будет красная буква — значит есть не принятые вами изменения и пока вы их не примете или не отклоните залить новые свое на GitHub будет невозможно

  • если возник конфликт, то клик правой клавишей по проекту и выбор в меню: Git —разрешить конфликт = после его разрешения можно будет залить свои изменения на GitHub

  • все! мы применили к файлам на GitHub изменения сделанные на локальном компьютере

html5

Подключение к удаленной базе данных посредством SSH-туннеля

Подключение к удаленной базе данных посредством SSH-туннеля созданного в PuTTY может потребоваться в том случае, если вы работаете "за прокси", а ваше приложение не имеет возможности настраиваться на работу с прокси-сервером по конкретному порту 3306 или вообще. Чтобы "обойти прокси" придется прибегнуть к несложной уловке: создать SSH-туннель в PuTTY на определенный порт, а затем осуществить локальное подключение в вашем приложении на вышеуказанный порт. Обратите внимание, что PuTTY не должен быть выключен: после подключения к серверу по SSH просто сверните его и запомните, что SSH-тоннель работает только при включенном PuTTY.

Вот пошаговая инструкция по подключению к удаленной базе данных из NetBeans 7.4 через SSH-тоннель созданный в PuTTY:

[Spoiler (click to open)]

  1. создаем и сохраняем новое именованное подключение в PuTTY к опеределенному адресу по порту 22

  2. заходим на вкладку Connection - Proxy и производим настройки подключения к вашему прокси серверу: указываем ip-адрес, порт, логин и пароль

  3. заходим на вкладку Connection - SSH - Tunnels и создаем SSH-тоннель с локального порта 13306 на удаленный адрес по порту 3306

  4. переходи на вкладку Sessions и нажимаем Save, сохранив тем самым все нужные настройки

  5. используя вновь созданное подключение, входим на сервер и сворачиваем PuTTY в трей

  6. в NetBeans на вкладке "Службы", кликаем правой клавишей по ярлыку "Базы данных" и выбираем пункт "Новое соединение"

  7. в мастере новых соединений на странице "Обнаружение драйвера" в выпадающем списке выбираем MySQL(Connector\J Driver) и идем далее

  8. на странице "Настройка соединения" указываем наш порт 13306 в поле "Порт", а в поле "Адрес" оставляем localhost, затем вводим название базы данных, логин, пароль и тестируем подключение — после успешного тестирования: сохраняемся

Вот и все! Для визуальной наглядности, на изображениях ниже представлены шаги описанного выше процесса.

Создание SSH-тоннеля в PuTTY

подключение к удаленной базе данных через SSH-тоннель в PuTTY подключение к удаленной базе данных через SSH-тоннель в PuTTY подключение к удаленной базе данных через SSH-тоннель в PuTTY подключение к удаленной базе данных через SSH-тоннель в PuTTY

Подключение к удаленной базе в NetBeans

подключение к удаленной базе данных через SSH-тоннель в PuTTY подключение к удаленной базе данных через SSH-тоннель в PuTTY

html5

Основы работы с GitHub в NetBeans

Это первая статья из нескольких, о работе с Git и web-сервисом GitHub посредством NetBeans

NetBeans - крайне удобная среда разработки и одной из предустановленных фишек является возможность управления версиями проекта посредством git. А это значит, что можно активно использовать сетевой сервис GitHub для групповой работы над проектом. Писать на эту тему надо много - ибо есть нюансы... и, наверное, я когда-нибудь опишу этот процесс подробно = например на эти майские праздники...Но в данный момент ограничусь кратким путеводителем - для старта вполне достаточно.

[Spoiler (click to open)]

Итак.

Цель: опубликовать свой проект на GitHub непосредственно из NetBeans


  1. создаем на GitHub репозиторий и берем HTTP-ссылку на него = типа: https://github.com/your-account/my-project.git - при создании поставьте галочку, чтобы создался файлик README

  2. создаем проект в NetBeans и называем его как угодно

  3. кликаем правой клавишей по проекту и в контекстном меню выбираем: управление версиями — инициализировать репозиторий Git

  4. кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — фиксация (это наш первый commit)

  5. во всплывшем окне, в верхней части пишем пояснение этого коммита, в нижней части - выбираем те файлы которые хотим зафиксировать, нажимаем кнопку фиксировать и с этого момента у нас появляется первая ветка под названием master - эта ветка будет основой для всех последующих веток - по-этому слишком много всего в ней фиксировать не надо - выложить эту ветку и первый коммит на GitHub - не получится: для этого надо создать новую ветку с новым коммитом/фиксацией

  6. кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — ветвь — создать ветвь = пишем имя ветви (например, brunch-first) и нажимаем кнопку создать

  7. кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — ветвь —переключиться на ветвь и в выпадающем списке выбираем brunch-first - с этого момента все ваши правки будут видны только в этой ветке

  8. кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — фиксация (это наш второй commit) - с этого момента часть нашего проекта со всеми изменениями файлов и директорий готова к выкладке на GitHub

  9. кликаем правой клавишей по проекту и в контекстном меню выбираем: Git — удаленный — вытолкнуть, в поле URL-адрес репозитория вставляем адрес https://github.com/your-account/my-project.git, вписываем свои логин и пароль, ставим галочку запоминания пароля и жмем кнопку далее

  10. на следующей вкладке формы выбираем нашу ветку brunch-first — она будет помечена зеленой буковкой А и жмем кнопку Готово

  11. все... часть вашего проекта выложена на GitHub, а ваша ветка brunch-first будет доступна по адресу https://github.com/your-account/my-project/tree/brunch-first

html5

Создание виртуального хоста в GlassFish

В статье рассказывается о том, как привязать определенное web-приложение развернутое на сервере приложений GlassFish к определенному домену = то есть, чтобы ваше приложение было доступно по адресу myappsite.ru:8080, но никак не basesite.ru:8080/myappsite/

Работать будем в админке GalssFish... итак приступим...

[Spoiler (click to open)]

  1. создадим новый виртуальный сервер: придумаем ему id: типа new-server и в поле Hosts впишем нужный нам домен: типа myappsite.ru

  2. так же выберем http-listener-1 и http-listener-2

  3. поле Default Web Module пока оставим пустым

  4. перейдем на вкладку Application, нажмем кнопку Deploy, выберем нужный варник, впишем название:типа WebAppFirst

  5. в списке Virtual Servers отметим new-server и развернем его

  6. теперь вернемся на вкладку виртуальных серверов, выберем наш new-server и в списке Default Web Module выберем наше приложение: WebAppFirst

  7. сохранимся и на этом все!

теперь по адресу myappsite.ru:PORT будет доступно приложение WebAppFirst и отображаться оно будет только на данном домене

Создание виртуального хоста в GlassFish

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

Бины CDI или Context and Dependency Injection

Бины CDI или Context and Dependency Injection В технологии JSF впервые введено понятие «управляемый бин» managed bean для использования в web-приложениях. Но, к сожланеию, возможности управляемых бинов JSF довольно ограничены. В технологии, которая регламентирована спецификацией JSR 299 (сокращенно обозначаемой CDI — Context and Dependency Injection), определена более гибкая модель для бинов, которые управляются с помощью сервера приложений. Эти бины связаны с контекстом, например такими как: Контекст текущего запроса, Сеанс браузера, Жизненный цикл определяемый пользователем.

Технология CDI определяет механизмы для вставки бинов, перехвата и дополнения вызовов методов, а также активизации событий и наблюдения за ними. Технология CDI определяет гораздо более мощный механизм по сравнению с управляемыми бинами JSF, поэтому имеет смысл использовать именно бины CDI, если приложение развертывается на сервере приложений Java EE, например таком как GlassFish. Этот сервер автоматически поддерживает технологию CDI.

Обратите внимание! Можно также добавить справочную реализацию CDI к такому популярному контейнеру сервлетов как Tomcat. Дополнительные сведения приведены по адресу http://seamframework.org/Weld

Бины CDI используются по такому же принципу, как и управляемые бины JSF. Но для их объявления служит аннотация @Named вместо @ManagedBean используемая для управляемых бинов.

[Spoiler (click to open)]

Образец объявления бина CDI


  • @Named(“user”)

  • @SessionScoped

  • public class UserBean implements Serializable {

  • // your code here

  • }

После этого можно использовать выражения значения #{user} или #{user.name} по такому же принципу, как и управляемые бины JSF.

В данном случае аннотация @SessionScoped взята из пакета javax.enterprise.context, а не из пакета javax.faces.bean.

Обратите внимание! Для активизации обработки бинов CDI необходимо создать файл WEB-INF/beans.xml. Этот файл может быть пустым или, в случае необходимости, содержать необязательные команды по настройке конфигурации бинов. Дополнительные сведения о файле beans.xml содержится в спецификации бинов CDI по адресу http://jcp.org/en/jsr/summary?id=299

Следует отметить, что бины CDI с охватом сеанса, то есть @SessionScoped, должны реализовывать интерфейс Serializable.

Так сложилось исторически, что для поддержки бинов, которые могут использоваться на страницах JSF, предусмотрены два отдельных механизма: бины CDI и управляемые бины JSF. Разработчкам рекомендуется всегда использовать бины CDI, за исключением тех случаев когда приложение должно работать под управлением контейнера сервлетов Tomcat. Справедливости ради следует отметить, что существует промышленная версия Tomcat —Apache TomEE, использование которой позволит вам пользоваться всей мощью бинов CDI http://tomee.apache.org/

Образец кода бина CDI с охватом сеанса


  • package ru.model;

  • import javax.inject.Named;

  • import javax.enterprise.context.SessionScoped;

  • import java.io.Serializable;

  • @Named(value = "exampleBean")

  • @SessionScoped

  • public class ExampleBean implements Serializable {

  • // this is a constructor

  • public ExampleBean() {

  • }

  • private String string;

  • /**

  • * Get the value of string

  • *

  • * @return the value of string

  • */

  • public String getString() {

  • return string;

  • }

  • /**

  • * Set the value of string

  • *

  • * @param string new value of string

  • */

  • public void setString(String string) {

  • this.string = string;

  • }

  • }

Бины CDI или Context and Dependency Injection

очень полезная ссылка = www.cdi-spec.org