You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> on 2007/10/02 16:51:51 UTC
[jira] Created: (TAPESTRY-1798) Injection via Marker Annotations
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 { }
@MarkedBy(Local.class)
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
[jira] Commented: (TAPESTRY-1798) Injection via Marker Annotations
Posted by "Davor Hrg (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532017 ]
Davor Hrg commented on TAPESTRY-1798:
-------------------------------------
the above example definition for loacal annotation should be
@Retention(RetentionPolicy.RUNTIME) @interface Local{}
framework should warn, or even fail if @Retention(RetentionPolicy.RUNTIME)
is not set for the marker interface.
I've looked at guice and found following:
markers are called binding annotations in guice,
the service binder part is same as tapestry will probably use (different method name: markedBy)...
bind(Service.class)
.annotatedWith(Blue.class)
.to(BlueService.class);
injecting goes like this:
@Inject
void injectService(@Blue Service service)
defining the "marker" interface is bit more complicated...
/**
* Indicates we want the blue version of a binding.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Blue {}
> 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 { }
> @MarkedBy(Local.class)
> 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
[jira] Commented: (TAPESTRY-1798) Injection via Marker Annotations
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533389 ]
Howard M. Lewis Ship commented on TAPESTRY-1798:
------------------------------------------------
Committed the code changes, but won't close the issue until the docs are updated.
> 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
> Assignee: 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 { }
> @MarkedBy(Local.class)
> 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
[jira] Assigned: (TAPESTRY-1798) Injection via Marker Annotations
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAPESTRY-1798:
----------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: 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 { }
> @MarkedBy(Local.class)
> 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
[jira] Closed: (TAPESTRY-1798) Injection via Marker Annotations
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAPESTRY-1798.
------------------------------------------
Resolution: Fixed
Fix Version/s: 5.0.6
> 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
> Assignee: Howard M. Lewis Ship
> Fix For: 5.0.6
>
>
> 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 { }
> @MarkedBy(Local.class)
> 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
[jira] Commented: (TAPESTRY-1798) Injection via Marker Annotations
Posted by "Davor Hrg (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532012 ]
Davor Hrg commented on TAPESTRY-1798:
-------------------------------------
some thoughts....
when we need a specific implementation of a service...
Service binder could add a marker automaticaly,
the marker would be impl class.
service binder can have a method to add additional markers
using impl class as a marker can rise issues I'm nota aware currently...
> 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 { }
> @MarkedBy(Local.class)
> 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