[Springframework-developer] Re: Re: Proxying target classes

[Chris N. <ch...@si...>]

Les A. Hazlewood wrote:
> The problem is that java.security.ProtectionDomain of the CGLIB generated
> class is _not_ the same of the application classes loaded by the trusted
> classloader. Because of this, Exceptions are thrown all over the place 
> when we try to use that runtime-generated class.
> 
> java.lang.reflect.Proxy does not have this problem.  From the 1.4.2 J2SE
> API:
> 
> "The java.security.ProtectionDomain of a proxy class is the same as that
> of system classes loaded by the bootstrap class loader, such as
> java.lang.Object, because the code for a proxy class is generated by
> trusted system code. This protection domain will typically be granted
> java.security.AllPermission"
[snip]
> This is clearly a CGLIB problem.  Has anyone on the Spring team addressed
> this issue?  Do you know if there is a newer version of the CGLIB 
> distribution that solves this problem?

It is a problem, but I'm not sure there is a good answer.
java.lang.reflect.Proxy is allowed to belong to the ProtectionDomain of the
system classes because Sun wrote it. Short of CGLIB becoming part of the
JDK (haha) you will not be able to sign dynamically generated classes.
This will be more and more of a problem going forward as runtime bytecode
generation becomes more popular.

One option that has been discussed is the ability to spit out all of the
CGLIB classes to disk. You could then jar them up and sign them yourself.
CGLIB would have to be modified to look for the pre-generated classes
before generating new ones. There are some technical issues with doing this
properly, and it would be hard to guarantee that you've generated all the
necessary code offline, so I hope a different solution can be found.

Chris