[
https://issues.apache.org/jira/browse/TAP5-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796487#action_12796487
]
Thiago H. de Paula Figueiredo commented on TAP5-335:
----------------------------------------------------
Howard, your ServiceDescription lacks some way to get the annotations on
methods, something crucial for implementing many interesting features.
By the way, fixing this JIRA would solve the only thing that other IoC and DI
frameworks have and Tapestry-IoC doesn't.
Not having access to service implementation methods' annotations severely
prevents Tapestry-IoC to be used to implement a transaction management package,
for example. Putting the annotations in the service interfaces isn't a good
solution IMHO, as transaction managem is not part of a service definition,
being a part of the service implementation. And other methods, besides the
service interface ones, could be transactional.
The ideal scenario IMHO is to have the proxies have all the methods from the
service implementation, not just the service interface ones. This way, a proxy
could be used interchangeably with its delegate in terms of annotations. On the
other hand, if a solution that only provides access to service service methods'
annotation, I'm happy already. :)
Looking the the sources, it seems difficult to implement the proxies as I want,
Many places use ClassFab.proxyMethodsToDelegate(Class serviceInterface, String
delegateExpression, String toString) and the service implementation class is
not recorded anywhere. Or shouldn't I take take a look at ModuleImpl methods
first?
Any hints on how to solve this?
> Provide access to annotations of service implementation class
> -------------------------------------------------------------
>
> Key: TAP5-335
> URL: https://issues.apache.org/jira/browse/TAP5-335
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Affects Versions: 5.0.15
> Reporter: Lubor Gajda
>
> In some situations it would be useful to have direct access to annotations of
> service implementation class. This would allow us, during registry startup,
> detect services with some specific class or method level annotations and take
> related actions.
> For instance imagine tapestry-quartz integration based on simple declarative
> mechanism where it would be possible to use something like this:
> public class MyServiceImpl implements MyService {
> @Scheduled(cronExpression="0/5 * * * * ?")
> public void myMethod() {
> ...
> }
> }
> and framework would be able, during registry startup, automatically detect
> all service methods annotated by @Scheduled annotation and register them in
> the scheduler.
>
> I see two possible solutions:
> 1. Modify ServiceDef to hold information about service implementation class.
> 2. Service proxy could inherit all annotations from service implementation
> class, then we would be able to check annotations directly on service proxy.
>
> But maybe there is another, more elegant solution.
>
> For more details see thread:
> http://thread.gmane.org/gmane.comp.java.tapestry.user/67116/focus=67116
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
