Author: buildbot
Date: Sun Feb 18 20:20:09 2018
New Revision: 1025568
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/autoloading-modules.html
websites/production/tapestry/content/bean-validation.html
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/chainbuilder-service.html
websites/production/tapestry/content/defining-tapestry-ioc-services.html
websites/production/tapestry/content/hibernate-core-conf.html
websites/production/tapestry/content/hibernate-core.html
websites/production/tapestry/content/hibernate.html
websites/production/tapestry/content/injection-in-detail.html
websites/production/tapestry/content/integrating-with-spring-framework.html
websites/production/tapestry/content/object-providers.html
websites/production/tapestry/content/operation-tracker.html
websites/production/tapestry/content/ordering-by-constraints.html
websites/production/tapestry/content/pipelinebuilder-service.html
websites/production/tapestry/content/service-advisors.html
websites/production/tapestry/content/service-implementation-reloading.html
websites/production/tapestry/content/starting-the-ioc-registry.html
websites/production/tapestry/content/supported-environments-and-versions.html
websites/production/tapestry/content/symbols.html
websites/production/tapestry/content/tapestry-ioc-configuration.html
websites/production/tapestry/content/tapestry-ioc-decorators.html
websites/production/tapestry/content/type-coercion.html
Modified: websites/production/tapestry/content/autoloading-modules.html
==============================================================================
--- websites/production/tapestry/content/autoloading-modules.html (original)
+++ websites/production/tapestry/content/autoloading-modules.html Sun Feb 18
20:20:09 2018
@@ -77,10 +77,10 @@
</div>
<div id="content">
- <div id="ConfluenceContent"><p><strong>Autoloading of
modules</strong> allows new features to be added to an application just by
"dropping in" a JAR that contains a module: the services in the module are
automatically integrated into the overall service registry, along with any
configuration or other supporting code and resources.</p><p>An example of this
is the <a href="autoloading-modules.html">tapestry-upload</a> library, which
introduces an Upload component, along with supporting services related to
handling file upload requests.</p><p>The core Tapestry IoC module is
automatically included. When using the Tapestry web framework, the core
Tapestry module is also included, as is an optional per-application module,
plus any autoloaded modules.</p><p>Module autoloading isn't 100% free ... you
must tell Tapestry IoC where the modules to load are located, which can be done
via a Manifest file entry, or via an annotation.</p><h1
id="AutoloadingModules-JARManifestEntrie
s">JAR Manifest Entries</h1><p>When setting up the registry, Tapestry can
automatically locate modules packaged into JARs. It does this by searching for
a particular global manifest entry.</p><p>The manifest entry name is
"Tapestry-Module-Classes". The value is a comma-separated list of fully
qualified class names of module classes (this allows a single JAR to contain
multiple, related modules). Whitespace is ignored.</p><p>Example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+ <div id="ConfluenceContent"><p><strong>Autoloading of
modules</strong> allows new features to be added to an application just by
"dropping in" a JAR that contains a module: the services in the module are
automatically integrated into the overall service registry, along with any
configuration or other supporting code and resources.</p><p>An example of this
is the <a href="uploading-files.html">tapestry-upload</a> library, which
introduces an Upload component, along with supporting services related to
handling file upload requests.</p><p>The core Tapestry IoC module is
automatically included. When using the Tapestry web framework, the core
Tapestry module is also included, as is an optional per-application module,
plus any autoloaded modules.</p><p>Module autoloading isn't 100% free ... you
must tell Tapestry IoC where the modules to load are located, which can be done
via a Manifest file entry, or via an annotation.</p><h1
id="AutoloadingModules-JARManifestEntries">J
AR Manifest Entries</h1><p>When setting up the registry, Tapestry can
automatically locate modules packaged into JARs. It does this by searching for
a particular global manifest entry.</p><p>The manifest entry name is
"Tapestry-Module-Classes". The value is a comma-separated list of fully
qualified class names of module classes (this allows a single JAR to contain
multiple, related modules). Whitespace is ignored.</p><p>Example:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
<pre class="brush: text; gutter: false; theme: Default"
style="font-size:12px;">Manifest-Version: 1.0
Tapestry-Module-Classes: org.example.mylib.LibModule,
org.example.mylib.internal.InternalModule</pre>
-</div></div><p>If you are using Maven 2, then getting these entries into your
JAR's manifest is as simple as some configuration in your pom.xml:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><p>If you are using Maven 2, then getting these entries into your
JAR's manifest is as simple as some configuration in your pom.xml:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeHeader
panelHeader pdl" style="border-bottom-width: 1px;"><b>pom.xml
(partial)</b></div><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><project>
. . .
<build>
@@ -101,7 +101,7 @@ Tapestry-Module-Classes: org.example.myl
</build>
. . .
</project></pre>
-</div></div><p>More details are provided in the <a class="external-link"
href="http://maven.apache.org/guides/mini/guide-manifest.html";>Maven Manifest
Guide</a>.</p><h1 id="AutoloadingModules-SubModuleAnnotation">SubModule
Annotation</h1><p>Often, you will have several different modules working
together that should all be loaded as a unit.</p><p>One approach is to update
the module ids into the manifest, as shown in the previous
extension.</p><p>This can become tedious, and somewhat brittle in the face of
refactorings (such as renaming of classes or packages).</p><p>A better
alternative is the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/SubModule.html";>SubModule
annotation</a> annotation.</p><p>The value for this annotation is a list of
<em>additional</em> classes to be treated as module classes, exactly as if they
were identified in the manifest. Despite the name, there is no hierarchy of
modules in Tapestry IoC.
</p><p>Example:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>More details are provided in the <a class="external-link"
href="http://maven.apache.org/guides/mini/guide-manifest.html";>Maven Manifest
Guide</a>.</p><h1 id="AutoloadingModules-SubModuleAnnotation">SubModule
Annotation</h1><p>Often, you will have several different modules working
together that should all be loaded as a unit.</p><p>One approach is to update
the module ids into the manifest, as shown in the previous
extension.</p><p>This can become tedious, and somewhat brittle in the face of
refactorings (such as renaming of classes or packages).</p><p>A better
alternative is the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/SubModule.html";>SubModule</a>
annotation.</p><p>The value for this annotation is a list of
<em>additional</em> classes to be treated as module classes, exactly as if they
were identified in the manifest. Despite the name, there is no hierarchy of
modules in Tapestry IoC.</p><p>Exam
ple:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@SubModule(
{ InternalTransformModule.class })
public final class InternalModule
Modified: websites/production/tapestry/content/bean-validation.html
==============================================================================
--- websites/production/tapestry/content/bean-validation.html (original)
+++ websites/production/tapestry/content/bean-validation.html Sun Feb 18
20:20:09 2018
@@ -117,7 +117,7 @@ Added in 5.2
</div>
-<p>Tapestry has always provided a powerful non-JSR 303 validation mechanism
(see <a href="bean-validation.html">Bean Validation</a>). Among other things
this mechanism allows you to annotate your domain model classes with the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/beaneditor/Validate.html";>@Validate</a>
annotation. However, this annotation is problematic if your domain model is
used in non-Tapestry applications as well as in Tapestry applications. Your
non-Tapestry application becomes dependent on <em>tapestry5-annotations</em>
module. To make your domain model independent from Tapestry you can use the <a
class="external-link" href="http://jcp.org/en/jsr/detail?id=303";
rel="nofollow">JSR 303: Bean Validation</a> instead. This library provides
integration between Tapestry and JSR-303.</p><h2
id="BeanValidation-Configuration">Configuration</h2><p>The Tapestry's JSR 303 -
Bean Validation Library is responsible for configuring a
nd bootstrapping the <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a> for you. In order to use this library you have to
choose an implementation of the JSR-303 specification like <a
class="external-link" href="https://www.hibernate.org/412.html";
rel="nofollow">Hibernate Validator 4.x</a>. This library is not specific to any
implementation of JSR-303 and will work with any implementation of your
choice.</p><h3 id="BeanValidation-BootstrapingtheBeanValidator">Bootstraping
the Bean Validator</h3><p>The <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/beanvalidator/BeanValidatorSource.html";>BeanValidatorSource</a>
service is responsible for bootstrapping the <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a>. You can contribute a <a class="external-link"
href="http://tapest
ry.apache.org/current/apidocs/org/apache/tapestry5/beanvalidator/BeanValidatorConfigurer.html">BeanValidatorConfigurer</a>
to the configuration of this service in order to participate on the
configuration of <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a>.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<p>Tapestry has always provided a powerful non-JSR 303 validation mechanism
(see <a href="forms-and-validation.html">Forms and Validation</a>). Among
other things this mechanism allows you to annotate your domain model classes
with the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/beaneditor/Validate.html";>@Validate</a>
annotation. However, this annotation is problematic if your domain model is
used in non-Tapestry applications as well as in Tapestry applications. Your
non-Tapestry application becomes dependent on <em>tapestry5-annotations</em>
module. To make your domain model independent from Tapestry you can use the <a
class="external-link" href="http://jcp.org/en/jsr/detail?id=303";
rel="nofollow">JSR 303: Bean Validation</a> instead. This library provides
integration between Tapestry and JSR-303.</p><h2
id="BeanValidation-Configuration">Configuration</h2><p>The Tapestry's JSR 303 -
Bean Validation Library is responsible for con
figuring and bootstrapping the <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a> for you. In order to use this library you have to
choose an implementation of the JSR-303 specification like <a
class="external-link" href="https://www.hibernate.org/412.html";
rel="nofollow">Hibernate Validator 4.x</a>. This library is not specific to any
implementation of JSR-303 and will work with any implementation of your
choice.</p><h3 id="BeanValidation-BootstrapingtheBeanValidator">Bootstraping
the Bean Validator</h3><p>The <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/beanvalidator/BeanValidatorSource.html";>BeanValidatorSource</a>
service is responsible for bootstrapping the <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a>. You can contribute a <a class="external-link"
href="htt
p://tapestry.apache.org/current/apidocs/org/apache/tapestry5/beanvalidator/BeanValidatorConfigurer.html">BeanValidatorConfigurer</a>
to the configuration of this service in order to participate on the
configuration of <a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/Validator.html";
rel="nofollow">Validator</a>.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Contribute(BeanValidatorSource.class)
public static void
provideBeanValidatorConfigurer(OrderedConfiguration<BeanValidatorConfigurer>
configuration)
{
@@ -188,7 +188,7 @@ public static void provideBeanValidatorC
<t:form>
</body>
</html></pre>
-</div></div><p>Since the <em>validate</em> parameter defaults to the container
of the Form component, we could also remove <em>validate="this"</em> in the
example above.</p><h3
id="BeanValidation-ValidatingBeanswithBeanEditForm">Validating Beans with
BeanEditForm</h3><p>If you use the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/BeanEditForm.html";>BeanEditForm</a>
component it's even easier to validate your beans. The only thing you have to
do is to annotate your beans with JSR-303 annotations. If you are migrating
from Tapestry's built-in validation mechanism to JSR-303 Bean Validation, you
don't have to change your template at all.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>Since the <em>validate</em> parameter defaults to the container
of the Form component, we could also remove <em>validate="this"</em> in the
example above.</p><h3
id="BeanValidation-ValidatingBeanswithBeanEditForm">Validating Beans with
BeanEditForm</h3><p>If you use the <a
href="beaneditform-guide.html">BeanEditForm</a> component it's even easier to
validate your beans. The only thing you have to do is to annotate your beans
with JSR-303 annotations. If you are migrating from Tapestry's built-in
validation mechanism to JSR-303 Bean Validation, you don't have to change your
template at all.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class User
{
@NotNull
@@ -200,7 +200,7 @@ public static void provideBeanValidatorC
...
}</pre>
-</div></div><h3 id="BeanValidation-Client-sideValidation">Client-side
Validation</h3><p>Unfortunately JSR-303 doesn’t cover client-side
validation, so web frameworks supporting this JSR need to come up with
proprietary client-side solutions. Tapestry provides client-side validation for
the following JSR-303 constraints:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>JSR-303 constraint</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry' JavaScript function</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Max.html";
rel="nofollow">@Max</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.maxnumber</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax
/validation/constraints/Min.html" rel="nofollow">@Min</a></p></td><td
colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.minnumber</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/NotNull.html";
rel="nofollow">@NotNull</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.notnull</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Null.html";
rel="nofollow">@Null</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.isnull</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Pattern.html";
rel="nofollow">@Pattern</a></p></td><td colspan="1" rowspan="1" class="conf
luenceTd"><p>Tapestry.Validator.pattern</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html";
rel="nofollow">@Size</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.size</p></td></tr></tbody></table></div><h3
id="BeanValidation-Providingownclient-sidevalidators">Providing own
client-side validators</h3><p>Now let's see how to provide own client-side
validation for JSR-303 constraints. Imagine you created the following
constraint definition. The server-side implementation of the constraint is
implemented by RangeValidator. I suppose you are familiar with JSR-303, so I
don’t explain how to implement RangeValidator.</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><h3 id="BeanValidation-Client-sideValidation">Client-side
Validation</h3><p>Unfortunately JSR-303 doesn’t cover client-side
validation, so web frameworks supporting this JSR need to come up with
proprietary client-side solutions. Tapestry provides client-side validation for
the following JSR-303 constraints:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>JSR-303 constraint</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry' JavaScript function</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Max.html";
rel="nofollow">@Max</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.maxnumber</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax
/validation/constraints/Min.html" rel="nofollow">@Min</a></p></td><td
colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.minnumber</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/NotNull.html";
rel="nofollow">@NotNull</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.notnull</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Null.html";
rel="nofollow">@Null</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.isnull</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Pattern.html";
rel="nofollow">@Pattern</a></p></td><td colspan="1" rowspan="1" class="conf
luenceTd"><p>Tapestry.Validator.pattern</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html";
rel="nofollow">@Size</a></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Tapestry.Validator.size</p></td></tr></tbody></table></div><h3
id="BeanValidation-Providingownclient-sidevalidators">Providing own
client-side validators</h3><p>Now let's see how to provide own client-side
validation for JSR-303 constraints. Imagine you created the following
constraint definition. The server-side implementation of the constraint is
implemented by RangeValidator. I suppose you are familiar with JSR-303, so we
won't explain how to implement RangeValidator.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Documented
@Constraint(validatedBy = RangeValidator.class)
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/chainbuilder-service.html
==============================================================================
--- websites/production/tapestry/content/chainbuilder-service.html (original)
+++ websites/production/tapestry/content/chainbuilder-service.html Sun Feb 18
20:20:09 2018
@@ -135,7 +135,7 @@
</div>
-<p>With the chain of responsibility design pattern, a complex process is
broken down into many individual steps. Each step is a <em>command</em> (see <a
class="external-link" href="https://en.wikipedia.org/wiki/Command_pattern";
rel="nofollow">command pattern</a>). A key part of this is that the commands
are expected to implement some common interface. The commands are also
carefully arranged into a specific order.</p><p>The process operates by working
down the list of commands, and each command is given a chance to operate. In
the ChainBuilder service, a command can terminate the process either by
throwing an exception, or by returning true.</p><p>The return type of the
command method does not have to be boolean: For object types, any non-null
value short-circuits the process. For numeric type, any non-zero value. For
void methods, only throwing an exception will short circuit the
process.</p><p>Often, the command interface consists of a single method. When
the command interface ha
s multiple methods, each can be thought of as its own chain.</p><p>This is a
useful pattern because it makes it very easy to <em>extend</em> a given
process, simply by providing new commands and specifying where they fit into
the overall process. Most often chain of command is combined with an ordered <a
href="chainbuilder-service.html">configuration</a> to define what the list of
commands are (and in what order they should execute).</p><h1
id="ChainBuilderService-ChainBuilderService">ChainBuilder
Service</h1><p>Because this pattern is used so often inside Tapestry, a
built-in service exists to create implementations of the pattern as needed. The
<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ChainBuilder.html";>ChainBuilder</a>
service takes care of all the work:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<p>With the chain of responsibility design pattern, a complex process is
broken down into many individual steps. Each step is a <em>command</em> (see <a
class="external-link" href="https://en.wikipedia.org/wiki/Command_pattern";
rel="nofollow">command pattern</a>). A key part of this is that the commands
are expected to implement some common interface. The commands are also
carefully arranged into a specific order.</p><p>The process operates by working
down the list of commands, and each command is given a chance to operate. In
the ChainBuilder service, a command can terminate the process either by
throwing an exception, or by returning true.</p><p>The return type of the
command method does not have to be boolean: For object types, any non-null
value short-circuits the process. For numeric type, any non-zero value. For
void methods, only throwing an exception will short circuit the
process.</p><p>Often, the command interface consists of a single method. When
the command interface ha
s multiple methods, each can be thought of as its own chain.</p><p>This is a
useful pattern because it makes it very easy to <em>extend</em> a given
process, simply by providing new commands and specifying where they fit into
the overall process. Most often chain of command is combined with an ordered <a
href="tapestry-ioc-configuration.html">configuration</a> to define what the
list of commands are (and in what order they should execute).</p><h1
id="ChainBuilderService-ChainBuilderService">ChainBuilder
Service</h1><p>Because this pattern is used so often inside Tapestry, a
built-in service exists to create implementations of the pattern as needed. The
<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ChainBuilder.html";>ChainBuilder</a>
service takes care of all the work:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public interface ChainBuilder
{
<T> T build(Class<T> commandInterface, List<T> commands);
Modified:
websites/production/tapestry/content/defining-tapestry-ioc-services.html
==============================================================================
--- websites/production/tapestry/content/defining-tapestry-ioc-services.html
(original)
+++ websites/production/tapestry/content/defining-tapestry-ioc-services.html
Sun Feb 18 20:20:09 2018
@@ -128,7 +128,7 @@ public class MyAppModule
}</pre>
</div></div><p>When the service is bound, the value of the annotation is used
as id:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> binder.bind(Indexer.class, IndexerImpl.class);</pre>
-</div></div><p>This id can be overriden again by calling the method <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceBindingOptions.html#withIdjava.lang.String";>withId</a></p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><p>This id can be overriden again by calling the method <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceBindingOptions.html#withId-java.lang.String-";>withId(String)</a>:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> binder.bind(Indexer.class,
IndexerImpl.class).withId("FileSystemIndexer");</pre>
</div></div><h1
id="DefiningTapestryIOCServices-Injecting_DependenciesInjectingDependencies"><span
class="confluence-anchor-link"
id="DefiningTapestryIOCServices-Injecting_Dependencies"></span>Injecting
Dependencies</h1><p>It's pretty unlikely that your service will be able to
operate in a total vacuum. It will have other dependencies.</p><p>Dependencies
are provided to a service in one of several ways:</p><ul><li>As parameters to
the service builder method</li><li>As parameters to the service implementation
class' constructor (for autobuilt services)</li><li>As parameters passed to the
constructor of the service's module class (to be cached inside instance
variables)</li><li>Directly into fields of the service
implementation</li></ul><p>For example, let's say the Indexer needs a
JobScheduler to control when it executes, and a FileSystem to access files and
store indexes.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public static Indexer build(JobScheduler scheduler,
FileSystem fileSystem)
@@ -152,7 +152,7 @@ public class MyAppModule
return indexer;
}</pre>
-</div></div><p>If you find yourself injecting the same dependencies into
multiple service builder (or service decorator) methods, you can <a
href="defining-tapestry-ioc-services.html">cache dependency injections</a> in
your module, by defining a constructor. This reduces duplication in your
module.</p><h1
id="DefiningTapestryIOCServices-DisambiguationwithMarkerAnnotations">Disambiguation
with Marker Annotations</h1><p>In the previous example we were faced with a
problem: multiple versions of the JobScheduler service. They had the same
service interface but unique service ids. If you try to inject based on type,
the service to inject will be ambiguous. Tapestry will throw an exception
(identifying the parameter type and the matching services that implement that
type).</p><p>The problem is that when injecting a JobScheduler into some other
service we need to know which <em>one</em> to inject. Rather than using the
service id, another approach is to use a <em>marker annotation</em>.</
p><p>You may optionally link a service implementation with a marker
annotation.</p><p>For example, maybe you have one JobScheduler implementation
where the jobs are spread across a number of nodes in a cluster, and you have
another JobScheduler where the jobs are all executed exclusively in the current
process.</p><p>We can associate those two JobSchedulers with two
annotations.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>If you find yourself injecting the same dependencies into
multiple service builder (or service decorator) methods, you can <a
href="tapestry-ioc-modules.html">cache dependency injections</a> in your
module, by defining a constructor. This reduces duplication in your
module.</p><h1
id="DefiningTapestryIOCServices-DisambiguationwithMarkerAnnotations">Disambiguation
with Marker Annotations</h1><p>In the previous example we were faced with a
problem: multiple versions of the JobScheduler service. They had the same
service interface but unique service ids. If you try to inject based on type,
the service to inject will be ambiguous. Tapestry will throw an exception
(identifying the parameter type and the matching services that implement that
type).</p><p>The problem is that when injecting a JobScheduler into some other
service we need to know which <em>one</em> to inject. Rather than using the
service id, another approach is to use a <em>marker annotation</em>.</p><p>You m
ay optionally link a service implementation with a marker
annotation.</p><p>For example, maybe you have one JobScheduler implementation
where the jobs are spread across a number of nodes in a cluster, and you have
another JobScheduler where the jobs are all executed exclusively in the current
process.</p><p>We can associate those two JobSchedulers with two
annotations.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">@Target(
{ PARAMETER, FIELD })
@Retention(RUNTIME)
@@ -234,7 +234,7 @@ public class IndexerImpl implements Inde
. . .
}</pre>
-</div></div><p>Understanding why this is a bad idea involves a long detour
into inner details of the Java Memory Model. The short form is that other
threads may end up invoking methods on the IndexerImpl instance, and its fields
(even though they are final, even though they appear to already have been set)
may be uninitialized.</p><h1
id="DefiningTapestryIOCServices-FieldInjection">Field Injection</h1><p>The @<a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Inject.html";>Inject</a>
and @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/InjectService.html";>InjectService</a>
annotations may be used on instance fields of a service implementation class,
as an alternative to passing dependencies of the service implementation in via
the constructor.</p><p>Note that only dependencies are settable this way; if
you want resources, including the service's <a href="defin
ing-tapestry-ioc-services.html">configuration</a>, you must pass those through
the constructor. You <em>are</em> free to mix and match, injecting partially
with field injection and partially with constructor injection.</p><p>Caution:
injection via fields uses reflection to make the fields accessible. In
addition, it may not be as thread-safe as using the constructor to assign to
final fields.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>Understanding why this is a bad idea involves a long detour
into inner details of the Java Memory Model. The short form is that other
threads may end up invoking methods on the IndexerImpl instance, and its fields
(even though they are final, even though they appear to already have been set)
may be uninitialized.</p><h1
id="DefiningTapestryIOCServices-FieldInjection">Field Injection</h1><p>The @<a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Inject.html";>Inject</a>
and @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/InjectService.html";>InjectService</a>
annotations may be used on instance fields of a service implementation class,
as an alternative to passing dependencies of the service implementation in via
the constructor.</p><p>Note that only dependencies are settable this way; if
you want resources, including the service's <a href="tapes
try-ioc-configuration.html">configuration</a>, you must pass those through the
constructor. You <em>are</em> free to mix and match, injecting partially with
field injection and partially with constructor injection.</p><p>Caution:
injection via fields uses reflection to make the fields accessible. In
addition, it may not be as thread-safe as using the constructor to assign to
final fields.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">package org.example.myapp.services;
import org.apache.tapestry5.ioc.annotations.InjectService;
@@ -269,7 +269,7 @@ public class IndexerImpl implements Inde
return indexer;
}</pre>
-</div></div><p>This works the exact same way with autobuilt services, except
that the parameters of the service implementation constructor are considered,
rather than the parameters of the service builder method.</p><p>The
@InjectService annotation takes precedence over these resources.</p><p>If the
@InjectService annotation is not present, and the parameter type does not
exactly match a resource type, then <a
href="defining-tapestry-ioc-services.html">object injection</a> occurs. Object
injection will find the correct object to inject based on a number of
(extensible) factors, including the parameter type and any additional
annotations on the parameter.</p><p>Every once and a while, you'll have a
conflict between a resource type and an object injection. For example, the
following does not work as expected:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>This works the exact same way with autobuilt services, except
that the parameters of the service implementation constructor are considered,
rather than the parameters of the service builder method.</p><p>The
@InjectService annotation takes precedence over these resources.</p><p>If the
@InjectService annotation is not present, and the parameter type does not
exactly match a resource type, then <a href="object-providers.html">object
injection</a> occurs. Object injection will find the correct object to inject
based on a number of (extensible) factors, including the parameter type and any
additional annotations on the parameter.</p><p>Every once and a while, you'll
have a conflict between a resource type and an object injection. For example,
the following does not work as expected:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public static Indexer build(String serviceId, Log
serviceLog,
JobScheduler scheduler, FileSystem fileSystem,
@Value("${index-alerts-email}")
@@ -293,7 +293,7 @@ public class IndexerImpl implements Inde
return indexer;
}</pre>
-</div></div><p>Here, the alertEmail parameter will receive the configured
alerts email (see <a href="defining-tapestry-ioc-services.html">the symbols
documentation</a> for more about this syntax) rather than the service
id.</p><h1 id="DefiningTapestryIOCServices-BindingServiceBuilders">Binding
ServiceBuilders</h1><p>Yet another option is available: instead of binding an
interface to a implemention class, you can bind a service to a <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceBuilder.html";>ServiceBuilder</a>,
a callback used to create the service implementation. This is very useful in
very rare circumstances.</p><h1
id="DefiningTapestryIOCServices-BuiltinServices">Builtin Services</h1><p>A few
services within the Tapestry IOC Module are "builtin"; there is no service
builder method in the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/TapestryIOCModule.html";>T
apestryIOCModule</a> class.</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Service Id</strong></p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p><strong>Service
Interface</strong></p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>ClassFactory</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ClassFactory.html";>ClassFactory</a></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>LoggerSource</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/LoggerSource.html";>LoggerSource</a></p></td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><p>RegistryShutdownHub</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><a class="
external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/RegistryShutdownHub.html";>RegistryShutdownHub</a></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>PerthreadManager</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/PerthreadManager.html";>PerthreadManager</a></p></td></tr></tbody></table></div><p>Consult
the JavaDoc for each of these services to identify under what circumstances
you'll need to use them.</p><h1
id="DefiningTapestryIOCServices-MutuallyDependentServices">Mutually Dependent
Services</h1><p>One of the benefits of Tapestry IoC's proxy-based approach to
just-in-time instantiation is the automatic support for mutually dependent
services. For example, suppose that the Indexer and the FileSystem needed to
talk directly to each other. Normally, this would cause a "chicken-and-the-egg"
problem:
which one to create first?</p><p>With Tapestry IoC, this is not even
considered a special case:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+</div></div><p>Here, the alertEmail parameter will receive the configured
alerts email (see <span class="confluence-link">the </span><a
href="symbols.html"><span class="confluence-link">symbols
documentation</span></a> for more about this syntax) rather than the service
id.</p><h1 id="DefiningTapestryIOCServices-BindingServiceBuilders">Binding
ServiceBuilders</h1><p>Yet another option is available: instead of binding an
interface to a implemention class, you can bind a service to a <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceBuilder.html";>ServiceBuilder</a>,
a callback used to create the service implementation. This is very useful in
very rare circumstances.</p><h1
id="DefiningTapestryIOCServices-BuiltinServices">Builtin Services</h1><p>A few
services within the Tapestry IOC Module are "builtin"; there is no service
builder method in the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apac
he/tapestry5/ioc/services/TapestryIOCModule.html">TapestryIOCModule</a>
class.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p><strong>Service
Id</strong></p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Service Interface</strong></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>ClassFactory</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/ClassFactory.html";>ClassFactory</a></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>LoggerSource</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/LoggerSource.html";>LoggerSource</a></p></td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><p>RegistryShutdownHub</p></td><td colspan=
"1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/RegistryShutdownHub.html";>RegistryShutdownHub</a></p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>PerthreadManager</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/PerthreadManager.html";>PerthreadManager</a></p></td></tr></tbody></table></div><p>Consult
the JavaDoc for each of these services to identify under what circumstances
you'll need to use them.</p><h1
id="DefiningTapestryIOCServices-MutuallyDependentServices">Mutually Dependent
Services</h1><p>One of the benefits of Tapestry IoC's proxy-based approach to
just-in-time instantiation is the automatic support for mutually dependent
services. For example, suppose that the Indexer and the FileSystem needed to
talk directly to each other. Normally
, this would cause a "chicken-and-the-egg" problem: which one to create
first?</p><p>With Tapestry IoC, this is not even considered a special
case:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public static Indexer buildIndexer(JobScheduler
scheduler, FileSystem fileSystem)
{
IndexerImpl indexer = new IndexerImpl(fileSystem);
Modified: websites/production/tapestry/content/hibernate-core-conf.html
==============================================================================
--- websites/production/tapestry/content/hibernate-core-conf.html (original)
+++ websites/production/tapestry/content/hibernate-core-conf.html Sun Feb 18
20:20:09 2018
@@ -158,12 +158,10 @@
{
config.add("Widget", new WidgetHibernateConfigurer());
}</pre>
-</div></div><p>Note that the configuration is an OrderedConfiguration. The
library contributes two configurers by
default:</p><ul><li><strong>Default</strong> - performs default hibernate
configuration</li><li><strong>PackageName</strong> - loads entities by package
name as contributed to the HibernateEntityPackageManager service</li></ul><h2
id="Hibernate-Core-Conf-HibernateEntityPackageManagerConfiguration">HibernateEntityPackageManager
Configuration</h2><p>This configuration is a set of package names, identifying
where to search for entity classes.</p><p>For each package contributed, the
library will:</p><ul><li><a class="external-link"
href="http://docs.jboss.org/hibernate/stable/core/api/org/hibernate/cfg/AnnotationConfiguration.html#addPackage(java.lang.String)"
rel="nofollow">Add the package to the configuration</a>, which will load
annotations from the package-info class within the named package, if
present.</li><li>Every Java class in the package (or any subpackage) will b
e <a class="external-link"
href="http://docs.jboss.org/hibernate/stable/core/api/org/hibernate/cfg/AnnotationConfiguration.html#addAnnotatedClass(java.lang.Class)"
rel="nofollow">added as an annotated class</a>. This excludes inner classes,
but includes all other classes.</li></ul><p>By default, the package
<em>application-root-package.entities</em> is scanned as described above. If
you have additional packages containing entities, you must <a
href="hibernate-core-conf.html">contribute</a> them to the
tapestry.hibernate.HibernateEntityPackageManager service
configuration.</p><p>Example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public static void
contributeHibernateEntityPackageManager(Configuration<String>
configuration)
+</div></div><p>Note that the configuration is an OrderedConfiguration. The
library contributes two configurers by
default:</p><ul><li><strong>Default</strong> - performs default hibernate
configuration</li><li><strong>PackageName</strong> - loads entities by package
name as contributed to the HibernateEntityPackageManager service</li></ul><h2
id="Hibernate-Core-Conf-HibernateEntityPackageManagerConfiguration">HibernateEntityPackageManager
Configuration</h2><p>This configuration is a set of package names, identifying
where to search for entity classes.</p><p>For each package contributed, the
library will:</p><ul><li><a class="external-link"
href="http://docs.jboss.org/hibernate/stable/core/api/org/hibernate/cfg/AnnotationConfiguration.html#addPackage(java.lang.String)"
rel="nofollow">Add the package to the configuration</a>, which will load
annotations from the package-info class within the named package, if
present.</li><li>Every Java class in the package (or any subpackage) will b
e <a class="external-link"
href="http://docs.jboss.org/hibernate/stable/core/api/org/hibernate/cfg/AnnotationConfiguration.html#addAnnotatedClass(java.lang.Class)"
rel="nofollow">added as an annotated class</a>. This excludes inner classes,
but includes all other classes.</li></ul><p>By default, the package
<em>application-root-package.entities</em> is scanned as described above. If
you have additional packages containing entities, you must <a
href="configuration.html">contribute</a> them to the
tapestry.hibernate.HibernateEntityPackageManager service
configuration.</p><p>Example:</p>Error rendering macro 'code': Invalid value
specified for parameter 'firstline'<pre>public static void
contributeHibernateEntityPackageManager(Configuration<String>
configuration)
{
configuration.add("org.example.myapp.domain");
-}</pre>
-</div></div><p>You may add as many packages in this manner as you wish. This
option is most often used when the entities themselves are contained in a
library included within an application, rather than part of the application
directly.</p><h1 id="Hibernate-Core-Conf-HibernateSymbols">Hibernate
Symbols</h1><p>The Hibernate integration includes a number of <a
href="hibernate-core-conf.html">symbols</a> used to control certain
features:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>tapestry.hibernate.provide-entity-value-encoders</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>If true (the default) then
ValueEncoders are automatically provided for all Hibernate entities
(ValueEncoders are used to encode the primary keys of entities as strings that
can be included in URLs). Set to false if you want direct control over this
feature.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p
>tapestry.hibernate.default-configuration</p></td><td colspan="1" rowspan="1"
>class="confluenceTd"><p>If true (the default), then the application must
>include a <code>hibernate.cfg.xml</code> file. If your application configures
>itself entirely in code, you should set this symbol to
>false.</p></td></tr><tr><td colspan="1" rowspan="1"
>class="confluenceTd"><p>tapestry.hibernate.early-startup</p></td><td
>colspan="1" rowspan="1" class="confluenceTd"><p>If "true", the Hibernate is
>initialized when the application starts up. The default is "false", to start
>Hibernate up lazily, on first use.</p></td></tr></tbody></table></div></div>
+}</pre><p>You may add as many packages in this manner as you wish. This option
is most often used when the entities themselves are contained in a library
included within an application, rather than part of the application
directly.</p><h1 id="Hibernate-Core-Conf-HibernateSymbols">Hibernate
Symbols</h1><p>The Hibernate integration includes a number of <a
href="symbols.html">symbols</a> used to control certain features:</p><div
class="table-wrap"><table class="confluenceTable"><tbody><tr><td colspan="1"
rowspan="1"
class="confluenceTd"><p>tapestry.hibernate.provide-entity-value-encoders</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>If true (the default) then
ValueEncoders are automatically provided for all Hibernate entities
(ValueEncoders are used to encode the primary keys of entities as strings that
can be included in URLs). Set to false if you want direct control over this
feature.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>tapestry.hiberna
te.default-configuration</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>If true (the default), then the application must
include a <code>hibernate.cfg.xml</code> file. If your application configures
itself entirely in code, you should set this symbol to
false.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>tapestry.hibernate.early-startup</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>If "true", the Hibernate is
initialized when the application starts up. The default is "false", to start
Hibernate up lazily, on first use.</p></td></tr></tbody></table></div></div>
</div>
<div class="clearer"></div>
Modified: websites/production/tapestry/content/hibernate-core.html
==============================================================================
--- websites/production/tapestry/content/hibernate-core.html (original)
+++ websites/production/tapestry/content/hibernate-core.html Sun Feb 18
20:20:09 2018
@@ -145,7 +145,7 @@
</div>
-<p>This module only requires the <a href="hibernate-core.html">Tapestry
IoC</a> module. This makes it useful in non-web applications, such as back-end
processing.</p><p>The <a href="hibernate-core.html">Tapestry-hibernate</a>
module extends this further, adding features to support the creation of CRUD
(Create/Read/Update/Delete) database applications in Tapestry.</p><h1
id="Hibernate-Core-LicensingIssues">Licensing Issues</h1><p>Hibernate is
licensed under the Lesser GNU Public License. This is more restrictive license
than the Apache Software License used by the rest of Tapestry. The restrictions
mostly apply to redistributing Hibernate, especially in any altered form, and
will likely be irrelvant to the vast majority of users, but you should be
aware.</p><p>This library is compiled against version <strong>3.3.1.GA</strong>
of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work
with more recent versions.</p></div>
+<p>This module only requires the <a href="ioc.html">Tapestry IoC</a> module.
This makes it useful in non-web applications, such as back-end
processing.</p><p>The <a href="hibernate-core.html">Tapestry-hibernate</a>
module extends this further, adding features to support the creation of CRUD
(Create/Read/Update/Delete) database applications in Tapestry.</p><h1
id="Hibernate-Core-LicensingIssues">Licensing Issues</h1><p>Hibernate is
licensed under the Lesser GNU Public License. This is more restrictive license
than the Apache Software License used by the rest of Tapestry. The restrictions
mostly apply to redistributing Hibernate, especially in any altered form, and
will likely be irrelevant to the vast majority of users, but you should be
aware.</p><p>See <a href="supported-environments-and-versions.html">Supported
Environments and Versions</a> for the Hibernate versions that are
supported.</p></div>
</div>
<div class="clearer"></div>
Modified: websites/production/tapestry/content/hibernate.html
==============================================================================
--- websites/production/tapestry/content/hibernate.html (original)
+++ websites/production/tapestry/content/hibernate.html Sun Feb 18 20:20:09 2018
@@ -145,7 +145,7 @@
</div>
-<p>This represents access to the native Hibernate interfaces, exposed in a
thread-safe manner, within a <em>session-per-request</em> strategy.</p><p>Note
that a number of the more esoteric ideas in Hibernate are not supported,
including nested transactions and supporting multiple persistence
units.</p><p>The <a href="hibernate.html">tapestry-hibernate-core</a> module
allows non-web applications to access Hibernate.</p><h1
id="Hibernate-LicensingIssues">Licensing Issues</h1><p>Hibernate is licensed
under the Lesser GNU Public License. This is more restrictive license than the
Apache Software License used by the rest of Tapestry. The restrictions mostly
apply to redistributing Hibernate, especially in any altered form, and will
likely be irrelevant to the vast majority of users, but you should be
aware.</p><p>This library is compiled against version <strong>3.3.1.GA</strong>
of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work
with more recent versions.</p><h
2 id="Hibernate-Notes">Notes</h2><ul><li>Transactions are <em>aborted</em>
(not <em>committed</em>) at the end of each request: you must explicitly commit
the transaction if changes are to be saved.</li><li>The CommitAfter annotation
for component and service methods can commit the transaction automatically
after the method is invoked.</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/hibernate/HibernateGridDataSource.html";>HibernateGridDataSource</a>
can be used with the Grid component to support optimized queries against large
data sets.</li></ul></div>
+<p>This represents access to the native Hibernate interfaces, exposed in a
thread-safe manner, within a <em>session-per-request</em> strategy.</p><p>Note
that a number of the more esoteric ideas in Hibernate are not supported,
including nested transactions and supporting multiple persistence
units.</p><p>The <a href="hibernate-core.html">tapestry-hibernate-core</a>
module allows non-web applications to access Hibernate.</p><h1
id="Hibernate-LicensingIssues">Licensing Issues</h1><p>Hibernate is licensed
under the Lesser GNU Public License. This is more restrictive license than the
Apache Software License used by the rest of Tapestry. The restrictions mostly
apply to redistributing Hibernate, especially in any altered form, and will
likely be irrelevant to the vast majority of users, but you should be
aware.</p><p>See <a href="supported-environments-and-versions.html">Supported
Environments and Versions</a> for the versions of Hibernate supported.</p><h2
id="Hibernate-Notes">Notes</
h2><ul><li>Transactions are <em>aborted</em> (not <em>committed</em>) at the
end of each request: you must explicitly commit the transaction if changes are
to be saved.</li><li>The CommitAfter annotation for component and service
methods can commit the transaction automatically after the method is
invoked.</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/hibernate/HibernateGridDataSource.html";>HibernateGridDataSource</a>
can be used with the Grid component to support optimized queries against large
data sets.</li></ul></div>
</div>
<div class="clearer"></div>
Modified: websites/production/tapestry/content/injection-in-detail.html
==============================================================================
--- websites/production/tapestry/content/injection-in-detail.html (original)
+++ websites/production/tapestry/content/injection-in-detail.html Sun Feb 18
20:20:09 2018
@@ -117,7 +117,7 @@
</div>
-<p>Despite this, injection generally <em>Just Works</em>: most of the time,
you want Tapestry to inject a service, and only a single service implements the
service interface.</p><p>This document discusses what to do when you hit a case
that doesn't Just Work, or when you want to extend the injection logic in some
way.</p><p>Some aspects of this discussion reflect Tapestry IoC used within a
Tapestry web application: the tapestry-core module makes some extensions to
injection.</p><h1 id="InjectioninDetail-InjectionTriggers">Injection
Triggers</h1><p>Injection is triggered in a number of ways:</p><ul><li>A field
in a component class, autobuilt object, or service implementation class is
annotated with @Inject.</li><li>A method parameter to a service builder method,
a decorator method, or a contribute method (in a Tapestry IoC module
class).</li><li>A constructor parameter to an autobuilt object, or a service
implementation class.</li><li>Any of the above with an @InjectService annotatio
n.</li></ul><p>These define the <em>point of
injection</em>.</p><p>Injection also covers a related matter: providing special
resources to a service or component (remember that pages are specialized
components). For a service, the service's id (as a string) or extensible
configuration (as a Collection, List or Map) may be provided. For a component,
the component's id, locale, message catalog, or component resources may be
provided.</p><h1 id="InjectioninDetail-StandardInjectionProcessing">Standard
Injection Processing</h1><p>This section describes standard injection, which
applies at the IoC layer: autobuilt objects and service implementations. The
steps for injection into Tapestry components are slightly different and are
covered later.</p><p>So a the point of injection, Tapestry has identified a
field or parameter that should be injected. At this point, Tapestry knows the
following:</p><ul><li>The field name (if field injection). The parameter name
is not available.</li><li>Th
e field or parameter type, as a Java class. In many cases, this will be enough
to identify what object shall be injected.</li><li>Any additional annotations
on the field or parameter.</li></ul><p>Tapestry proceeds with this
information.</p><h2 id="InjectioninDetail-Checkfor@InjectService">Check for
@InjectService</h2><p>Tapestry checks first for the @InjectService annotation.
The value of this annotation is the service id to inject. When @InjectService
is present at the point of injection, the search is complete, though the
injection can fail (throwing an exception) if the service id indicated does not
exist, or if the service's interface is not compatible with the field's
type.</p><h2 id="InjectioninDetail-Checkforserviceresources">Check for service
resources</h2><p>This step applies only to IoC layer injection (not to
injection into components).</p><p>When the @Inject annotation is <em>not
present</em> at the point of injection, Tapestry checks to see if a resource
can be injected
. Services are global values, but resources are specific to the service under
construction.</p><p>When the Inject annotation is present, this step is skipped
(this is necessary when the object to be injected has a type that conflicts
with a resource type, such as List or Class).</p><ul><li>org.slf4j.Logger
– The Logger of the service being constructed (or the logger of the
Module class being instantiated).</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ObjectLocator.html";>ObjectLocator</a>
– For contribute methods, used to locate additional objects.</li><li><a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceResources.html";>ServiceResources</a>
– For service builder methods, an extended version of
ObjectLocator. </li><li>Class – The service interface
type.</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apido
cs/org/apache/tapestry5/ioc/OperationTracker.html">OperationTracker</a>
– Used to track deeply nested operations so that errors can be reported
sensibly.</li><li>Object, or service interface type – Passed to decorator
methods.</li><li>Collection, List, Map – Assembled service configurations
passed to service builder methods (or service class
constructors).</li><li><p>Configuration, OrderedConfiguration,
MappedConfiguration – Configuration passed to contribute methods, to
build service configurations. <br clear="none" class="atl-forced-newline"> <br
clear="none" class="atl-forced-newline"> If field type does not match any of
the available resource types, or the Inject annotation is present, logic
continues to the next step.</p><div class="confluence-information-macro
confluence-information-macro-warning"><span class="aui-icon aui-icon-small
aui-iconfont-error confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Injection
of resources into fields is triggered by the presence of the @<a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/InjectResource.html";>InjectResource</a>
annotation, whereas injection of resources into parameters occurs when the
Inject or InjectService annotation is <em>not</em> present. These rules are
slightly tricky, which reflects a desire to avoid any annotations except when
needed, and the fact that field injection came much later than parameter
injection.</p></div></div></li></ul><h2
id="InjectioninDetail-ServiceLookupbyTypeandAnnotations">Service Lookup by Type
and Annotations</h2><p>Tapestry attempts to find a matching
<em>service</em>.</p><p>First, it generates a set of services whose service
interface is compatible with the injection type. This is based on
assignability.</p><p>If the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Local.html";>Local<
/a> annotation is present, then services not from the module containing the
service being constructed will be eliminated.</p><p>Tapestry then works through
the known marker annotations. For each marker annotation that is present at the
point of injection, Tapestry eliminates services which <em>do not</em> have the
marker. Thus, if multiple marker annotations are present, the final service
must have <em>all of them</em>.</p><p>At the end, of this, Tapestry determines
how many services match.</p><ul><li>If there is a single matching service, then
the service to inject as been identified.</li><li>If there are no matches, and
there were no marker annotations at the point of injection, then the Tapestry
continues to the next step.</li><li>Otherwise there were either no matches, or
too many matches: Tapestry will throw a RuntimeException.</li></ul><h2
id="InjectioninDetail-MasterObjectProviderLookup">MasterObjectProvider
Lookup</h2><p>This is the point at which Tapestry's extensibility co
mes into play. MasterObjectProvider is a service, with a configuration of <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ObjectProvider.html";>ObjectProviders</a>.</p><p>The
MasterObjectProvider is also the point at which Tapestry's IoC layer
injection, and Tapestry's component injection, unite.</p><p>As a
chain-of-command, each of the following ObjectProviders will be considered and
will attempt to identify the object to be injected.</p><div
class="confluence-information-macro confluence-information-macro-note"><span
class="aui-icon aui-icon-small aui-iconfont-warning
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>A common problem when extending
injection is that contributions into the MasterObjectProvider configuration
have to be handled carefully. Any dependencies of the contributed objects
should be resolvable using only the early stages of the injection process,
otherwise MasterObje
ctProvider will have to be instantiated in order to handle its own injection:
Tapestry will detect this impossibility and throw an exception. In addition,
the <a href="injection-in-detail.html">TypeCoercer</a> service is used by
several ObjectProvider implementations, so the same restrictions apply to
TypeCoercer service contributions.</p></div></div><h3
id="InjectioninDetail-ValueObjectProvider">Value ObjectProvider</h3><p>Checks
for the presence of the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Value.html";>Value</a>
annotation. If present, then the annotation's value is evaluated (to expand
any symbol references), and the TypeCoercer service is used to convert the
resulting String to the injection type (the field or parameter type).</p><h3
id="InjectioninDetail-SymbolObjectProvider">Symbol
ObjectProvider</h3><p>Similar to the Value ObjectProvider: the @<a
class="external-link" href="http://tapestry.apache.org/
current/apidocs/org/apache/tapestry5/ioc/annotations/Symbol.html">Symbol</a>
annotation's value (if present) is looked up using the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/SymbolSource.html";>SymbolSource</a>
service, and converted to the injection type via the TypeCoercer
service.</p><h3 id="InjectioninDetail-AutobuildObjectProvider">Autobuild
ObjectProvider</h3><p>Checks to see if the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Autobuild.html";>Autobuild</a>
annotation is present and, if so, autobuilds the value for the parameter. Of
course, the object being built will itself be configured via injection.</p><h3
id="InjectioninDetail-ServiceOverrideObjectProvider">ServiceOverride
ObjectProvider</h3><p>Checks any contributions to the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/Ser
viceOverride.html">ServiceOverride</a> service. Contributions map a type to an
object of that type. Thus, ServiceOverrides will override injections of
services that are not qualified with a marker annotation.</p><h3
id="InjectioninDetail-AliasObjectProvider(tapestry-core)">Alias ObjectProvider
(tapestry-core)</h3><p>Uses the Alias service (<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/Alias.html";>API</a>)
to look for an object that can be injected.</p><div
class="confluence-information-macro confluence-information-macro-warning"><span
class="aui-icon aui-icon-small aui-iconfont-error
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Deprecated in Tapestry 5.2 and
removed in 5.4.</p></div></div><p>This is commonly used to override a built-in
service by contributing an object with the exact same interface. This is an
older and more complex version of the ServiceOverride provider.</p><h
3 id="InjectioninDetail-AssetObjectProvider(tapestry-core)">Asset
ObjectProvider (tapestry-core)</h3><p>Checks for the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Path.html";>Path</a>
annotation.</p><p>If present, the annotation's value has embedded symbols
expanded, and is converted into an Asset (which must exist).</p><p>The
TypeCoercer can then convert the Asset to the injection type, for example, as
Resource.</p><h3
id="InjectioninDetail-ServiceObjectProvider(tapestry-core)">Service
ObjectProvider (tapestry-core)</h3><p>Looks for the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Service.html";>Service</a>
annotation; if present, the annotation's value is the exact service id to
inject. This is necessary because injections into <em>component</em> fields are
always triggered by the Inject annotation.</p><div
class="confluence-information-macro confluence-in
formation-macro-note"><span class="aui-icon aui-icon-small
aui-iconfont-warning confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>This is supported but no longer
necessary, as the @InjectService annotation is now also supported for component
fields.</p></div></div><h3
id="InjectioninDetail-SpringBeanObjectProvider(tapestry-spring)">SpringBean
ObjectProvider (tapestry-spring)</h3><p>Attempts to resolve a Spring bean
purely by object type (Spring qualifiers are not supported). If no beans are
assignable to the type, then processing continues. If exactly one is
assignable, it is used as the injection value. If more than one bean is
assignable, it is an error (and a list of matching beans names will be part of
the thrown exception).</p><h2 id="InjectioninDetail-ServiceLookup">Service
Lookup</h2><p>If none of the ObjectProviders can identify the value to inject,
a last step occurs: lookup by service type. If exactly <em>one</em> service
matches t
he injection type, then that service is injected.</p><p>Otherwise, the lookup
fails because either no services match, or more than one matches. An exception
will be thrown with the details, including a list of matching services (if
there is more than one match).</p><h1
id="InjectioninDetail-Post-InjectionMethods">Post-Injection
Methods</h1><p>Autobuilt objects (services and the like, but <em>not</em>
components) may have post-injection methods.</p><p>Any public method may have
the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PostInjection.html";>PostInjection</a>
annotation.</p><p>Such methods are invoked after constructor and/or field
injection. Only <strong>public methods</strong> will be invoked. Any return
value is ignored.</p><p>The method often takes no parameters; however if the
method has parameters, these parameters are new points of
injection.</p><p>Often this is used to perform additional setup, such as regist
erring a service as a listener of events produced by another service:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<p>Despite this, injection generally <em>Just Works</em>: most of the time,
you want Tapestry to inject a service, and only a single service implements the
service interface.</p><p>This document discusses what to do when you hit a case
that doesn't Just Work, or when you want to extend the injection logic in some
way.</p><p>Some aspects of this discussion reflect Tapestry IoC used within a
Tapestry web application: the tapestry-core module makes some extensions to
injection.</p><h1 id="InjectioninDetail-InjectionTriggers">Injection
Triggers</h1><p>Injection is triggered in a number of ways:</p><ul><li>A field
in a component class, autobuilt object, or service implementation class is
annotated with @Inject.</li><li>A method parameter to a service builder method,
a decorator method, or a contribute method (in a Tapestry IoC module
class).</li><li>A constructor parameter to an autobuilt object, or a service
implementation class.</li><li>Any of the above with an @InjectService annotatio
n.</li></ul><p>These define the <em>point of
injection</em>.</p><p>Injection also covers a related matter: providing special
resources to a service or component (remember that pages are specialized
components). For a service, the service's id (as a string) or extensible
configuration (as a Collection, List or Map) may be provided. For a component,
the component's id, locale, message catalog, or component resources may be
provided.</p><h1 id="InjectioninDetail-StandardInjectionProcessing">Standard
Injection Processing</h1><p>This section describes standard injection, which
applies at the IoC layer: autobuilt objects and service implementations. The
steps for injection into Tapestry components are slightly different and are
covered later.</p><p>So a the point of injection, Tapestry has identified a
field or parameter that should be injected. At this point, Tapestry knows the
following:</p><ul><li>The field name (if field injection). The parameter name
is not available.</li><li>Th
e field or parameter type, as a Java class. In many cases, this will be enough
to identify what object shall be injected.</li><li>Any additional annotations
on the field or parameter.</li></ul><p>Tapestry proceeds with this
information.</p><h2 id="InjectioninDetail-Checkfor@InjectService">Check for
@InjectService</h2><p>Tapestry checks first for the @InjectService annotation.
The value of this annotation is the service id to inject. When @InjectService
is present at the point of injection, the search is complete, though the
injection can fail (throwing an exception) if the service id indicated does not
exist, or if the service's interface is not compatible with the field's
type.</p><h2 id="InjectioninDetail-Checkforserviceresources">Check for service
resources</h2><p>This step applies only to IoC layer injection (not to
injection into components).</p><p>When the @Inject annotation is <em>not
present</em> at the point of injection, Tapestry checks to see if a resource
can be injected
. Services are global values, but resources are specific to the service under
construction.</p><p>When the Inject annotation is present, this step is skipped
(this is necessary when the object to be injected has a type that conflicts
with a resource type, such as List or Class).</p><ul><li>org.slf4j.Logger
– The Logger of the service being constructed (or the logger of the
Module class being instantiated).</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ObjectLocator.html";>ObjectLocator</a>
– For contribute methods, used to locate additional objects.</li><li><a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ServiceResources.html";>ServiceResources</a>
– For service builder methods, an extended version of
ObjectLocator. </li><li>Class – The service interface
type.</li><li><a class="external-link"
href="http://tapestry.apache.org/current/apido
cs/org/apache/tapestry5/ioc/OperationTracker.html">OperationTracker</a>
– Used to track deeply nested operations so that errors can be reported
sensibly.</li><li>Object, or service interface type – Passed to decorator
methods.</li><li>Collection, List, Map – Assembled service configurations
passed to service builder methods (or service class
constructors).</li><li><p>Configuration, OrderedConfiguration,
MappedConfiguration – Configuration passed to contribute methods, to
build service configurations. <br clear="none" class="atl-forced-newline"> <br
clear="none" class="atl-forced-newline"> If field type does not match any of
the available resource types, or the Inject annotation is present, logic
continues to the next step.</p><div class="confluence-information-macro
confluence-information-macro-warning"><span class="aui-icon aui-icon-small
aui-iconfont-error confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Injection
of resources into fields is triggered by the presence of the @<a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/InjectResource.html";>InjectResource</a>
annotation, whereas injection of resources into parameters occurs when the
Inject or InjectService annotation is <em>not</em> present. These rules are
slightly tricky, which reflects a desire to avoid any annotations except when
needed, and the fact that field injection came much later than parameter
injection.</p></div></div></li></ul><h2
id="InjectioninDetail-ServiceLookupbyTypeandAnnotations">Service Lookup by Type
and Annotations</h2><p>Tapestry attempts to find a matching
<em>service</em>.</p><p>First, it generates a set of services whose service
interface is compatible with the injection type. This is based on
assignability.</p><p>If the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Local.html";>Local<
/a> annotation is present, then services not from the module containing the
service being constructed will be eliminated.</p><p>Tapestry then works through
the known marker annotations. For each marker annotation that is present at the
point of injection, Tapestry eliminates services which <em>do not</em> have the
marker. Thus, if multiple marker annotations are present, the final service
must have <em>all of them</em>.</p><p>At the end, of this, Tapestry determines
how many services match.</p><ul><li>If there is a single matching service, then
the service to inject as been identified.</li><li>If there are no matches, and
there were no marker annotations at the point of injection, then the Tapestry
continues to the next step.</li><li>Otherwise there were either no matches, or
too many matches: Tapestry will throw a RuntimeException.</li></ul><h2
id="InjectioninDetail-MasterObjectProviderLookup">MasterObjectProvider
Lookup</h2><p>This is the point at which Tapestry's extensibility co
mes into play. MasterObjectProvider is a service, with a configuration of <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ObjectProvider.html";>ObjectProviders</a>.</p><p>The
MasterObjectProvider is also the point at which Tapestry's IoC layer
injection, and Tapestry's component injection, unite.</p><p>As a
chain-of-command, each of the following ObjectProviders will be considered and
will attempt to identify the object to be injected.</p><div
class="confluence-information-macro confluence-information-macro-note"><span
class="aui-icon aui-icon-small aui-iconfont-warning
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p class="confluence-link">A common
problem when extending injection is that contributions into the
MasterObjectProvider configuration have to be handled carefully. Any
dependencies of the contributed objects should be resolvable using only the
early stages of the injection proce
ss, otherwise MasterObjectProvider will have to be instantiated in order to
handle its own injection: Tapestry will detect this impossibility and throw an
exception. In addition, the <a
href="typecoercer-service.html">TypeCoercer Service</a> is used by several
ObjectProvider implementations, so the same restrictions apply to TypeCoercer
service contributions.</p></div></div><h3
id="InjectioninDetail-ValueObjectProvider">Value ObjectProvider</h3><p>Checks
for the presence of the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Value.html";>Value</a>
annotation. If present, then the annotation's value is evaluated (to expand
any symbol references), and the TypeCoercer service is used to convert the
resulting String to the injection type (the field or parameter type).</p><h3
id="InjectioninDetail-SymbolObjectProvider">Symbol
ObjectProvider</h3><p>Similar to the Value ObjectProvider: the @<a
class="external-link" href
="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Symbol.html";>Symbol</a>
annotation's value (if present) is looked up using the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/SymbolSource.html";>SymbolSource</a>
service, and converted to the injection type via the TypeCoercer
service.</p><h3 id="InjectioninDetail-AutobuildObjectProvider">Autobuild
ObjectProvider</h3><p>Checks to see if the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Autobuild.html";>Autobuild</a>
annotation is present and, if so, autobuilds the value for the parameter. Of
course, the object being built will itself be configured via injection.</p><h3
id="InjectioninDetail-ServiceOverrideObjectProvider">ServiceOverride
ObjectProvider</h3><p>Checks any contributions to the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apac
he/tapestry5/ioc/services/ServiceOverride.html">ServiceOverride</a> service.
Contributions map a type to an object of that type. Thus, ServiceOverrides will
override injections of services that are not qualified with a marker
annotation.</p><h3
id="InjectioninDetail-AliasObjectProvider(tapestry-core)">Alias ObjectProvider
(tapestry-core)</h3><p>Uses the Alias service (<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/Alias.html";>API</a>)
to look for an object that can be injected.</p><div
class="confluence-information-macro confluence-information-macro-warning"><span
class="aui-icon aui-icon-small aui-iconfont-error
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Deprecated in Tapestry 5.2 and
removed in 5.4.</p></div></div><p>This is commonly used to override a built-in
service by contributing an object with the exact same interface. This is an
older and more complex version of the Se
rviceOverride provider.</p><h3
id="InjectioninDetail-AssetObjectProvider(tapestry-core)">Asset ObjectProvider
(tapestry-core)</h3><p>Checks for the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Path.html";>Path</a>
annotation.</p><p>If present, the annotation's value has embedded symbols
expanded, and is converted into an Asset (which must exist).</p><p>The
TypeCoercer can then convert the Asset to the injection type, for example, as
Resource.</p><h3
id="InjectioninDetail-ServiceObjectProvider(tapestry-core)">Service
ObjectProvider (tapestry-core)</h3><p>Looks for the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Service.html";>Service</a>
annotation; if present, the annotation's value is the exact service id to
inject. This is necessary because injections into <em>component</em> fields are
always triggered by the Inject annotation.</p><div class="confluence-in
formation-macro confluence-information-macro-note"><span class="aui-icon
aui-icon-small aui-iconfont-warning
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>This is supported but no longer
necessary, as the @InjectService annotation is now also supported for component
fields.</p></div></div><h3
id="InjectioninDetail-SpringBeanObjectProvider(tapestry-spring)">SpringBean
ObjectProvider (tapestry-spring)</h3><p>Attempts to resolve a Spring bean
purely by object type (Spring qualifiers are not supported). If no beans are
assignable to the type, then processing continues. If exactly one is
assignable, it is used as the injection value. If more than one bean is
assignable, it is an error (and a list of matching beans names will be part of
the thrown exception).</p><h2 id="InjectioninDetail-ServiceLookup">Service
Lookup</h2><p>If none of the ObjectProviders can identify the value to inject,
a last step occurs: lookup by service type. If exactly <
em>one</em> service matches the injection type, then that service is
injected.</p><p>Otherwise, the lookup fails because either no services match,
or more than one matches. An exception will be thrown with the details,
including a list of matching services (if there is more than one match).</p><h1
id="InjectioninDetail-Post-InjectionMethods">Post-Injection
Methods</h1><p>Autobuilt objects (services and the like, but <em>not</em>
components) may have post-injection methods.</p><p>Any public method may have
the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PostInjection.html";>PostInjection</a>
annotation.</p><p>Such methods are invoked after constructor and/or field
injection. Only <strong>public methods</strong> will be invoked. Any return
value is ignored.</p><p>The method often takes no parameters; however if the
method has parameters, these parameters are new points of
injection.</p><p>Often this is used to perform add
itional setup, such as registerring a service as a listener of events produced
by another service:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class MyServiceImpl implements MyService,
UpdateListener
{
@PostInjection
@@ -134,7 +134,6 @@
<div class="aui-message aui-message-info">
Added in 5.3
ComponentResourceSelector is new as of release 5.3. It encapsulates a
locale plus additional application-specific data used for skinning and/or
themeing.
-
</div><h2 id="InjectioninDetail-AssetInjectionProvider">Asset
InjectionProvider</h2><p>Triggered by the @Path annotation: the Path value has
symbols expanded, and is then converted to an Asset.</p><h2
id="InjectioninDetail-ServiceInjectionProvider">Service
InjectionProvider</h2><p>Equivalent to the Service Lookup phase in an IoC layer
injection.</p><h1
id="InjectioninDetail-@InjectServiceinComponents">@InjectService in
Components</h1><p>You may use the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/InjectService.html";>InjectService</a>
annotation on component fields.</p><p></p></div>
</div>
