tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <...@tapestry.apache.org>
Subject [jira] Created: (TAPESTRY-1798) Injection via Marker Annotations
Date Tue, 02 Oct 2007 14:51:51 GMT
Injection via Marker Annotations

                 Key: TAPESTRY-1798
                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1798
             Project: Tapestry
          Issue Type: New Feature
          Components: tapestry-ioc
    Affects Versions: 5.0.5
            Reporter: Howard M. Lewis Ship

Currently in IoC, when injecting a service, you are limited to two options:
- Inject by type, assuming exactly one match
- Inject by explicit service id

In a fully featured system both of these are imperfect.

When you take into account the idea that there will be overrides for built in services, then
you can't rely on their being just a single match.  That's what the Alias service in tapestry-core
is all about: contributing to the MasterObjectProvider to handle overrides. Unfortunately,
contributions to Alias are clumsy, as they have to rely on @InjectService for disambiguation.

Having to know the service id is a problem, since service ids are not refactoring safe: refactoring
the service interface name will likely change the service id, but @InjectService annotation
values will still point to the old name.

Imagine instead a marker annotation; no attributes, attached to a type.  Maybe it's attached
to the service implementation class, maybe its specified to the ServiceBinder.

When injecting, the parameter type and annotations are checked for any known marker annotation
 (all the marker annotation will be identified at Registry start up).  The parameter type
is matched against services with the marker, at must be unique for just those services.

An idiom involving a nested annotation named "Local" is likely, thus:

public class MyModule

  @interface Local { }

  public MyService buildMyService(@Local OtherService other) { ...


I'm fairly certain Guice has something quite similiar.

The question is: can we get rid of service ids entirely?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message