Author: gavin.king(a)jboss.com
Date: 2009-11-13 08:40:09 -0500 (Fri, 13 Nov 2009)
New Revision: 5021
Modified:
doc/trunk/reference/en-US/injection.xml
Log:
improve
Modified: doc/trunk/reference/en-US/injection.xml
===================================================================
--- doc/trunk/reference/en-US/injection.xml 2009-11-13 11:51:55 UTC (rev 5020)
+++ doc/trunk/reference/en-US/injection.xml 2009-11-13 13:40:09 UTC (rev 5021)
@@ -498,11 +498,34 @@
</itemizedlist>
<para>
- 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>.
+ It's usually very easy to fix an unproxyable dependency problem. If an
injection point of type
+ <literal>X</literal> results in an unproxyable dependency, simply:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ add a constructor with no parameters to <literal>X</literal>,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ change the type of the injection point to
<literal>Instance<X></literal>,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ introduce an interface <literal>Y</literal>, implemented by
the injected bean, and change
+ the type of the injection point to <literal>Y</literal>, or
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if all else fails, change the scope of the injected bean to
<literal>@Dependent</literal>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
<note>
<para>
A future release of Weld will likely support a non-standard workaround for this
limitation, using
Show replies by date