Loggin AOP problem

[denis.zhdanov]

I succeeded in running your example eventually.

Solution:

1. Define target managed bean at the spring config (add the following declaration to it - '<bean id="testBean" class="com.test.BeanTest"/>');
2. Add 'cglib' library to your applications dependencies (necessary for creating aop proxy for the target bean);
3. Use 'SpringBeanVariableResolver' instead of 'DelegatingVariableResolver' at the 'faces-config.xml':
   

   <application>
       <view-handler>com.icesoft.faces.facelets.D2DFaceletViewHandler</view-handler>
       <variable-resolver>org.springframework.web.jsf.SpringBeanVariableResolver</variable-resolver>
   </application>

[necronet]

Well it work i just have one question why i couldnt do it with my bean on faces-config.xml isnt wrong to create two beans with the same name???

Spring context

<bean id="testBean" class="com.test.BeanTest"/>

Faces config

 <managed-bean>
               <managed-bean-name>testBean</managed-bean-name>
               <managed-bean-class>com.test.BeanTest</managed-bean-class>
               <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

Or Spring has a way to keep both object with the same reference??

[denis.zhdanov]

Dude, I've never worked either with jsf or spring jsf at all

All I can do here is to provide you a guide line on how I sorted out your problem:

1. Started the application at your initial configuration;
2. Checked call stack when 'BeanTest.myMetodo()' was called and detected that spring was not involved to the processing;
3. Read javadoc for the spring class that was used at your config - DelegatingVariableResolver:
   

   SF 1.1 VariableResolver that first delegates to the original resolver of the underlying JSF implementation (for resolving managed-bean objects as defined in faces-config.xml as well as well-known implicit EL attributes), then to the Spring root WebApplicationContext (for resolving Spring beans).

4. I know spring aop principles and realize that aop logic is involved only if aop proxy is called instead of the 'raw' bean, so, I became suspicious for the message 'first delegates to the original resolver of the underlying JSF implementation';
5. The javadoc also mentions JSF 1.1 VariableResolver, so, I checked what spring implementations of it are available over than DelegatingVariableResolver;
6. I found SpringBeanVariableResolver that states the following:
   

   This is a subclass of the JSF 1.1 DelegatingVariableResolver, letting Spring bean definitions override other attributes of the same name.

   So, it looked like it tries to use the beans from spring context whenever possible;
7. I checked DelegatingVariableResolver javadoc mentions jsf config snippet where jsf and spring stuffs are linked via spring bean name;
8. I tried to combine all of above together and checked that it works as expected now;

You can find all of the further jsf-related answers by yourself using the similar algorithm. Spring provides an excellent documentation (either reference or javadoc). Just don't be afraid to work with it.

One more important note - I believe that it's very-very-very-very-...-very important to avoid leaky abstractions, i.e. should have an understanding either of spring or jsf principles in order to be able to work with them at good level. I have a good spring knowledge and some basic understanding of JSF ideas, that helped me to find out the problem.

[necronet]

i apreciate it then thank you