springframework-developer

[Springframework-developer] Proxying target classes

[Colin S. <col...@ex...>]

Rod,

Have you ever seen cglib's EnhancerEmitter blow up on trying to create a 
proxy? I generally only have to proxy interfaces, so have not proxied 
classes too much so far, however I just had a case where I needed to 
proxy a class directly, and got the following exception:

 method 'onMessage' due to throwable 
[org.springframework.beans.factory.BeanCrea
tionException: Error creating bean with name 'packaging-engine' defined 
in class
path resource [packaging-applicationContext.xml]: Initialization method 
of bean
failed; nested exception is:
        org.springframework.aop.framework.AopConfigException: Unexpected 
AOP exc
eption; nested exception is:
        java.lang.NullPointerException]
08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
08:07:48,585 ERROR [LogInterceptor] RuntimeException:
org.springframework.beans.factory.BeanCreationException: Error creating 
bean wit
h name 'packaging-engine' defined in classpath resource 
[packaging-applicationCo
ntext.xml]: Initialization method of bean failed; nested exception is:
        org.springframework.aop.framework.AopConfigException: Unexpected 
AOP exc
eption; nested exception is:
        java.lang.NullPointerException
org.springframework.aop.framework.AopConfigException: Unexpected AOP 
exception;
nested exception is:
        java.lang.NullPointerException
java.lang.NullPointerException
        at 
net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
407)
        at net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
        at 
net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
31)
        at 
net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)

This is using BeanNameAutoProxyCreator, with proxyTargetClass set to 
true. I actually used another postprocessor just for this case, since 
normally I only care about interfaces, so there's nothing else in it:

  <bean id="packaging-txAutoProxyCreator2" 
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="proxyTargetClass"><value>true</value></property>
    <property name="interceptorNames">
      <list>
        <idref bean="hibInterceptor"/>
        <idref local="packaging-matchAllTxInterceptor"/>
      </list>
    </property>
    <property name="beanNames">
      <list>
           <idref local="packaging-engine"/>
      </list>
    </property>
  </bean>

The class in question (Engine) is a fairly simple class. It implements 
no interfaces.

Regards,
Colin

[Springframework-developer] Re: Proxying target classes

[Rod J. <rod...@in...>]

I saw this once only and it was my fault (accidentally wrapped a String as
the target, rather than real object).

Are any of the methods, or the object itself, final?

Can you reproduce this in a failing test case so I can look at it? There
certainly should be a better error message, even if it's a CGLIB prob.

Regards,
Rod

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>;
<rod...@in...>
Sent: Wednesday, January 28, 2004 1:20 PM
Subject: Proxying target classes


> Rod,
>
> Have you ever seen cglib's EnhancerEmitter blow up on trying to create a
> proxy? I generally only have to proxy interfaces, so have not proxied
> classes too much so far, however I just had a case where I needed to
> proxy a class directly, and got the following exception:
>
>  method 'onMessage' due to throwable
> [org.springframework.beans.factory.BeanCrea
> tionException: Error creating bean with name 'packaging-engine' defined
> in class
> path resource [packaging-applicationContext.xml]: Initialization method
> of bean
> failed; nested exception is:
>         org.springframework.aop.framework.AopConfigException: Unexpected
> AOP exc
> eption; nested exception is:
>         java.lang.NullPointerException]
> 08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
> 08:07:48,585 ERROR [LogInterceptor] RuntimeException:
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean wit
> h name 'packaging-engine' defined in classpath resource
> [packaging-applicationCo
> ntext.xml]: Initialization method of bean failed; nested exception is:
>         org.springframework.aop.framework.AopConfigException: Unexpected
> AOP exc
> eption; nested exception is:
>         java.lang.NullPointerException
> org.springframework.aop.framework.AopConfigException: Unexpected AOP
> exception;
> nested exception is:
>         java.lang.NullPointerException
> java.lang.NullPointerException
>         at
> net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
> 407)
>         at
net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
>         at
> net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
> 31)
>         at
> net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)
>
> This is using BeanNameAutoProxyCreator, with proxyTargetClass set to
> true. I actually used another postprocessor just for this case, since
> normally I only care about interfaces, so there's nothing else in it:
>
>   <bean id="packaging-txAutoProxyCreator2"
>
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>
>     <property name="proxyTargetClass"><value>true</value></property>
>     <property name="interceptorNames">
>       <list>
>         <idref bean="hibInterceptor"/>
>         <idref local="packaging-matchAllTxInterceptor"/>
>       </list>
>     </property>
>     <property name="beanNames">
>       <list>
>            <idref local="packaging-engine"/>
>       </list>
>     </property>
>   </bean>
>
> The class in question (Engine) is a fairly simple class. It implements
> no interfaces.
>
> Regards,
> Colin
>
>

[Springframework-developer] Re: Proxying target classes

[Colin S. <col...@ex...>]

The class is not final, and there are no final methods. And I was wrong, 
it actually already implemented one interface, InitializingBean.

I was definitely wrapping the right object, as afterwards I added a new 
service interface to the object, took out the proxyTargetClass property, 
and everything is now working fine. Unfortunately I need to get this 
code working and deployed today/tomorrow, so adding the interface was 
the easiest solution. In a day or two I can try to reproduce this in a 
test case...


Rod Johnson wrote:

>I saw this once only and it was my fault (accidentally wrapped a String as
>the target, rather than real object).
>
>Are any of the methods, or the object itself, final?
>
>Can you reproduce this in a failing test case so I can look at it? There
>certainly should be a better error message, even if it's a CGLIB prob.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>;
><rod...@in...>
>Sent: Wednesday, January 28, 2004 1:20 PM
>Subject: Proxying target classes
>
>
>  
>
>>Rod,
>>
>>Have you ever seen cglib's EnhancerEmitter blow up on trying to create a
>>proxy? I generally only have to proxy interfaces, so have not proxied
>>classes too much so far, however I just had a case where I needed to
>>proxy a class directly, and got the following exception:
>>
>> method 'onMessage' due to throwable
>>[org.springframework.beans.factory.BeanCrea
>>tionException: Error creating bean with name 'packaging-engine' defined
>>in class
>>path resource [packaging-applicationContext.xml]: Initialization method
>>of bean
>>failed; nested exception is:
>>        org.springframework.aop.framework.AopConfigException: Unexpected
>>AOP exc
>>eption; nested exception is:
>>        java.lang.NullPointerException]
>>08:07:48,585 INFO  [JtaTransactionManager] Initiating transaction rollback
>>08:07:48,585 ERROR [LogInterceptor] RuntimeException:
>>org.springframework.beans.factory.BeanCreationException: Error creating
>>bean wit
>>h name 'packaging-engine' defined in classpath resource
>>[packaging-applicationCo
>>ntext.xml]: Initialization method of bean failed; nested exception is:
>>        org.springframework.aop.framework.AopConfigException: Unexpected
>>AOP exc
>>eption; nested exception is:
>>        java.lang.NullPointerException
>>org.springframework.aop.framework.AopConfigException: Unexpected AOP
>>exception;
>>nested exception is:
>>        java.lang.NullPointerException
>>java.lang.NullPointerException
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter$4.getMethods(EnhancerEmitter.java:
>>407)
>>        at
>>    
>>
>net.sf.cglib.proxy.NoOpGenerator.generate(NoOpGenerator.java:69)
>  
>
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter.emitMethods(EnhancerEmitter.java:4
>>31)
>>        at
>>net.sf.cglib.proxy.EnhancerEmitter.<init>(EnhancerEmitter.java:172)
>>
>>This is using BeanNameAutoProxyCreator, with proxyTargetClass set to
>>true. I actually used another postprocessor just for this case, since
>>normally I only care about interfaces, so there's nothing else in it:
>>
>>  <bean id="packaging-txAutoProxyCreator2"
>>
>>    
>>
>class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
>  
>
>>    <property name="proxyTargetClass"><value>true</value></property>
>>    <property name="interceptorNames">
>>      <list>
>>        <idref bean="hibInterceptor"/>
>>        <idref local="packaging-matchAllTxInterceptor"/>
>>      </list>
>>    </property>
>>    <property name="beanNames">
>>      <list>
>>           <idref local="packaging-engine"/>
>>      </list>
>>    </property>
>>  </bean>
>>
>>The class in question (Engine) is a fairly simple class. It implements
>>no interfaces.
>>
>>Regards,
>>Colin
>>
>>
>>    
>>
>
>  
>

[Springframework-developer] Re: Proxying target classes

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

Colin Sampaleanu <colinml1 <at> exis.com> writes:

> Unfortunately I need to get this code working and deployed today/tomorrow,

> so adding the interface was the easiest solution. In a day or two I can 

> try to reproduce this in a test case...



It's hard for me to test right now but FYI I'm pretty sure this bug is fixed 

in CGLIB CVS.



Chris

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

[Colin S. <col...@ex...>]

Chris Nokleberg wrote:

>Colin Sampaleanu <colinml1 <at> exis.com> writes:
>
>  
>
>>Unfortunately I need to get this code working and deployed today/tomorrow,
>>    
>>
>
>  
>
>>so adding the interface was the easiest solution. In a day or two I can 
>>    
>>
>
>  
>
>>try to reproduce this in a test case...
>>    
>>
>
>
>
>It's hard for me to test right now but FYI I'm pretty sure this bug is fixed 
>
>in CGLIB CVS.
>
>
>  
>
So you actually think this was a cglib bug? Any reason why the Spring 
unit tests would not have caught this? They should be doing similar 
stuff to my code.

 If I can get half an hour on the weekend then, I may roll back my 
changes to test the CVS version.

[Springframework-developer] Re: Proxying target classes

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

Colin Sampaleanu wrote:
> The class is not final, and there are no final methods. And I was wrong,
> it actually already implemented one interface, InitializingBean.

I sent a reply before but it didn't show up. I'm pretty sure this is a bug
that was fixed recently in CGLIB CVS. If you could try with a newer jar
file I would appreciate it, otherwise let me know how to reproduce the
problem.

Thanks,
Chris

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

[Les A. H. <le...@ha...>]

> Colin Sampaleanu wrote:
> > The class is not final, and there are no final methods. And I was wrong,
> > it actually already implemented one interface, InitializingBean.
>
> I sent a reply before but it didn't show up. I'm pretty sure this is a bug
> that was fixed recently in CGLIB CVS. If you could try with a newer jar
> file I would appreciate it, otherwise let me know how to reproduce the
> problem.

As I've missed the beginning of this thread, I apologize if what I'm about to
ask was the exact same question about Proxying via CGLIB ;)  If not, it still
is related.

We recently came across an issue that might prevent us from using Spring
(because of CGLIB dependencies) in client-tier swing/webstart/applet
deployments.

We have to sign our swing deployment jars.  After the user accepts the signed
application, it is then assigned its own protection domain for that codesource,
as per J2SE security specs.  In some of our classes, we use a custom CGLIB
proxy to wrap access to ejb handles.  We're using the CGLIB jar that came with
the SpringFramework v. 1.0 M4.

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"

This implies that any generated classes created by Spring's use of CGLIB would
not work either in a signed environment.

Our application server (which also uses CGLIB in some cases) does not have this
problem because it is granted the AllPermission upon startup, so we are happily
using Spring there.

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?

Luckily, a java.lang.reflect.Proxy conversion from our CGLIB implementation went
smoothly, but I consider that a workaround.  Just looking for information, and
seeing what you folks know about the problem...

Regards,

Les

[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

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

[Colin S. <col...@ex...>]

Chris Nokleberg wrote:

>Colin Sampaleanu wrote:
>  
>
>>The class is not final, and there are no final methods. And I was wrong,
>>it actually already implemented one interface, InitializingBean.
>>    
>>
>
>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
>that was fixed recently in CGLIB CVS. If you could try with a newer jar
>file I would appreciate it, otherwise let me know how to reproduce the
>problem.
>
>Thanks,
>Chris
>
>  
>
Chris/Rod,

I found some time just now to temporarilly back out my changes, and try 
the previous problem code with the cglib from CVS (as of yesterday), and 
indeed that version appears to resolve the problem discussed in this thread.

Rod, I'm not clear on how general a bug/problem this is in cglib (ie 
will it affect only some uses of targetProxyClass=true, or only some?), 
but does it warrant shipping a CVS version of cglib with the upcoming 
1.0RC1 version?

Regards,
Colin

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

[Colin S. <col...@ex...>]

Les A. Hazlewood wrote:

>>Colin Sampaleanu wrote:
>>    
>>
>>>The class is not final, and there are no final methods. And I was wrong,
>>>it actually already implemented one interface, InitializingBean.
>>>      
>>>
>>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
>>that was fixed recently in CGLIB CVS. If you could try with a newer jar
>>file I would appreciate it, otherwise let me know how to reproduce the
>>problem.
>>    
>>
>
>As I've missed the beginning of this thread, I apologize if what I'm about to
>ask was the exact same question about Proxying via CGLIB ;)  If not, it still
>is related.
>
>We recently came across an issue that might prevent us from using Spring
>(because of CGLIB dependencies) in client-tier swing/webstart/applet
>deployments.
>  
>
Just to clarify; if you are ok with proxying only by interfaces (the 
default for Spring, controlled by the 'proxyTargetClass' param on the 
proxy factory bean classes), then Spring actually does not have any 
cglib dependencies; it will use a standard J2SE proxy.

Now if you do set that flag to true, then it will use cglib and you will 
have the issues you mention in your environment...

Regards,
Colin

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

[Les A. H. <le...@ha...>]

> >>>The class is not final, and there are no final methods. And I was wrong,
> >>>it actually already implemented one interface, InitializingBean.
> >>>
> >>>
> >>I sent a reply before but it didn't show up. I'm pretty sure this is a bug
> >>that was fixed recently in CGLIB CVS. If you could try with a newer jar
> >>file I would appreciate it, otherwise let me know how to reproduce the
> >>problem.
> >>
> >>
> >
> >As I've missed the beginning of this thread, I apologize if what I'm about
> to
> >ask was the exact same question about Proxying via CGLIB ;)  If not, it
> still
> >is related.
> >
> >We recently came across an issue that might prevent us from using Spring
> >(because of CGLIB dependencies) in client-tier swing/webstart/applet
> >deployments.
> >
> >
> Just to clarify; if you are ok with proxying only by interfaces (the
> default for Spring, controlled by the 'proxyTargetClass' param on the
> proxy factory bean classes), then Spring actually does not have any
> cglib dependencies; it will use a standard J2SE proxy.
>
> Now if you do set that flag to true, then it will use cglib and you will
> have the issues you mention in your environment...
>
> Regards,
> Colin

Incredible.  It seems as if things are even remotely configurable, Spring can
handle it!  Fantastic work!

Thanks again,

Les