I do need to decorate(not override) it to add extra behaviour for some
cases,
and delegate to orig service for the rest.

I'm currently building a ComponentMesasgeCatalog that can be updated on the
fly,
and also loaded from database (loading from db has it's drawbacks, but I
want it ....)

Davor Hrg

On Dec 5, 2007 11:21 PM, Massimo Lusetti (JIRA) <[email protected]>
wrote:

>
>    [
> https://issues.apache.org/jira/browse/TAPESTRY-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548845]
>
> Massimo Lusetti commented on TAPESTRY-1958:
> -------------------------------------------
>
> Well it's me that didn't get the whole point, now i got more, sorry for
> the noise.
>
> One question, if you need to override the decorated service why you need
> it?
>
> > aditional example for service decorators
> > ----------------------------------------
> >
> >                 Key: TAPESTRY-1958
> >                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1958
> >             Project: Tapestry
> >          Issue Type: Improvement
> >          Components: Documentation, tapestry-ioc
> >    Affects Versions: 5.0.6
> >            Reporter: Davor Hrg
> >             Fix For: 5.0.7
> >
> >
> > documentation for decorating services should have an additional example
> > somethig like this for situations where we are decorating a specific
> service,
> > and not using some general decorator factory
> >     public static ComponentMessagesSource
> decorateComponentMessagesSource(Object delegate, Logger logger){
> >         return new
> ComponentMessagesSourceDecorator((ComponentMessagesSource) delegate,logger);
> >     }
> > this should be documented because the decorator is ignored if above is
> chenged this way
> > (this is somehow more logical than above but doesn't work)
> >     public static ComponentMessagesSource
> decorateComponentMessagesSource(ComponentMessagesSource delegate, Logger
> logger){
> >         return new ComponentMessagesSourceDecorator(delegate,logger);
> >     }
> > I think that the second sample caused exceptions in earlier versions....
> > (the exception was even more misleading)
> > of course, if not too much trouble, tapestry ioc could be modified so
> that the second example works as well
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to