I wish I had the level of insight into AOP in the context of Tapestry back in 2005-2006 that I have now.
On Sun, May 9, 2010 at 6:57 PM, Alex Kotchnev <[email protected]> wrote: > Nevermind on the pointers regarding the ClassTransformation API, I think I > got it. Once I figured out the couple of classes involved, it was very > straightforward. > > Howard, nice work on the new API, much more readable and cleaner than > before ! I think it will also be easier to debug too, since you'll be able to set breakpoints inside the various callback objects rather than vainly seek out dynamically generated code. > > Regards, > > Alex Kotchnev > > On Sun, May 9, 2010 at 7:36 PM, Alex Kotchnev > <[email protected]>wrote: > >> I've been looking into the new ClassTransformation API and I'm a bit >> puzzled about why a whole bunch of methods are deprecated and are made to >> throw an exception. I guess if any code depends on those methods, it will >> compile (w/ deprecation warnings) but will throw up at runtime. So, I'm a >> bit puzzled why that's the case. If the intent is to keep just a little bit >> of backward compatibility, then it seems likely that the methods shouldn't >> throw an exception. If the goal is to replace those methods w/ something >> else, why not just remove them so any code that depends on them just doesn't >> compile. >> >> On a separate note, any pointers (beyond the javadoc and Howard's blog >> posts) on how to replace the old usage w/ the new usage would be highly >> appreciated. I'll probably dive into 5.2 to see some examples, but anything >> extra would be great. >> >> Regards, >> >> Alex K >> > -- 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]
