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
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
