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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to