Re: Copy annotations from service implementation to proxies

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Fri, 28 Jun 2013 20:20:43 -0300, Howard Lewis Ship <hl...@gmail.com>  
wrote:

> As I remember it, I changed the API so that a search for an annotation  
> on a service will also check the service implementation ... so rather  
> than
> "copy" the annotations (which is very, very problematic), the code looks
> into two places. Take a peek at implementations of AnnotationProvider.

Hello, Howard!

Why is copying the annotations from service implementation method to their  
corresponding proxy classes so problematic? I've asked this once in June,  
no answer. Is it problematic or just hard?

I've just tested this and MethodInvocation.getAnnotation() doesn't  
actually check the service implementation method. From debugging the code,  
I've found that it ends up looking at the proxy, not at the service  
implementation. Right now, the only solution is to put annotations in  
service interfaces, something which is very against OOP principles in my  
humble opinion, so I think this is a very strong downside for  
Tapestry-IoC. And I want to fix that.

I've written a test for that and it fails (at least on 5.4-alpha-22):

public class MethodAdviceTest {

	@Test
	public void MethodAdvice_getAnnotation() {
		
		RegistryBuilder builder = new RegistryBuilder();
		builder.add(TestModule.class);
		final Registry build = builder.build();
		final Service service = build.getService(Service.class);
		assert service.method("aaaa") != null;

	}

}

public interface Service {
	public String method(String string);
}

public class ServiceImpl implements Service {
	@CacheResult // from javax.cache / cache-api 0.6-SNAPSHOT
	public String method(String string) {
		return null;
	}
}

public class TestModule {

	public static void bind(ServiceBinder binder) {
		binder.bind(Service.class, ServiceImpl.class);
	}
	
	@Advise(serviceInterface = Service.class)
	public static void advise(MethodAdviceReceiver methodAdviceReceiver) {
		methodAdviceReceiver.adviseAllMethods(new TestAdvice());
	}
	
	final private static class TestAdvice implements MethodAdvice {

		/* (non-Javadoc)
		 * @see  
org.apache.tapestry5.plastic.MethodAdvice#advise(org.apache.tapestry5.plastic.MethodInvocation)
		 */
		public void advise(MethodInvocation invocation) {

			CacheResult cacheResult =  
invocation.getMethod().getAnnotation(CacheResult.class);
			if (cacheResult == null) {
				cacheResult = invocation.getAnnotation(CacheResult.class);
				if (cacheResult != null) {
					invocation.setReturnValue("Annotation found");
				}
			}
			invocation.proceed();
			
		}
		
	}
	
}


>
>
> On Fri, Jun 28, 2013 at 1:37 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> Oops, now I realized my suggestion was written in a bad way. It's about
>> Tapestry-IoC services, not Tapestry(-core).
>>
>> What I'm actually suggesting is beyond that: it's about copying the
>> annotations on service implementation *methods* to their corresponding
>> methods in the service proxy. This would solve the problem described by
>> John. This cannot be solved in any other way in Tapestry-IoC right now.
>>
>>
>> On Fri, 28 Jun 2013 16:51:40 -0300, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>
>>  Yes, but it is optional.  Anything you don't want to specify using an
>>> annotation on the interface can be specified instead using the
>>> ServiceBinder interface, or as an annotation on a module method.
>>>
>>> Ok, in this case, if you want to use the Tapestry-specific magic, you  
>>> get
>>> to use the Tapestry-specific annotation.
>>>
>>> If you don't like that, you can inject the underlying JPASessionManager
>>> service and get/commit the transaction yourself.  Or create a
>>> Tapestry-facing Facade with the Tapestry annotations whose  
>>> implementation
>>> delegates to the "vanilla" interface.
>>>
>>>
>>> On Fri, Jun 28, 2013 at 6:27 AM, Thiago H de Paula Figueiredo <
>>> thiagohp@gmail.com> wrote:
>>>
>>>  On Thu, 27 Jun 2013 06:05:14 -0300, <no...@comments.apache.org>
>>>> wrote:
>>>>
>>>>  Hello,
>>>>
>>>>> John has commented on http://tapestry.apache.org/**
>>>>> integrating-with-jpa.html<http**://tapestry.apache.org/**
>>>>> integrating-with-jpa.html<http://tapestry.apache.org/integrating-with-jpa.html>
>>>>> >
>>>>>
>>>>> .
>>>>> You can find the comment here:
>>>>> http://tapestry.apache.org/****integrating-with-jpa.html#****
>>>>> comment_1410<http://tapestry.apache.org/**integrating-with-jpa.html#**comment_1410>
>>>>> <http://tapestry.**apache.org/integrating-with-**jpa.html#comment_1410<http://tapestry.apache.org/integrating-with-jpa.html#comment_1410>
>>>>> >
>>>>>
>>>>> Please note that if the comment contains a hyperlink, it must be
>>>>> approved
>>>>> before it is shown on the site.
>>>>>
>>>>> Below is the reply that was posted:
>>>>> ~~~~
>>>>> Adding implementations specific annotations to the service interfaces
>>>>> breaks the interface/implementation independence.
>>>>> ~~~~
>>>>>
>>>>>
>>>> I agree with this. What do you guys think? I think this is a serious
>>>> shotcoming in Tapestry-IoC.
>>>>
>>>> --
>>>> Thiago H. de Paula Figueiredo
>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail:  
>>>> dev-unsubscribe@tapestry.**apa**che.org<http://apache.org>
>>>> <de...@tapestry.apache.org>
>>>> >
>>>>
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:  
>> dev-unsubscribe@tapestry.**apache.org<de...@tapestry.apache.org>
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>


-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org