Problem with using spring bean from eagerly-fetched JSF managed bean in Glassfish

Question

I'm working on a project using JSF 2.0 and Spring 3.0.5, which is running on Glassfish 3.1 open source edition. Then I have a ApplicationScoped managed bean declared with 'eager':

@ManagedBean(eager = true)
@ApplicationScoped
public class CommonMB

which have a managed property injected using EL:

@ManagedProperty(#{foo})
private Foo foo;

and then configure foo in Spring context file:

<bean id="foo" class="Foo" />

lastly configure Spring EL resolver in faces-config.xml:

<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>

After all when I started up Glassfish, exceptions are thrown indicating the managed propertiy was not injected correctly:

Caused by: com.sun.faces.mgbean.ManagedBeanCreationException: unable to set property 'foo' on managed bean 'commonMB'
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:615)
at com.sun.faces.mgbean.ManagedBeanBuilder.buildBean(ManagedBeanBuilder.java:133)
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:104)
at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409)
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269)
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:256)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:255)
... 76 more
Caused by: java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered?
at org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationContext(FacesContextUtils.java:83)
at org.springframework.web.jsf.DelegatingVariableResolver.getWebApplicationContext(DelegatingVariableResolver.java:167)
at org.springframework.web.jsf.DelegatingVariableResolver.getBeanFactory(DelegatingVariableResolver.java:156)
at org.springframework.web.jsf.DelegatingVariableResolver.resolveSpringBean(DelegatingVariableResolver.java:134)
at org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:112)
at com.sun.faces.el.VariableResolverChainWrapper.getValue(VariableResolverChainWrapper.java:115)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at de.odysseus.el.tree.impl.ast.AstIdentifier.eval(AstIdentifier.java:84)
at de.odysseus.el.tree.impl.ast.AstEval.eval(AstEval.java:51)
at de.odysseus.el.tree.impl.ast.AstNode.getValue(AstNode.java:30)
at de.odysseus.el.TreeValueExpression.getValue(TreeValueExpression.java:122)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55)
at com.sun.faces.mgbean.BeanBuilder$Expression.evaluate(BeanBuilder.java:591)
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:606)
... 82 more

Since I'm using ContextLoaderListener to initialize Spring beans, and from the stacktrace it seems when JSF begin to initialize JSF beans in com.sun.faces.config.ConfigureListener, Spring context has not been set up yet, and that's why this exception happens.

So I'm wondering if there is something wrong with the initialization order between ConfigureListener(JSF) and ContextLoaderListener(Spring), Spring listener should come before JSF listener, but it didn't. Furthermore, JSF listener is configured in JSF impl implicitly and I don't know how can I change their order.

BTW, everything is OK when it's running on Tomcat 7, but on Glassfish 3.1 it messed up. Maybe there's something to do with different container implementation on invoking order of listeners?

Any idea about this problem? Thanks in advance!

Answer 1

everything is OK when it's running on Tomcat 7, but on Glassfish 3.1 it messed up

did you check the dependencies of your project ? afaik tomcat 7 does not provide jsf 2.0 support out of the box

for the proper configuration this spring forum thread might be useful http://forum.springsource.org/showthread.php?86577-Spring-3-JSF-2&p=290645#post290645