[Proxool-developer] Stumbling Block for Proxying Concrete Classes

[Bill H. <bi...@lo...>]

Hi all,

I've spent a few hours playing with Cglib and talking to the developers
trying to get concrete class proxying to work. And there is a
fundamental problem :(

Proxying for objects that declare all their important methods in an
interface is not a problem. It's when we try and expose some of methods
that are only declared in the concrete class that we get problems.

Cglib /will/ allow us to do it, but we have to extend the concrete
class. And to do that the concrete class must be non-final and have at
least one non-private constructor. And if there isn't a default
constructor then it starts to get a bit awkward because you end up
guessing the parameters. Nasty. 

This is what happens: we get a Connection object, say, from the driver
and want to proxy it and expose the concrete class. We ask Cglib to
build a new object based on a class that extends the concrete class. At
this point, it instantiates another instance. This is the big problem in
my mind. Now, we never actually use that instance - our proxy always
delegates to the instance we were handed by the driver. Nevertheless, we
have no idea what the consequences are of instantiating another
Connection object. Maybe it will try and connect to the database, or
make the driver think there are more open connections than there really
are.

To quote Chris Nokleberg from Cglib: "But unfortunately there is no way
to proxy an existing class without creating a new copy (you cannot
modify the bytecode of an existing class/object). Proxying by interface
works fine because you can always create a new class that implements the
interface. I wish I could help but it is a pretty fundamental JVM
limitation."

So we are left with injectable interfaces. This is possible, although we
need to do a bit of work. You can't make the concrete class implement
your new injectable interface: reflection just won't allow it. But we
will be able to match up the concrete methods with the injectable
interface methods using their signatures. This will allow us to create a
map of interface methods to concrete methods (that will be cached for
speed). I don't see any reason why this can't work.

It's a shame, because proxying the concrete class seemed like such a
neat solution. Injectable Interfaces are functional, but the client
needs to write and configure them. Anybody have an ideas?

- Bill