[jboss-user] [JBoss Seam] - Re: SeamRemoting Spring DelegatingVariableResolver

[dan.j.allen]

Oh yeah!  I finally figured out a way to do away with the need for the delegating variable resolver all together, which in my mind really feels like the right solution to this problem!  I am now using <seam:component> to expose my Spring bean as a native Seam component instance rather than relying on the variable resolver to look it up for me each time.  Just the performance gain alone is going to make this worthwhile.

"What was the problem before?" you ask.  Ah, well, Spring proxies were giving me quite a stumble.  After A LOT of debugging inside of Eclipse, I finally got to the bottom of the matter.  Seam can only expose Cglib proxies created by Spring, not JDK proxies (and Spring cannot do javassist, which would be another alternative).  Since the default for Spring is to use JDK proxies, I was facing a sure failure.

Long story short, imagine that you have a TransactionProxyFactoryBean that you want to inject into a Seam managed component acting as a JSF backing bean...pretty standard stuff for Spring folks.  Here is how it is done in 3 steps.  (I am taking a somewhat complex example, courtesy of Appfuse).

CourseManagerImpl.java - business object
public class CourseManagerImpl extends org.appfuse.service.impl.GenericManagerImpl<Course, Long> implements CourseManager {
  |   // make CGLIB happy, feed it a default constructor
  |   public CourseManagerImpl() {
  |     super( null );
  |   }
  | 	
  |   public CourseManagerImpl( GenericDao<Course, Long> courseDao ) {
  |     super( courseDao );
  |   }
  | 
  |   // finder methods...
  | }

applicationContext.xml - Spring configuration snippet
<bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" abstract="true">
  |   <!-- Seam cannot work with JDK proxies, so we must instead use Cglib-enhanced objects -->
  |   <property name="proxyTargetClass" value="true" />
  |   <property name="optimize" value="true" />
  |   <property name="transactionAttributes">
  |     <props>
  |       <prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
  |       <prop key="*">PROPAGATION_REQUIRED</prop>
  |     </props>
  |   </property>
  | </bean>
  | 
  | <bean id="courseManager" parent="baseTransactionProxy" lazy-init="true">
  |   <seam:component beanClass="com.example.CourseManagerImpl" />
  |   <property name="target">
  |     <bean class="com.example.CourseManagerImpl" autowire="constructor"/>
  |   </property>
  |   <property name="proxyInterfaces" value="com.example.CourseManager" />
  | </bean>

CourseListAction - Seam component / JSF backing bean
@Name( "courseListAction" )
  | @Scope( ScopeType.CONVERSATION )
  | public class CourseListAction implements Serializable {
  |   @In( create = true )
  |   private CourseManager courseManager;
  | 
  |   // other stuff...
  | }

Now, the injecting of the courseManager does not rely on the Spring-JSF variable resolver and hence is available during @WebRemote calls.  Keep in mind that the Spring bean must be lazy or you get strange errors on startup.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029204#4029204

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029204