You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Kersten <ma...@gmail.com> on 2013/08/24 12:07:51 UTC
Advice non-interface methods?
Hi there,
I found this example page:
http://tapestry.apache.org/using-tapestry-with-hibernate.html.
The problem I have are these lines:
package com.example.tutorial.pages.address;....public class CreateAddress {
...
@CommitAfter
Object onSuccess() {
...
}
}
Is it possible to annotate non-interface methods? How is that?
I am still struggling with @CommitAfter and all this. I would love to
annotate
the Implementation class instead of the service interface which seams more
obvious to me, since the transactional behavior is part of the
implementation
not the definition.
When I take a look about the Decorator class and the methods called
it boils down to AspectDecoratorImpl method:
public <T> AspectInterceptorBuilder<T> createBuilder(final Class<T>
serviceInterface, final T delegate,
AnnotationAccess annotationAccess, final String description) {
}
It says serviceInterface and the method used to advice Class.getMethods.
Therefore it would be all methods available.
Digging myself into the swamp of builder and bind, I found that the
serviceInterface seams to be the real provided interface rather then the
implementation class. Am I correct on this?
Is there any chance I can bend Tapestry to advise the implementation class
as well? It
would be create to use @CommitAfter in the implementation class rather then
the interface
where it does not belong to since Transactional behavior is for sure an
Implementation issue
and not about the description of what happends but how.
Cheers,
Martin
Re: Advice non-interface methods?
Posted by Martin Kersten <ma...@gmail.com>.
> | Is there any chance I can bend Tapestry to advise the implementation
class as well?
> Only if you change Tapestry-IoC to copy the annotations from service
implemention methods to the corresponding methods in the proxy created for
this service. Unfortunately, I don't > have the bytecode knowledge to do it
myself and Howard, which does, doesn't like the idea.
Same as the good old jmock discussion. Mocking classes is evil. Yeah and
when we did we liked it. It feels so unnatural not being able to advise
implementation methods.
2013/8/24 Thiago H de Paula Figueiredo <th...@gmail.com>
> On Sat, 24 Aug 2013 07:07:51 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> Hi there,
>>
>
> Hi!
>
> I found this example page:
>> http://tapestry.apache.org/**using-tapestry-with-hibernate.**html<http://tapestry.apache.org/using-tapestry-with-hibernate.html>
>> .
>>
>> The problem I have are these lines:
>>
>> package com.example.tutorial.pages.**address;....public class
>> CreateAddress {
>>
>> ...
>> @CommitAfter
>> Object onSuccess() {
>> ...
>> }
>> }
>>
>>
>> Is it possible to annotate non-interface methods? How is that?
>>
>
> Tapestry-IoC doesn't support that in services, just in page, component and
> mixin classes.
>
>
> I am still struggling with @CommitAfter and all this. I would love to
>> annotate the Implementation class instead of the service interface which
>> seams more obvious to me, since the transactional behavior is part of the
>> implementation not the definition.
>>
>
> Me too.
>
>
> When I take a look about the Decorator class and the methods called
>> it boils down to AspectDecoratorImpl method:
>>
>
> When you define a service without defining an interface, advice isn't
> applied to its methods.
>
>
> public <T> AspectInterceptorBuilder<T> createBuilder(final Class<T>
>> serviceInterface, final T delegate,
>> AnnotationAccess annotationAccess, final String description) {
>> }
>>
>> It says serviceInterface and the method used to advice Class.getMethods.
>> Therefore it would be all methods available.
>>
>> Digging myself into the swamp of builder and bind, I found that the
>> serviceInterface seams to be the real provided interface rather then the
>> implementation class. Am I correct on this?
>>
>
> Yep.
>
>
> Is there any chance I can bend Tapestry to advise the implementation
>> class as well?
>>
>
> Only if you change Tapestry-IoC to copy the annotations from service
> implemention methods to the corresponding methods in the proxy created for
> this service. Unfortunately, I don't have the bytecode knowledge to do it
> myself and Howard, which does, doesn't like the idea.
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Advice non-interface methods?
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Sat, 24 Aug 2013 07:07:51 -0300, Martin Kersten
<ma...@gmail.com> wrote:
> Hi there,
Hi!
> I found this example page:
> http://tapestry.apache.org/using-tapestry-with-hibernate.html.
>
> The problem I have are these lines:
>
> package com.example.tutorial.pages.address;....public class
> CreateAddress {
> ...
> @CommitAfter
> Object onSuccess() {
> ...
> }
> }
>
>
> Is it possible to annotate non-interface methods? How is that?
Tapestry-IoC doesn't support that in services, just in page, component and
mixin classes.
> I am still struggling with @CommitAfter and all this. I would love to
> annotate the Implementation class instead of the service interface which
> seams more obvious to me, since the transactional behavior is part of the
> implementation not the definition.
Me too.
> When I take a look about the Decorator class and the methods called
> it boils down to AspectDecoratorImpl method:
When you define a service without defining an interface, advice isn't
applied to its methods.
> public <T> AspectInterceptorBuilder<T> createBuilder(final Class<T>
> serviceInterface, final T delegate,
> AnnotationAccess annotationAccess, final String description)
> {
> }
>
> It says serviceInterface and the method used to advice Class.getMethods.
> Therefore it would be all methods available.
>
> Digging myself into the swamp of builder and bind, I found that the
> serviceInterface seams to be the real provided interface rather then the
> implementation class. Am I correct on this?
Yep.
> Is there any chance I can bend Tapestry to advise the implementation
> class as well?
Only if you change Tapestry-IoC to copy the annotations from service
implemention methods to the corresponding methods in the proxy created for
this service. Unfortunately, I don't have the bytecode knowledge to do it
myself and Howard, which does, doesn't like the idea.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org