Configuration for Faces Flow

[Micael Ericsson, modifié il y a 7 années.]

Our platform har recently moved to Liferay 6.2 (on Tomcat 7) and we pushed JSF to version 2.2.
We have several "wizard" style portlets in our portal. I am looking at Faces Flow to see if this can be a new "framework" for our wizards.

I have searched and found different suggestions but not a workable one for our platform.

First is the proper configuration of Liferay/Tomcat in order to get CDI to work, which I understand is needed for Faces Flow.

One guide suggested to put weld-servlet.jar in TOMCAT_HOME\lib (with context configuration) but this ended up in class not found exception (possible due to class clash problem).
Another guide with the approach to configure CDI in each portlet ended up in a blank portlet with no information why it didn't work.

Liferays tutorial on CDI shows the configuration of portlets but the link to configure Liferay with weld only points to standard setup of Liferay on Tomcat, nothing about weld.
(https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/contexts-and-dependency-injection-for-jsf-portlets#configuring-jsf-portlets-to-use-cdi).

I would like a tutorial on how to setup a portlet with faces flow running on Liferay 6.2/Tomcat 7 platform.
I would also like to know if CDI configuration should be done in Liferay/Tomcat or in each portlet.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

When you get an opportunity, I recommend that you download our jsf2-flows-portlet demo war and deploy it in your Liferay 6.2 + Tomcat 7 environment.

The demo has WEB-INF/lib/weld-servlet.jar as well as some config settings in portlet.xml and web.xml to make CDI work correctly.

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Neil Griffin:

Hi Micael,

When you get an opportunity, I recommend that you download our jsf2-flows-portlet demo war and deploy it in your Liferay 6.2 + Tomcat 7 environment.

The demo has WEB-INF/lib/weld-servlet.jar as well as some config settings in portlet.xml and web.xml to make CDI work correctly.

Kind Regards,

Neil

Hi Neil

I forgot to mention that I have tried that but stumbled upon building. I downloaded the whole liferay-faces tree (https://github.com/liferay/liferay-faces/tree/4.2.5-ga6) and opened the jsf2-flows-portlet in NetBeans. Did a clean then a build with dependencies. This is the error message I got:

Liferay Faces Parent .............................. SUCCESS [4.568s]
Liferay Faces Util ................................ SUCCESS [7.211s]
Liferay Faces Alloy ............................... FAILURE [2.892s]
Liferay Faces Bridge API .......................... SKIPPED
Liferay Faces Bridge .............................. SKIPPED
Liferay Faces Demos ............................... SKIPPED
Liferay Faces Bridge Demos ........................ SKIPPED
JSF2 Flows Portlet ................................ SKIPPED
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 20.793s
Finished at: Wed Jul 06 10:09:50 CEST 2016
Final Memory: 31M/437M
------------------------------------------------------------------------
Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project liferay-faces-alloy: An Ant BuildException has occured: Warning: Could not find file C:\Project\Test\liferay-faces-4.2.5-ga6\reslib\target\classes\META-INF\yui3-bsd-license.txt to copy.
around Ant part ...<copy file="C:\Project\Test\liferay-faces-4.2.5-ga6\alloy/../reslib/target/classes/META-INF/yui3-bsd-license.txt" tofile="C:\Project\Test\liferay-faces-4.2.5-ga6\alloy\target/classes/META-INF/resources/liferay-faces-alloy/yui/yui3-bsd-license.txt"/>... @ 4:252 in C:\Project\Test\liferay-faces-4.2.5-ga6\alloy\target\antrun\build-main.xml
-> [Help 1]

I guessed I needed to build reslib first so I did with the following error:

Liferay Faces Parent .............................. SUCCESS [0.952s]
Liferay Faces Util ................................ SUCCESS [2.983s]
Liferay Faces Resource Library .................... FAILURE [2.771s]
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 8.099s
Finished at: Wed Jul 06 10:15:52 CEST 2016
Final Memory: 33M/542M
------------------------------------------------------------------------
Failed to execute goal com.googlecode.maven-download-plugin:download-maven-plugin:1.2.1:wget (unpack-alloy) on project liferay-faces-reslib: IO Error: Could not get content -> [Help 1]

Then I tried to open parent pom (perhaps I should have started here) and build complete project but the build stopped at reslib with same error as above. Googled the error but couldn't find any help.

Can you help me with this. I downloaded the zip - I don't have any Git client installed.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

If you are building the ZIP for the 4.2.5-ga6 tag from GitHub then you will need to make the following change in the liferay-faces/reslib/pom.xml descriptor because the download URL for AlloyUI changed after the Liferay Faces release:

<configuration>
     <url>https://github.com/liferay/liferay-portal/raw/0f75db5b5c6a8a7c6b07295cc12acdf362bfb1b4/portal-web/third-party/alloy-${alloyui.zip.version}.zip</url>
    <unpack>true</unpack>
    <outputdirectory>${project.build.directory}/classes/META-INF/resources</outputdirectory>
    <md5>37cb9069053f2e181bd26bd78a216c53</md5>
 </configuration>

Alternatively, you can try building with the 4.x branch of our new liferay-faces-bridge-impl.git repository. For more information, see the following blog entries:

• New Git Repositories for Liferay Faces
• New Liferay Faces Version Scheme
• Liferay Faces Project News - April 2016
• OSGi File Naming Convention for Liferay Faces Artifacts
• New Maven Archetypes for JSF Portlets

Note: If you build with the 4.x branch, be sure to include "-P liferay62" on the mvn command line to build WARs for Liferay 6.2 instead of 7.0.

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

The configuration did the trick. Building went smooth for JSF2 Flow part. It crashed later in process but I only needed the jsf2flow.

Next step is to deploy and I got 2 class not found error:
- weld-servlet and spi/Contextual.

I read through the CDI for JSF portlets document and added a couple of configurations in portlets web.xml. Still deploy error.
Since weld-servlet is a vital part and cause error I search for it in war-fil - not included. Found in portlets web.xml that it is in depency but in profile Tomcat or Jetty. We are using Tomcat. I haven't used profile with maven before so instead of learning this I moved the weld-servlet dependency from profile to a direct dependency. Now I could deploy and run the portlet. I could start the booking flow and move to the Flight.

Thanks for this help. Next step is to make my own flow portlet and with this base I think it would work.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

You can activate the liferay and tomcat profiles with "mvn -P liferay,tomcat clean package"

I'm glad it is working for you. Thanks for using Liferay Faces!

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

I tried to convert one of our existing Liferay portlets to faces flow with following:
- created meta-inf/context.xml
- created web-inf/beans.xml
- added info about cdi filter to portlet.xml
- added info cdi and weld to web.xml
Contents for above files are taken from the jsf2flow portlet.

Created a flow with 3 pages and one bean. The scenario was to keep my old first page and from that page start the flow.
After building I got the following error upon deploy:

13:32:08,299 INFO [servletWeldServlet:57] WELD-ENV-001008: Initialize Weld using ServletContainerInitializer
jul 08, 2016 1:32:08 EM org.apache.catalina.startup.HostConfig reload
VARNING: Error during context [/MinaUppgifter] restart
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/MinaUppgifter]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at org.apache.catalina.startup.HostConfig.reload(HostConfig.java:1533)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1497)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1695)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:333)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchFieldError: CONTAINER_ATTRIBUTE_NAME
at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:136)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:61)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5517)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 11 more

I looked into jsf2flow but couldn't find any information about "CONTAINER_ATTRIBUTE_NAME". I also googled for it but couldn't find any information.

If I try to open page with portlet nothing is shown. Appearently because of above error.

Any suggestions on what I am missing?
Included the zipped portlet if that could help.

My summer leave starts on Monday. It is possible I occasionally drop in at the office during this 4-weeks leave so feel free to suggest solutions.

[Micael Ericsson, modifié il y a 7 années.]

Back from a really nice vecation. Any suggestions on how to proceed with my problems?

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

Moving forward we will be maintaining Liferay Faces artifacts from our new Git repositories under our new Version Scheme.

We plan on releasing artifacts from these new repositories this month (August, 2016) and it would be easier for us to help you if you migrated to these new artifacts as dependencies in your project.

If you have time, could you please try our new jsf-flows-portlet.war artifact that I've attached to this thread? It is designed to work in a Liferay 6.2 + JSF 2.2 + CDI 1.2 + Weld 2.3.3.Final environment.

Thanks,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Neil Griffin:

....
If you have time, could you please try our new jsf-flows-portlet.war artifact that I've attached to this thread? It is designed to work in a Liferay 6.2 + JSF 2.2 + CDI 1.2 + Weld 2.3.3.Final environment.

The jsf-flows-portlet worked without any problem.
I upgraded my portlets weld-servlet dependency to version 2.3.3. Not sure if I made any more changes, but now it's working. I have a working flow of three steps.

One thing though. In our latest release we put some time into friendly-urls. In the jsf2 flows demo the url is the same through out the flow ("http://domain.xx/test").
When I start my flow the url is not "friendly".

http://domain.xx/group/s/mina-uppgifter?p_auth=2ytYdKuW&p_p_id=MinaUppgifter_WAR_MinaUppgifter&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_MinaUppgifter_WAR_MinaUppgifter_javax.faces.ClientWindow=BA8E599544DD26A1D0EDCAE254D02E90%3A_MinaUppgifter_WAR_MinaUppgifter_%3A2&_MinaUppgifter_WAR_MinaUppgifter__facesViewIdRender=%2Fviews%2FminaUppgifterIntro.xhtml

"Mina uppgifter" is the name of the portlet.

Our friendly-url configuration is made in liferay-portlet.xml with:

<friendly-url-mapper-class>com.liferay.portal.kernel.portlet.DefaultFriendlyURLMapper</friendly-url-mapper-class>
<friendly-url-mapping>an</friendly-url-mapping>
<friendly-url-routes>ansokan-friendly-url-routes.xml</friendly-url-routes>

And then mapped in minauppgifter-friendly-url-routes.xml as:

<routes>
<route>
<pattern>/steg2</pattern>
<implicit-parameter name="_facesViewIdRender">/minaflow/steg2.xhtml</implicit-parameter>
</route>
<route>
<pattern>/minaflow</pattern>
<implicit-parameter name="_facesViewIdRender">/minaflow/minaflow.xhtml</implicit-parameter>
</route>
<route>
<pattern>/minauppgifter</pattern>
<implicit-parameter name="_facesViewIdRender">/views/minaUppgifterIntro.xhtml</implicit-parameter>
</route>
</routes>

Is this the proper way to get friendly-url working with flow ?
And why does your and my portlet differ in url output?

Regards,
Micael

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

The jsf-flows-portet I attached uses f:ajax to navigate from view to view, which is why the URL stays the same the whole way through.

I am pleased to report that the version(s) of Liferay Faces Bridge associated with our new version scheme will support friendly ActionURL and ResourceURL. Prior to that, the bridge only supported RenderURL. For more information, see: FACES-2654.

I would recommend that you make sure that you are using the -SNAPSHOT dependencies of our new artifacts as your dependencies in WEB-INF/lib. You can get them from our Snapshot Repository or from the WEB-INF/lib folder of the attached jsf-flows-portlet. See the blog post titled Liferay Faces Project News - April 2016 for more information.

Thanks,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

I added com.liferay.faces.bridge.ext-7.0.0-SNAPSHOT (latest version I could find) to our portlet, Built and deployed it.
Upon running I got a runtime exception:

java.lang.ClassNotFoundException: javax.portlet.HeaderRequest

Since the demo used 3.0.0-SNAPSHOT i tried that also. New runtime exception:

java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:org/osgi/framework/FrameworkUtil

I received .faces.bridge-api-4.0.0-SNAPSHOT and faces.util-3.0.0-SNAPSHOT when building with latest dependency.

Can there be a problem for us running this on Liferay 6.2?

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

The reason why you are seeing the "javax.portlet.HeaderRequest" error is because the master/7.x branch of liferay-faces-bridge-ext.git is designed for JSF 2.3 + Portlet 3.0, and HeaderRequest is part of the Portlet 3.0 API.

For Liferay 6.2, you need to be using the 3.x version (3.0.0-SNAPSHOT), which is JSF 2.2 + Liferay 6.2. That would be the "latest" version for JSF 2.2 + Liferay 6.2. For more information, see our new version scheme.

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

As I stated in my last post I also tried with version 3.0.0.-SNAPSHOT and got an concurrentexception upon deploy.
I tried to update our liferay faces dependecies to match those in the jsf-demo. Now deploy worked but I get an exception when visiting page with portlet.

The error:

ALLVARLIG: Servlet.service() for servlet MinaUppgifter Servlet threw exception javax.portlet.faces.BridgeException: javax.faces.FacesException
at com.liferay.faces.bridge.internal.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:99)
at com.liferay.faces.bridge.internal.BridgeImpl.doFacesRequest(BridgeImpl.java:141)
at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:673)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:359)
at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:589)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:262)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:55)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:112)
...
16:59:58,827 ERROR [http-nio-8443-exec-2][render_portlet_jsp:132] null
java.lang.NullPointerException
at com.liferay.faces.bridge.renderkit.html_basic.internal.BodyRendererBridgeImpl.encodeBegin(BodyRendererBridgeImpl.java:115)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:865)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:458)
at javax.faces.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:146)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at com.liferay.faces.bridge.application.internal.ViewHandlerCompatImpl.renderView(ViewHandlerCompatImpl.java:95)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)

Portlets dependencies:

activation-1.1.jar
AtlasClientProxy-12.0.jar
cdi-portlet-bridge-shared-6.2.0.2.jar
com.liferay.faces.alloy-2.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.api-4.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.ext-3.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.impl-4.0.0-SNAPSHOT.jar
com.liferay.faces.util-3.0.0-SNAPSHOT.jar
esapi-2.0.1.jar
JavaxEjb-1.0.jar
jboss-el-2.0.0.GA.jar
jsf-api-2.2.12.jar
jsf-impl-2.2.12.jar
mail-1.4.7.jar
primefaces-5.3.jar
weld-servlet-2.3.3.Final.jar

Any suggestions?

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

The jsf-flows-portlet war contains the following relevant dependencies:

com.liferay.faces.alloy-2.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.api-4.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.ext-3.0.0-SNAPSHOT.jar
com.liferay.faces.bridge.impl-4.0.0-SNAPSHOT.jar
com.liferay.faces.util-3.0.0-SNAPSHOT.jar
javax.faces-2.2.13.jar
log4j-1.2.14.jar
weld-servlet-2.3.3.Final.jar

Regarding Mojarra, you can use the javax.faces-2.2.13.jar monolithic (API + Impl) jar or the separate jsf-api/jsf-impl jars like you have.

Also, you can delete this dependency from your project since it is no longer necessary with Weld 2.x:
cdi-portlet-bridge-shared-6.2.0.2.jar

Finally, I'd recommend that you compare the web.xml and portlet.xml descriptors from the jsf-flows-portlet with yours. There might be some com.liferay.cdi type entries in there associated with cdi-portlet-bridge-shared-6.2.0.2.jar that you don't need anymore.

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

CDI dependency and settings are now removed, but nothing has changed.
I also compared all my xml-configuration files with the one in jsf-demo - remove a couple more settings. Same runtime error.
Google the error but couldn't find any suitable suggestion.

Any more suggestions?

More stack trace:

ALLVARLIG: Servlet.service() for servlet MinaUppgifter Servlet threw exception
javax.portlet.faces.BridgeException: javax.faces.FacesException
at com.liferay.faces.bridge.internal.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:99)
at com.liferay.faces.bridge.internal.BridgeImpl.doFacesRequest(BridgeImpl.java:141)
at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:673)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:359)
at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:589)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:262)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:55)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at org.jboss.weld.servlet.WeldCrossContextFilter.doFilter(WeldCrossContextFilter.java:67)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:204)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:109)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543)
at com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:583)
at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:656)
at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:362)
at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(render_005fportlet_jsp.java:1239)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

When you get an opportunity, please attach the latest version of your project to this forum thread. It would be best if you could provide a project in source form that we can build with Maven.

Thank you,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

Supplied is maven project of portlet.
I think I have removed/commented out code with dependency to our backend code.

Regards,
Micael

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

Thank you for the sample portlet in source form. I took a quick look at the pom.xml descriptor and noticed that javax.servlet-api needs to have <scope>provided</scope> because when I build the portlet, I saw this:

WEB-INF/lib/javax.servlet-api-3.0.1.jar

I will make it <scope>provided</scope> locally for now and then try to reproduce the Faces Flow problem.

Kind Regards,

Neil

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

I reproduced the issue. The first problem I found was that the XHTML files are missing the <h:head /> component, which is necessary in order to make the bridge's HeadRenderer render resources to the <head>...</head> section of the portal page.

The other problem was the presence of the following in the WEB-INF/faces-config.xml descriptor:

<default-render-kit-id>PRIMEFACES_MOBILE</default-render-kit-id>

Apparently we have an incompatibility between Liferay Faces Bridge and the PrimeFaces Mobile render-kit. Is it essential to your project?

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil,
and thanks for the time you take.

The absense of <h:head.. was due to a flow problem I was waiting with. But since you noticed: The problem I had was that with h:head the flow didn't start when clicking to start it. Remove h:head and it worked. This was the simple portlet based from jsf-demo settings.

Regarding Prime faces we have extensive use of them. When moving to 6.2 our site should also be responsive and we based that upon Prime faces mobile. Working fine. Replacing Prime Faces is not an option right now.

I tried to find any bug report on this but couldn't. What is your input on this?

[Neil Griffin, modifié il y a 7 années.]

Micael Ericsson:

The absense of <h:head.. was due to a flow problem I was waiting with. But since you noticed: The problem I had was that with h:head the flow didn't start when clicking to start it. Remove h:head and it worked. This was the simple portlet based from jsf-demo settings.

I checked the Facelet views in the jsf-flows-portlet demo like booking.xhtml, and returnFromSurveyFlow.xhtml and they all contain the h:head component. Both h:head and h:body will be necessary in any view (but not in a ui:composition that is included with ui:include or something like that). If this is still an issue for you, then please post another maven project that reproduces the problem and we can treat that separately.

Micael Ericsson:

Regarding Prime faces we have extensive use of them. When moving to 6.2 our site should also be responsive and we based that upon Prime faces mobile. Working fine. Replacing Prime Faces is not an option right now.

I just visited the p:dataTable example of the PrimeFaces Showcase and resized the browser to be fairly small. PrimeFaces seems to have very good responsive UI built into it without using the mobile renderkit. Are there certain responsive benefits provided that the mobile renderkit that are essential to your project and are not found in the ordinary PrimeFaces components?

Micael Ericsson:

I tried to find any bug report on this but couldn't. What is your input on this?

I recently created FACES-2910 in order to track this issue. Please click on the "watch" link in JIRA to be notified with status updates.

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

Regarding Jira FACES-2910 and steps to reproduce:
- In production we have several portlets with liferay-faces-bridge-impl-4.2.5.jar and PRIMEFACES_MOBILE as default render. Working fine.
My problem occured when using 4.0.0.-SNAPSHOT version of bridge impl. FYI.

Regarding using Primefaces mobile we are using pm:field in all our input fields and styling is based upon pm:field. It is possible to change but it is time consuming to change styling.

Regarding the h:head problem I will get back to that issue when above steps are solved. Right now I am setting up environment without PrimeFaces but still having problem. Supplied is a portlet project starting from previous supplied MinaUppgifter. I tried to remove all reference to PrimeFaces. Renamed project to DemoFlowTest.
Build, Deploy and Load page works fine, but starting flow gives the following error:

java.lang.NullPointerException
- STACK TRACE
java.lang.NullPointerException
at com.liferay.faces.bridge.renderkit.html_basic.internal.BodyRendererBridgeImpl.encodeBegin(BodyRendererBridgeImpl.java:115)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:865)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:458)
at javax.faces.view.ViewDeclarationLanguageWrapper.renderView(ViewDeclarationLanguageWrapper.java:146)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at com.liferay.faces.bridge.application.internal.ViewHandlerCompatImpl.renderView(ViewHandlerCompatImpl.java:95)

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

Thank you for the updated reproducer portlet. We are very close to the end of our testing phase prior to releasing the Liferay Faces artifacts from the new Git repositories. We should be able to focus on FACES-2910 soon after the release. Now that our artifacts are on separate release schedules, we should be able to provide a dot/patch release that includes a fix for FACES-2910 more quickly than normal.

Kind Regards,

Neil

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

As you may have seen, last week we released our new artifacts based on our new version scheme.

Although the release did not include a fix for FACES-2910, the fix was committed today under FACES-2921 and will appear in the next "patch" release of Liferay Faces Bridge. When you get a chance, please try version 4.0.1-SNAPSHOT from our Snapshot Repository and let us know if the NullPointerException goes away.

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

I changed to 4.0.1-SNAPSHOT of bridge impl. It didn't work - same NPE as earlier. Then I dowloaded the source code in order to debug.

I found the problem in encodeBegin method of BodyRendererBridgeImpl class. At row 95 I have the following:

Map<Object, Object> facesContextAttributes = facesContext.getAttributes();
List<UIComponent> headResourcesToRenderInBody = (List<UIComponent>) facesContextAttributes.get(
HeadRendererBridgeImpl.HEAD_RESOURCES_TO_RENDER_IN_BODY);

When debugging headResourcesToRenderInBody is null which causes NPE at row 115 (for loop). Adding "if null" and rebuilding - my little demo flow portlet works. You should be able to reproduce the problem and the solution in the project I supplied earlier.

The NPE occured when starting the flow in my simple demo.
If I included PrimeFaces 6 and added render kit info for mobile the above problem occured when loading page.
Same exception only at two different occations.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

Thanks for trying the snapshot version of the bridge. Our project schedule should allow us to revisit this issue and try to reproduce the problem again on Monday, September 12.

Kind Regards,

Neil

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

In the meantime, please make sure you have h:head and h:body in your views. If the presence of h:head is causing another problem, then please let us know the details.

Thank you,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Neil Griffin:

Hi Micael,
In the meantime, please make sure you have h:head and h:body in your views. If the presence of h:head is causing another problem, then please let us know the details.
Thank you,
Neil

Reviewing my demo code I found that start view has h:head tag but the flow pages didn't. Adding h:head to them solved the NPE problem.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

I'm glad to hear that it is working for you now. Thanks for letting us know

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

I continue on this thread since the next problem I came across is based on my demo flow portlet.

So the next step is to add CDI to my beans. I have the following classes:

• demoflowmodelbean (flow scope),
• demoflowbackingbean (request scope)
• demoflowservice (application scope).

Structure and contents for these are based on demo jsf flow portlet. The backing bean has a @inject to access service.
The problem I have is when my backing bean tries to access injected service this service is not created and I get a NPE.

Looking through the jsf flow demo I can't find how the service is created. What am I missing?.

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

What does your service java source look like? The BookingServiceMockImpl.java class in the jsf-flows-portlet demo has a CDI bean annotated with @ApplicationScoped. If you are doing the same thing and want it managed by CDI, then make sure you are importing javax.enterprise.context.ApplicationScoped and not javax.faces.bean.ApplicationScoped.

Neil

[Micael Ericsson, modifié il y a 7 années.]

Neil Griffin:

Hi Micael,

What does your service java source look like? The BookingServiceMockImpl.java class in the jsf-flows-portlet demo has a CDI bean annotated with @ApplicationScoped. If you are doing the same thing and want it managed by CDI, then make sure you are importing javax.enterprise.context.ApplicationScoped and not javax.faces.bean.ApplicationScoped.
Neil

Yes, I am importing javax.enterprise.context.ApplicationScoped. I was missing the interface for my service-class. Creating an interface and implementing class solved this problem.

But then I ran into a "common" problem: "WELD-001303: No active contexts for scope type javax.faces.flowScoped". Google gave a couple of suggestions to this problem but none could help me.

ALLVARLIG: Servlet.service() for servlet DemoFlow Servlet threw exception
javax.portlet.faces.BridgeException: javax.portlet.faces.BridgeException: javax.faces.FacesException: #{demoFlowController.initDemoflow}: org.jboss.weld.context
.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped
at com.liferay.faces.bridge.internal.BridgePhaseActionImpl.execute(BridgePhaseActionImpl.java:135)
at com.liferay.faces.bridge.internal.BridgeImpl.doFacesRequest(BridgeImpl.java:93)
at javax.portlet.faces.GenericFacesPortlet.processAction(GenericFacesPortlet.java:501)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:71)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:48)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:112)

I provided latest build of Demo project. Any suggestions on what the problem could be?

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

Sorry for the delay in responding. Thank you for attaching DemoFlowTest.zip -- I noticed the following issues:

1. The WEB-INF/liferay-portlet.xml descriptor has an element ordering problem which causes the portlet to have a DTD validation error upon deployment. In order to fix it, I had to move <portlet-name>DemoFlow</portlet-name> to be the first element after the opening <portlet> element.

2. There are no @ApplicationScoped beans in the project.

3. The following code causes Weld to throw ContextNotActiveException because you attempt to access a @FlowScoped bean before the initDemoflow() method returns. The return value of that method is used by the JSF navigation-handler to begin the flow of views in the /demoflow folder. This means that you can't call itsDemoFlowModelBean.setTexter(texter) until after the flow begins.

@Named
@RequestScoped
public class DemoFlowController
{
	@Inject
	private TextService itsTextService;

	@Inject
	private DemoFlowModelBean itsDemoFlowModelBean;

	public String initDemoflow()
	{
		HashMap<string, string> texter = itsTextService.readTexter(64L, 12L);
		itsDemoFlowModelBean.setTexter(texter);

		return "demoflow";
	}
}</string,>

Kind Regards,

Neil

[Micael Ericsson, modifié il y a 7 années.]

Hi Neil

Great feedback on when flow scope starts. I changed a bit in my logic and now my demo works as intended. I have a class with Application scope and that wrosk as inteded too.

Regards,
Micael

[Neil Griffin, modifié il y a 7 années.]

Hi Micael,

I'm so glad things are working for you now. Thanks for letting us know.

Neil

[Neil Griffin, modifié il y a 6 années.]

Hi Micael,

Just wanted to mention that the PrimeFaces roadmap states that the PRIMEFACES_MOBILE renderkit will be deprecated in PrimeFaces 6.2 and removed in PrimeFaces 6.3.

Kind Regards,

Neil

[Kyle Joseph Stiemann, modifié il y a 7 années.]

Moved to the Liferay Faces - English category.