I'd be just as happy to outright remove the methods as to keep them around as non-functional. Again, what we'll see is that 5.1 compatible code will not even load correctly, due to the references to (now) non-existend methods on ClassTransformation. As currently implemented, the code will load and a more understandable exception report will be generated.
On Mon, May 10, 2010 at 1:46 PM, Alex Kotchnev <[email protected]> wrote: > Howard, > I guess this was my point exactly : it seems to me "deprecated" code is > one that still works (maybe not perfectly ), but is not recommended for > future usage. If the "old" methods have no way to reasonably to continue to > work (e.g. possibly w/ the old behavior), then in my opinion they should be > removed, instead of being marked as deprecated. I'm not advocating to try to > reconstruct the old methods and try to make them work in a weird way, > despite the fact that the 5.2 design has moved on. > > I guess the question is which approach is more useful: to have an > explanatory exception at runtime if someone was mixing pre-5.2 and 5.2 > compiled code vs pre-5.2 code being more upfront about the > incompatibilities at compile time. > > I'd personally prefer not having the old methods around. > > Regards, > > Alex K > > On Mon, May 10, 2010 at 4:30 PM, Howard Lewis Ship <[email protected]> wrote: > >> It just comes down to the inability of the old and new methods for >> instrumenting component classes to work together. If I could find a >> way to make the old code work correctly alongside the new code, I >> would. To be honest, I don't remember perfectly what the problems >> were, I think it was ambiguities in terms of where fields referenced >> inside added methods (added with Javassist pseudo-Java) were >> intercepted or not. There may also have been some conflicts in terms >> of creating a method (from psuedo-Java) and then adding advice to the >> method. >> >> My goal here was to ensure that if some code relied on the old code, >> it would get a useful runtime exception, rather than one of those >> wierd incompatible class exceptions (i.e., where the method signature >> does not exist). >> >> On Mon, May 10, 2010 at 11:49 AM, Alex Kotchnev >> <[email protected]> wrote: >> > Howard, >> > would you comment on the deprecated methods that throw an exception ? I >> > understand the value from a documentation point of view (e.g. you have a >> > place in the javadocs that explicitly says which other method is to be >> > used). However, from a code stand point, code that uses those methods >> will >> > most definitely create a broken app, which seems a bit counter intuitive. >> In >> > a way, although the change doesn't introduce backward incompatibility at >> > compile time (e.g. your code will still compile) , the end result is that >> > the new changes are NOT backward compatible. I'm not sure if this will >> end >> > up as a side note in some release notes doc, but I think it would be much >> > more useful to break some builds than to let the builds pass but not >> behave >> > as expected. >> > >> > Regards, >> > >> > Alex K >> > >> > On Mon, May 10, 2010 at 12:55 PM, Howard Lewis Ship <[email protected] >> >wrote: >> > >> >> 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] >> >> >> >> >> > >> >> >> >> -- >> 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] >> >> > -- 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]
