tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: T5.2 ClassTransformation : why deprecate & throw an exception
Date Mon, 10 May 2010 21:41:21 GMT
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 <akochnev@gmail.com> 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 <hlship@gmail.com> 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
>> <akochnev@troymaxventures.com> 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 <hlship@gmail.com
>> >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
>> >> <akochnev@troymaxventures.com> 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
>> >> > <akochnev@troymaxventures.com>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: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>



-- 
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message