Re: Proxies based on class not interface

[David Jencks <da...@yahoo.com>]

On Aug 11, 2005, at 2:32 PM, Aaron Mulder wrote:

> 	Right now, if you want a proxy to a ServerInfo (which is a class
> which implements no interfaces), the kernel's ProxyManager will give 
> one
> to you.  To do that, it creates a subclass of ServerInfo and overrides 
> the
> methods it can.
>
> 	It seems like it might be preferable if we only created proxies
> based on interfaces.  This would be a long-term goal, as we'd have to
> provide interrfaces for all the classes that need them (such as
> ServerInfo) and change our references (which use proxies) to be based 
> on
> interface instead of class.  It seems that we're also creating some
> proxies where the class to proxy is java.lang.Object (don't ask me!), 
> and
> we have to hunt that stuff down.

Those are mostly there to force a particular startup/dependency order.
>
> 	Nevertheless, I'm wondering what other people think *in principle*
> of removing support for proxies based on class, some day when it 
> becomes
> possible.

What is the advantage?  We aren't going to be able to convince the 
cglib guys to remove support for proxying classes.
thanks
david jencks

>
> Thanks,
> 	Aaron
>

Re: Proxies based on class not interface

[Jules Gosnell <ju...@coredevelopers.net>]

Dain Sundstrom wrote:

> On Aug 11, 2005, at 2:22 PM, David Jencks wrote:
>
>>
>> On Aug 11, 2005, at 2:32 PM, Aaron Mulder wrote:
>>
>>
>>>     Right now, if you want a proxy to a ServerInfo (which is a class
>>> which implements no interfaces), the kernel's ProxyManager will  
>>> give one
>>> to you.  To do that, it creates a subclass of ServerInfo and  
>>> overrides the
>>> methods it can.
>>>
>>>     It seems like it might be preferable if we only created proxies
>>> based on interfaces.  This would be a long-term goal, as we'd have to
>>> provide interrfaces for all the classes that need them (such as
>>> ServerInfo) and change our references (which use proxies) to be  
>>> based on
>>> interface instead of class.  It seems that we're also creating some
>>> proxies where the class to proxy is java.lang.Object (don't ask  
>>> me!), and
>>> we have to hunt that stuff down.
>>>
>>
>> Those are mostly there to force a particular startup/dependency order.
>>
>>>
>>>     Nevertheless, I'm wondering what other people think *in  principle*
>>> of removing support for proxies based on class, some day when it  
>>> becomes
>>> possible.
>>>
>>
>> What is the advantage?
>
>
> I personally would like to see support for creating a class based  
> proxy be removed.  It just encourages bad (lazy) programming.
>
>> We aren't going to be able to convince the cglib guys to remove  
>> support for proxying classes.
>
>
> We don't need or want them to remove it.  We can simply turn off this  
> feature in our proxy factory.
>
> -dain

The Spring integration already gets around this by generating a new 
interface that is the sum of all methods on a POJO's class, then 
instantiating a proxy of this and wrapping the POJO with it. The proxy 
is then plugged into the kernel (my memory may be a bit rusty on this - 
but the point stands)

So,

1) removing the ability to proxy anything that is not interfaced-based 
from the kernel, will not prevent people from doing so, just make it 
more awkward.

2) there may be a valid reason for wanting to do so.

Of course, a decent Spring/POJO/kernel integration would render this 
unnecessary :-)

Jules

-- 
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**********************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/

Re: Proxies based on class not interface

[Dain Sundstrom <da...@iq80.com>]

On Aug 11, 2005, at 2:22 PM, David Jencks wrote:

>
> On Aug 11, 2005, at 2:32 PM, Aaron Mulder wrote:
>
>
>>     Right now, if you want a proxy to a ServerInfo (which is a class
>> which implements no interfaces), the kernel's ProxyManager will  
>> give one
>> to you.  To do that, it creates a subclass of ServerInfo and  
>> overrides the
>> methods it can.
>>
>>     It seems like it might be preferable if we only created proxies
>> based on interfaces.  This would be a long-term goal, as we'd have to
>> provide interrfaces for all the classes that need them (such as
>> ServerInfo) and change our references (which use proxies) to be  
>> based on
>> interface instead of class.  It seems that we're also creating some
>> proxies where the class to proxy is java.lang.Object (don't ask  
>> me!), and
>> we have to hunt that stuff down.
>>
>
> Those are mostly there to force a particular startup/dependency order.
>
>>
>>     Nevertheless, I'm wondering what other people think *in  
>> principle*
>> of removing support for proxies based on class, some day when it  
>> becomes
>> possible.
>>
>
> What is the advantage?

I personally would like to see support for creating a class based  
proxy be removed.  It just encourages bad (lazy) programming.

> We aren't going to be able to convince the cglib guys to remove  
> support for proxying classes.

We don't need or want them to remove it.  We can simply turn off this  
feature in our proxy factory.

-dain