You don't need the MapConfigService, you can use a serviceId (or a marker
annotation) to disambiguate your HazelcastConfigurer instances.
// serviceId = "mapConfigHazelcastConfigurer"
public HazelcastConfigurer buildMapConfigHazelcastConfigurer(final
Collection mapConfigs) {
return new Hazelcas
Thank you,
In my case, MapConfig contributions can be reduced to HazelcastConfigurer
contributions (and now I see I should have used the latter from the start)
so (to avoid many refactorings) I created another service that converts
MapConfig contributions to a HazelcastConfigurer.
public class Ma
There's a huge complexity cost for allowing a single service to expose
multiple configurations, and its rare to need. Often, a solution that
breaks the single service into two (or more) services, even if just to
support the constraint of a single configuration, leads to better, more
testable code a
Yes, this is a limitation of tapestry contributions. This can be worked
around.
Create a MapConfigProvider service which has a getter for the MapConfig
collection. Contribute MapConfig objects to the MapConfigProvider.
Then pass the MapConfigProvider and the second collection to your
HazelcastCon
Hello,
I would like to contribute 2 collections to a service, but I am afraid
Tapestry only supports one collection to be contributed. Am I right?
My service constructor is like this:
public HazelcastConfigServiceImpl(
final Collection mapConfigs,
final Collection hzConfigurers) { ... }
And I
