특정한 예외 상항에서 매개 변수가 없는 것을 허용하는 생성자와 함께하는 모든 Java 클래스는 Web Bean으로 이에는 모든 JavaBean이 포함됩니다. 이에 더하여 모든 EJB 3-스타일 세션 빈도 Web Bean입니다. 물론 매일 작성하셨던 JavaBeans 및 EJB는 Web Beans 사양에 의해 정의된 새로운 서비스의 장점을 취할 수 없지만, Web Beans으로서 기존 코드를 변경하지 않고 이 모든 것을 사용하실 수 있습니다 — 기타 다른 Web Beans로의 삽입, Web Beans XML 설정 기능을 통한 설정, 인터셉터 및 데코레이터 추가 등—

다양한 애플리케이션에서 오랫동안 사용해 온 두 개의 Java 클래스를 갖고 있다고 가정합시다. 첫 번째 클래스는 문자열을 문장 목록으로 구문 분석합니다:

public class SentenceParser {

    public List<String

> parse(String text) { ... }

}

두 번째 클래스는 하나의 언어에서 다른 언어로 문장을 번역할 수 있는 외부 시스템에 대한 무상태 세션 빈 프론트엔드입니다:

@Stateless

public class SentenceTranslator implements Translator {

    public String translate(String sentence) { ... }

}

여기서 Translator는 로컬 인터페이스입니다:

@Local

public interface Translator {

    public String translate(String sentence);

}

불행하게도 전체 텍스트 문서를 번역하는 기존 클래스가 없으므로, 이러한 작업을 실행하는 Web Bean을 작성합시다:

public class TextTranslator {

    

    private SentenceParser sentenceParser;

    private Translator sentenceTranslator;

    

    @Initializer

    TextTranslator(SentenceParser sentenceParser, Translator sentenceTranslator) {

        this.sentenceParser = sentenceParser;

        this.sentenceTranslator = sentenceTranslator;

    }

    

    public String translate(String text) {

        StringBuilder sb = new StringBuilder();

        for (String sentence: sentenceParser.parse(text)) {

            sb.append(sentenceTranslator.translate(sentence));

        }

        return sb.toString();

    }

    

}

인스턴스를 Web Bean, Servlet 또는 EJB로 삽입하여 TextTranslator 인스턴스를 얻을 수 있습니다:

@Initializer

public setTextTranslator(TextTranslator textTranslator) {

    this.textTranslator = textTranslator;

}

다른 방법으로 Web Beans 관리자 방식을 직접 호출하여 인스턴스를 획득할 수 있습니다:

TextTranslator tt = manager.getInstanceByType(TextTranslator.class);

하지만 잠시 기다려주십시오: TextTranslator는 매개 변수 없는 생성자를 갖지 않습니다! 그래도 이것이 Web Bean입니까? 클래스가 @Initializer라고 어노테이션된 생성자를 갖고 있을 경우 매개 변수 없이 생성자를 갖지 않는 클래스는 Web Bean이 될 수 있습니다.

예상하셨듯이, @Initializer 어노테이션은 의존성 삽입을 사용하여 실행하기 위한 무엇인가를 갖고 있습니다! @Initializer는 생성자 또는 Web Bean 방식에 적용될 수 있으며, Web Bean을 인스턴스화할 때 Web Bean 관리자에게 생성자 또는 Web Bean 방식을 호출할 것을 지시합니다. Web Bean 관리자는 기타 다른 Web Beans를 생성자 또는 방식의 매개 변수에 삽입하게 됩니다.

시스템 초기화시 Web Bean 관리자는 각각의 삽입 지점을 만족시키는 하나의 Web Bean이 존재하도록 이를 유효화해야 합니다. 예에서 사용 가능한 Translator 구현이 없을 경우 — SentenceTranslator EJB가 배치되지 않는 다면 — Web Bean 관리자는 UnsatisfiedDependencyException을 넘기게 됩니다. 하나 이상의 Translator를 구현할 수 있을 경우, Web Bean 관리자는 AmbiguousDependencyException을 넘기게 됩니다.

정확하게 Web Bean은 무엇인가요?

Web Bean은 비지니스 로직이 들어 있는 애플리케이션 클래스입니다. Web Bean은 Java 코드에서 직접 불러오거나 또는 Unified EL을 통해 불러올 수 있습니다. Web Bean은 트랜젝션 리소스에 액세스할 수 있습니다. Web Beans 사이에서의 종속성은 Web Bean 관리자에 의해 자동으로 관리됩니다. 대부분의 Web Beans은 상태 유지 (stateful) 및 컨텍스트 기반입니다. Web Bean 수명 주기는 항상 Web Bean 관리자에 의해 관리됩니다.

두 번째 내용으로 돌아가 봅시다. "컨텍스트화"된다는 의미는 정확하게 무엇입니까? Web Beans가 상태 유지 세션 빈이면, 보유하고 있는것이 어떤 빈 인스턴스인가가 문제입니다. 무상태 구성 요소 모델 이나 (예: 무상태 세션 빈) 또는 singleton 구성요소 모델 (예: ervlets 또는 singleton 빈)과는 다르게 Web Bean의 다른 클라이언트는 다른 상태에 있는 Web Bean을 보게 됩니다. 클라이언트-가시성 상태는 클라이언트가 참조하고 있는 Web Bean의 인스턴스가 무엇인가에 의존합니다.

하지만, 무상태 또는 싱글턴 모델과 같으나 상태 유지 세션 빈 과는 다르게, 클라이언트는 인스턴스의 수명 주기를 명시적으로 생성 또는 파괴하여 제어하지 못합니다. 대신, Web Bean의 범위는 다음 사항을 결정합니다:

Web Beans 애플리케이션에 있는 주어진 스레드의 경우, Web Bean 범위와 관련된 활성 컨텍스트가 있을 수 있습니다. 이러한 컨텍스트는 스레드에서 유일하거나 (예: 요청 범위일 경우) 또는 특정한 다른 스레드와 공유될 수 있거나 (예: Web Bean이 세션 범위일 경우) 또는 기타 다른 모든 스레드일 수 있습니다 (Web Bean이 애플리케이션 범위일 경우).

동일한 컨텍스트에서 실행되는 클라이언트 (예: 기타 다른 Web Bean)는 동일한 Web Bean의 인스턴스를 보게 됩니다. 하지만 다른 컨텍스트에서 실행되는 클라이언트는 다른 인스턴스를 보게 됩니다.

컨텍스트 모델의 큰 장점 중 하나는 상태 유지 Web Beans가 서비스처럼 다루어지게 하는 것입니다! 클라이언트는 사용되는 Web Bean의 수명 주기 관리 자체를 고려하거나, 또는 수명 주기가 무엇인지를 알 필요가 없습니다. Web Beans는 메세지를 전달하여 상호작용하고 Web Bean 구현은 자신의 상태에 따른 수명 주기를 정의합니다. Web Beans는 다음과 같은 이유로 느슨하게 연결되어 있습니다:

하나의 Web Bean을 동일한 API를 구현하고 다른 Web Bean 구현에 영향을 미치지 않고 다른 수명 주기 (다른 범위)를 갖는 다른 Web Bean으로 대체할 수 있습니다. 사실, 4.2절. “배치 유형 ”에서 살펴보실 수 있듯이 Web Beans는 배치시 Web Bean 구현을 덮어쓰기하기 위한 정교한 기능을 정의합니다.

모든 Web Bean 클라이언트가 Web Beans가 될 수 없음에 유의합니다. Servlets 또는 Message-Driven Beans와 같은 — 본래 삽입 가능한 컨텍스트 객체가 아닌 — 객체는 삽입에 의해 Web Beans에 참조를 획득할 수 있습니다.

보다 공식적으로 spec에 따르면:

이러한 용어가 Web Bean 개발자에게 무엇을 의미하는 살펴봅시다.

@CreditCard PaymentProcessor paymentProcessor

@CreditCard

public class CreditCardPaymentProcessor 

    implements PaymentProcessor { ... }

@Mock

public class MockSentenceTranslator implements Translator {

    public String translate(String sentence) {

        return "Lorem ipsum dolor sit amet";

    }

}

@SessionScoped

public class ShoppingCart { ... }

@SessionScoped @Named("cart")

public class ShoppingCart { ... }

<h:dataTable value="#{cart.lineItems}" var="item">
    ....
</h:dataTable
>

@SessionScoped @Named

public class ShoppingCart { ... }

@SessionScoped 

@Interceptors(TransactionInterceptor.class)

public class ShoppingCart { ... }

@SessionScoped @Transactional

public class ShoppingCart { ... }

JavaBeans, EJB 및 기타 다른 Java 클래스가 Web Beans이 될 수 있음을 살펴보았습니다. 하지만, 정확히 어떤 종류의 객체가 Web Beans인가요?

@Stateful @SessionScoped

public class ShoppingCart {


    ...

    

    @Remove

    public void destroy() {}


}

@ApplicationScoped

public class Generator {


    private Random random = new Random( System.currentTimeMillis() );

    

    @Produces @Random int next() {

        return random.nextInt(100);

    }


}

@Random int randomNumber

@Produces @RequestScoped Connection connect(User user) {

    return createConnection( user.getId(), user.getPassword() );

}

void close(@Disposes Connection connection) {

    connection.close();

}

You'll need to download JBoss AS 5.0.1.GA from jboss.org, and unzip it. For example:

$ cd /Applications
$ unzip ~/jboss-5.0.1.GA.zip

Next, download Web Beans from seamframework.org, and unzip it. For example

$ cd ~/
$ unzip ~/webbeans-$VERSION.zip

다음으로, JBoss가 위치해 있는 곳을 Web Beans에게 알려야 합니다. jboss-as/build.properties를 편집하고 jboss.home 속성을 설정합니다. 예:

jboss.home=/Applications/jboss-5.0.1.GA

To install Web Beans, you'll need Ant 1.7.0 installed, and the ANT_HOME environment variable set. For example:

$ unzip apache-ant-1.7.0.zip
$ export ANT_HOME=~/apache-ant-1.7.0

Then, you can install the update. The update script will use Maven to download Web Beans automatically.

$ cd webbeans-$VERSION/jboss-as
$ ant update

이제, 첫번째 예제를 배치할 준비가 되었습니다!

numberguess 예제를 배치하려면:

$ cd examples/numberguess
ant deploy

Start JBoss AS:

$ /Application/jboss-5.0.0.GA/bin/run.sh

애플리케이션이 배치되면 http://localhost:8080/webbeans-numberguess에서 살펴보시기 바랍니다!

Web Beans includes a second simple example that will translate your text into Latin. The numberguess example is a war example, and uses only simple beans; the translator example is an ear example, and includes enterprise beans, packaged in an EJB module. To try it out:

$ cd examples/translator
ant deploy

애플리케이션이 배치되면 http://localhost:8080/webbeans-translator에 가보십시오!

You'll need to download Tomcat 6.0.18 or later from tomcat.apache.org, and unzip it. For example:

$ cd /Applications
$ unzip ~/apache-tomcat-6.0.18.zip

Next, download Web Beans from seamframework.org, and unzip it. For example

$ cd ~/
$ unzip ~/webbeans-$VERSION.zip

Next, we need to tell Web Beans where Tomcat is located. Edit jboss-as/build.properties and set the tomcat.home property. For example:

tomcat.home=/Applications/apache-tomcat-6.0.18

To deploy the numberguess example for tomcat:

$ cd examples/tomcat
ant tomcat.deploy

Start Tomcat:

$ /Applications/apache-tomcat-6.0.18/bin/startup.sh

애플리케이션이 배치되면 http://localhost:8080/webbeans-numberguess에서 살펴보시기 바랍니다!

TODO

numberguess 애플리케이션에서 1에서 100사이의 숫자를 알아내기 위해 주어진 10 번을 시도하게 됩니다. 각각 시도한 후 숫자가 너무 높은지 또는 너무 낮은지를 알려주게 됩니다.

numberguess 예제는 여러 Web Beans, 설정 파일, Facelet JSF 페이지로 구성되어 있으며, war로 패키지되어 있습니다 설정 파일부터 시작합시다.

예제에 해당하는 모든 설정 파일은 WEB-INF/에 위치해 있으며, 이는 소스 트리에 있는 WebContent에 저장되어 있습니다. 먼저, faces-config.xml을 사용하여, Facelets를 사용할 JSF를 알려주게 됩니다:

<?xml version='1.0' encoding='UTF-8'?>

<faces-config version="1.2"

              xmlns="http://java.sun.com/xml/ns/javaee"

              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">

    

    <application>

        <view-handler

>com.sun.facelets.FaceletViewHandler</view-handler>

    </application>



</faces-config

>

여기에는 빈 web-beans.xml 파일이 있어, 이는 Web Beans 애플리케이션으로 애플리케이션을 표시합니다.

마지막으로, web.xml 파일이 있습니다:

<?xml version="1.0" encoding="UTF-8"?>

<web-app version="2.5"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
   
   <display-name
>Web Beans Numbergues example</display-name>

   <!-- JSF -->
              
   <servlet>
      <servlet-name
>Faces Servlet</servlet-name>
      <servlet-class
>javax.faces.webapp.FacesServlet</servlet-class>
      <load-on-startup
>1</load-on-startup>
   </servlet>

   <servlet-mapping>
      <servlet-name
>Faces Servlet</servlet-name>
      <url-pattern
>*.jsf</url-pattern>
   </servlet-mapping>
              
   <context-param>
      <param-name
>javax.faces.DEFAULT_SUFFIX</param-name>
      <param-value
>.xhtml</param-value>
   </context-param>

   <session-config>
      <session-timeout
>10</session-timeout>
   </session-config>

</web-app
>

	Enable and load the JSF servlet
	Configure requests to .jsf pages to be handled by JSF
	Tell JSF that we will be giving our source files (facelets) an extension of .xhtml
	Configure a session timeout of 10 minutes

Let's take a look at the Facelet view:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:s="http://jboss.com/products/seam/taglib">

  <ui:composition template="template.xhtml">
    <ui:define name="content">
       <h1
>Guess a number...</h1>
       <h:form id="NumberGuessMain">
          <div style="color: red">
             <h:messages id="messages" globalOnly="false"/>
             <h:outputText id="Higher" value="Higher!" rendered="#{game.number gt game.guess and game.guess ne 0}"/>
             <h:outputText id="Lower" value="Lower!" rendered="#{game.number lt game.guess and game.guess ne 0}"/>
          </div>
   
          <div>
             I'm thinking of a number between #{game.smallest} and #{game.biggest}.
             You have #{game.remainingGuesses} guesses.
          </div>
     
          <div>
             Your guess: 
             <h:inputText id="inputGuess" 
                          value="#{game.guess}" 
                          required="true" 
                          size="3" 
                          disabled="#{game.number eq game.guess}">
                <f:validateLongRange maximum="#{game.biggest}" 
                                     minimum="#{game.smallest}"/>
             </h:inputText>
            <h:commandButton id="GuessButton"  
                             value="Guess" 
                             action="#{game.check}" 
                             disabled="#{game.number eq game.guess}"/>
          </div>
          <div>
            <h:commandButton id="RestartButton" value="Reset" action="#{game.reset}" immediate="true" />
          </div>
       </h:form>
    </ui:define>
  </ui:composition>
</html
>

	Facelets is a templating language for JSF, here we are wrapping our page in a template which defines the header.
	There are a number of messages which can be sent to the user, "Higher!", "Lower!" and "Correct!"
	As the user guesses, the range of numbers they can guess gets smaller - this sentance changes to make sure they know what range to guess in.
	This input field is bound to a Web Bean, using the value expression.
	A range validator is used to make sure the user doesn't accidentally input a number outside of the range in which they can guess - if the validator wasn't here, the user might use up a guess on an out of range number.
	And, of course, there must be a way for the user to send their guess to the server. Here we bind to an action method on the Web Bean.

예제에는 4 개의 클래스가 존재합니다, 첫 번째 두 개는 바인딩 유형입니다. 먼저, 임의의 숫자를 삽입하기 위해 사용되는 @Random 바인딩 유형이 있습니다:

@Target( { TYPE, METHOD, PARAMETER, FIELD })

@Retention(RUNTIME)

@Documented

@BindingType

public @interface Random {}

삽입될 수 있는 최대 번호 삽입하기 위해 사용되는 @MaxNumber 바인딩 유형도 있습니다:

@Target( { TYPE, METHOD, PARAMETER, FIELD })

@Retention(RUNTIME)

@Documented

@BindingType

public @interface MaxNumber {}

Generator 클래스는 생산자 방식을 통해 임의의 숫자를 생성해야 할 책임이 있습니다. 또한 이는 생산자 방식을 통하여 가능한 최대 숫자를 나타냅니다:

@ApplicationScoped

public class Generator {

   

   private java.util.Random random = new java.util.Random( System.currentTimeMillis() );

   

   private int maxNumber = 100;

   

   java.util.Random getRandom()

   {

      return random;

   }

   

   @Produces @Random int next() { 

      return getRandom().nextInt(maxNumber); 

   }

   

   @Produces @MaxNumber int getMaxNumber()

   {

      return maxNumber;

   }


}

Generator는 애플리케이션 범위로 되어 있음을 발견하실 것입니다; 따라서 매번 다른 임의 숫자를 갖지 않게 됩니다.

애플리케이션에 있는 마지막 Web Bean은 Game 범위 세션입니다.

@Named 어노테이션이 사용되므로 JSF 페이지에서 EL을 통해 bean을 사용할 수 있음을 인지하실 것입니다. 마지막으로 생성자 삽입을 사용하여 임의의 숫자로 게임을 초기화합니다. 물론, 게임 플레이어에게 언제 게임에어 이겼는지를 알려주어야 하므로, FacesMessage로 피드백을 제공합니다.

package org.jboss.webbeans.examples.numberguess;



import javax.annotation.PostConstruct;

import javax.faces.application.FacesMessage;

import javax.faces.context.FacesContext;

import javax.webbeans.AnnotationLiteral;

import javax.webbeans.Current;

import javax.webbeans.Initializer;

import javax.webbeans.Named;

import javax.webbeans.SessionScoped;

import javax.webbeans.manager.Manager;


@Named

@SessionScoped

public class Game

{

   private int number;

   

   private int guess;

   private int smallest;

   private int biggest;

   private int remainingGuesses;

   

   @Current Manager manager;

   

   public Game()

   {

   }

   

   @Initializer

   Game(@MaxNumber int maxNumber)

   {      

      this.biggest = maxNumber;

   }


   public int getNumber()

   {

      return number;

   }

   

   public int getGuess()

   {

      return guess;

   }

   

   public void setGuess(int guess)

   {

      this.guess = guess;

   }

   

   public int getSmallest()

   {

      return smallest;

   }

   

   public int getBiggest()

   {

      return biggest;

   }

   

   public int getRemainingGuesses()

   {

      return remainingGuesses;

   }

   

   public String check()

   {

      if (guess

>number)

      {

         biggest = guess - 1;

      }

      if (guess<number)

      {

         smallest = guess + 1;

      }

      if (guess == number)

      {

         FacesContext.getCurrentInstance().addMessage(null, new FacesMessage("Correct!"));

      }

      remainingGuesses--;

      return null;

   }

   

   @PostConstruct

   public void reset()

   {

      this.smallest = 0;

      this.guess = 0;

      this.remainingGuesses = 10;

      this.number = manager.getInstanceByType(Integer.class, new AnnotationLiteral<Random

>(){});

   }

   

}

<listener>
   <listener-class>org.jboss.webbeans.environment.tomcat.Listener</listener-class>
</listener>

번역 예제는 입력하신 아무 문장을 가져가 이를 라틴어로 번역합니다.

번역 예제는 ear로 작성되며, EJB가 들어있게 됩니다. 따라서, 문장 구조가 numberguess 예보다 훨씬 복잡합니다.

먼저, webbeans-translator-ear 모듈에 있는 ear aggregator를 살펴봅시다. Maven은 자동으로 application.xml을 생성합니다:

<plugin>

   <groupId

>org.apache.maven.plugins</groupId>

   <artifactId

>maven-ear-plugin</artifactId>

   <configuration>

      <modules>

         <webModule>

            <groupId

>org.jboss.webbeans.examples.translator</groupId>

            <artifactId

>webbeans-translator-war</artifactId>

            <contextRoot

>/webbeans-translator</contextRoot>

         </webModule>

      </modules>

   </configuration>

</plugin

>

url (http://localhost:8080/webbeans-translator)을 제공하는 컨텍스트 경로를 설정합니다.

<?xml version="1.0" encoding="UTF-8"?>

<application xmlns="http://java.sun.com/xml/ns/javaee" 

             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

             xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"

             version="5">

  <display-name

>webbeans-translator-ear</display-name>

  <description

>Ear Example for the reference implementation of JSR 299: Web Beans</description>

  

  <module>

    <web>

      <web-uri

>webbeans-translator.war</web-uri>

      <context-root

>/webbeans-translator</context-root>

    </web>

  </module>

  <module>

    <ejb

>webbeans-translator.jar</ejb>

  </module>

</application

>

Next, lets look at the war. Just as in the numberguess example, we have a faces-config.xml (to enable Facelets) and a web.xml (to enable JSF) in WebContent/WEB-INF.

텍스트를 번역하데 facelet이 사용됩니다. numberguess 예제에서와 같이 양식으로된 템플릿이 있습니다 (간결하게 하기 위해 여기서는 생략됨):

<h:form id="NumberGuessMain">

            

   <table>

      <tr align="center" style="font-weight: bold" >

         <td>

            Your text

         </td>

         <td>

            Translation

         </td>

      </tr>

      <tr>

         <td>

            <h:inputTextarea id="text" value="#{translator.text}" required="true" rows="5" cols="80" />

         </td>

         <td>

            <h:outputText value="#{translator.translatedText}" />

         </td>

      </tr>

   </table>

   <div>

      <h:commandButton id="button" value="Translate" action="#{translator.translate}"/>

   </div>

   

</h:form

>

사용자는 왼쪽 텍스트 부분에 텍스트를 입력할 수 있으며, 번역하기 버튼을 누르면 오른쪽에 번역 결과가 나타나게 됩니다.

마지막으로, ejb 모듈인 webbeans-translator-ejb를 살펴봅시다. src/main/resources/META-INF에는 Web Beans가 들어 있는 것으로 아카이브를 표시하기 위해 사용되는 빈 web-beans.xml이 있습니다.

가장 흥미로운 코드 부분은 마지막을 위해 남겨두겠습니다! 프로젝트에는 두 개의 심플 beans인 SentenceParser 및 TextTranslator와 두 개의 엔터프라이즈 beans인 TranslatorControllerBean 및 SentenceTranslator가 있습니다. 이제 Web Bean에 관해 보다 많이 알고 계실 것이므로, 가장 중요한 부분만 여기서 다루겠습니다.

SentenceParser 및 TextTranslator는 beans에 의존하며, TextTranslator는 생성자 초기화를 사용합니다:

public class TextTranslator { 

   private SentenceParser sentenceParser; 

   private Translator sentenceTranslator; 

   

   @Initializer

   TextTranslator(SentenceParser sentenceParser, Translator sentenceTranslator) 

   { 

      this.sentenceParser = sentenceParser; 

      this.sentenceTranslator = sentenceTranslator;

TextTranslator는 무상태 세션빈으로 (로컬 비지니스 인터페이스와 함께), 완전한 번역기를 개발할 수는 없지만, 잘 작동하고 있습니다!

마지막으로, UI 기반 제어기가 있어, 이는 사용자로 부터 텍스트를 수집하여 번역기에 이를 보냅니다. 이는 요청 범위, 이름, 상태 유지 세션빈으로 번역기에 삽입되어 있습니다.

@Stateful

@RequestScoped

@Named("translator")

public class TranslatorControllerBean implements TranslatorController

{

   

   @Current TextTranslator translator;

bean은 페이지에 있는 모든 영역에 대해 getter 및 setter를 갖습니다.

이는 상태 유지 세션 빈이므로, 제거 방식을 갖고 있어야 합니다:

   @Remove

   public void remove()

   {

      

   }

Web Beans 관리자는 bean이 삭제될 때 제거 방식을 호출하게 됩니다; 이러한 경우 요청 마지막에 호출하게 됩니다.

특정 API 유형을 구현하는 하나 이상의 Web Bean이 있을 경우, 삽입 지점은 바인딩 어노테이션을 사용하여 어떤 Web Bean이 삽입되어야 할 지를 지정할 수 있습니다. 예를 들어, PaymentProcessor의 두 가지 구현이 있을 수 있습니다:

@PayByCheque

public class ChequePaymentProcessor implements PaymentProcessor {

    public void process(Payment payment) { ... }

}

@PayByCreditCard

public class CreditCardPaymentProcessor implements PaymentProcessor {

    public void process(Payment payment) { ... }

}

여기서 @PayByCheque 및 @PayByCreditCard는 바인딩 어노테이션입니다:

@Retention(RUNTIME)

@Target({TYPE, METHOD, FIELD, PARAMETER})

@BindingType

public @interface PayByCheque {}

@Retention(RUNTIME)

@Target({TYPE, METHOD, FIELD, PARAMETER})

@BindingType

public @interface PayByCreditCard {}

클라이언트 Web Bean 개발자는 바인딩 어노테이션을 사용하여 정확히 어떤 Web Bean이 삽입되어야 하는 지를 지정합니다.

영역 삽입 사용:

@PayByCheque PaymentProcessor chequePaymentProcessor;

@PayByCreditCard PaymentProcessor creditCardPaymentProcessor;

초기화 방식 삽입 사용:

@Initializer

public void setPaymentProcessors(@PayByCheque PaymentProcessor chequePaymentProcessor, 

                                 @PayByCreditCard PaymentProcessor creditCardPaymentProcessor) {

   this.chequePaymentProcessor = chequePaymentProcessor;

   this.creditCardPaymentProcessor = creditCardPaymentProcessor;

}

생성자 삽입 사용:

@Initializer

public Checkout(@PayByCheque PaymentProcessor chequePaymentProcessor, 

                @PayByCreditCard PaymentProcessor creditCardPaymentProcessor) {

   this.chequePaymentProcessor = chequePaymentProcessor;

   this.creditCardPaymentProcessor = creditCardPaymentProcessor;

}

@Retention(RUNTIME)

@Target({TYPE, METHOD, FIELD, PARAMETER})

@BindingType

public @interface PayBy {

    PaymentType value();

}

@PayBy(CHEQUE) PaymentProcessor chequePaymentProcessor;

@PayBy(CREDIT_CARD) PaymentProcessor creditCardPaymentProcessor;

@Asynchronous @PayByCheque PaymentProcessor paymentProcessor

@Produces 

@Asynchronous @PayByCheque 

PaymentProcessor createAsyncPaymentProcessor(@PayByCheque PaymentProcessor processor) {

    return new AsynchronousPaymentProcessor(processor);

}

모든 Web Beans는 배치 유형을 갖습니다. 각각의 배치 유형은 시스템의 일부 배치에 조건부로 설치되어야 하는 Web Beans 모음을 인식합니다.

예를 들어, @Mock라는 배치 유형을 정의할 수 있으며, 이는 시스템이 통합적인 테스트 환경 내에서 실행될 때 설치되어야 하는 Web Beans를 인식합니다:

@Retention(RUNTIME)

  @Target({TYPE, METHOD})

  @DeploymentType

  public @interface Mock {}

지불 절차를 처리하기 위한 외부적 시스템과 상호 작용하는 일부 Web Bean이 있다고 가정합시다:

public class ExternalPaymentProcessor {

        

    public void process(Payment p) {

        ...

    }

    

}

이러한 Web Bean이 배치 유형을 명시적을 지정하지 않고 있으므로, 이는 기본값 배치 유형 @Production을 갖게 됩니다.

통합 또는 단위 테스트를 위해 외부적 시스템은 속도가 느리거나 또는 사용 불가능합니다. 따라서 모의 객체를 생성할 수 있습니다:

@Mock 

public class MockPaymentProcessor implements PaymentProcessor {


    @Override

    public void process(Payment p) {

        p.setSuccessful(true);

    }


}

하지만 Web Bean 관리자가 특정 배치에 어떤 구현을 사용할 지를 어떻게 결정할까요?

<WebBeans>

    <Deploy>

        <Standard/>

        <Production/>

        <test:Mock/>

    </Deploy>

</WebBeans

>

@Current PaymentProcessor paymentProcessor

바인딩 어노테이션 및 삽입 지점의 API 유형을 구현하는 모든 Web Beans의 배치 유형을 고려한 후, Web Bean 관리자는 삽입할 하나의 Web Bean을 인식하지 못할 경우 타입 안정적 해상도 알고리즘은 실패하게 됩니다.

UnsatisfiedDependencyException 또는 AmbiguousDependencyException을 수정하기가 쉽습니다.

UnsatisfiedDependencyException을 수정하려면, API 유형을 구현하는 Web Bean을 제공하고 삽입 지점의 바인딩 유형을 갖거나 — 또는 API 유형을 이미 구현하고 있는 Web Bean의 배치 유형을 활성화하고 바인딩 유형을 갖습니다.

AmbiguousDependencyException을 수정하려면, 두 개의 API 유형 구현 사이에서 구별하기 위해 바인딩 유형을 소개하거나 구현 중 하나의 배치 유형을 변경하여 Web Bean 관리자가 이들 사이에서 선택하기 위해 배치 유형 우선 순위를 사용할 수 있습니다. AmbiguousDependencyException은 두 개의 Web Beans가 바인딩 유형을 공유하여 동일한 배치 유형을 갖고 있을 때에만 발생할 수 있습니다.

Web Beans에서 의존성 삽입을 사용할 때 유의하셔야 할 사항이 한 가지 더 있습니다.

삽입된 Web Bean 클라이언트는 Web Bean 인스턴스에 직접적인 참조를 유지하지 않습니다.

요청 범위로 바운딩된 Web Bean으로의 직접 참조를 보유하고 있는 애플리케이션 범위에 바운딩된 Web Bean을 가정해 봅시다. 애플리케이션 범위에 바운딩된 Web Bean은 다른 많은 요청 사이에서 공유됩니다. 하지만, 각각의 요청은 요청 범위로 바운딩된 Web Bean의 다른 인스턴스를 확인해야 합니다!

이제 애플리케이션 범위로 바운딩된 Web Bean으로의 직접 참조를 보유하고 있는 세션 범위에 바운딩된 Web Bean을 가정해 봅시다. 때때로 세션 컨텍스트는 메모리를 보다 효과적으로 사용하기 위해 디스크 순서대로 나열됩니다. 하지만, 애플리케이션 범위로 바운딩된 Web Bean 인스턴스는 세션 범위로 바운딩된 Web Bean과 함께 나열되어서는 안됩니다!

따라서, Web Bean은 기본값 범위 @Dependent를 갖지 않는 한, Web Bean 관리자는 프록시 객체를 통해 삽입된 모든 참조를 Web Bean으로 돌려 놓아야 합니다. 이러한 클라이언트 프록시는 방식 호출을 받는 Web Bean 인스턴스가 현재 컨텍스트와 관련된 인스턴스임을 확인해야 할 책임이 있습니다. 또한 클라이언트 프록시는 Web Beans가 삽입된 다른 Web Beans를 귀납적으로 나열하지 않고 디스크 순서대로 나열한 세션 컨텍스트와 같은 컨텍스트로 바운딩되게 합니다.

Java 언어의 한계로 인해, 일부 Java 유형은 Web Bean 관리자에 의해 프록시될 수 없습니다. 따라서, 삽입 지점 유형이 프록시될 수 없을 경우 Web Bean 관리자는 UnproxyableDependencyException을 던지게 됩니다.

다음과 같은 Java 유형은 Web Bean 관리자에 의해 프록시될 수 없습니다:

UnproxyableDependencyException을 수정하기 쉽습니다. 간단하게 삽입된 클래스에 매개 변수가 없는 생성자를 추가하고, 인터페이스를 소개하거나, 삽입된 Web Bean의 범위를 @Dependent로 변경합니다.

애플리케이션은 삽입에 의해 Manager 인터페이스의 인스턴스를 획득할 수 있습니다:

@Current Manager manager;

Manager 객체는 프로그램적으로 Web Bean 인스턴스의 획득을 위한 방식 모음을 제공합니다.

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class);

바인딩 어노테이션은 AnnotationLiteral 도우미 클래스를 하부클래스화하여 지정될 수 있으며, 그렇지 않으면 Java에서 어노테이션 유형을 인스턴스화하기 어렵습니다.

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new AnnotationLiteral<CreditCard

>(){});

바인딩 유형이 어노테이션 멤버를 갖을 경우, AnnotationLiteral의 임의의 하부클래스를 사용할 수 없습니다 — 대신 named 하부 클래스를 생성해야 합니다:

abstract class CreditCardBinding 

    extends AnnotationLiteral<CreditCard

> 

    implements CreditCard {}

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new CreditCardBinding() { 

                                                   public void value() { return paymentType; } 

                                               } );

Enterprise Web Beans는 EJB 사양에 의해 정의된 모든 수명 주기 콜백을 지원합니다: @PostConstruct, @PreDestroy, @PrePassivate 및 @PostActivate.

심플 Web Beans는 @PostConstruct 및 @PreDestroy 콜백 기능만을 지원합니다.

엔터프라이즈 및 심플 Web Beans는 Java EE 리소스 삽입, EJB 및 JPA 영구적 컨텍스에 대해 @Resource, @EJB 및 @PersistenceContext의 사용을 각각 지원합니다. 심플 Web Beans는 @PersistenceContext(type=EXTENDED)의 사용을 지원하지 않습니다.

@PostConstruct 콜백은 모든 의존성이 삽입된 후에 나타납니다.

특정 종류의 의존성 객체가 있습니다 — @Dependent 범위와 함께 Web Beans — 객체 또는 이는 실행 가능하게 되기 위해 삽입되는 삽입 지점에 관해 알아야 합니다. 예:

@Dependent 범위와 함께 Web Bean은 InjectionPoint 인스턴스를 삽입하고 해당 삽입 지점에 관련된 메타데이트를 액세스합니다.

다음 예를 살펴봅시다. 다음과 같은 코드는 프로그램을 리팩토링하기에 취약하고 장황합니다:

Logger log = Logger.getLogger(MyClass.class.getName());

이와 같이 현명한 생산자 방식은 로그 범주를 명시적으로 지정하지 않고 JDK Logger를 삽입하게 합니다:

class LogFactory {


   @Produces Logger createLogger(InjectionPoint injectionPoint) { 

      return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName()); 

   }


}

이제 다음을 작성할 수 있습니다:

@Current Logger log;

확신하시지 않습니까? 그러시다면 여기에 두 번째 예제가 있습니다. HTTP 매개 변수를 삽입하려면, 바인딩 유형을 정의해야 합니다:

@BindingType

@Retention(RUNTIME)

@Target({TYPE, METHOD, FIELD, PARAMETER})

public @interface HttpParam {

   @NonBinding public String value();

}

다음과 같이 삽입 지점에서 이러한 바인딩 유형을 사용할 수 있습니다:

@HttpParam("username") String username;

@HttpParam("password") String password;

다음의 생산자 방식은 다음과 같이 작업합니다:

class HttpParams


   @Produces @HttpParam("")

   String getParamValue(ServletRequest request, InjectionPoint ip) {

      return request.getParameter(ip.getAnnotation(HttpParam.class).value());

   }


}

HttpParam 어노테이션의 value() 멤버는@NonBinding.을 어노테이션하므로 Web Bean 관리자에 의해 무시됨에 유의하시기 바랍니다.

Web Bean 관리자는 InjectionPoint 인터페이스를 구현하는 내장된 Web Bean을 제공합니다:

public interface InjectionPoint { 

   public Object getInstance(); 

   public Bean<?> getBean(); 

   public Member getMember(): 

   public <T extends Annotation

> T getAnnotation(Class<T

> annotation); 

   public Set<T extends Annotation

> getAnnotations(); 

}

Web Beans는 extensible context model을 특징으로 합니다. 새로운 범위 유형 어노테이션을 생성하여 새로운 범위를 정의할 수 있습니다:

@Retention(RUNTIME)

@Target({TYPE, METHOD})

@ScopeType

public @interface ClusterScoped {}

물론 이는 이러한 작업 중 쉬운 부분입니다. 이러한 범위 유형을 유용하게 하려면, 범위를 구현하는 Context 객체를 정의해야 합니다! Context 구현은 아주 기술적인 작업으로, 프레임워크 개발 만을 목적으로 합니다.

Web Bean 범위를 지정하기 위해 Web Bean 구현 클래스에 범위 유형 어노테이션을 적용할 수 있습니다:

@ClusterScoped

public class SecondLevelCache { ... }

주로, Web Beans의 내장된 범위 중 하나를 사용하게 됩니다.

Web Beans는 네 가지 내장된 범위를 정의합니다:

Web Beans를 사용하는 웹 애플리케이션의 경우:

요청 및 애플리케이션 범위도 활성화되어 있습니다:

애플리케이션이 활성 컨텍스트가 없는 범위와 함께 Web Bean을 호출하고자할 경우, 런타임시 ContextNotActiveException은 Web Bean 관리자에 의해 넘기게 됩니다.

네 개의 내장된 범위 중 세 개는 모든 Java EE 개발자에게 익숙하므로, 여기서 다루지 않겠습니다. 하지만 이 중 하나의 범위 새로운 것입니다.

Web Beans 컨버세이션 범위는 시스템 사용자와 관련된 상태를 보유하고 있는 전통 세션 범위와 유사하며, 서버에 여러 가지 요청을 보냅니다. 하지만, 세션 범위와 다르게 컨버세이션 범위는 다음과 같은 사항을 갖습니다:

컨버세이션은 사용자 관점에서의 작업 단위, 작업 내용을 나타냅니다. 컨버세이션 컨텍스트는 현재 사용자가 작업하고 있는 것과 관련된 상태를 유지합니다. 사용자가 동시에 여러가지 작업을 실행하고 있을 경우, 여러 개의 컨버세이션이 있게 됩니다.

컨버세이션 컨텍스트는 JSF 요청 시 활성화되어 있습니다. 하지만 대부분의 컨버세이션은 요청 마지막에 삭제됩니다. 컨버세이션이 여러 가지 요청을 통해 상태를 유지해야 할 경우, 장기 실행 컨버세이션으로 요청되어야 합니다.

@Current Conversation conversation;

@ConversationScoped @Stateful

public class OrderBuilder {


    private Order order;

    private @Current Conversation conversation;

    private @PersistenceContext(type=EXTENDED) EntityManager em;

    

    @Produces public Order getOrder() {

        return order;

    }


    public Order createOrder() {

        order = new Order();

        conversation.begin();

        return order;

    }

    

    public void addLineItem(Product product, int quantity) {

        order.add( new LineItem(product, quantity) );

    }


    public void saveOrder(Order order) {

        em.persist(order);

        conversation.end();

    }

    

    @Remove

    public void destroy() {}

    

}

<a href="/addProduct.jsp?cid=#{conversation.id}"
>Add Product</a
>

conversation.setTimeout(timeoutInMillis);

네 가지 내장된 범위에 더하여, Web Beans는 dependent pseudo-scope라는 기능을 특징으로 합니다. 이는 범위 유형을 명시하지 않는 Web Bean에 대한 기본값 범위입니다.

예를 들어, Web Bean에는 @Dependent 범위 유형이 있습니다:

public class Calculator { ... }

Web Bean의 삽입 지점이 의존적 Web Bean을 해결할 때, 의존적 Web Bean의 새로운 인스턴스는 처음으로 Web Bean이 초기화될 때 마다 생성됩니다. 의존적 Web Beans의 인스턴스는 다른 Web Bean 사이에서나 또는 다른 삽입 지점 간에 공유되지 않습니다. 이는 일부 다른 Web Bean 인스턴스에 대해 의존적 객체입니다.

의존하는 인스턴스가 삭제되면 의존적 Web Bean 인스턴스가 삭제됩니다.

클래스 또는 EJB bean이 일부 다른 범위 유형과 함께 Web Bean으로 명시되어 있어도, Web Beans는 Java 클래스 또는 EJB bean의 의존적 인스턴스를 쉽게 획득할 수 있게 합니다.

@New Calculator calculator;

@ConversationScoped

public class Calculator { ... }

public class PaymentCalc {


    @Current Calculator calculator;

    @New Calculator newCalculator;


}

생산자 방식의 기본값 범위는 @Dependent로 되어 있으므로, 매 번 Web Bean 관리자가 이러한 영역 또는 동일한 생산자 방식으로 해결되는 다른 영역을 삽입할 때 마다 호출됩니다. 따라서, 각각의 사용자 세션에 대해 PaymentStrategy 객체의 인스턴스가 여러개 있을 수 있습니다.

이러한 기능을 변경하려면, @SessionScoped 어노테이션 방식을 추가할 수 있습니다.

@Produces @Preferred @SessionScoped

public PaymentStrategy getPaymentStrategy() {

    ...

}

이제 생산자 방식이 호출되면, 반환된 PaymentStrategy는 세션 컨텍스트로 바운드됩니다. 동일한 세션에서 생산자 방식은 다시 호출되지 않습니다.

위의 코드에 한 가지 문제가 있을 수 있습니다. CreditCardPaymentStrategy 구현은 Java new 연산자를 사용하여 인스턴스화됩니다. 애플리케이션에 의해 직접 인스턴스화된 객체는 의존성 삽입의 장점을 취할 수 없으며 인터셉터를 갖지 못합니다.

이러한 방식을 원하지 않을 경우, 의존성 삽입을 생산자 방식으로 사용하여 Web Bean 인스턴스를 획득할 수 있습니다:

@Produces @Preferred @SessionScoped

public PaymentStrategy getPaymentStrategy(CreditCardPaymentStrategy ccps,

                                          ChequePaymentStrategy cps,

                                          PayPalPaymentStrategy ppps) {

    switch (paymentStrategy) {

        case CREDIT_CARD: return ccps;

        case CHEQUE: return cps;

        case PAYPAL: return ppps;

        default: return null;

    } 

}

CreditCardPaymentStrategy가 요청 범위 Web Bean이면 어떻게 합니까? 이럴 경우 생산자 방식은 현재 요청 범위 임스턴스를 세선 범위로 "활성화되게" 됩니다. 이는 버그입니다! 요청 범위 객체는 세션이 종료되기 전 Web Bean 관리자에 의해 삭제되지만, 객체에 대한 참조는 세션 범위에 "남아 있게" 됩니다. 이러한 오류는 Web Bean 관리자에 의해 검출되지 않으므로 생산자 방식에 Web Bean 인스턴스를 반환할 경우 각별히 주의하시기 바랍니다!

이러한 버그를 해결할 수 있는 세 가지 방법이 있습니다. CreditCardPaymentStrategy 구현 범위를 변경할 수 있지만, Web Bean의 클라이언트에 영향을 미칠 수 있습니다. 보다 나은 방법으로 생산자 방식의 범위를 @Dependent 또는 @RequestScoped로 변경하는 것입니다.

하지만 보다 일반적인 방법은 특별한 @New 바인딩 어노테이션을 사용하는 것입니다.

다음과 같은 생산자 방식을 고려합니다:

@Produces @Preferred @SessionScoped

public PaymentStrategy getPaymentStrategy(@New CreditCardPaymentStrategy ccps,

                                          @New ChequePaymentStrategy cps,

                                          @New PayPalPaymentStrategy ppps) {

    switch (paymentStrategy) {

        case CREDIT_CARD: return ccps;

        case CHEQUE: return cps;

        case PAYPAL: return ppps;

        default: return null;

    } 

}

CreditCardPaymentStrategy의 새로운 의존성 인스턴스가 생성되면, 생산자 방식으로 전달하고, 생산자 방식에 의해 반환된 후, 마지막으로 세션 컨텍스트로 바운딩됩니다. 의존성 객체는 세션 마지막에 Preferences 객체가 삭제될 때 까지 삭제되지 않습니다.