Weld SVN: r4647 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: peteroyle
Date: 2009-11-04 06:24:34 -0500 (Wed, 04 Nov 2009)
New Revision: 4647
Modified:
doc/trunk/reference/en-US/gettingstarted.xml
Log:
Minor typo
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 11:24:15 UTC (rev 4646)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 11:24:34 UTC (rev 4647)
@@ -1253,7 +1253,7 @@
</listitem>
<listitem>
<para>
- execute the following command
+ Execute the following command
</para>
<programlisting>mvn -Drun</programlisting>
</listitem>
16 years, 5 months
- 1
- 0
Weld SVN: r4646 - examples/trunk/se/numberguess.
by weld-commits＠lists.jboss.org
Author: peteroyle
Date: 2009-11-04 06:24:15 -0500 (Wed, 04 Nov 2009)
New Revision: 4646
Modified:
examples/trunk/se/numberguess/readme.txt
Log:
Updated readme file
Modified: examples/trunk/se/numberguess/readme.txt
===================================================================
--- examples/trunk/se/numberguess/readme.txt 2009-11-04 11:12:33 UTC (rev 4645)
+++ examples/trunk/se/numberguess/readme.txt 2009-11-04 11:24:15 UTC (rev 4646)
@@ -15,54 +15,81 @@
limitations under the License.
====
+===================
+Running the Example
+===================
+
+As with all Weld SE applications, this example is executed
+by starting Java with org.jboss.weld.environment.se.StartMain
+as the main class. Of course you will need all of the relevant jar dependencies
+on your classpath, which is most easily done by loading the project into your
+favourite Maven-capable IDE and running it from there.
+
+To run this example using Maven directly:
+
+ - Ensure that Maven 2 (version 2.0.10+) is installed and in your PATH
+ - Ensure that the JAVA_HOME environment variable is pointing to your JDK installation
+ - Open a command line or terminal window in the examples/se/numberguess directory
+ - Execute the following command
+
+ mvn -Drun
+
===========================
Swing Example: Number Guess
===========================
Here's an example of a Swing application, Number Guess, similar to the example in chapter 3.4.
+This example shows how to use the Weld SE extension to in a Java SE based Swing application
+with no EJB or servlet dependencies. This example can be found in the examples/se/numberguess
+folder of the Weld distribution.
+
In the Number Guess application you get given 10 attempts to guess a number between 1 and
100. After each attempt, you will be told whether you are too high, or too low. This example can
be found in the examples/se/numberguess folder of the Web Beans distribution.
-There is an empty beans.xml file in the META-INF package (src/main/resources/META-INF/beans.xml), which
-marks this application as a Web Beans application.
+As usual, there is an empty beans.xml file in the root package (src/main/resources/beans.xml),
+which marks this application as a CDI application.
-The game's main logic is located in Game.java. Some key points about this class:
+The game's main logic is located in Game.java. Here is the code for that class,
+highlighting the ways in which this differs from the web application version:
- The bean is application scoped instead of session scoped, since an instance of the
- application represents a single 'session'.
+ The bean is application scoped rather than session scoped, since an instance
+ of a Swing application typically represents a single 'session'.
- The bean is not named, since it doesn't need to be accessed via EL
+ Notice that 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:
+ In Java SE there is no JSF FacesContext to which messages can be added. 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
+ If the game has been won or lost
- 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.
+ If the most recent guess was invalid
- Validation of user input is performed during the check() method, since there is no dedicated
- validation phase
+ 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.
- 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.
+ Since there is no dedicated validation phase, validation of user input is performed
+ during the check() method.
-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. Some key points about this class:
+ The reset() method makes a call to the injected rndGenerator in order to get
+ the random number at the start of each game. Note that 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:
+
The instance of Game for the application is injected.
- 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.
+ 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.
@@ -87,25 +114,3 @@
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.
-
--------------------
-Running the Example
--------------------
-
-As with all Web Beans SE applications, this example is executed
-by starting Java with org.jboss.weld.environment.se.StartMain
-as the main class. Of course you will need all of the relevant jar dependencies
-on your classpath, which is most easily done by loading the project into your
-favourite Maven-capable IDE and running it from there..
-
-To run this example using Maven directly:
-
-- 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
16 years, 5 months
- 1
- 0
Weld SVN: r4645 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: peteroyle
Date: 2009-11-04 06:12:33 -0500 (Wed, 04 Nov 2009)
New Revision: 4645
Modified:
doc/trunk/reference/en-US/gettingstarted.xml
Log:
Updated Java SE Number Guess example walkthrough
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 11:08:23 UTC (rev 4644)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 11:12:33 UTC (rev 4645)
@@ -1223,143 +1223,169 @@
<title>The numberguess example for Java SE with Swing</title>
<para>
- This example can be found in the
- <literal>examples/se/numberguess</literal> folder of the Weld
- distribution.
+ This example shows how to use the Weld SE extension to in a
+ Java SE based Swing application with no EJB or servlet dependencies.
+ This example can be found in the <literal>examples/se/numberguess</literal>
+ folder of the Weld distribution.
</para>
-
<para>
- To run this example:
+ To run the example:
</para>
<itemizedlist>
<listitem>
<para>
- Open a command line/terminal window in the
- <literal>examples/se/numberguess</literal> directory
+ Ensure that Maven 2 (version 2.0.10+) is installed and in your PATH
</para>
</listitem>
<listitem>
<para>
- Ensure that Maven 2 is installed and in your PATH
+ Ensure that the <literal>JAVA_HOME</literal> environment
+ variable is pointing to your JDK installation
</para>
</listitem>
<listitem>
<para>
- Ensure that the <literal>JAVA_HOME</literal> environment
- variable is pointing to your JDK installation
+ Open a command line or terminal window in the
+ <literal>examples/se/numberguess</literal> directory
</para>
</listitem>
<listitem>
<para>
execute the following command
</para>
- <programlisting>$> mvn -Drun</programlisting>
+ <programlisting>mvn -Drun</programlisting>
</listitem>
</itemizedlist>
-
+ <para>
+ Let's have a look at the significant code and configuration
+ files that make up this example.
+ </para>
- <para>
- There is an empty <literal>beans.xml</literal> file in the root
+ <para>
+ As usual, there is an empty <literal>beans.xml</literal> file in the root
package (<literal>src/main/resources/beans.xml</literal>), which
marks this application as a CDI application.
</para>
<para>
The game's main logic is located in <literal>Game.java</literal>.
- Here is the code for that class, highlighting the changes made
- from the web application version:
+ Here is the code for that class, highlighting the ways in which this
+ differs from the web application version:
</para>
<programlistingco>
<areaspec>
<area id="scope" coords="1" />
- <area id="name" coords="1" />
+ <area id="name" coords="2" />
<area id="messages1" coords="26" />
- <area id="validation" coords="39" />
- <area id="reset" coords="68" />
+ <area id="validation" coords="41" />
+ <area id="reset" coords="73" />
</areaspec>
<programlisting role="JAVA"><![CDATA[@ApplicationScoped
-public class Game implements Serializable {
+public class Game implements Serializable
+{
+ public static final int MAX_NUM_GUESSES = 10;
- private int number;
- private int guess;
- private int smallest;
- private int biggest;
- private int remainingGuesses;
- private boolean validNumberRange = true;
+ private Integer number;
+ private int guess = 0;
+ private int smallest = 0;
- @Inject @MaxNumber private int maxNumber;
+ @Inject
+ @MaxNumber
+ private int maxNumber;
- @Inject Generator rndGenerator;
+ private int biggest;
+ private int remainingGuesses = MAX_NUM_GUESSES;
+ private boolean validNumberRange = true;
+ @Inject
+ Generator rndGenerator;
+
+ public Game()
+ {
+ }
+
...
- public boolean isValidNumberRange() {
- return validNumberRange;
- }
+ public boolean isValidNumberRange()
+ {
+ return validNumberRange;
+ }
- public boolean isGameWon() {
- return guess == number;
- }
+ public boolean isGameWon()
+ {
+ return guess == number;
+ }
- public boolean isGameLost() {
- return guess != number && remainingGuesses <= 0;
- }
+ public boolean isGameLost()
+ {
+ return guess != number && remainingGuesses <= 0;
+ }
- public boolean check() {
- boolean result = false;
+ public boolean check()
+ {
+ boolean result = false;
- if (checkNewNumberRangeIsValid()) {
- if (guess > number) {
- biggest = guess - 1;
- }
+ if (checkNewNumberRangeIsValid())
+ {
+ if (guess > number)
+ {
+ biggest = guess - 1;
+ }
- if (guess < number) {
- smallest = guess + 1;
- }
+ if (guess < number)
+ {
+ smallest = guess + 1;
+ }
- if (guess == number) {
- result = true;
- }
+ if (guess == number)
+ {
+ result = true;
+ }
- remainingGuesses--;
- }
+ remainingGuesses--;
+ }
- return result;
- }
+ return result;
+ }
- private boolean checkNewNumberRangeIsValid() {
- return validNumberRange = ((guess >= smallest) && (guess <= biggest));
- }
+ private boolean checkNewNumberRangeIsValid()
+ {
+ return validNumberRange = ((guess >= smallest) && (guess <= biggest));
+ }
- @PostConstruct
- public void reset() {
- this.smallest = 0;
- ...
- this.number = rndGenerator.next();
- }
+ @PostConstruct
+ public void reset()
+ {
+ this.smallest = 0;
+ this.guess = 0;
+ this.remainingGuesses = 10;
+ this.biggest = maxNumber;
+ this.number = rndGenerator.next();
+ }
}]]></programlisting>
<calloutlist>
<callout arearefs="scope">
<para>
- The bean is application scoped instead of session scoped,
- since an instance of the application represents a single 'session'.
+ The bean is application scoped rather than session scoped,
+ since an instance of a Swing application typically represents
+ a single 'session'.
</para>
</callout>
<callout arearefs="name">
<para>
- The bean is not named, since it doesn't need to be accessed
- via EL
+ Notice that the bean is not named, since it doesn't need to
+ be accessed via EL.
</para>
</callout>
<callout arearefs="messages1">
<para>
- There is no JSF <literal>FacesContext</literal> to add
- messages to. Instead the <literal>Game</literal> class
- provides additional information about the state of the
+ In Java SE there is no JSF <literal>FacesContext</literal>
+ to which messages can be added. Instead the <literal>Game</literal>
+ class provides additional information about the state of the
current game including:
</para>
@@ -1380,26 +1406,25 @@
<para>
This allows the Swing UI to query the state of the game,
which it does indirectly via a class called
- <literal>MessageGenerator,</literal> in order to determine
+ <literal>MessageGenerator</literal>, in order to determine
the appropriate messages to display to the user during the
game.
</para>
</callout>
<callout arearefs="validation">
<para>
- Validation of user input is performed during the
- <literal>check()</literal> method, since there is no
- dedicated validation phase
+ Since there is no dedicated validation phase, validation of
+ user input is performed during the <literal>check()</literal> method.
</para>
</callout>
<callout arearefs="reset">
<para>
The <literal>reset()</literal> method makes a call to the
injected <literal>rndGenerator</literal> in order to get
- the random number at the start of each game. It cannot use
- <literal>manager.getInstanceByType(Integer.class, new AnnotationLiteral<Random>(){})</literal>
- as the JSF example does because there will not be any active contexts like
- there is during a JSF request.
+ the random number at the start of each game. Note that it
+ cannot use <literal>manager.getInstanceByType(Integer.class, new AnnotationLiteral<Random>(){})</literal>
+ as the JSF example does because there will not be any active
+ contexts like there is during a JSF request.
</para>
</callout>
</calloutlist>
@@ -1407,7 +1432,7 @@
<para>
The <literal>MessageGenerator</literal> class depends on the
- current instance of <literal>Game</literal>, and queries its
+ current instance of <literal>Game</literal> 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 <literal>MessageGenerator</literal>
@@ -1417,49 +1442,59 @@
<programlistingco>
<areaspec>
<area id="game" coords="3" />
- <area id="challenge" coords="5" />
- <area id="result" coords="16" />
+ <area id="challenge" coords="6" />
+ <area id="result" coords="17" />
</areaspec>
- <programlisting role="JAVA"><![CDATA[public class MessageGenerator {
- @Inject Game game;
+ <programlisting role="JAVA"><![CDATA[public class MessageGenerator
+{
+ @Inject
+ private 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?" );
+ 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();
- }
+ 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;
+ public String getResultMessage()
+ {
+ if (game.isGameWon())
+ {
+ return "You guessed 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";
- }
+ if (game.getGuess() < game.getNumber())
+ {
+ direction = "Higher";
+ }
+ else
+ {
+ direction = "Lower";
+ }
- return direction + "! You have " + game.getRemainingGuesses() + " guesses left.";
- }
- }
-
+ return direction + "! You have " + game.getRemainingGuesses() + " guesses left.";
+ }
+ }
}]]></programlisting>
<calloutlist>
<callout arearefs="game">
@@ -1471,12 +1506,12 @@
<callout arearefs="challenge">
<para>
The <literal>Game</literal>'s state is interrogated to
- determine the appropriate challenge message.
+ determine the appropriate challenge message ...
</para>
</callout>
<callout arearefs="result">
<para>
- And again to determine whether to congratulate, console or
+ ... and again to determine whether to congratulate, console or
encourage the user to continue.
</para>
</callout>
@@ -1491,71 +1526,76 @@
<programlistingco>
<areaspec>
<area id="gameIn" coords="3" />
- <area id="messagesIn" coords="4" />
- <area id="start" coords="6" />
- <area id="init" coords="18" />
- <area id="guess1" coords="34" />
- <area id="replay" coords="44" />
- <area id="refresh" coords="50" />
+ <area id="messagesIn" coords="6" />
+ <area id="start" coords="9" />
+ <area id="init" coords="21" />
+ <area id="guess1" coords="38" />
+ <area id="replay" coords="48" />
</areaspec>
- <programlisting role="JAVA"><![CDATA[public class NumberGuessFrame extends javax.swing.JFrame {
+ <programlisting role="JAVA"><![CDATA[public class NumberGuessFrame extends javax.swing.JFrame
+{
+ @Inject
+ private Game game;
- private @Inject Game game;
- private @Inject MessageGenerator msgGenerator;
+ @Inject
+ private MessageGenerator msgGenerator;
- public void start( @Observes @Deployed Manager manager ) {
- java.awt.EventQueue.invokeLater( new Runnable()
- {
- public void run()
- {
- initComponents();
- setVisible( true );
- }
- } );
- }
+ public void start(@Observes ContainerInitialized event)
+ {
+ java.awt.EventQueue.invokeLater(new Runnable()
+ {
+ public void run()
+ {
+ initComponents();
+ setVisible(true);
+ }
+ });
+ }
- private void initComponents() {
+ 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();
+ 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);
+ mainLabel.setText(msgGenerator.getChallengeMessage());
+ mainMsgPanel.add(mainLabel);
- messageLabel.setText(msgGenerator.getResultMessage());
- mainMsgPanel.add(messageLabel);
+ messageLabel.setText(msgGenerator.getResultMessage());
+ mainMsgPanel.add(messageLabel);
...
- }
+ }
- private void guessButtonActionPerformed( java.awt.event.ActionEvent evt ) {
- int guess = Integer.parseInt(guessText.getText());
+ private void guessButtonActionPerformed( java.awt.event.ActionEvent evt )
+ {
+ int guess = Integer.parseInt(guessText.getText());
+ game.setGuess( guess );
+ game.check();
+ refreshUI();
- game.setGuess( guess );
- game.check();
- refreshUI();
-
}
- private void replayBtnActionPerformed( java.awt.event.ActionEvent evt ) {
- game.reset();
- 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();
- }
+ guessText.requestFocus();
+ }
- // swing components
- private javax.swing.JPanel borderPanel;
+ // swing components
+ private javax.swing.JPanel borderPanel;
...
- private javax.swing.JButton replayBtn;
+ private javax.swing.JButton replayBtn;
}]]></programlisting>
<calloutlist>
@@ -1571,14 +1611,14 @@
</callout>
<callout arearefs="start">
<para>
- This application is started in the usual CDI SE way,
- by observing the <literal>@Deployed Manager</literal> event.
+ This application is started in the prescribed Weld SE way,
+ by observing the <literal>ContainerInitialized</literal> event.
</para>
</callout>
<callout arearefs="init">
<para>
This method initialises all of the Swing components. Note
- the use of the <literal>msgGenerator</literal>.
+ the use of the <literal>msgGenerator</literal> here.
</para>
</callout>
<callout arearefs="guess1">
@@ -1606,7 +1646,7 @@
Calls <literal>refreshUI</literal>. If there were
validation errors with the input, this will have been
captured during <literal>game.check()</literal> and
- as such will be reflected in the messeges returned by
+ as such will be reflected in the messages returned by
<literal>MessageGenerator</literal> and subsequently
presented to the user. If there are no validation
errors then the user will be told to guess again
@@ -1624,13 +1664,6 @@
refreshes the messages in the UI.
</para>
</callout>
- <callout arearefs="refresh">
- <para>
- <literal>refreshUI</literal> uses the
- <literal>MessageGenerator</literal> to update the messages
- to the user based on the current state of the Game.
- </para>
- </callout>
</calloutlist>
</programlistingco>
16 years, 5 months
- 1
- 0
Weld SVN: r4644 - examples/trunk/se/numberguess/src/main/java/org/jboss/weld/environment/se/example/numberguess.
by weld-commits＠lists.jboss.org
Author: peteroyle
Date: 2009-11-04 06:08:23 -0500 (Wed, 04 Nov 2009)
New Revision: 4644
Modified:
examples/trunk/se/numberguess/src/main/java/org/jboss/weld/environment/se/example/numberguess/MessageGenerator.java
Log:
typo
Modified: examples/trunk/se/numberguess/src/main/java/org/jboss/weld/environment/se/example/numberguess/MessageGenerator.java
===================================================================
--- examples/trunk/se/numberguess/src/main/java/org/jboss/weld/environment/se/example/numberguess/MessageGenerator.java 2009-11-04 09:00:20 UTC (rev 4643)
+++ examples/trunk/se/numberguess/src/main/java/org/jboss/weld/environment/se/example/numberguess/MessageGenerator.java 2009-11-04 11:08:23 UTC (rev 4644)
@@ -31,13 +31,13 @@
public String getChallengeMessage()
{
- StringBuilder chalengeMsg = new StringBuilder("I'm thinking of a number between ");
- chalengeMsg.append(game.getSmallest());
- chalengeMsg.append(" and ");
- chalengeMsg.append(game.getBiggest());
- chalengeMsg.append(". Can you guess what it is?");
+ 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 chalengeMsg.toString();
+ return challengeMsg.toString();
}
public String getResultMessage()
16 years, 5 months
- 1
- 0
Weld SVN: r4643 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: nickarls
Date: 2009-11-04 04:00:20 -0500 (Wed, 04 Nov 2009)
New Revision: 4643
Modified:
doc/trunk/reference/en-US/ee.xml
doc/trunk/reference/en-US/extend.xml
doc/trunk/reference/en-US/gettingstarted.xml
doc/trunk/reference/en-US/injection.xml
doc/trunk/reference/en-US/interceptors.xml
doc/trunk/reference/en-US/intro.xml
doc/trunk/reference/en-US/part1.xml
doc/trunk/reference/en-US/part4.xml
doc/trunk/reference/en-US/ri-spi.xml
doc/trunk/reference/en-US/scopescontexts.xml
doc/trunk/reference/en-US/specialization.xml
doc/trunk/reference/en-US/stereotypes.xml
Log:
typos
Modified: doc/trunk/reference/en-US/ee.xml
===================================================================
--- doc/trunk/reference/en-US/ee.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/ee.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -219,7 +219,7 @@
<para>
For Java SE execution, beans may be deployed in any location in which EJBs may be deployed for execution by the
embeddable EJB Lite container. Again, each location must contain a <literal>beans.xml</literal> file. (That
- doesn't rule out the possibility of having an extention which provides support for normal Java SE execution,
+ doesn't rule out the possibility of having an extension which provides support for normal Java SE execution,
like the Weld Java SE module).
</para>
Modified: doc/trunk/reference/en-US/extend.xml
===================================================================
--- doc/trunk/reference/en-US/extend.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/extend.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -57,7 +57,7 @@
<para>
The <literal>BeanManager</literal> interface lets us register and obtain beans, interceptors, decorators,
- observers and contexts programatically.
+ observers and contexts programmatically.
</para>
<programlisting role="JAVA"><![CDATA[public interface Manager {
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -43,7 +43,7 @@
<para>a supported runtime environment (minimum versions shown)</para>
<itemizedlist>
<listitem>
- <para>JBoss AS 5.2.0 (currenly only nightly builds of JBoss AS 5.2.0.Beta1 are available), or</para>
+ <para>JBoss AS 5.2.0 (currently only nightly builds of JBoss AS 5.2.0.Beta1 are available), or</para>
</listitem>
<listitem>
<para>GlassFish 3.0, or</para>
@@ -98,7 +98,7 @@
<para>
After you have downloaded JBoss AS, extract it. (We recommended renaming the folder to include the
<literal>as</literal> qualifier so it's clear that it's the application server). You can move the extracted
- folder anywhere you like. Whereever it lays to rest, that's what we'll call the JBoss AS installation
+ folder anywhere you like. Wherever it lays to rest, that's what we'll call the JBoss AS installation
directory, or <literal>JBOSS_HOME</literal>.
</para>
@@ -324,7 +324,7 @@
<para>
In order for Ant to push the artifact to the Tomcat hot deploy directory, it needs to know where the Tomcat
- installation is located. Again, we need to setup a propery in the local.build.properties file in the
+ installation is located. Again, we need to setup a property in the local.build.properties file in the
examples directory of the Weld distribution. If you haven't yet created this file, do so now. Then assign
the path of your Tomcat installation to the property key tomcat.home.
</para>
@@ -410,7 +410,7 @@
The Maven plugin communicates with Tomcat over HTTP, so it doesn't care where you have installed Tomcat.
However, the plugin configuration assumes you are running Tomcat in its default configuration, with a hostname
of localhost and port 8080. The readme.txt file in the example directory has information about how to modify
- the Maven settings to accomodate a different setup.
+ the Maven settings to accommodate a different setup.
</para>
<para>
@@ -730,7 +730,7 @@
<callout arearefs="instructions">
<para>
As the user guesses, the range of numbers they can guess gets
- smaller - this sentance changes to make sure they know the
+ smaller - this sentence changes to make sure they know the
number range of a valid guess.
</para>
</callout>
@@ -920,7 +920,7 @@
<tip>
<para>
You must also include the JARs for JSF, EL, and the common annotations
- (<literal>jsr250-api.jar</literal>), all of which are provided by the Java EE platorm (a Java EE
+ (<literal>jsr250-api.jar</literal>), all of which are provided by the Java EE platform (a Java EE
application server). Are you starting to appreciate why a Java EE platform is worth using?
</para>
</tip>
@@ -969,7 +969,7 @@
<note>
<para>
We'll also be using the Eclipse IDE in these examples. Instructions are provided later for running the
- example from the commandline, but since you'll likely need to do more than just deploy examples, we'll get
+ example from the command line, but since you'll likely need to do more than just deploy examples, we'll get
setup in this full development environment.
</para>
</note>
@@ -988,7 +988,7 @@
<para>
If you have m2eclipse installed, you can open any Maven project directly. From within Eclipse, select
<emphasis>File -> Import... -> Maven Projects</emphasis>. Then, browse to the location of the Wicket
- numberguess example. You should see that Eclipse recognizes the existance of a Maven project.
+ numberguess example. You should see that Eclipse recognizes the existence of a Maven project.
</para>
<mediaobject>
@@ -1652,7 +1652,7 @@
<note>
<para>
- Jave EE 6, which bundles EJB 3.1, allows you to package EJBs in a WAR, which will make this structure much
+ Java EE 6, which bundles EJB 3.1, allows you to package EJBs in a WAR, which will make this structure much
simpler! Still, there are other advantages of using an EAR.
</para>
</note>
@@ -1716,7 +1716,7 @@
</para>
<para>
- More intersting is the JSF view used to translate text. Just as in the numberguess example we have a template,
+ More interesting is the JSF view used to translate text. Just as in the numberguess example we have a template,
which surrounds the form (ommitted here for brevity):
</para>
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -235,7 +235,7 @@
this.asyncPaymentProcessor = asyncPaymentProcessor;
}]]></programlisting>
- <para>Using using constructor injection:</para>
+ <para>Using constructor injection:</para>
<programlisting role="JAVA"><![CDATA[@Inject
public Checkout(@Synchronous PaymentProcessor syncPaymentProcessor,
@@ -275,7 +275,7 @@
<title>Qualifiers with members</title>
<para>
- Annotations can have members (i.e., fields) just like regular classes. You can use these fields to furthur
+ Annotations can have members (i.e., fields) just like regular classes. You can use these fields to further
discriminate the qualifier. This simply prevents an explosion of annotations that you have to introduce.
For instance, if you wanted to create several qualifiers representing different payment methods, you could
aggregate them under a single annotation using a member:
@@ -375,7 +375,7 @@
</para>
<para>
- During the course of your development, your going to encounter these errors. Let's learn how to resolve them.
+ During the course of your development, you're going to encounter these errors. Let's learn how to resolve them.
It's usually pretty easy, and a decent IDE can really help out here.
</para>
@@ -437,7 +437,7 @@
If you recall, Seam also boasted the ability to reference the current instance of a component. However, Seam
went about it differently. In Seam, the references are established prior to the method call and cleared
afterword using an interceptor—a process known as bijection. This model was not very friendly to multiple
- threads sharing instances and thefore the client proxy approach was adopted in CDI instead.
+ threads sharing instances and therefore the client proxy approach was adopted in CDI instead.
</para>
</note>
@@ -535,7 +535,7 @@
.select(new AnnotationLiteral<Asynchronous>() {});]]></programlisting>
<para>
- You can choose to create a concreate type for all of your annotation literals, such as:
+ You can choose to create a concrete type for all of your annotation literals, such as:
</para>
<programlisting role="JAVA"><![CDATA[abstract class AsynchronousQualifier
@@ -543,7 +543,7 @@
<note>
<para>
- The concrete is required if your qualifier has members, since an anonymous subclass cannot define members.
+ The concrete type is required if your qualifier has members, since an anonymous subclass cannot define members.
</para>
</note>
@@ -567,7 +567,7 @@
<para>
You won't always be able to take advantage of the type safety that CDI provides. One of those places is the JSF
- view. To accomodate that environment, CDI must learn to speak the binding language that view templates
+ view. To accommodate that environment, CDI must learn to speak the binding language that view templates
understand. That language is the Unified EL.
</para>
Modified: doc/trunk/reference/en-US/interceptors.xml
===================================================================
--- doc/trunk/reference/en-US/interceptors.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/interceptors.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -5,7 +5,7 @@
<title>Interceptors</title>
<para>
- Thanks to the managed bean specification, intereceptors are now part of the core functionality of a bean. That
+ Thanks to the managed bean specification, interceptors are now part of the core functionality of a bean. That
means that you no longer need to make your class an EJB just to use interceptors!
</para>
@@ -253,7 +253,7 @@
@Transactional public void checkout() { ... }
}]]></programlisting>
- <programlisting role="JAVA"><![CDATA[@Transactionl
+ <programlisting role="JAVA"><![CDATA[@Transactional
public class ShoppingCart {
@Secure public void checkout() { ... }
}]]></programlisting>
Modified: doc/trunk/reference/en-US/intro.xml
===================================================================
--- doc/trunk/reference/en-US/intro.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/intro.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -182,8 +182,8 @@
</tip>
<para>
- Alternatively, we may obtain an instance of <literal>TextTranslator</literal> programatically from an injected
- instance of <literal>Instance</literal>, paramaterized with the bean type:
+ Alternatively, we may obtain an instance of <literal>TextTranslator</literal> programmatically from an injected
+ instance of <literal>Instance</literal>, parameterized with the bean type:
</para>
<programlisting role="JAVA"><![CDATA[@Inject Instance<TextTranslator> textTranslatorSource;
@@ -265,7 +265,7 @@
<para>
One great advantage of the contextual model is that it allows stateful beans to be treated like services! The
client need not concern itself with managing the lifecycle of the bean it's using, <emphasis>nor does it even
- need to know what that lifecyle is.</emphasis> Beans interact by passing messages, and the bean implementations
+ need to know what that lifecycle is.</emphasis> Beans interact by passing messages, and the bean implementations
define the lifecycle of their own state. The beans are loosely coupled because:
</para>
@@ -373,8 +373,8 @@
The bean types alone often do not provide enough information for the container to know which bean to inject.
For instance, suppose we have two implementations of the <literal>PaymentProcessor</literal> interface:
<literal>CreditCardPaymentProcessor</literal> and <literal>DebitPaymentProcessor</literal>. Injecting into a
- field of type <literal>PaymentProcessor</literal> introduces an ambigious condition. In these cases, the
- container must rely on some client-visible semantic that is satisified by one implementation of the bean
+ field of type <literal>PaymentProcessor</literal> introduces an ambiguous condition. In these cases, the
+ container must rely on some client-visible semantic that is satisfied by one implementation of the bean
type, but not by others. That semantic is called a qualifier.
</para>
@@ -540,7 +540,7 @@
<para>
We've already seen how qualifiers let us choose between multiple implementations of an interface at
- development time. But sometimes we have an interface whose implementation varies dependending upon
+ development time. But sometimes we have an interface whose implementation varies depending upon
the deployment environment. For example, we may want to use a mock implementation in a testing
environment. An <emphasis>alternative</emphasis> may be declared by annotating the bean class or
producer method or field with the <literal>@Alternative</literal> annotation.
@@ -581,7 +581,7 @@
well just put the interceptor code <emphasis>in</emphasis> the implementation. Second, the order in which
the interceptors are applied is taken from the order in which they are declared in the annotation or the XML
descriptor. Perhaps this isn't so bad if you're applying the interceptors to a single bean. But, if you are
- applying them repeatly, then there is a chance that you'll inadvertly define a different order for different
+ applying them repeatedly, then there is a chance that you'll inadvertently define a different order for different
beans. Now that is a problem.
</para>
@@ -685,7 +685,7 @@
<para>
EJB 3 session beans belong to the EJB specification. That is, the basic lifecycle and semantics. Beyond
that, they get to participate in CDI just like any other bean. There are some restrictions about which
- scopes can be assigned to a session bean, but other than that, they are interchangable with regular managed
+ scopes can be assigned to a session bean, but other than that, they are interchangeable with regular managed
beans. That means you can inject one session bean into another, a managed bean into a session bean, a
session bean into a managed bean, have a managed bean observe an event raised by a session bean, and so on.
</para>
@@ -952,7 +952,7 @@
<para>
Naturally, there remained some mismatch with the new style of dependency injection in CDI. Most notably,
- resource injections rely on string-based names to qualify ambigious types, and there is no real consistency
+ resource injections rely on string-based names to qualify ambiguous types, and there is no real consistency
as to how a resource obtains its name (sometimes JNDI, other times from an XML descriptor or even a default
name). Producer fields turned out to be an elegant adapter to rein them in and get them to participate in
the CDI system just like any other injectable bean.
Modified: doc/trunk/reference/en-US/part1.xml
===================================================================
--- doc/trunk/reference/en-US/part1.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/part1.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -138,7 +138,7 @@
</itemizedlist>
<para>
- The main theme of CDI, which is instrumental in removing these complexities, is <emphasis>loose-couping with
+ The main theme of CDI, which is instrumental in removing these complexities, is <emphasis>loose-coupling with
strong typing</emphasis>. Let's study what that phrase means.
</para>
Modified: doc/trunk/reference/en-US/part4.xml
===================================================================
--- doc/trunk/reference/en-US/part4.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/part4.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -14,7 +14,7 @@
into the Java EE platform via an SPI. This SPI positions CDI as the foundation for a new ecosystem of
<emphasis>portable</emphasis> extensions and integration with existing frameworks and technologies. The CDI
services will be able to reach a diverse collection of technologies, such as business process management (BPM)
- engines, existing web frameworks and defacto standard component models. Of course, The Java EE platform will never
+ engines, existing web frameworks and de facto standard component models. Of course, The Java EE platform will never
be able to standardize all the interesting technologies that are used in the world of Java application
development, but CDI makes it easier to use the technologies which are not yet part of the platform seamlessly
within the Java EE environment.
Modified: doc/trunk/reference/en-US/ri-spi.xml
===================================================================
--- doc/trunk/reference/en-US/ri-spi.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/ri-spi.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -114,7 +114,7 @@
<para>
BDA X may also reference another BDA Y whose beans can be resolved by, and injected into, any bean in BDA X.
These are the accessible BDAs, and every BDA that is directly accessible by BDA X should be returned. A BDA
- will also have BDAs which are accessible transtivively, and the transitive closure of the sub-graph of BDA X
+ will also have BDAs which are accessible transitively, and the transitive closure of the sub-graph of BDA X
describes all the beans resolvable by BDA X.
</para>
@@ -291,7 +291,7 @@
<para>
<literal>InjectionServices</literal> provides a very simple contract, the
<literal>InjectionServices.aroundInject(InjectionContext ic);</literal> intercepter will be called for every
- instance that CDI injects, whether it is a contextual instance, or a non-contexutal instance injected by
+ instance that CDI injects, whether it is a contextual instance, or a non-contextual instance injected by
<literal>InjectionTarget.inject()</literal>.
</para>
@@ -491,7 +491,7 @@
<para>
If you are integrating Weld into a JSF environment you must register
- <literal>org.jboss.weld.el.WeldELContextListener</literal> as as an EL Context listener.
+ <literal>org.jboss.weld.el.WeldELContextListener</literal> as an EL Context listener.
</para>
<para>
@@ -537,7 +537,7 @@
<para>
If you are integrating Weld into a JSP environment you must register
- <literal>org.jboss.weld.el.WeldELContextListener</literal> as as an EL Context listener.
+ <literal>org.jboss.weld.el.WeldELContextListener</literal> as an EL Context listener.
</para>
<para>
Modified: doc/trunk/reference/en-US/scopescontexts.xml
===================================================================
--- doc/trunk/reference/en-US/scopescontexts.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/scopescontexts.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -54,7 +54,7 @@
<para>
Of course, that's the easy part of the job. For this scope type to be useful, we will also need to define a
<literal>Context</literal> object that implements the scope! Implementing a <literal>Context</literal> is
- usually a very technical task, intended for framework development only. You can expect an implemention of the
+ usually a very technical task, intended for framework development only. You can expect an implementation of the
business scope, for instance, in a future version of Seam.
</para>
@@ -172,7 +172,7 @@
<title>Conversation demarcation</title>
<para>
- CDI provides a built-in bean for controlling the lifecyle of conversations in a JSF application. This bean
+ CDI provides a built-in bean for controlling the lifecycle of conversations in a JSF application. This bean
may be obtained by injection:
</para>
Modified: doc/trunk/reference/en-US/specialization.xml
===================================================================
--- doc/trunk/reference/en-US/specialization.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/specialization.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -7,9 +7,9 @@
<para>
When you first start developing with CDI, you'll likely be dealing only with a single bean implementation for each
bean type. In this case, it's easy to understand how beans get selected for injection. As the complexity of your
- application grows, multiple occurances of the same bean type start appearing, either because you have multiple
+ application grows, multiple occurrences of the same bean type start appearing, either because you have multiple
implementations or two beans share a common (Java) inheritance. That's when you have to begin studying the
- specialization, inheritance and alternative rules to work through unsatisified or ambiguous dependencies or to
+ specialization, inheritance and alternative rules to work through unsatisfied or ambiguous dependencies or to
avoid certain beans from being called.
</para>
Modified: doc/trunk/reference/en-US/stereotypes.xml
===================================================================
--- doc/trunk/reference/en-US/stereotypes.xml 2009-11-04 06:31:52 UTC (rev 4642)
+++ doc/trunk/reference/en-US/stereotypes.xml 2009-11-04 09:00:20 UTC (rev 4643)
@@ -145,7 +145,7 @@
<title>Alternatives as stereotypes</title>
<para>
- A stereotype can inicate that all beans to which it is applied are <literal>@Alternative</literal> beans. If
+ A stereotype can indicate that all beans to which it is applied are <literal>@Alternative</literal> beans. If
you can remember back to the early days of the specification, this is the closest match to a deployment type.
Whole sets of beans can be enabled or left disabled by activating a single stereotype.
</para>
16 years, 5 months
- 1
- 0
Weld SVN: r4642 - cdi-tck/trunk/impl/src/main/resources.
by weld-commits＠lists.jboss.org
Author: shane.bryzak(a)jboss.com
Date: 2009-11-04 01:31:52 -0500 (Wed, 04 Nov 2009)
New Revision: 4642
Modified:
cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
Log:
more assertions updated
Modified: cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml
===================================================================
--- cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-04 00:16:57 UTC (rev 4641)
+++ cdi-tck/trunk/impl/src/main/resources/tck-audit-cdi.xml 2009-11-04 06:31:52 UTC (rev 4642)
@@ -2958,35 +2958,43 @@
</assertion>
<assertion id="b">
- <text>When a bean is declared to have |@Dependent| scope, any injected instance of the bean is bound to the lifecycle of the bean, servlet or EJB into which it is injected.</text>
+ <text>When a bean is declared to have |@Dependent| scope, any instance of the bean injected into an object that is being created by the container is bound to the lifecycle of the newly created object.</text>
</assertion>
<assertion id="ca">
<text>When a bean is declared to have |@Dependent| scope, when a unified EL expression in a JSF or JSP page that refers to the bean by its EL name is evaluated, at most one instance of the bean is instantiated. This instance exists to service just a single evaluation of the EL expression. It is reused if the bean EL name appears multiple times in the EL expression, but is never reused when the EL expression is evaluated again, or when another EL expression is evaluated.</text>
</assertion>
- <assertion id="da">
- <text>When a bean is declared to have |@Dependent| scope, any instance of the bean that receives a producer method~, producer field, disposer method or observer method~ invocation exists to service that invocation only</text>
- </assertion>
+ <group>
+ <text>When a bean is declared to have |@Dependent| scope, any instance of the bean that receives a producer method, producer field, disposer method or observer method invocation exists to service that invocation only</text>
+
+ <assertion id="da">
+ <text>Test with a producer method.</text>
+ </assertion>
- <assertion id="db">
- <text>When a bean is declared to have |@Dependent| scope, any instance of the bean that receives a ~producer method,~ producer field~, disposer method or observer method~ invocation exists to service that invocation only</text>
- </assertion>
+ <assertion id="db">
+ <text>Test with a producer field.</text>
+ </assertion>
- <assertion id="dc">
- <text>When a bean is declared to have |@Dependent| scope, any instance of the bean that receives a ~producer method, producer field,~ disposer method ~or observer method~ invocation exists to service that invocation only</text>
- </assertion>
+ <assertion id="dc">
+ <text>Test with a disposer method.</text>
+ </assertion>
- <assertion id="dd">
- <text>When a bean is declared to have |@Dependent| scope, any instance of the bean that receives a ~producer method, producer field, disposer method or~ observer method invocation exists to service that invocation only</text>
+ <assertion id="dd">
+ <text>Test with an observer method.</text>
+ </assertion>
+ </group>
+
+ <assertion id="dg">
+ <text>Any instance of the bean injected into method parameters of a disposer method or observer method exists to service the method invocation only (except for observer methods of container lifecycle events).</text>
</assertion>
<assertion id="e">
- <text>Every invocation of the |get()| operation of the |Context| object for the |@Dependent| scope with a |CreationalContext| returns a new instance of the given bean</text>
+ <text>Every invocation of the |get()| operation of the |Context| object for the |@Dependent| scope with a |CreationalContext| returns a new instance of the given bean.</text>
</assertion>
<assertion id="f">
- <text>Every invocation of the |get()| operation of the |Context| object for the |@Dependent| scope with no |CreationalContext| returns a null value</text>
+ <text>Every invocation of the |get()| operation of the |Context| object for the |@Dependent| scope with no |CreationalContext| returns a null value.</text>
</assertion>
<assertion id="g">
@@ -3031,7 +3039,7 @@
</assertion>
</section>
- <section id="6.4.2" title="Dependent object destruction">
+ <section id="6.4.2" title="Destruction of objects with scope @Dependent">
<group>
<text>The container must ensure that all dependent objects of a non-contextual instance of a bean or other Java EE component class are destroyed when the instance is destroyed by the container.</text>
@@ -3158,25 +3166,42 @@
<section id="6.5.4" title="Contextual reference validity">
<assertion id="a">
- <text>Any reference to a bean with a normal scope is valid as long as the application maintains a hard reference to it. However, it may only be invoked when the context associated with the normal scope is active. If it is invoked when the context is inactive, a |ContextNotActiveException| is thrown by the container.</text>
+ <text>Any reference to a bean with a normal scope is valid as long as the application maintains a hard reference to it. However, it may only be invoked when the context associated with the normal scope is active. If it is invoked when the context is inactive, a |ContextNotActiveException| is thrown by the container.</text>
</assertion>
<assertion id="b" testable="false">
- <text>
- Any reference to a bean with a pseudo-scope (such as |@Dependent|) is valid until the bean instance to which it refers is destroyed. It may be invoked even if the context associated with the pseudo-scope is not active. If the application invokes a method of a reference to an instance that has already been destroyed, the behavior is undefined.
- </text>
+ <text>Any reference to a bean with a pseudo-scope (such as |@Dependent|) is valid until the bean instance to which it refers is destroyed. It may be invoked even if the context associated with the pseudo-scope is not active. If the application invokes a method of a reference to an instance that has already been destroyed, the behavior is undefined.</text>
<note>Describes unspecified behavior</note>
</assertion>
</section>
+
+ <section id="6.5.5" title="Injectable references">
+ <assertion id="a">
+ <text>From time to time, the container must obtain an injectable reference for an injection point. The container must identify a bean according to the rules defined in Section 5.2, "Typesafe resolution" and resolving ambiguities according to Section 5.2.1, "Unsatisfied and ambiguous dependencies", then obtain a contextual reference for this bean and the type of the injection point according to Section 6.5.3, "Contextual reference for a bean".</text>
+ </assertion>
+
+ <assertion id="b">
+ <text>For certain combinations of scopes, the container is permitted to optimize the procedure for obtaining an injectable reference for an injection point - the container is permitted to directly inject a contextual instance of the bean, as defined in Section 6.5.2, "Contextual instance of a bean", and if an incompletely initialized instance of the bean is registered with the current |CreationalContext|, as defined in Section 6.1, "The Contextual interface", the container is permitted to directly inject this instance.</text>
+ </assertion>
+ </section>
+
+ <section id="6.5.6" title="Injectable reference validity">
+ <assertion id="a">
+ <text>Injectable references to a bean must respect the rules of contextual reference validity, with the following exceptions - a reference to a bean injected into a field, bean constructor or initializer method is only valid until the object into which it was injected is destroyed, a reference to a bean injected into a producer method is only valid until the producer method bean instance that is being produced is destroyed, and a reference to a bean injected into a disposer method or observer method is only valid until the invocation of the method completes.</text>
+ </assertion>
+
+ <assertion id="b" testable="false">
+ <text>The application should not invoke a method of an invalid injected reference. If the application invokes a method of an invalid injected reference, the behavior is undefined.</text>
+ <note>Behavior is undefined.</note>
+ </assertion>
+ </section>
<section id="6.6" title="Passivation and passivating scopes">
<assertion id="a" implied="true">
- <text>Test passivation occurs</text>
+ <text>Test that passivation occurs.</text>
</assertion>
</section>
-
-
<section id="6.6.1" title="Passivation capable beans">
<assertion id="a" testable="false">
<text>As defined by the EJB specification, all stateful session beans are passivation capable. Stateless and singleton session beans are not passivation capable.</text>
@@ -3297,12 +3322,12 @@
<section id="6.6.4" title="Validation of passivation capable beans and dependencies">
<assertion id="aaa">
- <text>If a managed bean which declares a passivating scope is not passivation capable, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a managed bean which declares a passivating scope is not passivation capable, then the container automatically detects the problem and treats it as a deployment problem.</text>
<note>Here we check the class, as interceptors and decorators are tested below</note>
</assertion>
<group>
- <text>If a managed bean which declares a passivating scope has a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a managed bean which declares a passivating scope has a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="aaba">
<text>Test with injected field.</text>
</assertion>
@@ -3317,7 +3342,7 @@
</group>
<group>
- <text>If a managed bean which declares a passivating scope has an interceptor or decorator with a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a managed bean which declares a passivating scope has an interceptor or decorator with a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="aac">
<text>Test interceptor with injected field.</text>
@@ -3345,7 +3370,7 @@
</group>
<group>
- <text>If a stateful session bean has a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a stateful session bean has a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="ba">
<text>Test with an injected field.</text>
@@ -3362,7 +3387,7 @@
</group>
<group>
- <text>If a stateful session bean has an interceptor or decorator with a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a stateful session bean has an interceptor or decorator with a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="bda">
<text>Test an interceptor with an injected field.</text>
@@ -3390,7 +3415,7 @@
</group>
<group>
- <text>If a producer method declares a passivating scope and the container is able to determine that it is not passivation capable by inspecting its return type, or has a parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a producer method declares a passivating scope and the container is able to determine that it is not passivation capable by inspecting its return type, or has a parameter that does not resolve to a passivation capable dependency, then the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="ca">
<text>Test a producer method with a non passivation-capable return type.</text>
@@ -3402,8 +3427,7 @@
</group>
<assertion id="d">
- <text>If a producer field declares a passivating scope and the container is able to determine that it is not passivation capable by inspecting its type, then the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4,
-"Problems detected automatically by the container".</text>
+ <text>If a producer field declares a passivating scope and the container is able to determine that it is not passivation capable by inspecting its type, then the container automatically detects the problem and treats it as a deployment problem.</text>
</assertion>
<group>
@@ -3451,7 +3475,7 @@
</group>
<group>
- <text>If a bean which declares a passivating scope type, or any stateful session bean, has a decorator which is not a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If a bean which declares a passivating scope type, or any stateful session bean, has a decorator which is not a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="ha">
<text>Test with a bean which declares a passivating scope type.</text>
@@ -3885,7 +3909,7 @@
</assertion>
<group>
- <text>If, and only if, the invocation is a business method invocation it passes through the method interceptor and decorator stacks, and in the case of a session bean, it is subject to EJB services such a declarative transaction management, concurrency, security and asynchronicity, as defined by the EJB specification.</text>
+ <text>If, and only if, the invocation is a business method invocation it passes through method interceptors and decorators, and in the case of a session bean, it is subject to EJB services such a declarative transaction management, concurrency, security and asynchronicity, as defined by the EJB specification.</text>
<assertion id="a">
<text>Verify that a managed bean's business methods are intercepted</text>
@@ -4309,7 +4333,7 @@
</assertion>
<assertion id="b">
- <text>Interceptor bindings are transitive�an interceptor binding declared by an interceptor binding type is inherited by all beans and other interceptor binding types that declare that interceptor binding type.</text>
+ <text>Interceptor bindings are transitive - an interceptor binding declared by an interceptor binding type is inherited by all beans and other interceptor binding types that declare that interceptor binding type.</text>
</assertion>
<assertion id="c" testable="false">
@@ -4337,6 +4361,10 @@
<assertion id="a">
<text>The interceptor bindings of an interceptor are specified by annotating the interceptor class with the binding types and the |(a)javax.interceptor.Interceptor| annotation.</text>
</assertion>
+
+ <assertion id="ab">
+ <text>An interceptor class may declare multiple interceptor bindings.</text>
+ </assertion>
<assertion id="b">
<text>If an interceptor does not declare an |@Interceptor| annotation, it must be bound to beans using |@Interceptors| or |ejb-jar.xml|.</text>
@@ -4355,6 +4383,18 @@
<assertion id="a">
<text>An interceptor binding may be declared by annotating the bean class, or a method of the bean class, with the interceptor binding type.</text>
</assertion>
+
+ <assertion id="b">
+ <text>A bean class or method of a bean class may declare multiple interceptor bindings.</text>
+ </assertion>
+
+ <assertion id="c">
+ <text>If the bean class of a managed bean declares or inherits a class level interceptor binding or a stereotype with interceptor bindings, it must not be declared final, or have any non-static, non-private, final methods. If a managed bean has a class-level interceptor binding and is declared final or has a non-static, non-private, final method, the container automatically detects the problem and treats it as a definition error.</text>
+ </assertion>
+
+ <assertion id="d">
+ <text>If a non-static, non-private method of a bean class of a managed bean declares a method level interceptor binding, neither the method nor the bean class may be declared final. If a non-static, non-private, final method of a managed bean has a method level interceptor binding, the container automatically detects the problem and treats it as a definition error.</text>
+ </assertion>
</section>
<section id="9.4" title="Interceptor enablement and ordering">
@@ -4369,7 +4409,7 @@
</assertion>
<group>
- <text>Each child |<class>| element must specify the name of an interceptor class. If there is no class with the specified name, or if the class with the specified name is not an interceptor class, the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>Each child |<class>| element must specify the name of an interceptor class. If there is no class with the specified name, or if the class with the specified name is not an interceptor class, the container automatically detects the problem and treats it as a deployment problem.</text>
<assertion id="caa">
<text>Test with a non-existant class.</text>
@@ -4381,7 +4421,7 @@
</group>
<assertion id="cb">
- <text>If the same class is listed twice under the |<interceptors>| element, the container automatically detects the problem and treats it as a deployment problem, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If the same class is listed twice under the |<interceptors>| element, the container automatically detects the problem and treats it as a deployment problem.</text>
</assertion>
<assertion id="f">
@@ -4395,12 +4435,12 @@
<section id="9.5" title="Interceptor resolution">
<assertion id="a">
- <text>For a lifecycle callback, the bean interceptor bindings include the interceptor bindings declared by the bean at the class level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes.
+ <text>For a lifecycle callback method, the interceptor bindings include the interceptor bindings declared or inherited by the bean at the class level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes.
</text>
</assertion>
<group>
- <text>For a business method, or EJB timeout method, the bean interceptor bindings include the interceptor bindings declared by the bean at the class level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes, together with all interceptor bindings declared at the method level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively.</text>
+ <text>For a business method, or EJB timeout method, the bean interceptor bindings include the interceptor bindings declared or inherited by the bean at the class level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively, and of stereotypes, together with all interceptor bindings declared at the method level, including interceptor bindings declared as meta-annotations of other interceptor bindings, recursively.</text>
<assertion id="ba">
<text>Check a business method</text>
</assertion>
@@ -4410,13 +4450,9 @@
</group>
<assertion id="ca">
- <text>First, the container identifies the set of matching enabled interceptors where, for each interceptor binding declared by the interceptor, there exists an interceptor binding in the set of bean interceptor bindings with (a) the same type and (b) the same annotation member value for each member which is not annotated |(a)javax.enterprise.inject.NonBinding| (see Section 9.5.2, "Interceptor binding types with members"), and the interceptor intercepts the given kind of lifecycle callback or business method, and the interceptor is enabled in the bean deployment archive of the bean.</text>
+ <text>An interceptor is bound to a method if the method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which is not annotated |(a)javax.enterprise.util.NonBinding|, and the interceptor intercepts the given kind of lifecycle callback or business method, and the interceptor is enabled in the bean deployment archive of the bean.</text>
</assertion>
-
- <assertion id="ea">
- <text>Next, the container orders the matching interceptors according to the interceptor ordering specified in Section 9.4, "Interceptor enablement and ordering".</text>
- </assertion>
-
+
<group>
<text>For a custom implementation of the Interceptor interface defined in Section 11.1.2, "The Interceptor interface", the container calls |getInterceptorBindings()| to determine the interceptor bindings of the interceptor and |intercepts()| to determine if the interceptor intercepts a given kind of lifecycle callback, EJB timeout or business method.</text>
<assertion id="fa">
@@ -4443,7 +4479,7 @@
<section id="9.5.1" title="Interceptors with multiple bindings">
<group>
- <text>An interceptor class may specify multiple interceptor bindings, in which case the interceptor will be applied only to beans that declare all the bindings at the class level, and to methods of beans for which every binding appears at either the method or class level.</text>
+ <text>An interceptor class may specify multiple interceptor bindings.</text>
<assertion id="a">
<text>Test that the interceptor is applied to a bean with all of the bindings.</text>
</assertion>
@@ -4468,7 +4504,7 @@
</assertion>
<assertion id="d">
- <text>If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error.</text>
</assertion>
</section>
@@ -4913,7 +4949,7 @@
</assertion>
<assertion id="g" testable="false">
- <text>An application or portable extension may add support for new kinds of beans beyond those defined by the this specification (managed beans, session beans, producer methods and fields, resources and message destinations) by implementing |Bean| and registering beans with the container, using the mechanism defined in Section 11.5.2, "AfterBeanDiscovery event".</text>
+ <text>A portable extension may add support for new kinds of beans beyond those defined by the this specification (managed beans, session beans, producer methods and fields, resources and message destinations) by implementing |Bean| and registering beans with the container, using the mechanism defined in Section 11.5.2, "AfterBeanDiscovery event".</text>
</assertion>
</section>
@@ -4945,11 +4981,11 @@
</assertion>
<assertion id="c">
- <text>|intercepts()| returns |true| if the interceptor intercepts callbacks or business methods of the given type, and |false| otherwise.</text>
+ <text>|intercepts()| returns |true| if the interceptor intercepts the specified kind of lifecycle callback or method invocation, and |false| otherwise.</text>
</assertion>
<assertion id="d">
- <text>|intercept()| invokes the specified kind of lifecycle callback or business method upon the given instance.</text>
+ <text>|intercept()| invokes the specified kind of lifecycle callback or method invocation interception upon the given instance of the interceptor.</text>
</assertion>
<assertion id="e">
@@ -4998,7 +5034,7 @@
</assertion>
<group>
- <text>For a |Producer| that represents a class, |produce()| calls the constructor annotated |@Inject| if it exists, or the constructor with no parameters otherwise, as defined in Section 5.6.3, "Injection using the bean constructor". and returns the resulting instance. If the class has interceptors, |produce()| is responsible for building the interceptor and decorator stacks for the instance.</text>
+ <text>For a |Producer| that represents a class, |produce()| calls the constructor annotated |@Inject| if it exists, or the constructor with no parameters otherwise, as defined in Section 5.6.3, "Injection using the bean constructor". and returns the resulting instance. If the class has interceptors, |produce()| is responsible for building the interceptors and decorators of the instance.</text>
<assertion id="ba">
<text>Test field injection occurs</text>
</assertion>
@@ -5064,7 +5100,7 @@
</assertion>
<assertion id="i">
- <text>|inject()| performs dependency injection upon the given object. First, the container performs Java EE component environment injection according to the semantics required by the Java EE platform specification. Next, it sets the value of all injected fields, and then calls all initializer methods, as defined in Section 5.6.4, "Injection of fields and initializer methods".</text>
+ <text>|inject()| performs dependency injection upon the given object. The container performs Java EE component environment injection, according to the semantics required by the Java EE platform specification, sets the value of all injected fields, and calls all initializer methods, as defined in Section 5.6.4, "Injection of fields and initializer methods".</text>
</assertion>
<assertion id="j">
@@ -5156,7 +5192,7 @@
<section id="11.3.4" title="Obtaining a Bean by type">
<assertion id="aa">
- <text>The method |BeanManager.getBeans()| returns the set of beans which match the given required type and qualifiers and are accessible to the class into which the |BeanManager| was injected, or to the Java EE component from whose JNDI environment namespace the |BeanManager| was obtained, according to the rules of typesafe resolution defined in Section 5.3, "Typesafe resolution".</text>
+ <text>The method |BeanManager.getBeans()| returns the set of beans which have the given required type and qualifiers and are available for injection in the module or library containing the class into which the |BeanManager| was injected or the Java EE component from whose JNDI environment namespace the |BeanManager| was obtained, according to the rules of typesafe resolution defined in Section 5.3, "Typesafe resolution".</text>
</assertion>
<assertion id="b">
@@ -5182,7 +5218,7 @@
<section id="11.3.5" title="Obtaining a Bean by name">
<assertion id="aa">
- <text>The method |BeanManager.getBeans()| which accepts a string returns the set of beans which match the given EL name and are accessible to the class into which the |BeanManager| was injected, or to the Java EE component from whose JNDI environment namespace the |BeanManager| was obtained, according to the rules of EL name resolution defined in Section 5.4, "EL name resolution".</text>
+ <text>The method |BeanManager.getBeans()| which accepts a string returns the set of beans which have the given EL name and are available for injection in the module or library containing the class into which the |BeanManager| was injected or the Java EE component from whose JNDI environment namespace the |BeanManager| was obtained, according to the rules of EL name resolution defined in Section 5.4, "EL name resolution".</text>
</assertion>
<assertion id="b">
@@ -5561,7 +5597,7 @@
</assertion>
<assertion id="b">
- <text>Observers of these events must be service providers of the service |javax.enterprise.inject.spi.Extension| declared in |META-INF/services|.</text>
+ <text>Observer methods of these events must belong to extensions. An extension is a service provider |javax.enterprise.inject.spi.Extension| declared in |META-INF/services|.</text>
</assertion>
<assertion id="c">
@@ -5569,7 +5605,7 @@
</assertion>
<assertion id="d">
- <text>Service providers may have observer methods, which may observe container initialization events and obtain an injected |BeanManager| reference.</text>
+ <text>The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods.</text>
</assertion>
<assertion id="e">
@@ -5686,7 +5722,7 @@
<section id="11.5.5" title="ProcessAnnotatedType event">
<assertion id="a">
- <text>The container must fire an event for each Java class it discovers, before it reads the declared annotations. The event object must be of type |javax.enterprise.inject.spi.ProcessAnnotatedType<X>|, where |X| is the class.</text>
+ <text>The container must fire an event for each Java class it discovers in a bean deployment archive, before it reads the declared annotations. The event object must be of type |javax.enterprise.inject.spi.ProcessAnnotatedType<X>|, where |X| is the class.</text>
</assertion>
<assertion id="ba">
@@ -5712,7 +5748,7 @@
<section id="11.5.6" title="ProcessInjectionTarget event">
<group>
- <text>The container must fire an event for each managed bean, session bean, Java EE component class supporting injection, producer method or producer field it discovers. The event object must be of type |javax.enterprise.inject.spi.ProcessInjectionTarget<X>|, where |X| is the managed bean class, session bean class or Java EE component class supporting injection.</text>
+ <text>The container must fire an event for every Java EE component class supporting injection that may be instantiated by the container at runtime, including every managed bean declared using |@ManagedBean|, EJB session or message-driven bean, enabled bean, enabled interceptor or enabled decorator.</text>
<assertion id="aaa">
<text>Test event is fired for a managed bean</text>
</assertion>
@@ -5846,7 +5882,7 @@
<section id="11.5.7" title="ProcessProducer event">
<group>
- <text>The container must fire an event for each producer method or field, including resources.</text>
+ <text>The container must fire an event for each producer method or field of each enabled bean, including resources.</text>
<assertion id="aa">
<text>Test producer method</text>
</assertion>
@@ -5913,7 +5949,7 @@
<section id="11.5.8" title="ProcessBean event">
<assertion id="aa" testable="false">
- <text>The container must fire an event for each bean it discovers, before registering the |Bean| object. The event object in the package |javax.enterprise.inject.spi| depends upon what kind of bean was discovered.</text>
+ <text>The container must fire an event for each enabled bean, interceptor or decorator deployed in a bean deployment archive, before registering the |Bean| object. No event is fired for any |@New| qualified bean, defined in Section 3.12, "@New qualified beans".</text>
<note>Tested below</note>
</assertion>
@@ -6032,7 +6068,7 @@
<section id="11.5.9" title="ProcessObserverMethod event">
<assertion id="aaa">
- <text>The container must fire an event for each observer method. The event object must be of type |javax.enterprise.inject.spi.ProcessObserverMethod<T, X>| where |T| is the bean class of the bean that declares the observer method and |X| is the observed event type of the observer method.</text>
+ <text>The container must fire an event for each observer method of each enabled bean, before registering the |ObserverMethod| object. The event object must be of type |javax.enterprise.inject.spi.ProcessObserverMethod<T, X>| where |T| is the bean class of the bean that declares the observer method and |X| is the observed event type of the observer method.</text>
</assertion>
<assertion id="aba">
@@ -6058,14 +6094,18 @@
<section id="12.1" title="Bean deployment archives">
<assertion id="aa" testable="false">
- <text>Bean classes must be deployed in bean deployment archives.</text>
+ <text>Bean classes of enabled beans must be deployed in bean deployment archives.</text>
</assertion>
<assertion id="a" testable="false">
- <text>A library jar, EJB jar or rar archive is a bean deployment archive if it has a file named |beans.xml| in the |META-INF| directory. The |WEB-INF/classes| directory of a war is a bean deployment archive if there is a file named |beans.xml| in the |WEBINF| directory of the war. A directory in the JVM classpath is a bean deployment archive if it has a file named |beans.xml| in the |META-INF| directory.</text>
+ <text>A library jar, EJB jar, application client jar or rar archive is a bean deployment archive if it has a file named |beans.xml| in the |META-INF| directory. The |WEB-INF/classes| directory of a war is a bean deployment archive if there is a file named |beans.xml| in the |WEBINF| directory of the war. A directory in the JVM classpath is a bean deployment archive if it has a file named |beans.xml| in the |META-INF| directory.</text>
<note>covered in bb*, bc*, bd*</note>
</assertion>
+ <assertion id="b" testable="false">
+ <text>The container is not required to support application client jar bean deployment archives.</text>
+ </assertion>
+
<assertion id="ba" testable="false">
<text>The container searches for beans in bean deployment archives in the application classpath.</text>
<note>covered in bb*, bc*, bd*</note>
@@ -6135,14 +6175,10 @@
</group>
<assertion id="be" testable="false">
- <text>When searching for beans, the container considers any Java class in any bean deployment archive, and any |ejb-jar.xml| file in the metadata directory of any EJB bean deployment archive.</text>
+ <text>When searching for beans, the container considers any Java class in any bean deployment archive, any |ejb-jar.xml| file in the metadata directory of any EJB bean deployment archive, any Java class referenced by the |@New| qualifier of an injection point of another bean, and any interceptor or decorator class declared in the |beans.xml| file of any bean deployment archive.</text>
<note>covered in bb*, bc*, bd*</note>
</assertion>
- <assertion id="ca">
- <text>If a bean is deployed in an archive or directory that does not contain a file named |beans.xml| in the metadata directory, it will not be discovered by the container.</text>
- </assertion>
-
<assertion id="d" testable="false">
<text>If a bean class is deployed in two different bean deployment archives, non-portable behaviour results. Portable applications must deploy each bean class in exactly one bean deployment archive.</text>
<note>Describes undefined behavior</note>
@@ -6164,7 +6200,8 @@
</assertion>
<group>
- <text>Next, the container must perform bean discovery, and abort initialization of the application if any definition errors exist, as defined in Section 12.4, "Problems detected automatically by the container".</text>
+ <text>Next, the container must perform bean discovery, and abort initialization of the application if any definition errors exist, as defined in Section 12.4, "Problems detected automatically by the container". Additionally, for every Java EE component class supporting injection that may be instantiated by the container at runtime, the container must create an |InjectionTarget| for the class, as defined in 11.2, "The Producer and InjectionTarget interfaces", and fire an event of type ProcessInjectionTarget, as defined in Section 11.5.6, "ProcessInjectionTarget event".</text>
+
<assertion id="da">
<text>Check beans are discovered</text>
</assertion>
@@ -6201,7 +6238,7 @@
</assertion>
<group>
- <text>For each Java class in any bean deployment archive, the container must create an |AnnotatedType| representing the class and fire an event of type |ProcessAnnotatedType|, as defined in Section 11.5.5, "ProcessAnnotatedType event".</text>
+ <text>For each Java class or interface deployed in a bean deployment archive, the container must create an |AnnotatedType| representing the type and fire an event of type |ProcessAnnotatedType|, as defined in Section 11.5.5, "ProcessAnnotatedType event".</text>
<assertion id="ba">
<text>Check managed bean</text>
</assertion>
@@ -6238,7 +6275,7 @@
</group>
<assertion id="c" testable="false">
- <text>For each Java class in any bean deployment archive, the container must inspect the class metadata to determine if it is a bean or other Java EE component class supporting injection, or if it declares event mappings.</text>
+ <text>For each Java class in any bean deployment archive, the container must inspect the type metadata to determine if it is a bean or other Java EE component class supporting injection.</text>
<note>No consequence</note>
</assertion>
@@ -6285,7 +6322,7 @@
</group>
<group>
- <text>For each Java class in any bean deployment archive, the container must, if the class is a bean, create a |Bean| object that implements the rules defined in Section 7.3.1, "Lifecycle of managed beans", Section 7.3.2, "Lifecycle of stateful session beans" or Section 7.3.3, "Lifecycle of stateless session and singleton beans", and fire an event which is a subtype of |ProcessBean|, as defined in Section 11.5.8, "ProcessBean event".</text>
+ <text>For each Java class in any bean deployment archive, the container must, if the class is an enabled bean, interceptor or decorator, create a |Bean| object that implements the rules defined in Section 7.3.1, "Lifecycle of managed beans", Section 7.3.2, "Lifecycle of stateful session beans" or Section 7.3.3, "Lifecycle of stateless session and singleton beans", and fire an event which is a subtype of |ProcessBean|, as defined in Section 11.5.8, "ProcessBean event".</text>
<assertion id="fa">
<text>Check a managed bean</text>
</assertion>
@@ -6294,12 +6331,8 @@
</assertion>
</group>
- <assertion id="g">
- <text>For each session bean declared in |ejb-jar.xml| in each EJB bean deployment archive the container must create a |Bean| object that implements the rules defined in Section 7.3.2, "Lifecycle of stateful session beans" or Section 7.3.3, "Lifecycle of stateless session and singleton beans", and fire an event of type |ProcessSessionBean|, as defined in Section 11.5.8, "ProcessBean event".</text>
- </assertion>
-
<group>
- <text>For each bean, the container must search the clas for producer methods and fields, including resources, and for each producer method or field create a |Producer|, as defined in Section 11.2, "The Producer and InjectionTarget interfaces", and fire an event of type |ProcessProducer|, as defined in Section 11.5.7, "ProcessProducer event", and then create a |Bean| object that implements the rules defined in Section 7.3.4, "Lifecycle of producer methods", Section 7.3.5, "Lifecycle of producer fields" or Section 7.3.6, "Lifecycle of resources", and fire an event which is a subtype of |ProcessBean|, as defined in Section 11.5.8, "ProcessBean event".</text>
+ <text>For each enabled bean, the container must search the class for producer methods and fields, including resources, and for each producer method or field create a |Producer|, as defined in Section 11.2, "The Producer and InjectionTarget interfaces", and fire an event of type |ProcessProducer|, as defined in Section 11.5.7, "ProcessProducer event", and then if the producer method or field is enabled, create a |Bean| object that implements the rules defined in Section 7.3.4, "Lifecycle of producer methods", Section 7.3.5, "Lifecycle of producer fields" or Section 7.3.6, "Lifecycle of resources", and fire an event which is a subtype of |ProcessBean|, as defined in Section 11.5.8, "ProcessBean event".</text>
<assertion id="ha">
<text>
Check a producer method
@@ -6314,7 +6347,7 @@
<assertion id="i">
- <text>For each bean, the container must search the class for observer methods, and for each observer method create an |ObserverMethod| object, as defined in Section 11.1.3, "The ObserverMethod interface" and fire an event of type |ProcessObserverMethod|, as defined in Section 11.5.9, "ProcessObserverMethod event".</text>
+ <text>For each enabled bean, the container must search the class for observer methods, and for each observer method create an |ObserverMethod| object, as defined in Section 11.1.3, "The ObserverMethod interface" and fire an event of type |ProcessObserverMethod|, as defined in Section 11.5.9, "ProcessObserverMethod event".</text>
</assertion>
<group>
@@ -6346,33 +6379,26 @@
</assertion>
<assertion id="o">
- <text>For each observer method of an enabled bean, the container registers an instance of the |ObserverMethod| interface defined in Section 11.1.3, "The ObserverMethod interface".</text>
+ <text>For each observer method of every enabled bean, the container registers an instance of the |ObserverMethod| interface defined in Section 11.1.3, "The ObserverMethod interface".</text>
</assertion>
</section>
-
- <section id="12.4" title="Problems detected automatically by the container">
+
+ <section id="12.4" title="Integration with Unified EL">
<assertion id="a">
- <text>Definition errors may be detected by tooling at development time, and are also detected by the container at initialization time. If a definition error exists in a deployment, initialization will be aborted by the container.</text>
+ <text>The container must provide a Unified EL |ELResolver| to the servlet engine and JSF implementation that resolves bean EL names using the rules of name resolution defined in 5.3, "EL name resolution" and resolving ambiguities according to Section 5.3.1, "Ambiguous EL names".</text>
</assertion>
-
+
<assertion id="b">
- <text>Deployment problems are detected by the container at initialization time. If a deployment problem exists in a deployment, initialization will be aborted by the container.</text>
+ <text>If a name used in an EL expression resolves to more than one bean, the |ELResolver| must throw an |AmbiguousResolutionException|.</text>
</assertion>
- <assertion id="d" testable="false">
- <text>The container is permitted to define a non-portable mode, for use at development time, in which some definition errors and deployment problems do not cause application initialization to abort.</text>
- <note>Specifies undefined behavior</note>
+ <assertion id="c">
+ <text>If a name used in an EL expression does not resolve to any bean, the |ELResolver| must return a null value.</text>
</assertion>
- <assertion id="e" testable="false">
- <text>Exceptions represent problems that may not be detected until they actually occur at runtime. All exceptions defined by this specification are unchecked exceptions.</text>
- <note>Explanatory note</note>
+ <assertion id="d">
+ <text>Otherwise, if a name used in an EL expression resolves to exactly one bean, the |ELResolver| must return a contextual instance of the bean, as defined in Section 6.5.2, "Contextual instance of a bean".</text>
</assertion>
-
- <assertion id="f" testable="false">
- <text>All exceptions defined by this specification may be safely caught and handled by the application.</text>
- <note>Explanatory note</note>
- </assertion>
</section>
</specification>
16 years, 5 months
- 1
- 0
Weld SVN: r4641 - cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/event/observer.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-03 19:16:57 -0500 (Tue, 03 Nov 2009)
New Revision: 4641
Modified:
cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/event/observer/ObserverTest.java
Log:
WELD-226
Modified: cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/event/observer/ObserverTest.java
===================================================================
--- cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/event/observer/ObserverTest.java 2009-11-03 22:31:19 UTC (rev 4640)
+++ cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/event/observer/ObserverTest.java 2009-11-04 00:16:57 UTC (rev 4641)
@@ -7,7 +7,6 @@
import javax.enterprise.inject.spi.ObserverMethod;
import org.jboss.jsr299.tck.AbstractJSR299Test;
-import org.jboss.jsr299.tck.literals.DefaultLiteral;
import org.jboss.test.audit.annotations.SpecAssertion;
import org.jboss.test.audit.annotations.SpecAssertions;
import org.jboss.test.audit.annotations.SpecVersion;
@@ -75,8 +74,7 @@
Set<ObserverMethod<? super StockPrice>> observers = getCurrentManager().resolveObserverMethods(new StockPrice());
assert observers.size() == 1;
ObserverMethod<?> observerMethod = observers.iterator().next();
- assert observerMethod.getObservedQualifiers().size() == 1;
- assert observerMethod.getObservedQualifiers().contains(new DefaultLiteral());
+ assert observerMethod.getObservedQualifiers().isEmpty();
}
@Test(groups = { "events" })
16 years, 5 months
- 1
- 0
Weld SVN: r4640 - cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-03 17:31:19 -0500 (Tue, 03 Nov 2009)
New Revision: 4640
Modified:
cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java
Log:
minor
Modified: cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java
===================================================================
--- cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java 2009-11-03 22:25:22 UTC (rev 4639)
+++ cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java 2009-11-03 22:31:19 UTC (rev 4640)
@@ -36,7 +36,7 @@
{
@Test(groups = "jboss-as-broken")
@SpecAssertion(section = "5.6.9", id = "ga")
- //WELD-228
+ //WELDINT-26
public void testDefinitionErrorDetected() {
assert false;
}
16 years, 5 months
- 1
- 0
Weld SVN: r4639 - core/trunk/impl/src/main/java/org/jboss/weld and 1 other directory.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-03 17:25:22 -0500 (Tue, 03 Nov 2009)
New Revision: 4639
Modified:
cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java
core/trunk/impl/src/main/java/org/jboss/weld/SimpleInjectionTarget.java
Log:
WELD-228
Modified: cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java
===================================================================
--- cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java 2009-11-03 21:57:11 UTC (rev 4638)
+++ cdi-tck/trunk/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injectionpoint/broken/not/bean/InjectionPointTest.java 2009-11-03 22:25:22 UTC (rev 4639)
@@ -34,7 +34,7 @@
@Resource(destination = WarArtifactDescriptor.WEB_XML_DESTINATION, source = "web.xml")
public class InjectionPointTest extends AbstractJSR299Test
{
- @Test(groups = "ri-broken")
+ @Test(groups = "jboss-as-broken")
@SpecAssertion(section = "5.6.9", id = "ga")
//WELD-228
public void testDefinitionErrorDetected() {
Modified: core/trunk/impl/src/main/java/org/jboss/weld/SimpleInjectionTarget.java
===================================================================
--- core/trunk/impl/src/main/java/org/jboss/weld/SimpleInjectionTarget.java 2009-11-03 21:57:11 UTC (rev 4638)
+++ core/trunk/impl/src/main/java/org/jboss/weld/SimpleInjectionTarget.java 2009-11-03 22:25:22 UTC (rev 4639)
@@ -80,6 +80,13 @@
this.persistenceContextInjectionPoints = Beans.getPersistenceContextInjectionPoints(null, type, beanManager);
this.persistenceUnitInjectionPoints = Beans.getPersistenceUnitInjectionPoints(null, type, beanManager);
this.resourceInjectionPoints = Beans.getResourceInjectionPoints(null, type, beanManager);
+ for (InjectionPoint ip : this.injectionPoints)
+ {
+ if (ip.getType().equals(InjectionPoint.class))
+ {
+ throw new DefinitionException("Cannot inject an InjectionPoint on a non-contextual type. Type: " + type + "; InjectionPoint: " + ip);
+ }
+ }
}
public T produce(CreationalContext<T> ctx)
16 years, 5 months
- 1
- 0
Weld SVN: r4638 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-03 16:57:11 -0500 (Tue, 03 Nov 2009)
New Revision: 4638
Modified:
doc/trunk/reference/en-US/gettingstarted.xml
Log:
more notes about remove method
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-03 21:47:49 UTC (rev 4637)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-03 21:57:11 UTC (rev 4638)
@@ -1844,10 +1844,11 @@
}]]></programlisting>
<para>
- <!-- QUESTION is this still a requirement in EJB 3.1? -->
- Since this is a stateful session bean, we have to have a remove method. The container will call the remove
- method for you when the bean is destroyed; in this case at the end of the request. (Keep in mind that since
- this bean is not dependent-scoped, the application is not allowed to invoke the remove method).
+ Since this is a stateful session bean, you can include an optional <literal>@Remove</literal> method, which the
+ container will call for you when the bean is destroyed; in this case at the end of the request. (Keep in mind
+ that since this bean is not dependent-scoped, the application is forbidden to invoke the remove method). Since
+ CDI is integrated into the container, it does not need this method to operate correctly. If the method's empty,
+ just get rid of it.
</para>
<para>
16 years, 5 months
- 1
- 0