HiveMind, the predecessor to Tapestry IoC, had private services & visibility. In my opinion, it caused more problems than it was worth.
What I'm hearing is a basic lack of trust between one developer and another within your team. One possible solution there is to work on that, or better documentation about how your services are meant to be used. You can never make things simple by adding complexity. Adding privacy will increase complexity, and add whole new ambiguities ... such as who can see a service in order for it to be advised or decorated. In fact, I wish I had a time machine to tell myself that (there are a number of areas in Tapestry I would prefer to simplify). In terms of your initial problem, the special @Local annotation may be helpful, which limits an injection to just services defined within the same module as the service receiving the injection. On Wed, Mar 28, 2012 at 7:38 AM, fmaylinch <ferranmayli...@gmail.com> wrote: > > Nikla wrote >> >> I guess the suggested @ModulePrivate would be similar [to @Local] but >> controlling >> service exposure scope instead of lookup scope. >> > > Good idea! > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/How-to-define-a-private-service-a-service-only-for-another-service-tp5597443p5600731.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- 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: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
