Develop JSF Portlet Compatibility with Contexts and Dependency Injection (CDI)

• Type: New Feature
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: None
• Fix Version/s: 3.1.2-ga3
• Component/s: liferay-faces-bridge
• Labels: None
• Similar Issues: Show 5 results ; ;

  FACES-1507	Develop jsf2-cdi-portlet demo
  FACES-1531	Develop new 4.1.x branch with compatibility for JSF 2.2 + Liferay Portal 6.1
  FACES-1583	Excluded javaee.api module from WEB-INF/jboss-deployment-structure.xml disables CDI and annotation processing in jsf2-cdi-portlet demo on JBoss AS
  FACES-1547	Specify version of CDI and JBoss Weld dependencies in master POM
  FACES-1377	Develop new liferay-faces-bridge-ice.jar dependency

This feature includes making sure that the new Java EE 6 Contexts and Dependency Injection (CDI) feature works with Liferay Faces Bridge in Liferay Portal. Plans are to test against JBoss Weld, but not Open WebBeans. Now that the WELD-510 issue has been fixed, it should be possible to verify that this works.

[Neil Griffin]

I spent some time today testing JSF2 + CDI (Weld 1.1.7) in Liferay 6.1.0.

I wasn't able to get it working with Tomcat 7 because it caused the following stacktrace:

java.lang.IllegalStateException: Must call associate() before calling activate()
 at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:277)
 at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:110)
 at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
 at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
 at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
 at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
 at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)

I wasn't able to get it working with GlassFish 3.1.1 either. It had the same stacktrace as Tomcat. It turns out that GlassFish bundles weld-osgi-bundle-1.1.1.Final.jar which doesn't contain the fix for WELD-510. When I tried to upgrade GlassFish to weld-osgi-bundle-1.1.7.Final.jar it started throwing NoClassDefFound exceptions:

org.jboss.weld.exceptions.WeldException: by java.lang.NoClassDefFoundError: org/jboss/weld/interceptor/proxy/LifecycleMixin
	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:282)
	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:236)
	at org.jboss.weld.bean.builtin.ee.AbstractEEBean.<init>(AbstractEEBean.java:43)
	at org.jboss.weld.bean.builtin.ee.UserTransactionBean.<init>(UserTransactionBean.java:52)
	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:190)
	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)

I tried to get it working in the Liferay+JBoss bundle, but it comes bundled with JBoss AS 7.0.2 which doesn't work with JSF 2.1. Finally I was only able to get it working in JBoss AS 7.1.1 – I had to install the Liferay Portal WAR into JBoss AS 7.1.1 manually. Although the portlet worked with @Inject on the initial render, I wasn't able to navigate from one Facelet view to another without getting an exception thrown by Weld:

16:11:34,534 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http--127.0.0.1-8080-4) Error Rendering View[/views/portletViewMode.xhtml]: javax.enterprise.context.ContextNotActiveException: Conversation Context not active when method called on conversation Transient conversation
	at org.jboss.weld.context.conversation.ConversationImpl.verifyConversationContextActive(ConversationImpl.java:197) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
	at org.jboss.weld.context.conversation.ConversationImpl.isTransient(ConversationImpl.java:149) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
	at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:102) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
	at com.sun.faces.renderkit.html_basic.FormRenderer.getActionStr(FormRenderer.java:232) [jsf-impl-2.1.7-jbossorg-2.jar:]
	at com.sun.faces.renderkit.html_basic.FormRenderer.encodeBegin(FormRenderer.java:135) [jsf-impl-2.1.7-jbossorg-2.jar:]

As a part of this issue, I would think that testing the Seam Faces module is also required. This is because if you want to use JSF2 @ViewScoped in combination with Weld, you would need to add the Seam Faces module. Unfortunately SEAMFACES-222 is preventing Seam Faces from working in portlet environments.

[Robin Wyss]

I tried to use Weld with tomcat 6/7. I was able to get rid of the "Must call associate() before calling activate()" with the WeldCrossContextFilter. But i then came across another problem, the org.jboss.weld.jsf.WeldPhaseListener makes casts the request to a HttpServletRequest, which causes a ClassCastException in the portlet environment.

[Neil Griffin]

@Robin: What version of Weld did you try with Tomcat?

[Robin Wyss]

It was 1.1.7.Final (weld-core and weld-servlet)

[Neil Griffin]

Progress on this issue is currently blocked because of https://issues.jboss.org/browse/WELD-1142

[Ivar Kanters]

What is the status of this issue? Is there a workaround? I'm having the same problem when using CDI (beans.xml) in my application (on glassfish 3.1.2.2 Liferay 6.1.1-ce-ga2).

[Neil Griffin]

Unfortunately there is no workaround at this time, but we're making good progress. The kind folks at JBoss have put together the following Wiki as a preliminary set of requirements:

https://github.com/jboss/cdi/wiki/CDI-Portlet-integration

[Neil Griffin]

Update: I was able to get a locally developed CDI based version of the jsf2-portlet working with @Inject today with JBoss Weld. Support right now is at the experimental stage. More news should be coming next week.

[Ivar Kanters]

Is there any news on this issue? (It's been more than a week since last comment ) I'm still facing the problem daily and have to make unnecessary sessionbeans (and inject them with @EJB) to workaround the problem. Also created a lot of "old fashion" factory classes where CDI would be much cleaner.

[Juan Gonzalez]

Great step forward having CDI in Liferay

[Neil Griffin]

@Ivar: We are developing a CDI compatibility JAR that might help. I will report back here when we have a JAR you can try. It might be another week or two before it's ready. Thanks for being so patient. – Neil

[Alfonso Mateos]

Good Morning, Neil, do you know an approximate date for this issue to be closed? It would be great to use CDI right from JSF portlets

[Neil Griffin]

Hi Everyone,

I want to thank everyone watching this ticket for being so patient. I know that this feature has been a long time coming.

The good news is that we just committed the new jsf2-cdi-portlet demo to Git. For more information, see: FACES-1507. As I mentioned in that ticket, we don't have the source code committed to Git for the new cdi1-portlet-bridge-shared.jar dependency. Please continue watching this issue (FACES-1211) to learn about when that code is available. You might also want to look at FACES-1546 which documents a new feature for detecting the version of CDI in the classpath.

Thanks again,

Neil

[Neil Griffin]

Please refer to the wiki article titled Developing JSF Portlets with CDI .