This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • ShadowBuilder Service

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Scrollbar

The ShadowBuilder service (see the PropertyShadowBuilder API) is used to build a special, delegating kind of service implementation that, essentially, allows a property of another service to be exposed as its own service.

Div
stylefloat:right
titleRelated Articles
classaui-label
Content by Label
showLabelsfalse
showSpacefalse
titleRelated Articles
cqllabel = "service-builders" and space = currentSpace()

For example, the tapestry-core module provides a Request property as a shadow of the RequestGlobals service's request property:

Code Block
java
java
public Request build()
{
  return shadowBuilder.build(requestGlobals, "request", Request.class);
}

(shadowBuilder and requestGlobals are injected into the module class instance)

This can be thought of as similar to:

Code Block
java
java
public Request build()
{
  return requestGlobals.getRequest();
}

However there is a critical difference between the two: a shadow property is re-evaluated on each method invocation. In the former case, the Request service will always obtain the current value of the request property from the per-thread RequestGlobals service. The second example is more than likely broken, since it will expose whatever value is in the request property of the RequestGlobals at the time the Request service implementation is realized.

Notice that in this example, the Request service is a normal singleton. This service can be freely injected into any service throughout the framework or application. Invoking methods on this service will always delegate to the current thread's request. Callers don't have to be aware of this internal delegation; it just happens.

Non-Reflective

When the shadow is created, reflection is used to translate the property name to a method name. This information is used to build a new class (at runtime) that is instantiated as the service implementation.

A typical method is implemented as (approximately):

Code Block
java
java
private final RequestGlobals source;

public String getParameter(String name)
{
  return source.getRequest().getParameter(name);
}

That is, the shadow implementation holds onto the target object (in the above example, the RequestGlobals service) and invokes a method on it directly, not using reflection, no differently than you would if you wrote the code yourself.

 

Scrollbar