Weld SVN: r4908 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-09 18:17:39 -0500 (Mon, 09 Nov 2009)
New Revision: 4908
Modified:
doc/trunk/reference/en-US/injection.xml
Log:
minor
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-09 23:16:00 UTC (rev 4907)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-09 23:17:39 UTC (rev 4908)
@@ -618,7 +618,7 @@
<title>Lifecycle callbacks and component environment injection</title>
<para>
- Managed beans and EJB beans support the lifecycle callback methods, <literal>@PostConstruct</literal> and
+ Managed beans and EJB beans support the lifecycle callback methods <literal>@PostConstruct</literal> and
<literal>@PreDestroy</literal> which are called after after all dependencies have been injected, and before the
bean is destroyed (when the context to which it belongs ends), respectively. EJB beans also support the EJB
callback methods <literal>@PrePassivate</literal> and <literal>@PostActivate</literal>.
14 years, 8 months
Weld SVN: r4906 - in extensions/trunk: servlet/tests and 1 other directory.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-09 18:16:00 -0500 (Mon, 09 Nov 2009)
New Revision: 4906
Modified:
extensions/trunk/pom.xml
extensions/trunk/servlet/tests/pom.xml
Log:
minor updates
Modified: extensions/trunk/pom.xml
===================================================================
--- extensions/trunk/pom.xml 2009-11-09 23:06:25 UTC (rev 4905)
+++ extensions/trunk/pom.xml 2009-11-09 23:16:00 UTC (rev 4906)
@@ -8,7 +8,7 @@
<parent>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-parent</artifactId>
- <version>2</version>
+ <version>6</version>
</parent>
<name>Weld Extensions Build Aggregator</name>
Modified: extensions/trunk/servlet/tests/pom.xml
===================================================================
--- extensions/trunk/servlet/tests/pom.xml 2009-11-09 23:06:25 UTC (rev 4905)
+++ extensions/trunk/servlet/tests/pom.xml 2009-11-09 23:16:00 UTC (rev 4906)
@@ -197,12 +197,6 @@
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/dependency/lib</outputDirectory>
</artifactItem>
- <artifactItem>
- <groupId>log4j</groupId>
- <artifactId>log4j</artifactId>
- <overWrite>true</overWrite>
- <outputDirectory>${project.build.directory}/dependency/lib</outputDirectory>
- </artifactItem>
</artifactItems>
</configuration>
</execution>
14 years, 8 months
Weld SVN: r4907 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-09 18:16:00 -0500 (Mon, 09 Nov 2009)
New Revision: 4907
Modified:
doc/trunk/reference/en-US/injection.xml
Log:
clean up
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-09 23:16:00 UTC (rev 4906)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-09 23:16:00 UTC (rev 4907)
@@ -4,10 +4,8 @@
<title>Dependency injection and programmatic lookup</title>
<para>
- One of the most significant features of CDI, certainly the most recognized, is dependency injection; but not just
- dependency injection—<emphasis>typesafe</emphasis> dependency injection. In this chapter, you'll learn how
- CDI is able to leverage the Java type system and annotations into a dependency injection strategy that is both
- strongly typed and keeps the bean implementation hidden from its clients.
+ One of the most significant features of CDI—certainly the most recognized—is dependency injection;
+ excuse me, <emphasis>typesafe</emphasis> dependency injection.
</para>
<section>
@@ -283,10 +281,11 @@
Then we select one of the possible member values when appling the qualifier:
</para>
- <programlisting role="JAVA"><![CDATA[private @Inject @PayBy(CHECK) CheckPayment checkPayment;]]></programlisting>
+ <programlisting role="JAVA"><![CDATA[private @Inject @PayBy(CHECK) PaymentProcessor checkPayment;]]></programlisting>
<para>
- We can force the container to ignore a member of a qualifier type by annotating the member <literal>@NonBinding</literal>.
+ We can force the container to ignore a member of a qualifier type by annotating the member
+ <literal>@NonBinding</literal>.
</para>
<programlisting role="JAVA"><![CDATA[@Qualifier
@@ -309,7 +308,7 @@
<programlisting role="JAVA"><![CDATA[@Inject @Synchronous @Reliable PaymentProcessor syncPaymentProcessor;]]></programlisting>
<para>
- Then a bean which has <emphasis>both</emphasis> qualifier annotations would be eligible for
+ Then only a bean which has <emphasis>both</emphasis> qualifier annotations would be eligible for
injection.
</para>
@@ -319,41 +318,7 @@
}]]></programlisting>
</section>
-
- <section>
- <title>Qualifiers on producer methods</title>
-
- <para>
- Even producer methods may specify qualifiers:
- </para>
-
- <programlisting role="JAVA"><![CDATA[@Produces @Asynchronous PaymentProcessor getPaymentProcessor() { ... }]]></programlisting>
-
- <tip>
- <para>
- If we really need to create beans with asynchronous semantics, EJB 3.1 asynchronous methods are an
- excellent solution.
- </para>
- </tip>
-
- </section>
-
- <section>
- <title>The default qualifier</title>
- <para>
- CDI defines the qualifier annotation <literal>@Default</literal> that is the default qualifier type for any
- injection point or bean that does not explicitly specify a qualifier.
- </para>
-
- <para>
- <!-- this is a really vague point -->
- The most common circumstance when it's necessary to explicitly specify <literal>@Default</literal> is on a bean
- which has another qualifier in addition to the default one.
- </para>
-
- </section>
-
</section>
<section>
@@ -363,40 +328,38 @@
The typesafe resolution algorithm fails when, after considering the qualifier annotations on all beans that
implement the bean type of an injection point and filtering out disabled beans (<literal>@Alternative</literal>
beans which are not explicitly enabled), the container is unable to identify exactly one bean to inject. The
- container will either throw an <literal>UnsatisfiedDependencyException</literal> or
- <literal>AmbiguousDependencyException</literal>, depending on the circumstance.
+ container will abort deployment, informing us of the unsatisfied or ambiguous dependency.
</para>
<para>
- 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.
+ During the course of your development, you're going to encounter this situation. Let's learn how to resolve it.
</para>
<para>
- To fix an <literal>UnsatisfiedDependencyException</literal>, either:
+ To fix an <emphasis>unsatisfied dependency</emphasis>, either:
</para>
<itemizedlist>
<listitem>
<para>
- create a bean which implements the bean type and has all the qualifier types of the injection point,
+ create a bean which implements the bean type and has all the qualifier types of the injection point,
</para>
</listitem>
<listitem>
<para>
- make sure that the bean you already have is in the classpath of the module with the injection point, or
+ make sure that the bean you already have is in the classpath of the module with the injection point, or
</para>
</listitem>
<listitem>
<para>
- explicitly enable an <literal>@Alternative</literal> bean that implements the bean type and has the
- appropriate qualifier types, using <literal>beans.xml</literal>.
+ explicitly enable an <literal>@Alternative</literal> bean that implements the bean type and has the
+ appropriate qualifier types, using <literal>beans.xml</literal>.
</para>
</listitem>
</itemizedlist>
<para>
- To fix an <literal>AmbiguousDependencyException</literal>, either:
+ To fix an <emphasis>ambiguous dependency</emphasis>, either:
</para>
<itemizedlist>
@@ -423,11 +386,6 @@
</para>
</listitem>
</itemizedlist>
-
- <para>
- An <literal>AmbiguousDependencyException</literal> can only occur if two enabled beans share the same
- qualifier types.
- </para>
<tip>
<para>Just remember: "There can be only one."</para>
@@ -439,7 +397,7 @@
</para>
<para>
- There's one more issue you need to be aware of when using the dependency injection service: client proxies.
+ Now there's one more issue you need to be aware of when using the dependency injection service.
</para>
</section>
@@ -472,21 +430,11 @@
the current context. The client proxy also allows beans bound to contexts such as the session context to be
serialized to disk without recursively serializing other injected beans.
</para>
-
- <note>
- <para>
- 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 therefore the client proxy approach was adopted in CDI instead.
- </para>
- </note>
<para>
- Unfortunately, due to limitations of the Java language, some Java types cannot be proxied by the container. If
- an inection point declared with one of these types resolves to a bean with any scope other than
- <literal>@Dependent</literal>, the container throws an <literal>UnproxyableDependencyException</literal> at
- system initialization time.
+ Unfortunately, due to limitations of the Java language, some Java types cannot be proxied by the container.
+ If an injection point declared with one of these types resolves to a bean with any scope other than
+ <literal>@Dependent</literal>, the container will abort deployment, informing us of the problem.
</para>
<para>The following Java types cannot be proxied by the container:</para>
@@ -506,9 +454,9 @@
</itemizedlist>
<para>
- It's usually very easy to fix an <literal>UnproxyableDependencyException</literal>. Simply add a constructor
- with no parameters to the injected class, introduce an interface, or, if all else fails, change the scope of
- the injected bean to <literal>@Dependent</literal>.
+ It's usually very easy to fix an unproxyable dependency problem. Simply add a constructor with no parameters to
+ the injected class, introduce an interface, or, if all else fails, change the scope of the injected bean to
+ <literal>@Dependent</literal>.
</para>
<note>
@@ -565,43 +513,42 @@
</itemizedlist>
<para>
- In these situations, the application may obtain an instance of the interface <literal>Instance</literal>
- parameterized for the bean type by injection:
+ In these situations, the application may obtain an instance of the interface <literal>Instance</literal>,
+ parameterized for the bean type, by injection:
</para>
<programlisting role="JAVA"><![CDATA[@Inject Instance<PaymentProcessor> paymentProcessorSource;]]></programlisting>
<para>
- The <literal>get()</literal> method on <literal>Instance</literal> can be used to produce a contextual instance
- of the bean programmatically.
+ The <literal>get()</literal> method of <literal>Instance</literal> produces a contextual instance of the bean.
</para>
<programlisting role="JAVA"><![CDATA[PaymentProcessor p = paymentProcessorSource.get();]]></programlisting>
<para>
- Of course, qualifiers can be specified at the injection point, as with a bean injection:
+ Of course, qualifiers can be specified at the injection point:
</para>
<programlisting role="JAVA"><![CDATA[@Inject @Asynchronous Instance<PaymentProcessor> paymentProcessorSource;]]></programlisting>
<para>
- You can also select a bean dynamically from the <literal>Instance</literal> by passing the bean's qualifier.
- First, you need to add the <literal>@Any</literal> annotation at the injection point:
+ Alternatively, we can specify the qualifier dynamically. First, we add the <literal>@Any</literal> qualifier to
+ the injection point:
</para>
<programlisting role="JAVA"><![CDATA[@Inject @Any Instance<PaymentProcessor> paymentProcessorSource;]]></programlisting>
<para>
- Then you specify which bean you want, by passing its qualifier to the <literal>select()</literal> method of
- <literal>Instance</literal>. You represent a qualifier annotation in code by subclassing the helper class
- <literal>AnnotationLiteral</literal>, since it's otherwise difficult to instantiate an annotation type in Java.
+ Now we can pass the qualifier to the <literal>select()</literal> method of <literal>Instance</literal>. We can
+ obtain a qualifier instance by subclassing the helper class <literal>AnnotationLiteral</literal>, since it's
+ otherwise difficult to instantiate an annotation type in Java.
</para>
<programlisting role="JAVA"><![CDATA[PaymentProcessor p = paymentProcessorSource
.select(new AnnotationLiteral<Asynchronous>() {});]]></programlisting>
<para>
- You can choose to create a concrete type for all of your annotation literals, such as:
+ We can choose to create a concrete type for the annotation literal:
</para>
<programlisting role="JAVA"><![CDATA[abstract class AsynchronousQualifier
@@ -609,26 +556,24 @@
<note>
<para>
- The concrete type is required if your qualifier has members, since an anonymous subclass cannot define members.
+ The concrete type is required if the qualifier has members.
</para>
</note>
-
+
<para>
- Again, like with annotation definitions, the <literal>AnnotationLiteral</literal> definition may seem a bit
- foreign at first, but it will soon become second nature as you will see it often in CDI applications.
- </para>
-
- <para>
Here's how you might make use of dynamic selection:
</para>
<programlisting><![CDATA[Annotation qualifier = synchronously ?
-new SynchronousQualifier() : new AsynchronousQualifier();
+ new SynchronousQualifier() : new AsynchronousQualifier();
PaymentProcessor p = anyPaymentProcessor.select(qualifier).get().process(payment);]]></programlisting>
</section>
- <section>
+ <!--section>
+
+ What the hell is the purpose of this section?! I didn't learn anything useful from it.
+
<title>Bean names and EL lookup</title>
<para>
@@ -667,35 +612,25 @@
business tier isn't tied to JSF in any way.
</para>
- </section>
+ </section-->
<section>
- <title>Lifecycle callbacks and resource injections</title>
+ <title>Lifecycle callbacks and component environment injection</title>
<para>
- As part of the managed bean contract, all CDI beans support the lifecycle callback methods,
- <literal>@PostConstruct</literal> and <literal>@PreDestroy</literal> which are called after the bean is
- initialized (and after injections take place) and before it is destroyed (when the context to which it is bound
- ends), respectively.
+ Managed beans and EJB beans support the lifecycle callback methods, <literal>@PostConstruct</literal> and
+ <literal>@PreDestroy</literal> which are called after after all dependencies have been injected, and before the
+ bean is destroyed (when the context to which it belongs ends), respectively. EJB beans also support the EJB
+ callback methods <literal>@PrePassivate</literal> and <literal>@PostActivate</literal>.
</para>
<para>
- Of course, session beans also support callback methods introduced by the EJB specification, such as
- <literal>@PrePassivate</literal> and <literal>@PostActivate</literal>.
+ Managed beans and EJB beans also support Java EE 5-style component environment injection, where the injection
+ point is declared using <literal>@Resource</literal>, <literal>@PersistenceContext</literal>,
+ <literal>@PersistenceUnit</literal>, <literal>@WebServiceRef</literal> or <literal>@EJB</literal>. However, in
+ a CDI environment, these annotations are most useful for declaring resources that can be injected by CDI.
</para>
- <para>
- Managed beans also support Java EE 5-style resource injections, declared using the <literal>@Resource</literal>
- annotation on a field. CDI beans can also inject session beans with the <literal>@EJB</literal> annotation.
- </para>
-
- <para>
- However, as you learned in a previous section, these injections are not fully type-safe, nor do they have the
- semantics that CDI provides. Therefore, it's the use of <literal>@Inject</literal> for injection is preferred.
- Relegate the resource injections to a bean that uses producer fields to mold these container-managed objects
- into injectable beans.
- </para>
-
</section>
<!--
14 years, 8 months
Weld SVN: r4905 - in examples/trunk/jsf: permalink and 1 other directory.
by weld-commits＠lists.jboss.org
Author: pete.muir(a)jboss.org
Date: 2009-11-09 18:06:25 -0500 (Mon, 09 Nov 2009)
New Revision: 4905
Modified:
examples/trunk/jsf/numberguess/readme.txt
examples/trunk/jsf/permalink/readme.txt
Log:
remove embedded stuff, it's flaky
Modified: examples/trunk/jsf/numberguess/readme.txt
===================================================================
--- examples/trunk/jsf/numberguess/readme.txt 2009-11-09 22:57:11 UTC (rev 4904)
+++ examples/trunk/jsf/numberguess/readme.txt 2009-11-09 23:06:25 UTC (rev 4905)
@@ -38,34 +38,6 @@
http://localhost:8080/weld-numberguess
-== Deploying with an embedded servlet container
-
-Run this command to execute the application in an embedded Jetty 6 container:
-
- mvn war:inplace jetty:run -Pjetty
-
-You can also execute the application in an embedded Tomcat 6 container:
-
- mvn war:inplace tomcat:run -Ptomcat
-
-In both cases, you can access the application at the following local URL
-
- http://localhost:9090/weld-numberguess
-
-In both cases, any changes to assets in src/main/webapp take effect immediately.
-If a change to a webapp configuration file is made, the application may
-automatically redeploy. The redeploy behavior can be fine-tuned in the plugin
-configuration (at least for Jetty). If you make a change to a classpath
-resource, you need to execute a build:
-
- mvn compile war:inplace {-Ptomcat,-Pjetty}
-
-Note that war:inplace copies the compiled classes and JARs inside
-src/main/webapp, under WEB-INF/classes and WEB-INF/lib, respectively, mixing
-source and compiled files. However, the build does work around these temporary
-files by excluding them from the packaged WAR and cleaning them during the
-Maven clean phase. These folders are also ignored by SVN.
-
== Deploying to standalone Tomcat
If you want to run the application on a standalone Tomcat 6, first download and
@@ -118,6 +90,8 @@
== Using Google App Engine
+KNOWN NOT WORKING IN THIS RELEASE
+
First, set up the Eclipse environment:
mvn clean eclipse:clean eclipse:eclipse -Pgae
Modified: examples/trunk/jsf/permalink/readme.txt
===================================================================
--- examples/trunk/jsf/permalink/readme.txt 2009-11-09 22:57:11 UTC (rev 4904)
+++ examples/trunk/jsf/permalink/readme.txt 2009-11-09 23:06:25 UTC (rev 4905)
@@ -29,44 +29,6 @@
Alternatively, run ant restart to have the app copied to you ${jboss.home}
-But you may want to take advantage of the embedded servlet containers.
-
-== Deploying with an embedded servlet container
-
-Run this command to execute the application in an embedded Jetty 6 container:
-
- mvn jetty:run -Pjetty
-
-You can also execute the application in an embedded Tomcat 6 container:
-
- mvn war:inplace tomcat:run -Ptomcat
-
-**Note that war:inplace overwrites src/main/webapp/WEB-INF/web.xml, effectively
-adding the Weld listener. You need to manually remove the listener before
-deploying to another container.
-
-You can access the application for either container at the following local URL:
-
- http://localhost:9090/weld-permalink
-
-In both cases, any changes to assets in src/main/webapp take effect immediately.
-If a change to a webapp configuration file is made, the application may
-automatically redeploy. The redeploy behavior can be fine-tuned in the plugin
-configuration (at least for Jetty). If you make a change to a classpath
-resource, you need to execute a build. For Jetty:
-
- mvn compile
-
-and for Tomcat:
-
- mvn compile war:inplace -Ptomcat
-
-Note that war:inplace copies the compiled classes and JARs inside
-src/main/webapp, under WEB-INF/classes and WEB-INF/lib, respectively, mixing
-source and compiled files. However, the build does work around these temporary
-files by excluding them from the packaged WAR and cleaning them during the Maven
-clean phase. These folders are also ignored by SVN.
-
== Deploying to standalone Tomcat
If you want to run the application on a standalone Tomcat 6, first download and
14 years, 8 months
Weld SVN: r4904 - examples/trunk/jsf/permalink.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-09 17:57:11 -0500 (Mon, 09 Nov 2009)
New Revision: 4904
Modified:
examples/trunk/jsf/permalink/readme.txt
Log:
add note about problem with war:inplace
Modified: examples/trunk/jsf/permalink/readme.txt
===================================================================
--- examples/trunk/jsf/permalink/readme.txt 2009-11-09 22:54:48 UTC (rev 4903)
+++ examples/trunk/jsf/permalink/readme.txt 2009-11-09 22:57:11 UTC (rev 4904)
@@ -41,6 +41,10 @@
mvn war:inplace tomcat:run -Ptomcat
+**Note that war:inplace overwrites src/main/webapp/WEB-INF/web.xml, effectively
+adding the Weld listener. You need to manually remove the listener before
+deploying to another container.
+
You can access the application for either container at the following local URL:
http://localhost:9090/weld-permalink
14 years, 8 months
Weld SVN: r4903 - examples/trunk/jsf/permalink.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-09 17:54:48 -0500 (Mon, 09 Nov 2009)
New Revision: 4903
Modified:
examples/trunk/jsf/permalink/pom.xml
Log:
nuke META-INF on clean
Modified: examples/trunk/jsf/permalink/pom.xml
===================================================================
--- examples/trunk/jsf/permalink/pom.xml 2009-11-09 22:53:24 UTC (rev 4902)
+++ examples/trunk/jsf/permalink/pom.xml 2009-11-09 22:54:48 UTC (rev 4903)
@@ -102,6 +102,7 @@
<!-- clean up files from war:inplace -->
<directory>${webapp.directory}</directory>
<includes>
+ <include>META-INF/**</include>
<include>WEB-INF/classes/**</include>
<include>WEB-INF/lib/**</include>
</includes>
14 years, 8 months
Weld SVN: r4902 - examples/trunk/jsf/permalink/src/main/webapp.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-09 17:53:24 -0500 (Mon, 09 Nov 2009)
New Revision: 4902
Modified:
examples/trunk/jsf/permalink/src/main/webapp/
Log:
ignore META-INF
Property changes on: examples/trunk/jsf/permalink/src/main/webapp
___________________________________________________________________
Name: svn:ignore
+ META-INF
14 years, 8 months
Weld SVN: r4901 - examples/trunk/jsf/permalink/src/main/java/org/jboss/weld/examples/permalink.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-09 17:41:27 -0500 (Mon, 09 Nov 2009)
New Revision: 4901
Modified:
examples/trunk/jsf/permalink/src/main/java/org/jboss/weld/examples/permalink/Blog.java
Log:
annotation placement
Modified: examples/trunk/jsf/permalink/src/main/java/org/jboss/weld/examples/permalink/Blog.java
===================================================================
--- examples/trunk/jsf/permalink/src/main/java/org/jboss/weld/examples/permalink/Blog.java 2009-11-09 22:31:19 UTC (rev 4900)
+++ examples/trunk/jsf/permalink/src/main/java/org/jboss/weld/examples/permalink/Blog.java 2009-11-09 22:41:27 UTC (rev 4901)
@@ -32,9 +32,8 @@
/**
* @author Dan Allen
*/
-@Model
public
-
+@Model
class Blog
{
private static final int PAGE_SIZE = 3;
14 years, 8 months
Weld SVN: r4900 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: gavin.king(a)jboss.com
Date: 2009-11-09 17:31:19 -0500 (Mon, 09 Nov 2009)
New Revision: 4900
Modified:
doc/trunk/reference/en-US/intro.xml
Log:
various improvements
Modified: doc/trunk/reference/en-US/intro.xml
===================================================================
--- doc/trunk/reference/en-US/intro.xml 2009-11-09 22:30:16 UTC (rev 4899)
+++ doc/trunk/reference/en-US/intro.xml 2009-11-09 22:31:19 UTC (rev 4900)
@@ -137,7 +137,7 @@
<programlistingco>
<areaspec>
- <area id="injection" coords="3"/>
+ <area id="textTranslator" coords="3"/>
</areaspec>
<programlisting role="JAVA"><![CDATA[@Named @RequestScoped
public class TranslateController {
@@ -164,7 +164,7 @@
}
}]]></programlisting>
<calloutlist>
- <callout arearefs="injection">
+ <callout arearefs="textTranslator">
<para>
Field injection of <literal>TextTranslator</literal> instance
</para>
@@ -307,7 +307,7 @@
</blockquote>
- <para>Let's see what some of these new terms mean.</para>
+ <para>Let's see what all this new terminology means.</para>
<section>
<title>Bean types, qualifiers and dependency injection</title>
@@ -323,7 +323,7 @@
</itemizedlist>
<para>
- A bean type is a user-defined class or interface; types that are client-visible. If the bean is an EJB
+ A bean type is a user-defined class or interface; a type that is client-visible. If the bean is an EJB
session bean, the bean type is the <literal>@Local</literal> interface or bean-class local view. A bean may
have multiple bean types. For example, the following bean has four bean types:
</para>
@@ -362,9 +362,8 @@
<para>
Bean types may be restricted to an explicit set by annotating the bean with the <literal>@Typed</literal>
- annotation and listing the bean types in the value of the annotation. For instance, this bean has been
- restricted to the bean type explicitly listed, <literal>Shop<Book></literal>, together with
- <literal>java.lang.Object</literal>:
+ annotation and listing the classes that should be bean types. For instance, the bean types of this bean have
+ been restricted to <literal>Shop<Book></literal>, together with <literal>java.lang.Object</literal>:
</para>
<programlisting role="JAVA"><![CDATA[(a)Typed(Shop.class)
@@ -375,19 +374,18 @@
}]]></programlisting>
<para>
- The bean types alone often do not provide enough information for the container to know which bean to inject.
+ Sometimes, a bean type alone does 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 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.
+ <literal>CreditCardPaymentProcessor</literal> and <literal>DebitPaymentProcessor</literal>. Injecting a field of
+ type <literal>PaymentProcessor</literal> introduces an ambiguous condition. In these cases, the client must
+ specify some additional quality of the implementation it is interested in. We model this kind of "quality" using
+ a qualifier.
</para>
<para>
- Qualifiers are represented by user-defined annotations that are themselves annotated with
- <literal>@Qualifer</literal>. These annotations extend the type system in Java to let you further qualify
- the type without having to fall back to string-based names as in many other dependency injection solutions.
- Here's an example of a qualifier annotation:
+ A qualifier is a user-defined annotation that is itself annotated <literal>@Qualifer</literal>. A qualifier
+ annotation is an extension of the type system. It lets us disambiguate a type without having to fall back to
+ string-based names. Here's an example of a qualifier annotation:
</para>
<programlisting role="JAVA"><![CDATA[@Qualifier
@@ -396,9 +394,9 @@
public @interface CreditCard {}]]></programlisting>
<para>
- You may not be used to seeing the definition of an annotation. In fact, this might be the first time you
- have encountered one. With CDI, they will become very familiar artifact as you will be creating them from
- time to time.
+ You may not be used to seeing the definition of an annotation. In fact, this might be the first time you've
+ encountered one. With CDI, annotation definitions will become a familiar artifact as you'll be creating them
+ from time to time.
</para>
<tip>
@@ -410,8 +408,9 @@
</tip>
<para>
- Now that we have defined a qualifier annotation, we can use it. The following injection point has the bean
- type <literal>PaymentProcessor</literal> and qualifier <literal>@CreditCard</literal>:
+ Now that we have defined a qualifier annotation, we can use it to disambiguate an injection point. The
+ following injection point has the bean type <literal>PaymentProcessor</literal> and qualifier
+ <literal>@CreditCard</literal>:
</para>
<programlisting role="JAVA"><![CDATA[@Inject @CreditCard PaymentProcessor paymentProcessor]]></programlisting>
@@ -425,15 +424,14 @@
<para>
For each injection point, the container searches for a bean which satisfies the contract, one which has
- the bean type and all the qualifiers. If it find exactly one matching bean, it injects an instance of
- that bean.
+ the bean type and all the qualifiers. If it finds exactly one matching bean, it injects an instance of
+ that bean. If it doesn't, it reports an error to the user.
</para>
<para>
- We've seen how to indicate that you want to inject a qualified bean. But how do you actually qualify the bean?
- By using the annotation, of course! The following bean has the qualifier <literal>@CreditCard</literal>
- and implements the bean type <literal>PaymentProcessor</literal>. Therefore, it satisfies our qualified
- injection point:
+ How do we specify that qualifiers of a bean? By annotating the bean class, of course! The following bean
+ has the qualifier <literal>@CreditCard</literal> and implements the bean type <literal>PaymentProcessor</literal>.
+ Therefore, it satisfies our qualified injection point:
</para>
<programlisting role="JAVA"><![CDATA[@CreditCard
@@ -455,9 +453,9 @@
-->
<para>
- CDI defines a simple <emphasis>resolution rule</emphasis> that helps the container decide what to do if there
- is more than one bean that satisfies a particular contract. We'll get into the details in
- <xref linkend="alternatives"/>.
+ That's not quite the end of the story. CDI also defines a simple <emphasis>resolution rule</emphasis> that helps
+ the container decide what to do if there is more than one bean that satisfies a particular contract. We'll get
+ into the details in <xref linkend="alternatives"/>.
</para>
<!--
@@ -544,8 +542,7 @@
</note>
<para>
- If you want, you can let CDI select a name for you by leaving off the
- value of the <literal>@Named</literal> annotation:
+ We can let CDI choose a name for us by leaving off the value of the <literal>@Named</literal> annotation:
</para>
<programlisting role="JAVA"><![CDATA[public @SessionScoped @Named
@@ -612,10 +609,14 @@
<para>
CDI provides a new approach to binding interceptors to beans that introduces a level of indirection (and
- thus control). We define a special kind of annotation called an <emphasis>interceptor binding
- type</emphasis> whose name describes the behavior implemented by the interceptor, in this case to perform
- transaction management:
+ thus control). We must define an <emphasis>interceptor binding type</emphasis> to describe the behavior
+ implemented by the interceptor.
</para>
+
+ <para>
+ An interceptor binding type is a user-defined annotation that is itself annotated <literal>@InterceptorBinding</literal>.
+ It lets us bind interceptor classes to bean classes with no direct dependency between the two classes.
+ </para>
<programlisting role="JAVA"><![CDATA[@InterceptorBinding
@Inherited
@@ -631,20 +632,23 @@
class TransactionInterceptor { ... }]]></programlisting>
<para>
- We can apply the interceptor to a bean by annotating to the bean class with the same interceptor
- binding type:
+ We can apply the interceptor to a bean by annotating the bean class with the same interceptor binding type:
</para>
<programlisting role="JAVA"><![CDATA[public @SessionScoped @Transactional
class ShoppingCart implements Serializable { ... }]]></programlisting>
<para>
- Now there's no direct dependency between the two implementations (bean and interceptor). Activation of
- interceptors is controlled by the CDI deployment descriptor <literal>META-INF/beans.xml</literal>
- of the jar or Java EE module, allowing us to control which interceptors apply in which deployment
- scenarios, along with the order of interceptor invocation when multiple interceptors apply to a
- bean.
+ Notice that <literal>ShoppingCart</literal> and <literal>TransactionInterceptor</literal> don't know
+ anything about each other.
</para>
+
+ <para>
+ Interceptors are deployment-specific. (We don't need a <literal>TransactionInterceptor</literal> in our
+ unit tests!) By default, an interceptor is disabled. We can enable an interceptor using the CDI deployment
+ descriptor <literal>META-INF/beans.xml</literal> of the jar or Java EE module. This is also where we
+ specify the interceptor ordering.
+ </para>
<para>
We'll discuss interceptors, and their cousins, decorators, in <xref linkend="interceptors"/> and <xref
@@ -659,8 +663,9 @@
<title>What kinds of classes are beans?</title>
<para>
- We've already seen that JavaBeans and EJB session beans can be (CDI) beans. Is that the whole story?
- Actually, it's just the beginning.
+ We've already seen two types of beans: JavaBeans and EJB session beans. Is that the whole story? Actually,
+ it's just the beginning. Let's explore the various kinds of beans that CDI implementations must support
+ out-of-the-box.
</para>
<section>
@@ -727,10 +732,9 @@
<para>
Session beans belong to the EJB specification. They have a special lifecycle, state management and concurrency
model that is different to other managed beans and non-managed Java objects. But session beans participate in
- CDI just like any other bean. There are some restrictions upon the scope that can be assigned to a session bean,
- but apart from than that, they may be used interchangeably with regular managed beans. That means you can inject
- one session bean into another session bean, 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.
+ CDI just like any other bean. You can inject one session bean into another session bean, 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>
<note>
@@ -746,7 +750,7 @@
The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their
superinterfaces. If the session bean has a bean class local view, the unrestricted set of bean types
contains the bean class and all superclasses. In addition, <literal>java.lang.Object</literal> is a bean
- type of every session bean. But, remote interfaces are <emphasis>not</emphasis> included in the set of bean
+ type of every session bean. But remote interfaces are <emphasis>not</emphasis> included in the set of bean
types.
</para>
@@ -796,8 +800,7 @@
<para>
Beans which hold references to heavy-weight resources, or hold a lot of internal state benefit from the
- advanced container-managed lifecycle defined by the EJB
- <literal>@Stateless</literal>/<literal>@Stateful</literal>/<literal>@Singleton</literal> model, with its
+ advanced container-managed lifecycle defined by the EJB stateless/stateful/singleton model, with its
support for passivation and instance pooling.
</para>
@@ -830,14 +833,15 @@
<para>
Not everything that needs to be injected can be boiled down to a bean class instantiated by the container
using <literal>new</literal>. There are plenty of cases where we need additional control. What if we need
- to decide at runtime which implementation of a type to instantiate and inject? What if we need to inject an
- object that is obtained by querying a service or transactional resource, for example by executing a JPA query?
+ to decide at runtime which implementation of a type to instantiate and inject? What if we need to inject
+ an object that is obtained by querying a service or transactional resource, for example by executing a JPA
+ query?
</para>
<para>
- A <emphasis>producer method</emphasis> is a method that acts as a source of bean instances, meaning the
- method declaration itself describes the bean and the container invokes the method to obtain an instance of
- the bean when no instance exists in the specified context. A producer method lets the application take full
+ A <emphasis>producer method</emphasis> is a method that acts as a source of bean instances. The method
+ declaration itself describes the bean and the container invokes the method to obtain an instance of the
+ bean when no instance exists in the specified context. A producer method lets the application take full
control of the bean instantiation process.
</para>
@@ -957,10 +961,10 @@
<para>
Naturally, there is now a slight mismatch with the new style of dependency injection in CDI. Most notably,
component environment injection relies on string-based names to qualify ambiguous types, and there is no
- real consistency as to the nature of the names (sometimes a JNDI name, other times an identifier from an
- XML descriptor, or even a default name). Producer fields turned out to be an elegant adaptor to reduce all
- this complexity to a common model and get component environment resources to participate in the CDI system
- just like any other kind of bean.
+ real consistency as to the nature of the names (sometimes a JNDI name, sometimes a persistence unit name,
+ sometimes an EJB link, sometimes a nonportable "mapped name"). Producer fields turned out to be an elegant
+ adaptor to reduce all this complexity to a common model and get component environment resources to
+ participate in the CDI system just like any other kind of bean.
</para>
<para>
14 years, 8 months
Weld SVN: r4899 - doc/trunk/reference/en-US.
by weld-commits＠lists.jboss.org
Author: dan.j.allen
Date: 2009-11-09 17:30:16 -0500 (Mon, 09 Nov 2009)
New Revision: 4899
Modified:
doc/trunk/reference/en-US/gettingstarted.xml
Log:
update wicket example to use jetty port 9090
Modified: doc/trunk/reference/en-US/gettingstarted.xml
===================================================================
--- doc/trunk/reference/en-US/gettingstarted.xml 2009-11-09 22:26:17 UTC (rev 4898)
+++ doc/trunk/reference/en-US/gettingstarted.xml 2009-11-09 22:30:16 UTC (rev 4899)
@@ -1034,6 +1034,13 @@
that allow the project to compile. You're now ready to develop!
</para>
+ <note>
+ <para>
+ You are also advised to uncheck the box "Skip Maven compiler when processing resources" in the Maven
+ properties screen because of conflicts with the Maven enforcer plugin.
+ </para>
+ </note>
+
<para>
If you are not using the m2eclipse plugin, you have to follow different steps to import the project.
First, switch into the Wicket numberguess example, then execute the Maven Eclipse plugin with the jetty
@@ -1069,7 +1076,7 @@
in the <literal>Start</literal> class. So running the example is as simple as right-clicking on that
Start class in <literal>src/test/java</literal> in the <emphasis>Package Explorer</emphasis> and choosing
<emphasis>Run as Java Application</emphasis>. You should see console output related to Jetty starting up;
- then visit able <literal>http://localhost:8080</literal> to view the app. To debug choose <emphasis>Debug
+ then visit able <literal>http://localhost:9090</literal> to view the app. To debug choose <emphasis>Debug
as Java Application</emphasis> instead.
</para>
</section>
@@ -1091,7 +1098,7 @@
<para>
to deploy the example to Tomcat. You can then access application at
- <literal>http://localhost:8080/weld-numberguess-wicket</literal>.
+ <literal>http://localhost:9090/weld-numberguess-wicket</literal>.
</para>
<para>
14 years, 8 months