We definitely want something like this in WeldX. However I would argue we should follow the design of interceptors much more closely. 1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)? 2) Drop the interface implementation requirement, and use the @AroundInvoke annotation 3) Add an annotation used to find the handlers e.g. @ServiceHandler 4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {} WDYT? On 28 Jun 2010, at 08:54, Stuart Douglas wrote: > After some discussions with Walter White I have added some > experimental code to weld extensions to enable the automatic proxying > of interfaces. > > To demonstrate how this works, here is a sample: > > @AutoProxy(QueryInvocationHandler.class) > public interface QueryService<T> {}; > > public interface UserQuery extends QueryService<User> > { > > @Query("select u from user u where u.username=:1") > public User findUserByUsername(String username); > > } > > public class QueryInvocationHandler implements InvocationHandler > { > > @Inject EntityManager entityManager; > > public Object invoke(Object proxy, Method method, Object[] args) >     throws Throwable > { > //run the query based on the annotations on the method > } > > } > > Any interface that extends QueryService will be automatically proxied > by the container, using the InvocationHander specified in the > @AutoProxy annotation. This proxy is registered as a bean, and if any > qualifiers are present on the Interface being proxied these are added > to the bean. It is also possible to inject into the InvocationHandler. >  I also plan to make @AutoProxy a meta annotation, so the above could > also be represented as: > > > @AutoProxy(QueryInvocationHandler.class) > public @interface QueryService{} > > @QueryService > public interface UserQuery > { > > @Query("select u from user u where u.username=:1") > public User findUserByUsername(String username); > > } > > Does all this sound ok, or does it not have a strong enough use case > to include it in Weld Extensions? > > Stuart

On 13/07/2010, at 2:20 AM, Pete Muir wrote: > We definitely want something like this in WeldX. > > However I would argue we should follow the design of interceptors much more closely. > > 1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)? > 2) Drop the interface implementation requirement, and use the @AroundInvoke annotation > 3) Add an annotation used to find the handlers e.g. @ServiceHandler > 4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {} > > WDYT? > Looks good, I was planning on doing the meta-annotation stuff at some point, and using AroundInvoke rather than implementing InvocationHandler is certainly an improvement. I don't see why getTarget should return null though. Even though having access to the object may not be not particularly useful, I think that most people would find this behaviour surprising. Also they may want to call getClass() or use instanceof on the object to determine the exact type they are dealing with. Another point is that seeing as how we already have the Javassist dependency should this be extended to work for abstract classes as well? Stuart > On 28 Jun 2010, at 08:54, Stuart Douglas wrote: > > >> After some discussions with Walter White I have added some experimental code to weld extensions to enable the automatic proxying of interfaces. >> >> To demonstrate how this works, here is a sample: >> >> @AutoProxy(QueryInvocationHandler.class) >> public interface QueryService<T> {}; >> >> public interface UserQuery extends QueryService<User> >> { >> >> @Query("select u from user u where u.username=:1") >> public User findUserByUsername(String username); >> >> } >> >> public class QueryInvocationHandler implements InvocationHandler >> { >> >> @Inject EntityManager entityManager; >> >> public Object invoke(Object proxy, Method method, Object[] args) >> throws Throwable >> { >> //run the query based on the annotations on the method >> } >> >> } >> >> Any interface that extends QueryService will be automatically proxied by the container, using the InvocationHander specified in the @AutoProxy annotation. This proxy is registered as a bean, and if any qualifiers are present on the Interface being proxied these are added to the bean. It is also possible to inject into the InvocationHandler. >> I also plan to make @AutoProxy a meta annotation, so the above could also be represented as: >> >> >> @AutoProxy(QueryInvocationHandler.class) >> public @interface QueryService{} >> >> @QueryService >> public interface UserQuery >> { >> >> @Query("select u from user u where u.username=:1") >> public User findUserByUsername(String username); >> >> } >> >> Does all this sound ok, or does it not have a strong enough use case to include it in Weld Extensions? >> >> Stuart >> >

On 13 Jul 2010, at 00:45, Walter White wrote: > Stuart, > > Your idea sounds good as well. > > I think my original motivation was when I first started with Spring in 2008, we proxied an abstract DAO if we didn't need custom functionality. If we needed custom functionality, then we extended the abstract DAO making it concrete. There was a configuration in spring that let you do that, but at that point in time, it was useful to avoid writing the same code again and again. > > I need to play around with that more to have a better answer. > > Walter > > On 07/12/2010 06:05 PM, Stuart Douglas wrote: >> On 13/07/2010, at 2:20 AM, Pete Muir wrote: >> >> >>> We definitely want something like this in WeldX. >>> >>> However I would argue we should follow the design of interceptors much more closely. >>> >>> 1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)? >>> 2) Drop the interface implementation requirement, and use the @AroundInvoke annotation >>> 3) Add an annotation used to find the handlers e.g. @ServiceHandler >>> 4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {} >>> >>> WDYT? >>> >> Looks good, I was planning on doing the meta-annotation stuff at some point, and using AroundInvoke rather than implementing InvocationHandler is certainly an improvement. >> >> I don't see why getTarget should return null though. Even though having access to the object may not be not particularly useful, I think that most people would find this behaviour surprising. Also they may want to call getClass() or use instanceof on the object to determine the exact type they are dealing with. What would getTarget return then? By definition there is no proxied object.

>> >> Another point is that seeing as how we already have the Javassist dependency should this be extended to work for abstract classes as well? Yes, seems reasonable. >> >> Stuart >> >> >>> On 28 Jun 2010, at 08:54, Stuart Douglas wrote: >>> >>> >>>> After some discussions with Walter White I have added some experimental code to weld extensions to enable the automatic proxying of interfaces. >>>> >>>> To demonstrate how this works, here is a sample: >>>> >>>> @AutoProxy(QueryInvocationHandler.class) >>>> public interface QueryService<T> {}; >>>> >>>> public interface UserQuery extends QueryService<User> >>>> { >>>> >>>> @Query("select u from user u where u.username=:1") >>>> public User findUserByUsername(String username); >>>> >>>> } >>>> >>>> public class QueryInvocationHandler implements InvocationHandler >>>> { >>>> >>>> @Inject EntityManager entityManager; >>>> >>>> public Object invoke(Object proxy, Method method, Object[] args) >>>> throws Throwable >>>> { >>>> //run the query based on the annotations on the method >>>> } >>>> >>>> } >>>> >>>> Any interface that extends QueryService will be automatically proxied by the container, using the InvocationHander specified in the @AutoProxy annotation. This proxy is registered as a bean, and if any qualifiers are present on the Interface being proxied these are added to the bean. It is also possible to inject into the InvocationHandler. >>>> I also plan to make @AutoProxy a meta annotation, so the above could also be represented as: >>>> >>>> >>>> @AutoProxy(QueryInvocationHandler.class) >>>> public @interface QueryService{} >>>> >>>> @QueryService >>>> public interface UserQuery >>>> { >>>> >>>> @Query("select u from user u where u.username=:1") >>>> public User findUserByUsername(String username); >>>> >>>> } >>>> >>>> Does all this sound ok, or does it not have a strong enough use case to include it in Weld Extensions? >>>> >>>> Stuart >>>> >>> >> >

On 13 Jul 2010, at 21:18, Stuart Douglas wrote: > > On 14/07/2010, at 3:56 AM, Pete Muir wrote: > >> >> On 13 Jul 2010, at 00:45, Walter White wrote: >> >>> Stuart, >>> >>> Your idea sounds good as well. >>> >>> I think my original motivation was when I first started with Spring in 2008, we proxied an abstract DAO if we didn't need custom functionality. If we needed custom functionality, then we extended the abstract DAO making it concrete. There was a configuration in spring that let you do that, but at that point in time, it was useful to avoid writing the same code again and again. >>> >>> I need to play around with that more to have a better answer. >>> >>> Walter >>> >>> On 07/12/2010 06:05 PM, Stuart Douglas wrote: >>>> On 13/07/2010, at 2:20 AM, Pete Muir wrote: >>>> >>>> >>>>> We definitely want something like this in WeldX. >>>>> >>>>> However I would argue we should follow the design of interceptors much more closely. >>>>> >>>>> 1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)? >>>>> 2) Drop the interface implementation requirement, and use the @AroundInvoke annotation >>>>> 3) Add an annotation used to find the handlers e.g. @ServiceHandler >>>>> 4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {} >>>>> >>>>> WDYT? >>>>> >>>> Looks good, I was planning on doing the meta-annotation stuff at some point, and using AroundInvoke rather than implementing InvocationHandler is certainly an improvement. >>>> >>>> I don't see why getTarget should return null though. Even though having access to the object may not be not particularly useful, I think that most people would find this behaviour surprising. Also they may want to call getClass() or use instanceof on the object to determine the exact type they are dealing with. >> >> What would getTarget return then? By definition there is no proxied object. > > I would have it return the Proxy instance. In this case, we would need to redefine the InvocationContext interface, as getTarget then has the wrong contract. Hmm, I can't see a good path through this. I am loath to add more interfaces that do different things. Any ideas?

Ok, you convinced me - let's just make sure we document it :-) On 14 Jul 2010, at 22:47, Stuart Douglas wrote: > I don't think that is does break the contract, especially in the case of an abstract class. The javadoc just says : > > Returns the target instance. > > And the instance of the generated proxy is the target instance. Proxy is not really a good word for this, as this is not really a proxy in the design patterns sense, but a proxy in the 'uses JDK proxies' sense. I wish they had called JDK proxies something else. > > Stuart > > On 14/07/2010, at 10:53 PM, Pete Muir wrote: > > >> On 13 Jul 2010, at 21:18, Stuart Douglas wrote: >> >> >>> On 14/07/2010, at 3:56 AM, Pete Muir wrote: >>> >>> >>>> On 13 Jul 2010, at 00:45, Walter White wrote: >>>> >>>> >>>>> Stuart, >>>>> >>>>> Your idea sounds good as well. >>>>> >>>>> I think my original motivation was when I first started with Spring in 2008, we proxied an abstract DAO if we didn't need custom functionality. If we needed custom functionality, then we extended the abstract DAO making it concrete. There was a configuration in spring that let you do that, but at that point in time, it was useful to avoid writing the same code again and again. >>>>> >>>>> I need to play around with that more to have a better answer. >>>>> >>>>> Walter >>>>> >>>>> On 07/12/2010 06:05 PM, Stuart Douglas wrote: >>>>> >>>>>> On 13/07/2010, at 2:20 AM, Pete Muir wrote: >>>>>> >>>>>> >>>>>> >>>>>>> We definitely want something like this in WeldX. >>>>>>> >>>>>>> However I would argue we should follow the design of interceptors much more closely. >>>>>>> >>>>>>> 1) The aroundInvoke method should take an InvocationContext, returning null for getTarget (what is the reason for passing the proxy into the method in the design below)? >>>>>>> 2) Drop the interface implementation requirement, and use the @AroundInvoke annotation >>>>>>> 3) Add an annotation used to find the handlers e.g. @ServiceHandler >>>>>>> 4) Add a meta-annotation @ServiceBinding(QueryInvocationHandler.class) @interface QueryService {} >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> >>>>>> Looks good, I was planning on doing the meta-annotation stuff at some point, and using AroundInvoke rather than implementing InvocationHandler is certainly an improvement. >>>>>> >>>>>> I don't see why getTarget should return null though. Even though having access to the object may not be not particularly useful, I think that most people would find this behaviour surprising. Also they may want to call getClass() or use instanceof on the object to determine the exact type they are dealing with. >>>>>> >>>> What would getTarget return then? By definition there is no proxied object. >>>> >>> I would have it return the Proxy instance. >>> >> In this case, we would need to redefine the InvocationContext interface, as getTarget then has the wrong contract. >> >> Hmm, I can't see a good path through this. I am loath to add more interfaces that do different things. >> >> Any ideas? >> >