So decoration isn't on its way out? Thought I read someting about it here
recently.
After a while, I got familiar with the concept of decoration, and now I
quite like it. As Howard says, I use it when I want to change the behaviour
of a specific known service. I just did such a change using advice because I
thought I wasn't supposed to use decoration anymore. I instantly reacted
negatively to the overly complex matching of method names that is far less
elegant than decoration in these cases. See my code sample below, a small
mod of the ClassNameLocator mentioned on the list earlier. I see several
weaknesses:
- Not refactoring safe (string matching of service name and method name)
- SuppressWarnings because of need to cast result of invocation.
- Catch and rethrow exception
- Requires plumbing code for handling of exception thrown in invocation
@SuppressWarnings("unchecked")
@Match("ClassNameLocator")
public static void
adviseClassNameLocatorForDuplicateClasses(MethodAdviceReceiver receiver) {
MethodAdvice advice = new MethodAdvice() {
public void advise(Invocation invocation) {
invocation.proceed();
Collection<String> classNames = (Collection<String>)
invocation.getResult();
Set<String> newClassNames = CollectionFactory.newSet();
for (String className : classNames) {
// Ensure uniqueness of class name by using set.
newClassNames.add(className);
}
invocation.overrideResult(newClassNames);
}
};
try {
Method m = receiver.getInterface().getMethod("locateClassNames",
String.class);
receiver.adviseMethod(m, advice);
}
catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
}
On Mon, Aug 9, 2010 at 10:41 PM, Howard Lewis Ship <[email protected]> wrote:
> When I see advise code that is looking for specific names of methods
> or casting parameters to specific types ... that's a case where it
> should be a decorator, not advice. Advice is meant for cases that are
> distinguished independent of those factors, typically by a method (or
> parameter) annotation.
>
> On Mon, Aug 9, 2010 at 1:33 PM, Igor Drobiazko <[email protected]>
> wrote:
> > I didn't use decorate methods for a while. I'm using advise methods and
> have
> > the feeling that advise methods are the equivalent subsitute for decorate
> > methods. Also documentation is telling that decorate methods have been
> > replaced by advise methods. But it looks like they still are needed.
> >
> > On Mon, Aug 9, 2010 at 10:15 PM, Howard Lewis Ship <[email protected]>
> wrote:
> >
> >> What's the replacement for decoration methods? Service advice methods
> >> are close, but fill a different niche (i..e, when the service
> >> interface isn't known). I use decorate methods now when I'm changing
> >> the behavior of a known service (i.e., I know the service interface at
> >> build time), and advice methods for more general work (usually driven
> >> by annotations, and in an interface agnostic manner).
> >>
> >> On Mon, Aug 9, 2010 at 12:44 PM, Igor Drobiazko
> >> <[email protected]> wrote:
> >> > Hi all,
> >> >
> >> > I'm going to fix the https://issues.apache.org/jira/browse/TAP5-1232by
> >> > reintroducing the injection of service ids into decorate methods in
> order
> >> > too make upgrade to 5.2 easier. The fix will affect only decorate
> >> methods.
> >> > Furthermore I would like to deprecate decorate methods by writing a
> note
> >> in
> >> > the documentation and logging a message at info level. Starting from
> 5.3
> >> I
> >> > would remove the decorate methods.
> >> >
> >> > Any objections?
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > Igor Drobiazko
> >> > http://tapestry5.de
> >> >
> >>
> >>
> >>
> >> --
> >> 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]
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
>
>
> --
> 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]
>
>
