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
