Stripping away qualified service ids (from T4/HiveMind) was one of the simplifications that came with Tapestry.
Finding a way to deal with naming conflicts now is going to pose a bit of a challenge. We're we are headed is something more like Guice, where there is no concept of a service id: just service interfaces and marker annotations (to deal with ambiguities). On Wed, Oct 20, 2010 at 3:14 AM, Inge Solvoll <[email protected]> wrote: > Some time ago, we had to change the id of one of our Spring beans. Reason: > chenillekit registers a service named "configurationService", which was the > name of our internal service as well. > > This is a good example of a slightly polluted namespace, you can't name your > service logically according to the company's naming rules, causing our > spring/hibernate guys to say: "This rigid tapestry thing is causing too much > pain..." > > The most obvious solution to this problem is to promote a coding standard > where you prefix the service id with your namespace, like > "ck:configurationService". But since most services are registered with > automatically generated id, that seems unlikely to happen. > > The more involved solution would be to (optionally maybe) generate all > service ids prefixed by the module name. Or perhaps generate prefix only for > those services that have a name collision. An optional prefix (configuration > based) would mean that libraries like chenillekit and tynamo could use that, > while applications could skip that part. > > Do you guys consider this to be an important issue, or is it an edge case? > > Regards > Inge > -- 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]
