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 anyway.
On Tue, Jun 4, 2013 at 6:53 AM, Lance Java <lance.j...@googlemail.com>wrote: > 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 > HazelcastConfigServiceImpl. > -- 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
