Ah, fortunately, not too difficult to find all the marker annotations, once the Registry is constructed.
On Tue, Jul 6, 2010 at 4:58 PM, Howard Lewis Ship <[email protected]> wrote: > Actually, that's part of what I'm doing. You should use @Marker on the > service (i.e., on its service implementation class), but use the > annotations themselves on the contribute methods: > > @Marker(Red.class) > publlic class SomeServiceImpl extends SomeService { ... > > @Contribute(SomeService.class) > @Red @Blue > public void providePurple() { > // Contribute to services which have Color OR Blue > > > Where we are differing is on that last line: should providePurple() be > invoked for SomeServiceImpl (because it has the Red marker) or NOT > (because its missing the Blue marker)? > > > Injection works your way, so should this. That is, if there was an injection: > > �...@inject @Color @Blue private SomeService injectionPoint; > > Then we would match services that are type SomeService and have marker > annotations Color and Blue. > > > Here's the trick: how do you know if an annotation is a marker > annotation or not (as opposed to any other kind of annotation, > including @Match or non-Tapestry specific ones)? I guess that an > annotation is a marker if any service any where makes it a marker. > That's going to require a big set of marker annotations inside > InternalRegistryImpl. > > On Tue, Jul 6, 2010 at 4:10 PM, Robert Zeigler <[email protected]> wrote: >> I just reread the e-mail and realized you were saying the exact opposite... >> that the contributions methods should be the superset of the services... >> whereas I was thinking it made sense for the service's markers to be a >> superset of the contribution's markers. But if you just changed the equals >> to contains all in the code, that would make the code look for the service's >> markers to be a superset of the contribution's markers. Doesn't that make >> more sense? >> >> @Color @Blue >> contributeSomething(...) >> >> >> @Color >> SomeService() >> >> We probably wouldn't want contributeSomething to contribute into >> SomeService, because the additional marker suggests that we are trying to >> contribute more specifically than just @Color. >> >> But if we had: >> >> @Color @Blue >> SomeService >> >> @Color >> contributeSomething() >> >> Then /probably/ contributeSomething should contribute to SomeService. That >> makes the Service's markers a superset of the contribution's markers. >> >> Cheers, >> >> Robert >> >> PS: Yes, I realize my syntax for marking a service is wrong. Consider the >> above pseudocode. :) >> >> On Jul 6, 2010, at 7/65:20 PM , Howard Lewis Ship wrote: >> >>> I'm looking over this code right now, from ModuleImpl: >>> >>> public Set<ContributionDef2> >>> getContributorDefsForService(ServiceDef serviceDef) >>> { >>> Set<ContributionDef2> result = CollectionFactory.newSet(); >>> >>> for (ContributionDef next : moduleDef.getContributionDefs()) >>> { >>> ContributionDef2 def = InternalUtils.toContributionDef2(next); >>> >>> if (serviceDef.getServiceId().equals(def.getServiceId())) >>> { >>> result.add(def); >>> } >>> else >>> { >>> Set<Class> markers = >>> CollectionFactory.newSet(def.getMarkers()); >>> >>> if (markers.contains(Local.class)) >>> { >>> if >>> (moduleDef.getServiceDef(serviceDef.getServiceId()) == null) >>> continue; >>> >>> markers.remove(Local.class); >>> } >>> >>> if (serviceDef.getMarkers().equals(markers) // Why >>> equals() ? >>> && serviceDef.getServiceInterface() == >>> def.getServiceInterface()) >>> { >>> result.add(def); >>> } >>> } >>> } >>> >>> return result; >>> } >>> >>> >>> I think that's an error, comparing the services markers to the >>> contribution methods markers using equals(). I believe that should be >>> containsAll(). As in, the contribution method's annotations are a >>> super-set of the service's marker annotations. >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator of Apache Tapestry >>> >>> The source for Tapestry training, mentoring and support. Contact me to >>> learn how I can get you up and productive in Tapestry fast! >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
