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.
Perhaps Tapestry IoC needs a bonified "override" method prefix for modules?
An easiler solution is to use decoration, and to change the
ComponentClassResolver API to provide the data you need!
On Fri, Mar 27, 2009 at 8:03 AM, Thiago H. de Paula Figueiredo
<thiag...@gmail.com> wrote:
> On Fri, Mar 27, 2009 at 11:31 AM, Ben Gidley <b...@gidley.co.uk> 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
> about this so the committers can do something about it. :)
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
