On Wed, 02 Sep 2015 05:43:26 -0300, Jochen Kemnade
<jochen.kemn...@eddyson.de> wrote:
I haven't thought of the case where you cannot change the source of the
class where the service is *injected*. That could be a problem indeed.
You can work with ServiceOverrides but only if only one of the
implementations is already a service.
Yeah.
I don't think adding this is risky exactly because you need to be
deliberate, marking the default service instance with @Primary or,
better> yet, a completely new annotation.
Yes, a new annotation is probably a good idea. @Default?
For explicitness, I'd go for @DefaultServiceImplementation.
But this will only help if you can change the source of the module where
the service is *created*. ;-)
I'm not claiming otherwise. ;) My plan is exactly about the need to be
explicit to define a default service implementation.
But if you pull in multiple modules that bind the same interface with
different implementations and without a service id or marker, you're
probably going to have a problem anyway.
Correct.
I wonder if there's a solution that can address all the possible cases,
and even those where you can change neither the service building nor the
injections. I'm thinking of something like
interface InjectionCandidate<T> {
public Collection<Annotation> getMarkers();
public T getValue();
}
interface InjectionCandidateSelector {
public <T> T selectCandidate(Collection<InjectionCandidate<T>>
candidates);
}
The default implementation would just fail if there is not exactly one
candidate, but you could override it with something like
I'm not sure we can define services which will be used in the code that
handles services themselves. It's too deep inside Tapestry-IoC. The only
way I can think would be Tapestry-IoC looking at a environmental variable
to know which implementation of this interface to use (or a default one if
the variable isn't defined), but I really don't want to have
Tapestry-IoC's core behavior depending on anything from the environment.
if (candidates.size() > 1) {
For me, if there's more than one service implementation of the same
service with @Default(ServiceImplemenation), it's an outright fatal
exception because it's not possible to know with 100% certainty what's the
default one because we have two. I'm just trying to cover one case with
one simple new rule.
return candidates.stream()
.filter((final InjectionCandidate candidate) ->
candidate.getMarkers().contains(Primary.class)).findFirst()
.orElseThrow(RuntimeException::new).getValue();
}
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
