This does get to the nature of "what's public, what's private?" That
is, I can see how we could provide an
@ConfigurationFor("ComponentClassResolver") annotation that would grab
the configuration for some other service, but that leaves me a little
chilled in terms of implementation privacy.
Perha
On Fri, Mar 27, 2009 at 11:31 AM, Ben Gidley wrote:
> Unfortunately in this instance I can't decorate the service and implement
> what I want as it isn't going to be possible to decorate it without access
> to the configuration.
I agree that this is a Tapestry IoC limitation. Please post a JIRA
a
Unfortunately in this instance I can't decorate the service and implement
what I want as it isn't going to be possible to decorate it without access
to the configuration. I have tried using decorate but it doesn't let me get
access to the default implementation's constructor.
The reason this is suc
Hi Ben,
If you want to provide some extensions / overrides some of the logic but keep
the basics in place then I think you might try decorate the service instead.
This page provides some good insight, take a look at the section "Decorating
the RequestExceptionHandler":
http://tapestry.formos.co
