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