[jboss-user] [JBoss Seam] - Re: SeamRemoting Spring DelegatingVariableResolver
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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...