[Proxool-developer] Summary of Cglib and Hibernate changes

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

Hi all,

I have been talking on the cglib and hibernate lists about the upcoming
release of cglib 2 and what that means for Proxool. I thought I'd
summarise the situation so everybody knows what is going on. It's a long
email, so apologies in advance.

Cglib are about to release version 2. As Chris says below, this will be
incompatible with version 1.

On Sun, 2003-11-16 at 19:08, Chris Nokleberg wrote: 

> [snip] this jar contains ASM 1.4, which is binary
> incompatible with 1.3, so CGLIB 1.0 and 2.0 can no longer coexist
> peacefully.

This means that if we are to upgrade to Cglib 2 then we need to make a
few changes to Proxool (Chris has already provided a patch for this) and
start distributing Cglib 2 with Proxool.

Okay. Why should we upgrade to Cglib 2? Well, anybody who decides to
upgrade to Cglib 2 for other reasons is going to get problems. People
who are likely to do that are users of Hibernate and Spring. Hibernate
actually distribute Proxool (thanks to Martin Crawford) so they require
Proxool to be updated in order to upgrade Cglib (which they are planning
to do when they release 2.1 in the next 4 weeks).

So we've decided to upgrade Proxool to use Cglib 2 and will release a
new version of Proxool shortly after Cglib 2 is released and (hopefully)
shortly before Hibernate 2.1 is released.

The consequence of which is that Hibernate 2.0 and earlier users will
not be able to upgrade Proxool without upgrading Hibernate. I think that
is acceptable as long as we make people aware of that. Same goes for
Spring.

It also means that anyone using Cglib in their own code will have to
make changes in order to use the latest Proxool. We should probably
provide some links in our own documentation about the best way to do
that (without going into too much detail).

There is another option that we could think about too: providing our own
ClassLoader. This would allow us to have Cglib 2 and Cglib 1 existing in
certain situations. Not very pretty and it wouldn't solve the problem of
the application code referencing Cglib 1.

Yet another option is that we use reflection to access Cglib and
auto-detect which version is available. If Cglib 2 is unavailable we
would resort to Cglib 1 and log a deprecation warning. This has
benefits: 1) people can use which version of Cglib they want, and
disadvantages: 1) code maintenance headache, 2) possible performance
impact (although I suspect it would be minimal if done right).

There are four Proxool classes effected: ProxyConnection,
ProxyDatabaseMetaData, ProxyFactory and ProxyStatement.

Phew. End of long message.

Regards,
Bill Horsman