The auto-wiring code adds bindings for implicit (non-local) injected dependencies by introspecting injection sites and using that information to generate bindings at runtime. At the moment it assumes such bindings are unscoped, but some components might want to inject a dependency using a specific scope (such as per-request or per-session).
Changing the dependency analyzer to look for scope annotations on the injection site is trivial, the main issue is that a lot of scope annotations (such as the existing Guice ones) can only be placed on types, not individual members - one solution would be to mark the component itself with the scope, and then apply that to any of its dependencies. Another thing to watch out for is when the same dependency is used in conflicting scopes. This is of particular concern when you want to scope a configuration value where the raw type is not under your control and value is used in many places.
In fact the best solution might actually be to solve this use-case another way and avoid auto-wiring scoped bindings. For example, currently users can inject Providers to get per-lookup instances and then manage the values themselves.
This issue was created automatically with bugzilla2github
Bugzilla Bug 386431
Date: 2012-08-01 18:34:59 -0400 From: Stuart McCulloch <mcculls@gmail.com> To: Project Inbox <sisu-inbox@eclipse.org>
See also: https://issues.sonatype.org/browse/SISU-3 Last updated: 2013-07-16 21:17:03 -0400
Comment 2144108
Date: 2012-08-01 18:34:59 -0400 From: Stuart McCulloch <mcculls@gmail.com>
Migrated from https://issues.sonatype.org/browse/SISU-3
The auto-wiring code adds bindings for implicit (non-local) injected dependencies by introspecting injection sites and using that information to generate bindings at runtime. At the moment it assumes such bindings are unscoped, but some components might want to inject a dependency using a specific scope (such as per-request or per-session).
Changing the dependency analyzer to look for scope annotations on the injection site is trivial, the main issue is that a lot of scope annotations (such as the existing Guice ones) can only be placed on types, not individual members - one solution would be to mark the component itself with the scope, and then apply that to any of its dependencies. Another thing to watch out for is when the same dependency is used in conflicting scopes. This is of particular concern when you want to scope a configuration value where the raw type is not under your control and value is used in many places.
In fact the best solution might actually be to solve this use-case another way and avoid auto-wiring scoped bindings. For example, currently users can inject Providers to get per-lookup instances and then manage the values themselves.