Tapestry 5
  1. Tapestry 5
  2. TAP5-335

Provide access to annotations of service implementation class

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-ioc
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Lubor Gajda created issue -
          Hide
          Howard M. Lewis Ship added a comment -

          It would be nice if we could expose the ServiceDef for a service to the service's builder, and make introspection of the Registry (to find ServiceDefs) part of the ObjectLocator API.

          Remember that there isn't always a service implementation class! Sometimes its a builder method, sometimes a class w/ constructor, sometimes a ServiceBuilder instance.

          I think we need a new representation of a service:

          public interface ServiceDescription extends AnnotationProvider

          { public String getServiceId(); public Class getServiceInterface(); Set<Class> getMarkers(); }

          It would provide annotations of the constructor or builder method and off the class (if known).

          ObjectLocator could be changed to include:

          public Map<String,ServiceDescription> getServiceDescriptions();

          This would be an immutable, case-insensitive map.

          Show
          Howard M. Lewis Ship added a comment - It would be nice if we could expose the ServiceDef for a service to the service's builder, and make introspection of the Registry (to find ServiceDefs) part of the ObjectLocator API. Remember that there isn't always a service implementation class! Sometimes its a builder method, sometimes a class w/ constructor, sometimes a ServiceBuilder instance. I think we need a new representation of a service: public interface ServiceDescription extends AnnotationProvider { public String getServiceId(); public Class getServiceInterface(); Set<Class> getMarkers(); } It would provide annotations of the constructor or builder method and off the class (if known). ObjectLocator could be changed to include: public Map<String,ServiceDescription> getServiceDescriptions(); This would be an immutable, case-insensitive map.
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          As long as we get access to the actual service instance object or Class, I guess this issue can be closed. Regarding the solution, if Lubor's #2 solution is possible, I think that's the best one, as it would work inside and outside Tapestry-IoC.

          Show
          Thiago H. de Paula Figueiredo added a comment - As long as we get access to the actual service instance object or Class, I guess this issue can be closed. Regarding the solution, if Lubor's #2 solution is possible, I think that's the best one, as it would work inside and outside Tapestry-IoC.
          Hide
          Sebastian Hennebrueder added a comment -

          I can not comment on how to solve this, but on what I was missing when evaluating Tapestry.

          I prefer to put annotations in the class and didn't manage to extend Tapestry-IOC in a way to achieve this
          http://www.nabble.com/-Tapestry-IOC--Interfaces-could-be-more-complete---MethodAdviceReceiver-and-Invocation-tt24836083.html#a24841800

          Show
          Sebastian Hennebrueder added a comment - I can not comment on how to solve this, but on what I was missing when evaluating Tapestry. I prefer to put annotations in the class and didn't manage to extend Tapestry-IOC in a way to achieve this http://www.nabble.com/-Tapestry-IOC--Interfaces-could-be-more-complete---MethodAdviceReceiver-and-Invocation-tt24836083.html#a24841800
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          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?

          Show
          Thiago H. de Paula Figueiredo added a comment - 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?
          Hide
          Ulrich Stärk added a comment - - edited

          Another use case where this could come in very handy are webservices. The javax.jws @Webservice annotation can be put on an interface but only without parameters like the serviceName parameter that identifies a service. This has to be on the implementation class and gets lost when creating a proxy around it.

          Show
          Ulrich Stärk added a comment - - edited Another use case where this could come in very handy are webservices. The javax.jws @Webservice annotation can be put on an interface but only without parameters like the serviceName parameter that identifies a service. This has to be on the implementation class and gets lost when creating a proxy around it.
          Igor Drobiazko made changes -
          Field Original Value New Value
          Assignee Igor Drobiazko [ igor.drobiazko ]
          Hide
          Igor Drobiazko added a comment -

          For services that are bound inside the bind method, annotations are copied from implementation class to proxy. For services that are created inside build methods there is still no access to annotations.

          Show
          Igor Drobiazko added a comment - For services that are bound inside the bind method, annotations are copied from implementation class to proxy. For services that are created inside build methods there is still no access to annotations.
          Igor Drobiazko made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 5.2.0 [ 12314122 ]
          Resolution Fixed [ 1 ]
          Hide
          Hudson added a comment -

          Integrated in tapestry-5.2-freestyle #162 (See http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/162/)
          TAP5-335: Provide access to annotations of service implementation class

          Show
          Hudson added a comment - Integrated in tapestry-5.2-freestyle #162 (See http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/162/ ) TAP5-335 : Provide access to annotations of service implementation class
          Alejandro Scandroli made changes -
          Link This issue relates to TAP5-1349 [ TAP5-1349 ]

            People

            • Assignee:
              Igor Drobiazko
              Reporter:
              Lubor Gajda
            • Votes:
              4 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development