With certain, very special exceptions, every Java class with a constructor that accepts no parameters is a Web Bean. That includes every JavaBean. Furthermore, every EJB 3-style session bean is a Web Bean. Sure, the JavaBeans and EJBs you've been writing every day have not been able to take advantage of the new services defined by the Web Beans specification, but you'll be able to use every one of them as Web Beans — injecting them into other Web Beans, configuring them via the Web Beans XML configuration facility, even adding interceptors and decorators to them — without touching your existing code.

Suponha que temos duas classes Java existentes, que temos utilizado por anos em várias aplicações. A primeira classe faz a divisão (parse) de uma string em uma lista de sentenças:

public class SentenceParser {

    public List<String

> parse(String text) { ... }

}

A segunda classe existente é um stateless session bean de fachada (front-end) para um sistema externo que é capaz de traduzir frases de uma língua para outra:

@Stateless

public class SentenceTranslator implements Translator {

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

}

Onde Translator é a interface local:

@Local

public interface Translator {

    public String translate(String sentence);

}

Infelizmente, não temos uma classe preexistente que traduz todo texto de documentos. Então vamos escrever um Web Bean que faz este trabalho:

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();

    }

    

}

Podemos obter uma instância de TextTranslator injetando-a em um Web Bean, Servlet ou EJB:

@Initializer

public setTextTranslator(TextTranslator textTranslator) {

    this.textTranslator = textTranslator;

}

Alternativamente, nós podemos obter uma instância invocando diretamente o método do gerenciador do Web Bean:

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

But wait: TextTranslator does not have a constructor with no parameters! Is it still a Web Bean? Well, a class that does not have a constructor with no parameters can still be a Web Bean if it has a constructor annotated @Initializer.

As you've guessed, the @Initializer annotation has something to do with dependency injection! @Initializer may be applied to a constructor or method of a Web Bean, and tells the Web Bean manager to call that constructor or method when instantiating the Web Bean. The Web Bean manager will inject other Web Beans to the parameters of the constructor or method.

At system initialization time, the Web Bean manager must validate that exactly one Web Bean exists which satisfies each injection point. In our example, if no implementation of Translator available — if the SentenceTranslator EJB was not deployed — the Web Bean manager would throw an UnsatisfiedDependencyException. If more than one implementation of Translator was available, the Web Bean manager would throw an AmbiguousDependencyException.

Então, o que, exatamente, é um Web Bean?

A Web Bean is an application class that contains business logic. A Web Bean may be called directly from Java code, or it may be invoked via Unified EL. A Web Bean may access transactional resources. Dependencies between Web Beans are managed automatically by the Web Bean manager. Most Web Beans are stateful and contextual. The lifecycle of a Web Bean is always managed by the Web Bean manager.

Let's back up a second. What does it really mean to be "contextual"? Since Web Beans may be stateful, it matters which bean instance I have. Unlike a stateless component model (for example, stateless session beans) or a singleton component model (such as servlets, or singleton beans), different clients of a Web Bean see the Web Bean in different states. The client-visible state depends upon which instance of the Web Bean the client has a reference to.

No entanto, como o modelo stateless ou singleton, mas ao contrário dos stateful session beans, o cliente não controla o ciclo de vida da instância por explicitamente criar e destruí-lo. Em vez disso, o escopo do Web Bean determina:

For a given thread in a Web Beans application, there may be an active context associated with the scope of the Web Bean. This context may be unique to the thread (for example, if the Web Bean is request scoped), or it may be shared with certain other threads (for example, if the Web Bean is session scoped) or even all other threads (if it is application scoped).

Clients (for example, other Web Beans) executing in the same context will see the same instance of the Web Bean. But clients in a different context will see a different instance.

One great advantage of the contextual model is that it allows stateful Web Beans to be treated like services! The client need not concern itself with managing the lifecycle of the Web Bean it is using, nor does it even need to know what that lifecyle is. Web Beans interact by passing messages, and the Web Bean implementations define the lifecycle of their own state. The Web Beans are loosely coupled because:

We can replace one Web Bean with a different Web Bean that implements the same API and has a different lifecycle (a different scope) without affecting the other Web Bean implementation. In fact, Web Beans defines a sophisticated facility for overriding Web Bean implementations at deployment time, as we will see in Seção 4.2, “Tipo de deploy”.

Note que nem todos os clientes de um Web Bean são Web Beans. Outros objetos, tais como Servlets ou Message-Driven Beans — que são, por natureza, não injetável, objetos contextuais — podem também obter referências a Web Beans por injeção.

Chega de mão abanando. Mais formalmente, de acordo com a especificação:

Vamos ver o que alguns destes termos significam, para o desenvolvedor 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 { ... }

We've already seen that JavaBeans, EJBs and some other Java classes can be Web Beans. But exactly what kinds of objects are 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();

}

Você precisa fazer o download do JBoss AS 5.0.1.GA em jboss.org e descompactá-lo. Por exemplo:"

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

Depois, faça o download da Web Beans em seamframework.org e descompacte-o. Por exemplo

$ cd ~/
$ unzip ~/webbeans-1.0.0.ALPHA1.zip

Em seguida, temos de dizer aos Web Beans onde o JBoss está localizado. Editar o jboss-as/build.properties e definir a propriedade jboss.home. Por exemplo:

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

Para instalar a Web Beans, você precisará do Ant 1.7.0 instalado e a variável de ambiente ANT_HOME setada. Por exemplo:

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

Então, você pode instalar a atualização. O script de atualização irá utilizar o Maven para fazer o download da Web Beans automaticamente.

$ cd webbeans-1.0.0.ALPHA1/jboss-as
$ ant update

Agora, você está pronto para fazer a publicação do seu primeiro exemplo!

Para implantar o exemplo numberguess:

$ cd examples/numberguess
ant deploy

Inicializando o JBoss AS:

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

Aguarde até que a aplicação seja implantada, e desfrute de horas de diversão em 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

Aguarde até que a aplicação seja implantada, e acesse http://localhost:8080/webbeans-translator!

Depois, faça o download do Tomcat 6.0.18 ou posterior em tomcat.apache.org, e descompacte-o. Por exemplo

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

Depois, faça o download da Web Beans em seamframework.org e descompacte-o. Por exemplo

$ cd ~/
$ unzip ~/webbeans-1.0.0.ALPHA1.zip

Em seguida, temos de dizer aos Web Beans onde o Tomcat está localizado. Editar o jboss-as/build.properties e definir a propriedade tomcat.home. Por exemplo:

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

Para implantar o exemplo numberguess no tomcat:

$ cd examples/tomcat
ant tomcat.deploy

Inicializando o Tomcat:

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

Aguarde até que a aplicação seja implantada, e desfrute de horas de diversão em http://localhost:8080/webbeans-numberguess!

TODO

Na aplicação numberguess você terá 10 tentativas para adivinhar um número entre 1 e 100. Após cada tentativa, você será informado se você disse muito acima, ou muito a baixo.

O exemplo numberguess é composto de um número de Web Beans, arquivos de configuração, e páginas Facelet JSF , empacotados como um war. Vamos começar com os arquivos de configuração.

All the configuration files for this example are located in WEB-INF/, which is stored in WebContent in the source tree. First, we have faces-config.xml, in which we tell JSF to use Facelets:

<?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

>

Existe um arquivo web-beans.xml vazio, que assinala esta aplicação como uma aplicação Web Beans.

Finalmente no 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.

The example exists of 4 classes, the first two of which are binding types. First, there is the @Random binding type, used for injecting a random number:

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

@Retention(RUNTIME)

@Documented

@BindingType

public @interface Random {}

Há também o binding type @MaxNumber, utilizado para injetar o número máximo que pode ser injetado:

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

@Retention(RUNTIME)

@Documented

@BindingType

public @interface MaxNumber {}

A classe Generator é responsável por criar um número aleatório, através de um método produtor. Ela também expõe o número máximo possível através de um método produtor:

@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;

   }


}

Você perceberá que o Generator está no escopo de aplicação; portanto, não obtemos um número aleatório diferente a cada vez.

O Web Bean final da aplicação é o Game em escopo de sessão.

You'll note that we've used the @Named annotation, so that we can use the bean through EL in the JSF page. Finally, we've used constructor injection to initialize the game with a random number. And of course, we need to tell the player when they've won, so we give feedback with a 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
>

O exemplo translator pegará qualquer frase que você fornecer, e traduzi-las para o Latim.

O exemplo translator é construído como um ear, e contém EJBs. Como resultado, a sua estrutura é mais complexa do que exemplo numberguess.

First, let's take a look at the ear aggregator, which is located in webbeans-translator-ear module. Maven automatically generates the application.xml for us:

<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

>

Aqui nós definiremos o caminho do contexto, que nos dá uma url amigável (http://localhost:8080/webbeans-translator). ulink>) .

<?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.

Mais interessante é o facelet utilizado para traduzir texto. Tal como no exemplo numberguess temos um template, que envolve o formulário (omitido aqui por brevitude):

<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

>

O usuário pode digitar um texto no textarea esquerdo, e clicar no botão traduzir para ver o resultado à direita.

Finally, let's look at the ejb module, webbeans-translator-ejb. In src/main/resources/META-INF there is just an empty web-beans.xml, used to mark the archive as containing Web Beans.

We've saved the most interesting bit to last, the code! The project has two simple beans, SentenceParser and TextTranslator and two enterprise beans, TranslatorControllerBean and SentenceTranslator. You should be getting quite familiar with what a Web Bean looks like by now, so we'll just highlight the most interesting bits here.

Tanto SentenceParser e TextTranslator são beans dependentes, e TextTranslator usa inicialização por construtor :

<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

>

TextTranslator é um bean stateless (com uma interface de negócios local), onde a mágica acontece - obviamente, não poderíamos desenvolver um tradutor completo, mas demos-lhe um bom caminho!

Finally, there is UI orientated controller, that collects the text from the user, and dispatches it to the translator. This is a request scoped, named, stateful session bean, which injects the translator.

@Stateful

@RequestScoped

@Named("translator")

public class TranslatorControllerBean implements TranslatorController

{

   

   @Current TextTranslator translator;

O bean também tem getters e setters para todos os campos da página.

Como esse é um stateful session bean, temos de ter um método de remoção:

   @Remove

   public void remove()

   {

      

   }

O gerenciador do Web Beans irá chamar o método remover para você quando o bean for destruído, neste caso no final da requisição.

If we have more than one Web Bean that implements a particular API type, the injection point can specify exactly which Web Bean should be injected using a binding annotation. For example, there might be two implementations of PaymentProcessor:

@PayByCheque

public class ChequePaymentProcessor implements PaymentProcessor {

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

}

@PayByCreditCard

public class CreditCardPaymentProcessor implements PaymentProcessor {

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

}

Onde @PayByCheque e @PayByCreditCard são anotações de binding:

@Retention(RUNTIME)

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

@BindingType

public @interface PayByCheque {}

@Retention(RUNTIME)

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

@BindingType

public @interface PayByCreditCard {}

Um desenvolvedor cliente de um Web Bean utiliza a anotação de binding para especificar exatamente quais Web Bean devem ser injetados.

Utilizando injeção por campos (field injection):

@PayByCheque PaymentProcessor chequePaymentProcessor;

@PayByCreditCard PaymentProcessor creditCardPaymentProcessor;

Utilizando injeção de método de inicialização:

@Initializer

public void setPaymentProcessors(@PayByCheque PaymentProcessor chequePaymentProcessor, 

                                 @PayByCreditCard PaymentProcessor creditCardPaymentProcessor) {

   this.chequePaymentProcessor = chequePaymentProcessor;

   this.creditCardPaymentProcessor = creditCardPaymentProcessor;

}

Ou utilizando injeção de construtor

@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);

}

All Web Beans have a deployment type. Each deployment type identifies a set of Web Beans that should be conditionally installed in some deployments of the system.

For example, we could define a deployment type named @Mock, which would identify Web Beans that should only be installed when the system executes inside an integration testing environment:

@Retention(RUNTIME)

  @Target({TYPE, METHOD})

  @DeploymentType

  public @interface Mock {}

Suponha que temos alguns Web Beans que interajam com um sistema externo para processar pagamentos:

public class ExternalPaymentProcessor {

        

    public void process(Payment p) {

        ...

    }

    

}

Uma vez que esse Web Bean não especifica explicitamente um tipo de implantação, ele tem o tipo de implantação padrão @Production.

For integration or unit testing, the external system is slow or unavailable. So we would create a mock object:

@Mock 

public class MockPaymentProcessor implements PaymentProcessor {


    @Override

    public void process(Payment p) {

        p.setSuccessful(true);

    }


}

But how does the Web Bean manager determine which implementation to use in a particular deployment?

<WebBeans>

    <Deploy>

        <Standard/>

        <Production/>

        <test:Mock/>

    </Deploy>

</WebBeans

>

@Current PaymentProcessor paymentProcessor

The typesafe resolution algorithm fails when, after considering the binding annotations and and deployment types of all Web Beans that implement the API type of an injection point, the Web Bean manager is unable to identify exactly one Web Bean to inject.

It's usually easy to fix an UnsatisfiedDependencyException or AmbiguousDependencyException.

To fix an UnsatisfiedDependencyException, simply provide a Web Bean which implements the API type and has the binding types of the injection point — or enable the deployment type of a Web Bean that already implements the API type and has the binding types.

To fix an AmbiguousDependencyException, introduce a binding type to distinguish between the two implementations of the API type, or change the deployment type of one of the implementations so that the Web Bean manager can use deployment type precedence to choose between them. An AmbiguousDependencyException can only occur if two Web Beans share a binding type and have exactly the same deployment type.

There's one more issue you need to be aware of when using dependency injection in Web Beans.

Clientes de um Web Bean injetado, geralmente não possuem uma referência direta a uma instância do Web Bean .

Imagine that a Web Bean bound to the application scope held a direct reference to a Web Bean bound to the request scope. The application scoped Web Bean is shared between many different requests. However, each request should see a different instance of the request scoped Web bean!

Now imagine that a Web Bean bound to the session scope held a direct reference to a Web Bean bound to the application scope. From time to time, the session context is serialized to disk in order to use memory more efficiently. However, the application scoped Web Bean instance should not be serialized along with the session scoped Web Bean!

Therefore, unless a Web Bean has the default scope @Dependent, the Web Bean manager must indirect all injected references to the Web Bean through a proxy object. This client proxy is responsible for ensuring that the Web Bean instance that receives a method invocation is the instance that is associated with the current context. The client proxy also allows Web Beans bound to contexts such as the session context to be serialized to disk without recursively serializing other injected Web Beans.

Unfortunately, due to limitations of the Java language, some Java types cannot be proxied by the Web Bean manager. Therefore, the Web Bean manager throws an UnproxyableDependencyException if the type of an injection point cannot be proxied.

Os seguintes tipos Java não podem ser "proxied" pelo gerenciador do Web Bean:

It's usually very easy to fix an UnproxyableDependencyException. Simply add a constructor with no parameters to the injected class, introduce an interface, or change the scope of the injected Web Bean to @Dependent.

A aplicação pode obter uma instância da interface Manager por injeção:

@Current Manager manager;

O objeto Manager fornece um conjunto de métodos para a obtenção de uma instância de um Web Bean programaticamente.

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

Binding annotations may be specified by subclassing the helper class AnnotationLiteral, since it is otherwise difficult to instantiate an annotation type in Java.

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new AnnotationLiteral<CreditCard

>(){});

If the binding type has an annotation member, we can't use an anonymous subclass of AnnotationLiteral — instead we'll need to create a named subclass:

abstract class CreditCardBinding 

    extends AnnotationLiteral<CreditCard

> 

    implements CreditCard {}

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new CreditCardBinding() { 

                                                   public void value() { return paymentType; } 

                                               } );

Enterprise Web Beans support all the lifecycle callbacks defined by the EJB specification: @PostConstruct, @PreDestroy, @PrePassivate and @PostActivate.

Web Beans simples suportam apenas chamadas a @PostConstruct e @PreDestroy.

Both enterprise and simple Web Beans support the use of @Resource, @EJB and @PersistenceContext for injection of Java EE resources, EJBs and JPA persistence contexts, respectively. Simple Web Beans do not support the use of @PersistenceContext(type=EXTENDED).

A chamada ao @PostConstruct sempre ocorre após todas as dependências serem injetadas.

There are certain kinds of dependent objects — Web Beans with scope @Dependent — that need to know something about the object or injection point into which they are injected in order to be able to do what they do. For example:

A Web Bean with scope @Dependent may inject an instance of InjectionPoint and access metadata relating to the injection point to which it belongs.

Let's look at an example. The following code is verbose, and vulnerable to refactoring problems:

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

This clever little producer method lets you inject a JDK Logger without explicitly specifying the log category:

class LogFactory {


   @Produces Logger createLogger(InjectionPoint injectionPoint) { 

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

   }


}

Podemos agora escrever:

@Current Logger log;

Not convinced? Then here's a second example. To inject HTTP parameters, we need to define a binding type:

@BindingType

@Retention(RUNTIME)

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

public @interface HttpParam {

   @NonBinding public String value();

}

We would use this binding type at injection points as follows:

@HttpParam("username") String username;

@HttpParam("password") String password;

O seguinte método produtor faz o trabalho:

class HttpParams


   @Produces @HttpParam("")

   String getParamValue(ServletRequest request, InjectionPoint ip) {

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

   }


}

(Note that the value() member of the HttpParam annotation is ignored by the Web Bean manager since it is annotated @NonBinding.)

The Web Bean manager provides a built-in Web Bean that implements the InjectionPoint interface:

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 possui um modelo extensível de contexto. É possível definir novos escopos, criando uma nova anotação de tipo de escopo:

@Retention(RUNTIME)

@Target({TYPE, METHOD})

@ScopeType

public @interface ClusterScoped {}

Evidentemente, essa é a parte mais fácil do trabalho. Para este tipo de escopo ser útil, nós também precisamos de definir um objeto Context que implementa o escopo! Implementar um Context é geralmente uma tarefa muito técnica, destinada apenas ao desenvolvimento do framework.

Podemos aplicar uma anotação de tipo de escopo a uma classe de implementação de um Web Bean para especificar o escopo do Web Bean:

@ClusterScoped

public class SecondLevelCache { ... }

Normalmente, você usará um dos escopos pré-definidos na Web Bean.

A Web Beans pré-define quatro tipo de escopos:

Para uma aplicação web que utiliza Web Beans:

Os escopos de request e aplicação também estão disponíveis:

Se a aplicação tenta invocar um Web Bean com um escopo que não tem um contexto ativo, uma ContextNotActiveException é lançada pelo gerenciador do Web Bean em tempo de execução.

Três dos quatro escopos pré-definidos devem ser extremamente familiares a todos os desenvolvedores Java EE, então não vamos perder tempo discutindo-os aqui. Um dos escopos, porém, é novo.

O escopo de conversação da Web Beans é um parecido com o tradicional escopo de sessão na medida em que mantém estado associado a um usuário do sistema, e o matém durante várias requisições para o servidor. No entanto, ao contrário do escopo de sessão, o escopo de conversação:

Uma conversação representa uma tarefa, uma unidade de trabalho do ponto de vista do usuário. O contexto de conversação mantém o estado associado com o que o usuário está atualmente fazendo. Se o usuário está fazendo várias coisas ao mesmo tempo, existem várias conversações.

A conversação está ativa durante qualquer requisição JSF. No entanto, a maioria das coversações são destruídas no final da requisição. Se uma conversação deve manter estado através de múltiplas requisições, deve explicitamente ser promovida para uma conversação de longa duração (long-running conversation).

@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);

Além dos quatro escopos pré-definidos, Web Beans possui o chamado dependent pseudo-scope. Este é o escopo padrão para um Web Bean que não declara explicitamente um tipo de escopo.

Por exemplo, esse Web Bean tem o tipo de escopo @Dependent:

public class Calculator { ... }

Quando um ponto de injeção num Web Bean resolve para um Web Bean dependente, uma nova instância do Web Bean dependente é criada a cada vez que o primeiro Web Bean é instanciado. Instâncias de Web Beans dependentes nunca são compartilhadas entre diferentes Web Beans ou diferentes pontos de injeção. Eles são objetos dependentes de alguma outra instância de Web Bean.

Instâncias de Web Bean dependentes são destruídas quando a instância que eles dependem é destruída.

Web Beans torna fácil a obtenção de uma instância dependente de uma classe Java ou um EJB, mesmo se a classe ou EJB já foram declarados como um Web Bean com outro tipo de escopo.

@New Calculator calculator;

@ConversationScoped

public class Calculator { ... }

public class PaymentCalc {


    @Current Calculator calculator;

    @New Calculator newCalculator;


}

O escopo padrão dos métodos produtores é @Dependent, e, por isso, vão ser chamados toda vez que o gerenciador do Web Bean injetar esse atributo ou qualquer outro atributo que resolve para o mesmo método produtor. Assim, pode haver várias instâncias do objeto PaymentStrategy para cada sessão do usuário.

Para mudar esse comportamento, nós podemos adicionar a anotação @SessionScoped ao método.

@Produces @Preferred @SessionScoped

public PaymentStrategy getPaymentStrategy() {

    ...

}

Agora, quando o método produtor é chamado, o PaymentStrategy retornado será associado ao contexto sessão. O método produtor não será invocado novamente na mesma sessão.

Existe um problema potencial com o código acima. As implementações de CreditCardPaymentStrategy são instanciadas utilizando o operador de Java new. Objetos instanciados diretamente pela aplicação não usufruem da injeção de dependência e não possuem interceptadores.

Se isso não é o que queremos, podemos utilizar a injeção de dependência no método produtor para obter instâncias do 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;

    } 

}

Espere, o que se CreditCardPaymentStrategy é um Web Bean de escopo de requisição? Então o método produtor tem o efeito de "promover" a instância atual no escopo de requisição para o escopo de sessão. Isso certamente é um erro! O objeto no escopo de requisição será destruído pelo gerenciador do Web Bean antes de terminar a sessão, mas a referência ao objeto será deixada "presa" no escopo sessão. Este erro não será detectado pelo gerenciador do Web Bean, por isso, tome cuidado quando retornar instâncias de Web Bean em métodos produtores!

Existem pelo menos três maneiras de corrigirmos esse erro. Podemos alterar o escopo da implementação do CreditCardPaymentStrategy, mas isso poderia afetar outros clientes desse Web Bean. A mehor opção seria alterar o escopo do médoto produtor para @Dependent ou @RequestScoped.

Mas, uma solução mais comum é utilizar a anotação especial de binding @New

Considere o seguinte método produtor:

@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;

    } 

}

Assim a nova instância dependente de CreditCardPaymentStrategy será criada, passada para o método produtor, retornada pelo método produtor e finalmente associada ao contexto de sessão. O objeto dependente não será destruído até que o objeto Preferences seja destruído, no término da sessão.