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
