You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Luke Wilson <lu...@viscri.co.uk> on 2012/04/20 18:39:36 UTC
PlasticClass.getMethods() doesn't include introduced methods.
Hi,
The behaviour of the now deprecated ClassTransformation.matchMethods() and related methods has changed to not include introduced Methods. I believe this problem also applies to fields.
On top of this, the built in ClassTransformationWorker2s use PlasticClass.getMethods() directly to find fields.
The sum total of this is that it is impossible to create a method or field in a ClassTransformationWorker/ClassTransformationWorker2 and have it taken into account by subsequent workers. Is this deliberate, or is it a bug? It's causing us headaches in our upgrade to Tapestry 5.3.
More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods.
Kind regards,
Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: PlasticClass.getMethods() doesn't include introduced methods.
Posted by Luke Wilson <lu...@viscri.co.uk>.
On 23 Apr 2012, at 16:50, Howard Lewis Ship wrote:
> Often the introduced methods have privileged access to fields,
> bypassing things like FieldConduits .... often, the introduced methods
> are how the FieldConduits are themselves implemented. Not excluding
> them from the field transformation step (where reads and writes of
> fields are converted into invocations of introduced methods) could
> yield infinite loops reading or writing fields!
I see.
>
> In you situation, you could probably recode you approach using a
> MethodAdvice on the introduced method, and use FieldHandles to
> read/write the values. It will probably be easier than creating the
> necessary bytecode using the changeImplementation().
>
Thanks, I'll take a look at FieldHandles. I already have a pretty ugly fix for RadioGroup not having a defaultValidate method (is this a bug in its own right?).
The other places where this looks like it might affect us are:
1) Creating a render phase method
2) Creating an event handler method - I guess I can fix this with TransformationSupport.addEventHandler(...).
> changeImplementation() exists for the few things that can't be
> addressed that way, and because I like to raise the bar higher in
> terms of efficiency on things inside the framework that will be
> replicated (hundreds of) thousands of times in an application.
+1 to bar-raising!
>
> On Sat, Apr 21, 2012 at 5:12 AM, Luke Wilson-Mawer <lu...@viscri.co.uk> wrote:
>>
>> On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote:
>>
>>> On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson <lu...@viscri.co.uk> wrote:
>>>>
>>>> More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods.
>>>>
>>>
>>> Ah, yes, I can see what you are going there.
>>>
>>> I think, perhaps, PlasticField and PlasticMethod may need a
>>> makeVisible() method that makes the introduced members visible inside
>>> PlasticClass.getMethods() and PlasticClass.getFields(). I don't think
>>> there's a way to extricate things so that member access within the
>>> introduced method is not transformed, but that's probably fine ... in
>>> your case, you want to make sure that the ParameterWorker sees your
>>> defaultValidate() method, and that method will be a stub with advice.
>>
>> What's the reason that introduced methods aren't visible by default like in in the old ClassTransformation? Are there consequences to just adding a line in PlasticClassImpl.createNewMethod() to add the new method onto the end of the methods list? I'm not all too familiar with the Plastic API but I could imagine using it for a whole bunch of things....
>>
>>>
>>>
>>>> Kind regards,
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>> Luke Wilson-Mawer
>> Director, Viscri Limited
>> luke@viscri.co.uk
>>
>> Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR
>> Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX
>> Registered number: 07031070
>>
>>
>>
>
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: PlasticClass.getMethods() doesn't include introduced methods.
Posted by Howard Lewis Ship <hl...@gmail.com>.
Often the introduced methods have privileged access to fields,
bypassing things like FieldConduits .... often, the introduced methods
are how the FieldConduits are themselves implemented. Not excluding
them from the field transformation step (where reads and writes of
fields are converted into invocations of introduced methods) could
yield infinite loops reading or writing fields!
In you situation, you could probably recode you approach using a
MethodAdvice on the introduced method, and use FieldHandles to
read/write the values. It will probably be easier than creating the
necessary bytecode using the changeImplementation().
changeImplementation() exists for the few things that can't be
addressed that way, and because I like to raise the bar higher in
terms of efficiency on things inside the framework that will be
replicated (hundreds of) thousands of times in an application.
On Sat, Apr 21, 2012 at 5:12 AM, Luke Wilson-Mawer <lu...@viscri.co.uk> wrote:
>
> On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote:
>
>> On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson <lu...@viscri.co.uk> wrote:
>>>
>>> More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods.
>>>
>>
>> Ah, yes, I can see what you are going there.
>>
>> I think, perhaps, PlasticField and PlasticMethod may need a
>> makeVisible() method that makes the introduced members visible inside
>> PlasticClass.getMethods() and PlasticClass.getFields(). I don't think
>> there's a way to extricate things so that member access within the
>> introduced method is not transformed, but that's probably fine ... in
>> your case, you want to make sure that the ParameterWorker sees your
>> defaultValidate() method, and that method will be a stub with advice.
>
> What's the reason that introduced methods aren't visible by default like in in the old ClassTransformation? Are there consequences to just adding a line in PlasticClassImpl.createNewMethod() to add the new method onto the end of the methods list? I'm not all too familiar with the Plastic API but I could imagine using it for a whole bunch of things....
>
>>
>>
>>> Kind regards,
>>>
>>> Luke
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> Luke Wilson-Mawer
> Director, Viscri Limited
> luke@viscri.co.uk
>
> Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR
> Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX
> Registered number: 07031070
>
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: PlasticClass.getMethods() doesn't include introduced methods.
Posted by Luke Wilson-Mawer <lu...@viscri.co.uk>.
On 20 Apr 2012, at 19:00, Howard Lewis Ship wrote:
> On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson <lu...@viscri.co.uk> wrote:
>>
>> More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods.
>>
>
> Ah, yes, I can see what you are going there.
>
> I think, perhaps, PlasticField and PlasticMethod may need a
> makeVisible() method that makes the introduced members visible inside
> PlasticClass.getMethods() and PlasticClass.getFields(). I don't think
> there's a way to extricate things so that member access within the
> introduced method is not transformed, but that's probably fine ... in
> your case, you want to make sure that the ParameterWorker sees your
> defaultValidate() method, and that method will be a stub with advice.
What's the reason that introduced methods aren't visible by default like in in the old ClassTransformation? Are there consequences to just adding a line in PlasticClassImpl.createNewMethod() to add the new method onto the end of the methods list? I'm not all too familiar with the Plastic API but I could imagine using it for a whole bunch of things....
>
>
>> Kind regards,
>>
>> Luke
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Luke Wilson-Mawer
Director, Viscri Limited
luke@viscri.co.uk
Registered address: Cawley House, 149-155 Canal Street, Nottingham, NG1 7HR
Postal address: 804, Eurotower, Courland Grove, London, SW8 2PX
Registered number: 07031070
Re: PlasticClass.getMethods() doesn't include introduced methods.
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Apr 20, 2012 at 9:39 AM, Luke Wilson <lu...@viscri.co.uk> wrote:
> Hi,
>
> The behaviour of the now deprecated ClassTransformation.matchMethods() and related methods has changed to not include introduced Methods. I believe this problem also applies to fields.
>
> On top of this, the built in ClassTransformationWorker2s use PlasticClass.getMethods() directly to find fields.
>
> The sum total of this is that it is impossible to create a method or field in a ClassTransformationWorker/ClassTransformationWorker2 and have it taken into account by subsequent workers. Is this deliberate, or is it a bug? It's causing us headaches in our upgrade to Tapestry 5.3.
I think that's a use case that isn't accounted for. The other APIs on
ClassTransformationWorker2, particularly TransformationSupport, are
intended to fill the gap.
My observation was that you would introduce a method to either add an
event handler method, which can be done using TransformationSupport,
or to introduce rendering behavior, which can be accomplished by
advising one of the render phase methods.
However, I'm interested in other use cases, and will certainly address
them if they are valid.
Sorry for your upgrade trouble; I'd have to say you are likely in the
minority, using the most advanced features of Tapestry (and,
unfortunately, paying the cost).
That being said, I hope you are enjoying the Plastic API more than its
various predecessors.
>
> More is described here: http://stackoverflow.com/questions/10249254/tapestry-5-3-plasticclass-getmethods-doesnt-include-introduced-methods.
>
Ah, yes, I can see what you are going there.
I think, perhaps, PlasticField and PlasticMethod may need a
makeVisible() method that makes the introduced members visible inside
PlasticClass.getMethods() and PlasticClass.getFields(). I don't think
there's a way to extricate things so that member access within the
introduced method is not transformed, but that's probably fine ... in
your case, you want to make sure that the ParameterWorker sees your
defaultValidate() method, and that method will be a stub with advice.
> Kind regards,
>
> Luke
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org