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.
**********************************/
