; Sun, 26 Jul 2015 22:19:49 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r959689 [1/4] - in /websites/production/tapestry/content: ./ cache/ Date: Sun, 26 Jul 2015 22:19:48 -0000 To: commits@tapestry.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20150726221949.EDBF3AC0024@hades.apache.org> Author: buildbot Date: Sun Jul 26 22:19:48 2015 New Revision: 959689 Log: Production update by buildbot for tapestry Modified: websites/production/tapestry/content/cache/main.pageCache websites/production/tapestry/content/chainbuilder-service.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/logging-in-tapestry.html websites/production/tapestry/content/object-providers.html websites/production/tapestry/content/operation-tracker.html websites/production/tapestry/content/parallel-execution.html websites/production/tapestry/content/pipelinebuilder-service.html websites/production/tapestry/content/registry-startup.html websites/production/tapestry/content/service-implementation-reloading.html websites/production/tapestry/content/service-serialization.html websites/production/tapestry/content/shadowbuilder-service.html websites/production/tapestry/content/starting-the-ioc-registry.html websites/production/tapestry/content/strategybuilder-service.html websites/production/tapestry/content/symbols.html websites/production/tapestry/content/type-coercion.html websites/production/tapestry/content/using-jsr-330-standard-annotations.html 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 Jul 26 22:19:48 2015 @@ -62,64 +62,81 @@

- Apache Tapestry > Documentation > User Guide > IoC > ChainBuilder Service + Apache Tapestry > Documentation > User Guide > IOC > ChainBuilder Service edit

The ChainBuilder Service is a built-in service used to implement of one of the most useful of the Gang Of Four design patterns, the chain of responsibility.

Chain of Command

Error formatting macro: contentbylabel: com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not parse cql : null

One of the most useful of the Gang Of Four Design Patterns is the command pattern.

With the command pattern, a complex process is broken down into many individual steps. The steps are the commands in the command pattern. A key part of this is that the commands are expected to implement some common interface. The commands are carefully arranged into a specific order.

The process operates by working down the list of commands. Each command is given a chance to operate. A command can terminate the process either by throwing an exception, or by returning true.

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.

Often, the command interface consists of a single method. When the command interface has multiple methods, each can be thought of as its own chain.

This is a useful pattern because it makes it very easy to extend 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 configuration to define what the list of commands are (and in what order they should execute).

- -

ChainBuilder Service

- -

Because this pattern is used so often inside Tapestry, a built-in service exists to create implementations of the pattern as needed. The ChainBuilder service takes care of all the work:

- -

-public interface ChainBuilder
+Related Articles
+
+
+        
+                Page:        
+
+        
+                        ChainBuilder Service
+                
+                        
+                    
+    

+        
+                Page:        
+
+        
+                        ShadowBuilder Service
+                
+                        
+                    
+    

+        
+                Page:        
+
+        
+                        IoC Cookbook - Patterns
+                
+                        
+                    
+    

+        
+                Page:        
+
+        
+                        StrategyBuilder Service
+                
+                        
+                    
+    

+        
+                Page:        
+
+        
+                        PipelineBuilder Service
+                
+                        
+                    
+    
+

With the chain of responsibility design pattern, a complex process is broken down into many individual steps. Each step is a command (see command pattern). 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.

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.

Often, the command interface consists of a single method. When the command interfac e has multiple methods, each can be thought of as its own chain.

ChainBuilder Service

Because this pattern is used so often inside Tapestry, a built-in service exists to create implementations of the pattern as needed. The ChainBuilder service takes care of all the work:

public interface ChainBuilder
 {
   <T> T build(Class<T> commandInterface, List<T> commands);
 }

- -

All that generics parameterization just ensures that the command interface matches the items in the list, and confirms that a single instance of the command interface will be returned.

- -

Invoking this method returns an object that encapsulates the chain of command for a particular interface and a particular list of commands implementing that interface.

- -

This can be used inside a service builder method. Nothing says a service builder method just has to instantiate a class; it is only required to return an appropriate object. We can just let the ChainBuilder service create that object.

- -

-  public static MyChainService build(List<MyChainService> commands,
+

All that generics parameterization just ensures that the command interface matches the items in the list, and confirms that a single instance of the command interface will be returned.

Invoking this method returns an object that encapsulates the chain of command for a particular interface and a particular list of commands implementing that interface.

  public static MyChainService build(List<MyChainService> commands,
     @InjectService("ChainBuilder")
     ChainBuilder chainBuilder)
   {
      return chainBuilder.build(MyChainService.class, commands);
   }

- -

Here, the behavior of the MyChainService is defined by its configuration: an ordered list of MyChainService commands that are contributed by one or more modules.

- -

Internally, the ChainBuilder creates a new class that implements the service interface. The list of commands is converted into an array, which is used inside the service implementation (for maximum efficiency). Therefore, changing the list after creating the chain instance will not affect the chain instance's behavior.

- -

ChainBuilder will reuse the fabricated class for any number of chains of the same command interface.

Here, the behavior of the MyChainService is defined by its configuration: an ordered list of MyChainService commands that are contributed by one or more modules.

ChainBuilder will reuse the fabricated class for any number of chains of the same command interface.

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 Jul 26 22:19:48 2015 @@ -31,8 +31,6 @@ - - - - - - @@ -67,20 +57,82 @@

Error formatting macro: contentbylabel: com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not parse cql : null

Hibernate-Core is a Tapestry module that provides basic Hibernate support without dependencies on the Tapestry-core (the web framework part of Tapestry).

Core Hibernate Support

This library contains basic Hibernate support package without dependencies on the Tapestry-core (the web framework part of Tapestry); it only requires the Tapestry IoC module. This makes it useful in non-web applications, such as back-end processing.

The Tapestry-hibernate module extends this further, adding features to support the creation of CRUD (Create/Read/Update/Delete) database applications in Tapestry.

Licensing Issues

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.

This library is compiled against version 3.3.1.GA of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work with more recent versions.

+ + +

+ +

+
+ Page:
+ +
+ Using Tapestry With Hibernate + + +
+
+
+ Page:
+ +
+ Hibernate Support FAQ + + +
+
+
+ Page:
+ +
+ Hibernate + + +
+
+
+ Page:
+ +
+ Hibernate Statistics + + +
+
+
+ Page:
+ +
+ Hibernate User Guide + + +
+
+
+ Page:
+ +
+ Hibernate - Core + + +
+
+
+ Page:
+ +
+ Hibernate - Core - Conf + + +
+

This module only requires the Tapestry IoC module. This makes it useful in non-web applications, such as back-end processing.

The Tapestry-hibernate module extends this further, adding features to support the creation of CRUD (Create/Read/Update/Delete) database applications in Tapestry.

Licensing Issues

This library is compiled against version 3.3.1.GA of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work with more recent versions.

Modified: websites/production/tapestry/content/hibernate.html ============================================================================== --- websites/production/tapestry/content/hibernate.html (original) +++ websites/production/tapestry/content/hibernate.html Sun Jul 26 22:19:48 2015 @@ -27,16 +27,6 @@ - - - - - - - @@ -67,8 +57,82 @@

Error formatting macro: contentbylabel: com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not parse cql : null

The Tapestry-Hibernate Integration Library provides out-of-the-box support for using Hibernate 3 as the back end for normal CRUD style Tapestry applications.

This represents access to the native Hibernate interfaces, exposed in a thread-safe manner, within a session-per-request strategy.

Note that a number of the more esoteric ideas in Hibernate are not supported, including nested transactions and supporting multiple persistence units.

The tapestry-hibernate-core module allows non-Tapestry applications to access Hibernate.

Licensing Issues

Hibernate is licensed under the Lesser GNU Public License. This is more restrictive license than the Apache Software L icense 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.

This library is compiled against version 3.3.1.GA of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work with more recent versions.

Notes

Transactions are aborted (not committed) at the end of each request: you must explicitly commit the transaction if changes are to be saved.
The CommitAfter annotation for component and service methods can commit the transaction automatically after the method is invoked.
HibernateGridDataSource can be used with the Grid component to support optimized queries against large data sets.

The Tapestry-Hibernate Integration Library provides out-of-the-box support for using Hibernate 3 as the back end for normal CRUD style Tapestry applications.

+ + + + + + + + +

+ +

+
+ Page:
+ +
+ Using Tapestry With Hibernate + + +
+
+
+ Page:
+ +
+ Hibernate Support FAQ + + +
+
+
+ Page:
+ +
+ Hibernate + + +
+
+
+ Page:
+ +
+ Hibernate Statistics + + +
+
+
+ Page:
+ +
+ Hibernate User Guide + + +
+
+
+ Page:
+ +
+ Hibernate - Core + + +
+
+
+ Page:
+ +
+ Hibernate - Core - Conf + + +
+

This represents access to the native Hibernate interfaces, exposed in a thread-safe manner, within a session-per-request strategy.

Note that a number of the more esoteric ideas in Hibernate are not supported, including nested transactions and supporting multiple persistence units.

The tapestry-hibernate-core module allows non-Tapestry applications to access Hibernate.

Licensing Issues

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.

This library is compiled against version 3.3.1.GA of Hibernate (and version 3.4.0.GA of hibernate-annotations), but should work with more recent versions.

Notes

Transactions are aborted (not committed) at the end of each request: you must explicitly commit the transaction if changes are to be saved.
The CommitAfter annotation for component and service methods can commit the transaction automatically after the method is invoked.
HibernateGridDataSource can be used with the Grid component to support optimized queries against large data sets.

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 Jul 26 22:19:48 2015 @@ -62,13 +62,51 @@

- Apache Tapestry > Documentation > User Guide > IoC > Injection in Detail + Apache Tapestry > Documentation > User Guide > IOC > Injection in Detail edit

Injection in Detail

Error formatting macro: contentbylabel: com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not parse cql : null

Injection in Tapestry IoC can be a complicated subject for a number of reasons:

Injection can occur in many places: on fields, and on parameters to methods and constructors of certain objects.
Parts of Injection are themselves defined in terms of Tapestry IoC services, many of which are extensible.

Despite this, injection generally Just Works: most of the time, you want Tapestry to inject a service, and only a single service implements the service interface.

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.

Some aspects of this discussion reflect Tapestry IoC used within a Tapestry web application: the tapestry-core module makes some extensions to inj ection.

Injection Triggers

Injection is triggered in a number of ways:

A field in a component class, autobuilt object, or service implementation class is annotated with @Inject.
A method parameter to a service builder method, a decorator method, or a contribute method (in a Tapestry IoC module class).
A constructor parameter to an autobuilt object, or a service implementation class.
Any of the above with an @InjectService annotation.

These define the point of injection.

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.

Standard Injection Processing

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.

So a the point of injection, Tapestry has identified a field or parameter that should be injected. At this point, Tapestry knows the following:

The field name (if field injection). The parameter name is not available.
The field or parameter type, as a Java class. In many cases, this will be enough to identify what object shall be injected.
Any additional annotations on the field or parameter.

Tapestry proceeds with this information.

Check for @InjectService

Tapestry checks first for the @InjectService annotation. The value of this annotation is the service id to inject. When @InjectService is present at t he 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.

Check for service resources

This step applies only to IoC layer injection (not to injection into components).

When the @Inject annotation is not present 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.

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).

org.slf4j.Logger – The Logger of the service being constructed (or the logger of the Module class being instantiated).
ObjectLocator – For contribute methods, used to locate additional objects.
ServiceResources – For service builder methods, an extended version of ObjectLocator.
Class – The service interface type.
OperationTracker – Used to track deeply nested operations so that errors can be reported sensibly.
Object, or service interface type – Passed to decorator methods.
Collection, List, Map – Assembled service configurations passed to service builder methods (or service class constructors).
Configuration, OrderedConfiguration, MappedConfi guration – Configuration passed to contribute methods, to build service configurations.

If field type does not match any of the available resource types, or the Inject annotation is present, logic continues to the next step.
Injection of resources into fields is triggered by the presence of the @InjectResource annotation, whereas injection of resources into parameters occurs when the Inject or InjectService annotation is not present. These rules are slightly tricky, which reflects a desire to avoid any annot ations except when needed, and the fact that field injection came much later than parameter injection.

Service Lookup by Type and Annotations

Tapestry attempts to find a matching service.

First, it generates a set of services whose service interface is compatible with the injection type. This is based on assignability.

If the @Local annotation is present, then services not from the module containing the service being constructed will be eliminated.

Tapestry then works through the known marker annotations. For each marker annotation that is present at the point of injection, Tapestry eliminates services which do not have the marker. Thus, if multiple marker annotations are present, the final service must have all of them.

At the end, of this, Tapestry determines how many services match.

If there is a single matching service, then the service to inject as been identified.
If there are no matches, and there were no marker annotations at the point of injection, then the Tapestry continues to the next step.
Otherwise there were either no matches, or too many matches: Tapestry will throw a RuntimeException.

MasterObjectProvider Lookup

This is the point at which Tapestry's extensibility comes into play. MasterObjectProvider is a service, with a configuration of ObjectProviders.

The MasterObjectProvider is also the point at which Tapestry's IoC layer injection, and Tapestry's component injection, unite.

As a chain-of-command, each of the following ObjectProviders will be considered and will attempt to identify the object to be injected.

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 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 TypeCoercer service is used by several ObjectProvider implementations, so the same restrictions apply to TypeCoercer service contributions.

Value ObjectProvider

Checks for the presence of the @Value 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).

Symbol ObjectProvider

Similar to the Value ObjectProvider: the @Symbol annotation's value (if present) is looked up using the SymbolSource service, and converted to the injection type via the TypeCoercer servi ce.

Autobuild ObjectProvider

Checks to see if the @Autobuild annotation is present and, if so, autobuilds the value for the parameter. Of course, the object being built will itself be configured via injection.

ServiceOverride ObjectProvider

Checks any contributions to the ServiceOverride 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.

Alias ObjectProvider (tapestry-core)

Uses the A lias service (API) to look for an object that can be injected.

Deprecated in Tapestry 5.2 and removed in 5.4.

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.

Asset ObjectProvider (tapestry-core)

Checks for the @Path annotation.

If present, the annotation's value has embedded symbols expanded, and is converted into an Asset (which must exist).

The TypeCoercer can then convert the Asset to the injection type, for example, as Resource.

Service ObjectProvider (tapestry-core)

Looks for the @Service annotation; if present, the annotation's value is the exact service id to inject. This is necessary because injections into component fields are always triggered by the Inject annotation.

This is supported but no longer necessary, as the @InjectService annotation is now also supported for component fields.< /p>

SpringBean ObjectProvider (tapestry-spring)

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).

Service Lookup

If none of the ObjectProviders can identify the value to inject, a last step occurs: lookup by service type. If exactly one service matches the injection type, then that service is injected.

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).

Post-Injection Methods

Autobuilt objects (services and the like, but not components) may have post-injection methods.

Any public method may have the @PostInjection annotation.

Such methods are invoked after constructor and/or field injection. Only public methods will be invoked. Any return value is ignored.

The method often takes no parameters; however if the method has parameters, these parameters are new points of injection.

Often this is used to perform additional setup, such as registerring a service as a listener of events produced by another service:

Injection in Tapestry IoC can be a complicated subject for a number of reasons:

Injection can occur in many places: on fields, and on parameters to methods and constructors of certain objects.
Parts of Injection are themselves defined in terms of Tapestry IoC services, many of which are extensible.

+ + + + + + + + +

+ +

+
+ Page:
+ +
+ Injection in Detail + + +
+
+
+ Page:
+ +
+ Injection FAQ + + +
+
+
+ Page:
+ +
+ Injection + + +
+

Despite this, injection generally Just Works: most of the time, you want Tapestry to inject a service, and only a single service implements the service interface.

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.

Some aspects of this discussion reflect Tapestry IoC used within a Tapestry web application: the tapestry-core module makes some extensions to injection.

Injection Triggers

Injection is triggered in a number of ways:

A field in a component class, autobuilt object, or service implementation class is annotated with @Inject.
A method parameter to a service builder method, a decorator method, or a contribute method (in a Tapestry IoC module class).
A constructor parameter to an autobuilt object, or a service implementation class.
Any of the above with an @InjectService ann otation.

These define the point of injection.

Standard Injection Processing

So a the point of injection, Tapestry has identified a field or parameter that should be injected. At this point, Tapestry knows the following:

The field name (if field injection). The parameter name is not available.
The field or parameter type, as a Java class. In many cases, this will be enough to identify what object shall be injected.
Any additional annotations on the field or parameter.

Tapestry proceeds with this information.

Check for @InjectService

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.

Check for service resources

This step applies only to IoC layer injection (not to injection into components).

When the @Inject annotation is not present at the point of injection, Tapestry checks to see if a resource can be in jected. Services are global values, but resources are specific to the service under construction.

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).

org.slf4j.Logger – The Logger of the service being constructed (or the logger of the Module class being instantiated).
ObjectLocator – For contribute methods, used to locate additional objects.
ServiceResources – For service builder methods, an extended version of ObjectLocator.
Class – The service interface type.
OperationTracker – Used to track deeply nested operations so that errors can be reported sensibly.
Object, or service interface type – Passed to decorator methods.
Collection, List, Map – Assembled service configurations passed to service builder methods (or service class constructors).
Configuration, OrderedConfiguration, MappedConfiguration – Configuration passed to contribute methods, to build service configurations.

If field type does not match any of the available resource types, or the Inject annotation is present, logic continues to the next step.
Injection of resources into fields is triggered by the presence of the @InjectResource annotation, whereas injection of resources into parameters occurs when the Inject or InjectService annotation is not 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.

Service Lookup by Type and Annotations

Tapestry attempts to find a matching service.

First, it generates a set of services whose service interface is compatible with the injection type. This is based on assignability.

If the @Local annotation is present, then services not from the module containing the service being constructed will be eliminated.

At the end, of this, Tapestry determines how many services match.

If there is a single matching service, then the service to inject as been identified.
If there are no matches, and there were no marker annotations at the point of injection, then the Tapestry continues to the next step.
Otherwise there were either no matches, or too many matches: Tapestry will throw a RuntimeException.

MasterObjectProvider Lo okup

This is the point at which Tapestry's extensibility comes into play. MasterObjectProvider is a service, with a configuration of ObjectProviders.

The MasterObjectProvider is also the point at which Tapestry's IoC layer injection, and Tapestry's component injection, unite.

As a chain-of-command, each of the following ObjectProviders will be considered and will attempt to identify the object to be injected.

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 resolva ble using only the early stages of the injection process, 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 TypeCoercer service is used by several ObjectProvider implementations, so the same restrictions apply to TypeCoercer service contributions.

Value ObjectProvider

Symbol ObjectProvider

Similar to the Value ObjectProvider: the @Symbol annotation's value (if present) is looked up using the SymbolSource service, and converted to the injection type via the TypeCoercer service.

Autobuild ObjectProvider

Checks to see if the @Autobuild annotation is present and, if so, autobuilds the value for the parameter. Of course, the object being built will itself be configured via injection.

ServiceOverride ObjectProvider

Alias ObjectProvider (tapestry-core)

Uses the Alias service (API) to look for an object that can be injected.

Deprecated in Tapestry 5.2 and removed in 5.4.

This is commonly used to ove rride 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.

Asset ObjectProvider (tapestry-core)

Checks for the @Path annotation.

If present, the annotation's value has embedded symbols expanded, and is converted into an Asset (which must exist).

The TypeCoercer can then convert the Asset to the injection type, for example, as Resource.

Service ObjectProvider (tapestry-core)

This is supported but no longer necessary, as the @InjectService annotation is now also supported for component fields.

SpringBean ObjectProvider (tapestry-spring)

Service Lookup

If none of the ObjectProviders can identify the value to inject, a last step occurs: lookup by service type. If exactly one service matches the injection type, then that service is injected.

Post-Injection Methods

Autobuilt objects (services and the like, but not components) may have post-injection methods.

Any public method may have the @PostInjection annotation.

Such methods are invoked after constructor and/or field injection. Only public methods will be invoked. Any return value is ignored .

The method often takes no parameters; however if the method has parameters, these parameters are new points of injection.

Often this is used to perform additional setup, such as registerring a service as a listener of events produced by another service:

public class MyServiceImpl implements MyService, UpdateListener
 {
   @PostInjection

Modified: websites/production/tapestry/content/integrating-with-spring-framework.html
==============================================================================
--- websites/production/tapestry/content/integrating-with-spring-framework.html (original)
+++ websites/production/tapestry/content/integrating-with-spring-framework.html Sun Jul 26 22:19:48 2015
@@ -32,7 +32,6 @@
   
   
   
-