Non vedi l'ora di iniziare a scrivere il primo Web Beans? O forse sei un pò scettico e ti domandi quali virtuosismi ti farà fare la specifica Web Beans! La buona notizia è che probabilmente hai già scritto e usato centinaia, forse migliaia di Web Beans. Potresti addirittura non ricordare il primo Web Bean scritto.

public class SentenceParser {

    public List<String

> parse(String text) { ... }

}

@Stateless

public class SentenceTranslator implements Translator {

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

}

@Local

public interface Translator {

    public String translate(String sentence);

}

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

    }

    

}

@Initializer

public setTextTranslator(TextTranslator textTranslator) {

    this.textTranslator = textTranslator;

}

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

@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 { ... }

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

}

Illustriamo queste idee con un esempio completo. Implementiamo il login/logout dell'utente per un'applicazione che utilizza JSF. Innanzitutto definiamo un Web Bean che mantenga username e password digitati durante il login:

@Named @RequestScoped

public class Credentials {

        

    private String username;

    private String password;

    

    public String getUsername() { return username; }

    public void setUsername(String username) { this.username = username; }

    

    public String getPassword() { return password; }

    public void setPassword(String password) { this.password = password; }

    

}

Questo Web Bean è associato al login all'interno della seguente form JSF:

<h:form>

    <h:panelGrid columns="2" rendered="#{!login.loggedIn}">

        <h:outputLabel for="username"

>Username:</h:outputLabel>

        <h:inputText id="username" value="#{credentials.username}"/>

        <h:outputLabel for="password"

>Password:</h:outputLabel>

        <h:inputText id="password" value="#{credentials.password}"/>

    </h:panelGrid>

    <h:commandButton value="Login" action="#{login.login}" rendered="#{!login.loggedIn}"/>

    <h:commandButton value="Logout" acion="#{login.logout}" rendered="#{login.loggedIn}"/>

</h:form

>

Il vero lavoro è fatto da un Web Bean con scope di sessione che mantiene le informazioni sull'utente correntemente loggato ed espone l'entity User agli altri Web Beans:

@SessionScoped @Named

public class Login {


    @Current Credentials credentials;

    @PersistenceContext EntityManager userDatabase;


    private User user;

    

    public void login() {

            

        List<User

> results = userDatabase.createQuery(

           "select u from User u where u.username=:username and u.password=:password")

           .setParameter("username", credentials.getUsername())

           .setParameter("password", credentials.getPassword())

           .getResultList();

        

        if ( !results.isEmpty() ) {

           user = results.get(0);

        }

        

    }

    

    public void logout() {

        user = null;

    }

    

    public boolean isLoggedIn() {

       return user!=null;

    }

    

    @Produces @LoggedIn User getCurrentUser() {

        return user;

    }


}

@LoggedIn è un'annotazione di binding:

@Retention(RUNTIME)

@Target({TYPE, METHOD, FIELD})

@BindingType

public @interface LoggedIn {}

Ora qualsiasi altro Web Bean può facilmente iniettare l'utente corrente:

public class DocumentEditor {


    @Current Document document;

    @LoggedIn User currentUser;

    @PersistenceContext EntityManager docDatabase;

    

    public void save() {

        document.setCreatedBy(currentUser);

        docDatabase.persist(document);

    }

    

}

Quest'esempio è un assaggio del modello di programmazione con Web Bean. Nel prossimo capitolo esploreremo la dependency injection dei Web Bean con maggior profondità.

Web Beans viene sviluppato all'indirizzo the Seam project. Si può scaricare l'ultima release di Web Beans dalla pagina di download.

Web Beans viene distribuito con due applicazioni deployabili d'esempio, webbeans-numberguess, un esempio in formato war, che contiene solo bean semplici, e webbeans-translator, un esempio in formato ear, che contiene bean enterprise. Ci sono anche due varianti dell'esempio Indovina Numero, per Tomcat e con jsf2, che può essere usato con JSF2. Per eseguire gli esempi occorre fare le seguenti cose:

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

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

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

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

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

$ cd examples/numberguess
ant deploy

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

$ cd examples/translator
ant deploy

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

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

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

$ cd examples/tomcat
ant tomcat.deploy

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

3.4. Esempio Indovina Numero

Nell'applicazione Indovina Numero avete a disposizione 10 tentativi per indovinare un numero tra 1 e 100. Dopo ciascun tentativo, siete informati se siete stati troppo alti o troppo bassi.

L'esempio Indovina Numero comprende un certo numero di Web Bean, file di configurazione e pagine JSF, assemblati in un war. Iniziamo dai file di configurazione.

Tutti i file di configurazione di questo esempio si trovano in WEB-INF/, che è situato in WebContent nell'albero dei sorgenti. Innanzitutto, c'è faces-config.xml, in cui JSF viene informata di usare 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

>

Vi è un file vuoto web-beans.xml, che identifica l'applicazione come applicazione Web Beans.

Infine c'è 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

Nota

Whilst this demo is a JSF demo, you can use Web Beans with any Servlet based web framework.

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.

L'esempio consiste di 4 classi, delle quali le prime due sono tipi di binding. Innanzitutto, c'è il tipo di binding @Random, usato per iniettare un numero casuale:

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

@Retention(RUNTIME)

@Documented

@BindingType

public @interface Random {}

C'è anche il tipo di binding @MaxNumber, usato per iniettare il numero massimo iniettatabile:

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

@Retention(RUNTIME)

@Documented

@BindingType

public @interface MaxNumber {}

Alla classe Generator è affidata la generazione del numero casuale, per mezzo di un metodo produttore. Inoltre essa espone il massimo numero possibile attraverso un metodo produttore:

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

   }


}

E' possibile notare che Generator ha scope applicazione; quindi non si ottiene un diverso numero casuale ogni volta.

Il Web Bean finale nell'applicazione è Game avente scope di sessione.

Si noti anche che è stata usata l'annotazione @Named, in modo che sia possibile usare il bean in espressioni EL presenti nelle pagine JSF. Infine, si è utilizzata l'iniezione del costruttore per inizializzare il gioco con un numero casuale. E naturalmente, è necessario dire al giocatore se ha vinto, informazione di feedback che viene fornita con un 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

>(){});

   }

   

}

3.4.1. The numberguess example in Tomcat

The numberguess for Tomcat differs in a couple of ways. Firstly, Web Beans should be deployed as a Web Application library in WEB-INF/lib. For your convenience we provide a single jar suitable for running Web Beans in any servlet container webbeans-servlet.jar.

Suggerimento

Certamente occorre anche includere JSF e EL, e le annotazioni comuni (jsr250-api.jar) che un server JEE include di default.

Secondly, we need to explicitly specify the servlet listener (used to boot Web Beans, and control it's interaction with requests) in web.xml:

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

3.4.2. The numberguess example for Apache Wicket

Whilst JSR-299 specifies integration with Java ServerFaces, Web Beans allows you to inject into Wicket components, and also allows you to use a conversation context with Wicket. In this section, we'll walk you through the Wicket version of the numberguess example.

Nota

You may want to review the Wicket documentation at http://wicket.apache.org/.

Like the previous example, the Wicket WebBeans examples make use of the webbeans-servlet module. The use of the Jetty servlet container is common in the Wicket community, and is chosen here as the runtime container in order to facilitate comparison between the standard Wicket examples and these examples, and also to show how the webbeans-servlet integration is not dependent upon Tomcat as the servlet container.

These examples make use of the Eclipse IDE; instructions are also given to deploy the application from the command line.

3.4.2.1. Creating the Eclipse project

To generate an Eclipse project from the example:

cd examples/wicket/numberguess
mvn -Pjetty eclipse:eclipse

Then, from eclipse, choose File -> Import -> General -> Existing Projects into Workspace, select the root directory of the numberguess example, and click finish. Note that if you do not intend to run the example with jetty from within eclipse, omit the "-Pjetty." This will create a project in your workspace called webbeans-wicket-numberguess

3.4.2.2. Running the example from Eclipse

This project follows the wicket-quickstart approach of creating an instance of Jetty in the Start class. So running the example is as simple as right-clicking on that Start class in src/test/java in the Package Explorer and choosing Run as Java Application. You should see console output related to Jetty starting up; then visit able http://localhost:8080 to view the app. To debug choose Debug as Java Application.

3.4.2.3. Running the example from the command line in JBoss AS or Tomcat

This example can also be deployed from the command line in a (similar to the other examples). Assuming you have set up the build.properties file in the examples directory to specify the location of JBoss AS or Tomcat, as previously described, you can run ant deploy from the examples/wicket/numberguess directory, and access the application at http://localhost:8080/webbeans-numberguess-wicket.

3.4.2.4. Understanding the code

JSF uses Unified EL expressions to bind view layer components in JSP or Facelet views to beans, Wicket defines it's components in Java. The markup is plain html with a one-to-one mapping between html elements and the view components. All view logic, including binding of components to models and controlling the response of view actions, is handled in Java. The integration of Web Beans with Wicket takes advantage of the same binding annotations used in your business layer to provide injection into your WebPage subclass (or into other custom wicket component subclasses).

The code in the wicket numberguess example is very similar to the JSF-based numberguess example. The business layer is identical!

Differences are:

• Each wicket application must have a WebApplication subclass, In our case, our application class is SampleApplication:

  public class SampleApplication extends WebBeansApplication {
     @Override
     public Class getHomePage() {
        return HomePage.class;
     }
  }

  This class specifies which page wicket should treat as our home page, in our case, HomePage.class

• In HomePage we see typical wicket code to set up page elements. The bit that is interesting is the injection of the Game bean:

   @Current Game game;

  The Game bean is can then be used, for example, by the code for submitting a guess:

  final Component guessButton = new AjaxButton("GuessButton") { 
     protected void onSubmit(AjaxRequestTarget target, Form form) {
        if (game.check()) {

  Nota

  All injections may be serialized; actual storage of the bean is managed by JSR-299. Note that Wicket components, like the HomePage and it subcomponents, are not JSR-299 beans.

  Wicket components allow injection, but they cannot use interceptors, decorators and lifecycle callbacks such as @PostConstruct or @Initializer methods.

• The example uses AJAX for processing of button events, and dynamically hides buttons that are no longer relevant, for example when the user has won the game.

• In order to activate wicket for this webapp, the Wicket filter is added to web.xml, and our application class is specified:

  <filter>
     <filter-name>wicket.numberguess-example</filter-name>
     <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
     <init-param>
        <param-name>applicationClassName</param-name>
        <param-value>org.jboss.webbeans.examples.wicket.SampleApplication</param-value>
     </init-param>
  </filter>
  
  <filter-mapping>
     <filter-name>wicket.numberguess-example</filter-name>
     <url-pattern>/*</url-pattern>
  </filter-mapping>
   
  <listener>
     <listener-class>org.jboss.webbeans.environment.servlet.Listener</listener-class>
  </listener>

  Note that the servlet listener is also added, as in the Tomcat example, in order to boostrap Web Beans when Jetty starts, and to hook Web Beans into the Jetty servlet request and session lifecycles.

3.4.3. The numberguess example for Java SE with Swing

This example can be found in the examples/se/numberguess folder of the Web Beans distribution.

To run this example:

• Open a command line/terminal window in the examples/se/numberguess directory

• Ensure that Maven 2 is installed and in your PATH

• Ensure that the JAVA_HOME environment variable is pointing to your JDK installation

• execute the following command

  mvn -Drun

There is an empty beans.xml file in the root package (src/main/resources/beans.xml), which marks this application as a Web Beans application.

The game's main logic is located in Game.java. Here is the code for that class, highlighting the changes made from the web application version:

@ApplicationScoped

public class Game implements Serializable

{


    private int number;

    private int guess;

    private int smallest;


    @MaxNumber

    private int maxNumber;


    private int biggest;

    private int remainingGuesses;

    private boolean validNumberRange = true;


    @Current Generator rndGenerator;


    ...


    public boolean isValidNumberRange()

    {

        return validNumberRange;

    }


    public boolean isGameWon()

    {

        return guess == number;

    }


    public boolean isGameLost()

    {

        return guess != number && remainingGuesses <= 0;

    }


    public boolean check()

    {

        boolean result = false;


        if ( checkNewNumberRangeIsValid() )

        {

            if ( guess > number )

            {

                biggest = guess - 1;

            }


            if ( guess < number )

            {

                smallest = guess + 1;

            }


            if ( guess == number )

            {

                result = true;

            }


            remainingGuesses--;

        }


        return result;

    }


    private boolean checkNewNumberRangeIsValid()

    {

        return validNumberRange = ( ( guess >= smallest ) && ( guess <= biggest ) );

    }


    @PostConstruct

    public void reset()

    {

        this.smallest = 0;

        ...

        this.number = rndGenerator.next();

    }

}

	The bean is application scoped instead of session scoped, since an instance of the application represents a single 'session'.
	The bean is not named, since it doesn't need to be accessed via EL
	There is no JSF FacesContext to add messages to. Instead the Game class provides additional information about the state of the current game including: If the game has been won or lost If the most recent guess was invalid This allows the Swing UI to query the state of the game, which it does indirectly via a class called MessageGenerator, in order to determine the appropriate messages to display to the user during the game.
	Validation of user input is performed during the check() method, since there is no dedicated validation phase
	The reset() method makes a call to the injected rndGenerator in order to get the random number at the start of each game. It cannot use manager.getInstanceByType(Integer.class, new AnnotationLiteral<Random>(){}) as the JSF example does because there will not be any active contexts like there is during a JSF request.

The MessageGenerator class depends on the current instance of Game, and queries its state in order to determine the appropriate messages to provide as the prompt for the user's next guess and the response to the previous guess. The code for MessageGenerator is as follows:

public class MessageGenerator

{

    @Current Game game;


    public String getChallengeMessage()

    {

        StringBuilder challengeMsg = new StringBuilder( "I'm thinking of a number between " );

        challengeMsg.append( game.getSmallest() );

        challengeMsg.append( " and " );

        challengeMsg.append( game.getBiggest() );

        challengeMsg.append( ". Can you guess what it is?" );


        return challengeMsg.toString();

    }


    public String getResultMessage()

    {

        if ( game.isGameWon() )

        {

            return "You guess it! The number was " + game.getNumber();

        } else if ( game.isGameLost() )

        {

            return "You are fail! The number was " + game.getNumber();

        } else if ( ! game.isValidNumberRange() )

        {

            return "Invalid number range!";

        } else if ( game.getRemainingGuesses() == Game.MAX_NUM_GUESSES )

        {

            return "What is your first guess?";

        } else

        {

            String direction = null;


            if ( game.getGuess() < game.getNumber() )

            {

                direction = "Higher";

            } else

            {

                direction = "Lower";

            }


            return direction + "! You have " + game.getRemainingGuesses() + " guesses left.";

        }

    }

}

	The instance of Game for the application is injected here.
	The Game's state is interrogated to determine the appropriate challenge message.
	And again to determine whether to congratulate, console or encourage the user to continue.

Finally we come to the NumberGuessFrame class which provides the Swing front end to our guessing game.

public class NumberGuessFrame  extends javax.swing.JFrame

{

    private @Current Game game;

    private @Current MessageGenerator msgGenerator;


    public void start( @Observes @Deployed Manager manager )

    {

        java.awt.EventQueue.invokeLater( new Runnable()

            {

                public void run()

                {

                    initComponents();

                    setVisible( true );

                }

            } );

    }


    private void initComponents() {


        buttonPanel = new javax.swing.JPanel();

        mainMsgPanel = new javax.swing.JPanel();

        mainLabel = new javax.swing.JLabel();

        messageLabel = new javax.swing.JLabel();

        guessText = new javax.swing.JTextField();

        ...

        mainLabel.setText(msgGenerator.getChallengeMessage());

        mainMsgPanel.add(mainLabel);


        messageLabel.setText(msgGenerator.getResultMessage());

        mainMsgPanel.add(messageLabel);

        ...

    }


    private void guessButtonActionPerformed( java.awt.event.ActionEvent evt )

    {

        int guess =  Integer.parseInt(guessText.getText());


        game.setGuess( guess );

        game.check();

        refreshUI();


    }


    private void replayBtnActionPerformed( java.awt.event.ActionEvent evt )

    {

       game.reset();

       refreshUI();

    }


    private void refreshUI()

    {

        mainLabel.setText( msgGenerator.getChallengeMessage() );

        messageLabel.setText( msgGenerator.getResultMessage() );

        guessText.setText( "" );

        guessesLeftBar.setValue( game.getRemainingGuesses() );

        guessText.requestFocus();

    }


    // swing components

    private javax.swing.JPanel borderPanel;

    ...

    private javax.swing.JButton replayBtn;


}

	The injected instance of the game (logic and state).
	The injected message generator for UI messages.
	This application is started in the usual Web Beans SE way, by observing the @Deployed Manager event.
	This method initialises all of the Swing components. Note the use of the msgGenerator.
	guessButtonActionPerformed is called when the 'Guess' button is clicked, and it does the following: Gets the guess entered by the user and sets it as the current guess in the Game Calls game.check() to validate and perform one 'turn' of the game Calls refreshUI. If there were validation errors with the input, this will have been captured during game.check() and as such will be reflected in the messeges returned by MessageGenerator and subsequently presented to the user. If there are no validation errors then the user will be told to guess again (higher or lower) or that the game has ended either in a win (correct guess) or a loss (ran out of guesses).
	replayBtnActionPerformed simply calls game.reset() to start a new game and refreshes the messages in the UI.
	refreshUI uses the MessageGenerator to update the messages to the user based on the current state of the Game.

<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

>

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

>

<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

>

public class TextTranslator { 

   private SentenceParser sentenceParser; 

   private Translator sentenceTranslator; 

   

   @Initializer

   TextTranslator(SentenceParser sentenceParser, Translator sentenceTranslator) 

   { 

      this.sentenceParser = sentenceParser; 

      this.sentenceTranslator = sentenceTranslator;

@Stateful

@RequestScoped

@Named("translator")

public class TranslatorControllerBean implements TranslatorController

{

   

   @Current TextTranslator translator;

   @Remove

   public void remove()

   {

      

   }

Ciò conclude il nostro breve tour degli esempi della RI di Web Beans. Per saperne di più, o per trovare ulteriore aiuto, per favore visitate http://www.seamframework.org/WebBeans/Development.

Abbiamo bisogno di aiuto in tutte le aree - soluzione dei bug, scrittura di nuove caratteristiche ed esempi e traduzione di questa guida.

Web Beans supporta tre meccanismi primari per la dependency injection:

Iniezione dei parametri del costruttore

public class Checkout {

        

    private final ShoppingCart cart;

    

    @Initializer

    public Checkout(ShoppingCart cart) {

        this.cart = cart;

    }


}

Iniezione dei parametri del metodo inizializzatore (initializer method):

public class Checkout {

        

    private ShoppingCart cart;


    @Initializer 

    void setShoppingCart(ShoppingCart cart) {

        this.cart = cart;

    }

    

}

Iniezione diretta degli attributi

public class Checkout {


    private @Current ShoppingCart cart;

    

}

La dependency injection avviene sempre quando il Web Bean viene istanziato la prima volta.

L'iniezione dei parametri del costruttore non è supportata per gli EJB, poiché gli EJB sono istanziati dal container EJB, non dal manager Web Bean.

I parametri dei costruttori e dei metodi di inizializzazione non devono essere annotati esplicitamente quando il tipo del binding è @Current, quello predefinito. I campi iniettati, comunque, devono specificare il tipo del binding, anche quando il tipo del binding è quello predefinito. Se il campo non specifica il tipo del binding, non verrà iniettato.

I metodi produttori supportano anche l'iniezione dei parametri:

@Produces Checkout createCheckout(ShoppingCart cart) {

    return new Checkout(cart);

}

Infine, i metodi observer (che vedremo in Capitolo 9, Eventi), i metodi disposal e i metodi distruttori supportano tutti l'iniezione dei parametri.

Le specifiche Web Beans definiscono una procedura, chiamata typesafe resolution algorithm (algoritmo di risoluzione sicura rispetto ai tipi), che il manager Web Bean segue quando deve identificare il Web Beanda iniettare in punto di iniezione. Questo algoritmo di primo acchito sembra complesso, ma una volta che lo si è compreso, in realtà, risulta piuttosto intuitivo. La risoluzione sicura dei tipi viene eseguita durante l'inizializzazione del sistema (system initialization time), il che significa che il manager Web Bean informerà immediatamente un utente se le dipendenze di un Web Bean non possono essere soddisfatte, lanciando una UnsatisfiedDependencyException o una AmbiguousDependencyException.

Lo scopo di questo algoritmo è di permettere a più Web Bean di implementare la stessa tipo definito dall'API e:

Indaghiamo come il manager di Web Beans individua un Web Bean da iniettare.

@PayByCheque

public class ChequePaymentProcessor implements PaymentProcessor {

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

}

@PayByCreditCard

public class CreditCardPaymentProcessor implements PaymentProcessor {

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

}

@Retention(RUNTIME)

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

@BindingType

public @interface PayByCheque {}

@Retention(RUNTIME)

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

@BindingType

public @interface PayByCreditCard {}

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

}

@Retention(RUNTIME)

  @Target({TYPE, METHOD})

  @DeploymentType

  public @interface Mock {}

public class ExternalPaymentProcessor {

        

    public void process(Payment p) {

        ...

    }

    

}

@Mock 

public class MockPaymentProcessor implements PaymentProcessor {


    @Override

    public void process(Payment p) {

        p.setSuccessful(true);

    }


}

<WebBeans>

    <Deploy>

        <Standard/>

        <Production/>

        <test:Mock/>

    </Deploy>

</WebBeans

>

@Current PaymentProcessor paymentProcessor

@Current Manager manager;

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

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new AnnotationLiteral<CreditCard

>(){});

abstract class CreditCardBinding 

    extends AnnotationLiteral<CreditCard

> 

    implements CreditCard {}

PaymentProcessor p = manager.getInstanceByType(PaymentProcessor.class, 

                                               new CreditCardBinding() { 

                                                   public void value() { return paymentType; } 

                                               } );

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

class LogFactory {


   @Produces Logger createLogger(InjectionPoint injectionPoint) { 

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

   }


}

@Current Logger log;

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

   }


}

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

}

Finora si sono visti pochi esempi di annotazioni di tipi di scope. Gli scope di un Web Bean determinano il ciclo di vita del Web Bean. Lo scope determina anche quali client fanno riferimento a quali istanze di Web Bean. Secondo la specifica Web Bean, uno scope determina:

Per esempio, se esiste un Web Bean con scope di sessione, CurrentUser, tutti i Web Bean che vengono chiamati nel contesto della medesima HttpSession vedranno la stessa istanza di CurrentUser. Quest'istanza verrà automaticamente creata la prima volta che in tale sessione occorre CurrentUser, e verrà distrutta automaticamente quando la sessione termina.

@Retention(RUNTIME)

@Target({TYPE, METHOD})

@ScopeType

public @interface ClusterScoped {}

@ClusterScoped

public class SecondLevelCache { ... }

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

public class Calculator { ... }

@New Calculator calculator;

@ConversationScoped

public class Calculator { ... }

public class PaymentCalc {


    @Current Calculator calculator;

    @New Calculator newCalculator;


}

I metodi produttori consentono di superare alcune limitazioni che sorgono quando il manager Web Bean è responsabile dell'istanziamento degli oggetti al posto dell'applicazione. Questi metodi sono anche il modo migliore per integrare gli oggetti che non sono Web Beans dentro l'ambiente Web Beans. (Si incontrerà un secondo approccio in Capitolo 12, Definire i Web Beans tramite XML.)

Secondo la specifica:

For example, producer methods let us:

In particular, producer methods let us use runtime polymorphism with Web Beans. As we've seen, deployment types are a powerful solution to the problem of deployment-time polymorphism. But once the system is deployed, the Web Bean implementation is fixed. A producer method has no such limitation:

@SessionScoped

public class Preferences {

    

    private PaymentStrategyType paymentStrategy;

    

    ...

    

    @Produces @Preferred 

    public PaymentStrategy getPaymentStrategy() {

        switch (paymentStrategy) {

            case CREDIT_CARD: return new CreditCardPaymentStrategy();

            case CHEQUE: return new ChequePaymentStrategy();

            case PAYPAL: return new PayPalPaymentStrategy();

            default: return null;

        } 

    }

    

}

Consider an injection point:

@Preferred PaymentStrategy paymentStrat;

This injection point has the same type and binding annotations as the producer method, so it resolves to the producer method using the usual Web Beans injection rules. The producer method will be called by the Web Bean manager to obtain an instance to service this injection point.

@Produces @Preferred @SessionScoped

public PaymentStrategy getPaymentStrategy() {

    ...

}

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

    } 

}

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

    } 

}