You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Alex Kotchnev <ak...@troymaxventures.com> on 2010/05/10 01:36:16 UTC
T5.2 ClassTransformation : why deprecate & throw an exception
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
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Pierce Wetter <pi...@paceap.com>.
There already is one:
https://issues.apache.org/jira/browse/TAP5-1138
Feel free to edit/comment on it.
--
View this message in context: http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5038401.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@gmail.com>.
Howard, should I file a defect to remove the methods that don't work?
On May 10, 2010 6:27 PM, "Pierce Wetter" <pi...@paceap.com> wrote:
Howard Lewis Ship wrote:
>
> I'd be just as happy to outright remove the methods as to keep them
...
Well, except the exception report points you at TransformMethod#extend
which doesn't exist! You should at least point to addAdvice, ideally with a
note that the code needs to be restructured.
--
View this message in context:
http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5033342.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-u...
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Pierce Wetter <pi...@paceap.com>.
Howard Lewis Ship wrote:
>
> 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.
>
Well, except the exception report points you at TransformMethod#extend
which doesn't exist! You should at least point to addAdvice, ideally with a
note that the code needs to be restructured.
--
View this message in context: http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5033342.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ak...@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 <hl...@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
>> <ak...@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
>> >> <ak...@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
>> >> > <ak...@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
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@gmail.com>.
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 <hl...@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
> <ak...@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
> >> <ak...@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
> >> > <ak...@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
>
>
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ak...@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 <hl...@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
>> <ak...@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
>> > <ak...@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
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@troymaxventures.com>.
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 <hl...@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
> <ak...@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
> > <ak...@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
>
>
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ak...@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
> <ak...@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
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@gmail.com>.
I was waiting to hear from one of the original developers (Robin) after he
gets a chance to take a look at my changes before deciding what to do / when
to release stuff. I think that all changes w/o the ClassTransformation fixes
might make a nice Spring 3 + T5.1 compatible release, whereas the ones w/
the ClassTransormation changes would make a nice Spring 3 + T5.2 bundle.
Anyway, it's good to hear that it works for you. I can't say I've grokked
the whole codebase yet; the migration (w/ the exception of
ClassTransformation) was mostly an exercise in tracking down the newly
repackaged & renamed classes from Spring Security 2 to S-S 3. Thus, I was
concerned that I might have missed something un-obvious.
Do you want to send me a patch (or just the POM file) w/ the updated pom so
that I don't have to duplicate your effort ?
Regards,
Alex Kotchnev
On Mon, May 10, 2010 at 6:09 PM, Pierce Wetter <pi...@paceap.com> wrote:
>
>
> On May 10, 2010, at 1:39 PM, akochnev [via Tapestry Developers] wrote:
>
> > Pierce,
> > I just committed the changes to tapestry-spring-security to support
> > spring-security 3.0.2 (and spring 3.0.2) and work w/ the latest T5.2
> > snapshots . The changes are in the T-s-s SVN trunk since yesterday. The
> > rewrite of T-s-s is exactly the reason for my questions on this topic.
> >
> > I haven't removed the extra private fields that the old code used to
> > create, but you're right - they're probably expendable.
>
> Oh, cool. Doing a source compare....
>
> Yeah, you mostly replicated what I did.
>
> The pom.xml checked in is still out of date. I made the following
> changes:
>
> 1. I updated the various version numbers in the properties.
>
> 2. I pointed the repositories at the EBR stuff mentioned on spring
> source.
>
> Hey! It worked!
>
> Are you going to put a 3.0.0-SNAPSHOT up?
>
> Pierce
>
>
> --
> View this message in context:
> http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5033289.html
> Sent from the Tapestry Developers mailing list archive at Nabble.com.
>
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Pierce Wetter <pi...@paceap.com>.
On May 10, 2010, at 1:39 PM, akochnev [via Tapestry Developers] wrote:
> Pierce,
> I just committed the changes to tapestry-spring-security to support
> spring-security 3.0.2 (and spring 3.0.2) and work w/ the latest T5.2
> snapshots . The changes are in the T-s-s SVN trunk since yesterday. The
> rewrite of T-s-s is exactly the reason for my questions on this topic.
>
> I haven't removed the extra private fields that the old code used to
> create, but you're right - they're probably expendable.
Oh, cool. Doing a source compare....
Yeah, you mostly replicated what I did.
The pom.xml checked in is still out of date. I made the following changes:
1. I updated the various version numbers in the properties.
2. I pointed the repositories at the EBR stuff mentioned on spring source.
Hey! It worked!
Are you going to put a 3.0.0-SNAPSHOT up?
Pierce
--
View this message in context: http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5033289.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@gmail.com>.
Pierce,
I just committed the changes to tapestry-spring-security to support
spring-security 3.0.2 (and spring 3.0.2) and work w/ the latest T5.2
snapshots . The changes are in the T-s-s SVN trunk since yesterday. The
rewrite of T-s-s is exactly the reason for my questions on this topic.
I haven't removed the extra private fields that the old code used to
create, but you're right - they're probably expendable.
Regards,
Alex K
On Mon, May 10, 2010 at 3:16 PM, Pierce Wetter <pi...@paceap.com> wrote:
>
> Yeah, I ran into this as well trying to port the tapestry-spring-security
> code, which uses extendMethod with 5.1.
>
> Also, the javadoc for 5.2 points you a TransformMethod#extend, which
> doesn't
> exist (filed an issue).
>
> At the very least it should point you to TransformMethod#addAdvice, but it
> really needs to point you to a document, because the new architecture the
> idiom to rely on inner classes and such.
>
> That is, the tapestry-string-security code has a worker that adds fields to
> a page, and then adds code to BeginRender and CleanupRender to lookup
> values
> in those fields in order to make a call:
>
> _$token = _$checker.checkBefore("${configField}");
>
> With the new method, adding the fields may not be necessary, because the
> advice can just cache them directly.
>
> (I think. tapestry-spring-security is not my code, so I'm trying to figure
> out how to rewrite it without knowing exactly what it's trying to do).
>
> So I dunno about the "never mind" on the pointers, I wasted a few hours
> trying to figure this out.
>
> Pierce
> --
> View this message in context:
> http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5032409.html
> Sent from the Tapestry Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Pierce Wetter <pi...@paceap.com>.
Yeah, I ran into this as well trying to port the tapestry-spring-security
code, which uses extendMethod with 5.1.
Also, the javadoc for 5.2 points you a TransformMethod#extend, which doesn't
exist (filed an issue).
At the very least it should point you to TransformMethod#addAdvice, but it
really needs to point you to a document, because the new architecture the
idiom to rely on inner classes and such.
That is, the tapestry-string-security code has a worker that adds fields to
a page, and then adds code to BeginRender and CleanupRender to lookup values
in those fields in order to make a call:
_$token = _$checker.checkBefore("${configField}");
With the new method, adding the fields may not be necessary, because the
advice can just cache them directly.
(I think. tapestry-spring-security is not my code, so I'm trying to figure
out how to rewrite it without knowing exactly what it's trying to do).
So I dunno about the "never mind" on the pointers, I wasted a few hours
trying to figure this out.
Pierce
--
View this message in context: http://tapestry-developers.221625.n2.nabble.com/T5-2-ClassTransformation-why-deprecate-throw-an-exception-tp5028206p5032409.html
Sent from the Tapestry Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5.2 ClassTransformation : why deprecate & throw an exception
Posted by Alex Kotchnev <ak...@troymaxventures.com>.
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 !
Regards,
Alex Kotchnev
On Sun, May 9, 2010 at 7:36 PM, Alex Kotchnev
<ak...@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
>