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