Him
Am 01.09.2015 um 15:57 schrieb Thiago H. de Paula Figueiredo:
Sometimes you have more than one service implementing the same interface
but not actually all of them are intended to be services. Otherwise, you
just need to use ObjectLocator.autobuild() everywhere.
Yes, but I think that's how you're supposed to do it, isn't it? Also,
there's @Autobuild as a shortcut.
Sometimes you have a service defined by an interface and you want another
service which is
defined by a subinterface.
In those cases you can use @Service to select the correct implementation.
It should however be possible to override ServiceInjectionProvider with an
implementation that behaves like that.
Contributing an InjectionProvider would only cover pages, components and
mixins, not injection into services.
You're right. You'd probably have to hook in some layers deeper, but I'm
not entirely sure where.
Isn't @Local usually sufficient for that use case?
Nope, because sometimes the expected default implementation of a service
comes from another module.
@Service should also help in those cases.
I'm not trying to bash the idea, I just want to find out if there's
really a need for the service selection process to be changed.
The idea sounds nice, but I'm afraid that it cause cause things to go
wrong badly and without anyone noticing because we're trying to be
smarter than we should.
Jochen
On Tue, 25 Aug 2015 10:15:45 -0300, Nathan Quirynen (JIRA)
<j...@apache.org> wrote:
Nathan Quirynen created TAP5-2491:
-------------------------------------
Summary: Default marker annotation
Key: TAP5-2491
URL: https://issues.apache.org/jira/browse/TAP5-2491
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.7
Reporter: Nathan Quirynen
Priority: Minor
It would be nice when making use of Marker annotations for tagging a
service, that a default marker value could be defined. So when no
marker annotation is added to the injection of the service this
defined default will be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
