Bad example, actually :) I guess I have to use advice in order to pass the (unknown value at runtime) method parameter on to the original service...
On Mon, Aug 9, 2010 at 11:23 PM, Inge Solvoll <[email protected]>wrote: > 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] >> >> >
