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.
Stuart
>
>>>
>>> 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
>>>>>
>>>>
>>>
>>
>
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
