Blade JSF Portlet example won't work

[8年前 に Jan Eerdekens によって更新されました。]

I'm currently looking into how we can get out current portlet stack (JSF + Primefaces + Liferay Faces Bridge) to work as an OSGI module in Liferay 7. My first step was to download and build the Blade JSF Portlet example that can be found in Ray's Blade repo on GitHub: https://github.com/rotty3000/blade/tree/master/liferay-gradle/blade.jsf.portlet.ds

I downloaded Liferay 7.0 CE b8, started and configured it and then tried to deploy the portlet I just build, but that gave me the following exception:

java.lang.NoClassDefFoundError: javax/faces/FacesException
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:330)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:407)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:357)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:349)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:330)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:407)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:357)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:349)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
	at java.lang.Class.getConstructor0(Class.java:3075)
	at java.lang.Class.newInstance(Class.java:412)
	at javax.portlet.faces.GenericFacesPortlet.getBridge(GenericFacesPortlet.java:268)
	at javax.portlet.faces.GenericFacesPortlet.init(GenericFacesPortlet.java:92)
	at com.liferay.portlet.InvokerPortletImpl.init(InvokerPortletImpl.java:292)
	at com.liferay.portlet.PortletInstanceFactoryImpl.init(PortletInstanceFactoryImpl.java:268)
	at com.liferay.portlet.PortletInstanceFactoryImpl.create(PortletInstanceFactoryImpl.java:181)
	at com.liferay.portal.kernel.portlet.PortletInstanceFactoryUtil.create(PortletInstanceFactoryUtil.java:49)
	at com.liferay.portlet.PortletBagFactory.create(PortletBagFactory.java:221)
	at com.liferay.portal.osgi.web.portlet.tracker.internal.PortletTracker.addingPortlet(PortletTracker.java:329)
	at com.liferay.portal.osgi.web.portlet.tracker.internal.PortletTracker.addingService(PortletTracker.java:189)
	at com.liferay.portal.osgi.web.portlet.tracker.internal.PortletTracker.addingService(PortletTracker.java:133)
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
	at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:1)
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
	at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
	at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:917)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)
	at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)
	at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)
	at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)
	at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)
	at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)
	at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)
	at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
	at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:1)
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:905)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:461)
	at org.eclipse.osgi.container.Module.start(Module.java:452)
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454)
	at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:700)
	at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:491)
	at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:437)
	at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:955)
	at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1336)
	at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Caused by: java.lang.ClassNotFoundException: javax.faces.FacesException cannot be found by blade.jsf.portlet.ds_1.0.0
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:444)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:357)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:349)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 91 more

It seems it was missing the JSF api & impl libs (secondary question: is it possible to deploy JSF as an OSGI module to be used by multiple JSF OSGI portlet modules?). After adding the JSF dependencies to the pom.xml I got further and it seems to deploy correctly and prints the 'INFO [BridgeImpl] Initializing Liferay Faces Bridge VERSION' message, but when I add the portlet to a page I get another exception:

18:42:24,382 ERROR [http-nio-8080-exec-4][render_portlet_jsp:131] null
java.lang.NullPointerException
	at com.liferay.faces.bridge.internal.BridgeImpl.doFacesRequest(BridgeImpl.java:129)
	at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:258)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:359)
	at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:207)
	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:57)
	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:113)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	at com.liferay.portal.osgi.web.portlet.tracker.internal.PortletTracker$PortletServletWrapper.service(PortletTracker.java:1446)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:153)
	at org.eclipse.equinox.http.servlet.internal.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:50)
	at com.liferay.portal.osgi.web.portlet.tracker.internal.PortletTracker$RestrictPortletServletRequestFilter.doFilter(PortletTracker.java:1466)
	at org.eclipse.equinox.http.servlet.internal.registration.FilterRegistration.doFilter(FilterRegistration.java:121)
	at org.eclipse.equinox.http.servlet.internal.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:45)
	at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:71)
	at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:98)

I tried different JSF versions (2.1 & 2.2) and Liferay Faces Bridge versions (3.2.5-ga6, 4.2.5-ga6 & 4.2.0-beta), but the exception remains. Is this a bug or am I doing something wrong?

[8年前 に Juan Gonzalez によって更新されました。]

Hi Jan,

JSF portlets for Liferay 7 are still a work in progress. Some things had been already fixed, but there are still other pending ones that we are working on at this moment.

[8年前 に Jan Eerdekens によって更新されました。]

Hi Juan,

Thank you already for the quick answers.

Will JSF portlets as an OSGI module be ready for the first release of Liferay 7 or should we first just look into keep using old style JSF portlet WARs like we're doing now? If this is the case: would it already be possible to split off our custom services as OSGI modules and use them, via Spring/CDI/something else, in our JSF portlets?

[8年前 に Neil Griffin によって更新されました。]

Hi Jan,

We intend to support deployment of both traditional Java EE style .war and also OSGi .jar bundles.

Both of these types of artifacts fall into the category of OSGi Web Application Bundles ( WAB ) . In other words, whether you copy a .war to the $LIFERAY_HOME/deploy folder or a .jar to the $LIFERAY_HOME/osgi/modules folder, they are both considered to be WABs.

We are working hard to get the portal ready to support JSF in time for the release of Liferay Portal 7 CE, but the Liferay Faces project will not have a production-ready bridge compatible with Liferay Portal 7 CE until after the release. We will however have SNAPSHOT versions of the bridge available for you to try.

Kind Regards,

Neil

[8年前 に Jan Eerdekens によって更新されました。]

Hi Neil,

I just tried to deploy one of the JSF portlets we made for a customer, but also ran into issues. After fixing a bunch of imports and using a matching bridge version (4.0.0-SNAPSHOT as far as I can tell), the portlet deploys without throwing exceptions, but when I add it to a page and reload it only partially works. It isn't displayed correctly, but the messages I see in the Chrome console might be related:

Refused to execute script from 'http://localhost:8080/web/guest/home?p_p_id=DeviceManagementPortlet_WAR_dsp…ceManagementPortlet_WAR_dspdevicemanagementportlet_ln=primefaces&v=5.3' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
home:318 Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:8080/web/guest/home?p_p_id=DeviceManagementPortlet_WAR_dsp…ceManagementPortlet_WAR_dspdevicemanagementportlet_ln=primefaces&v=5.3".
home:340 Uncaught ReferenceError: PrimeFaces is not defined

This seems to indicate that the Primefaces styling and Javascript isn't correctly coming through. Is there something I can do to fix this using properties, XHTML changes, lib changes, ... as the portlet, except for the necessary version changes, is the same that deploys fine on a Liferay 6.2?

[8年前 に Neil Griffin によって更新されました。]

Hi Jan,

We are currently working on fixes for FACES-2631, LPS-55854, and LPS-63935. At the time of this writing, of these are affecting deployment of JSF portlets in Liferay 7.0 CE. In addition, an updated version of Equinox will need to be included with the portal.

We are testing with daily snapshots of the master branch of the portal because 7.0.0 B8 does not include a fix for LPS-62693.

Until all these issues are fixed, you will experience difficulties with your PrimeFaces portlet testing. I recommend that you click the "watch" link in JIRA for each one of those issues in order to stay informed of our progress.

Kind Regards,

Neil

[8年前 に Jan Eerdekens によって更新されました。]

Hi Neil,

Excellent idea. I'll start watching the issues and schedule new tests when they're resolved.

Thank you for the swift replies and good luck with getting JSF to work as it is still our preferred portlet building technology.

[8年前 に Juan Gonzalez によって更新されました。]

Jan Eerdekens:

Thank you for the swift replies and good luck with getting JSF to work as it is still our preferred portlet building technology.

Thanks for your kind words Jan. We faced some challenges but we could fix them or are in progress for getting them fixed.

We made a big effort so JSF Portlet developers could get the best from OSGI while keeping JSF features intact.

[8年前 に Neil Griffin によって更新されました。]

Juan Gonzalez:

Jan Eerdekens:

Thank you for the swift replies and good luck with getting JSF to work as it is still our preferred portlet building technology.

Thanks for your kind words Jan. We faced some challenges but we could fix them or are in progress for getting them fixed.

We made a big effort so JSF Portlet developers could get the best from OSGI while keeping JSF features intact.

I would like to echo Juan's gratitude for your kind words. Along with OSGi compatibility, JSF has a strong future with Liferay Portal, as is evidenced by our commitment to lead the JSR 378 standard for Portlet 3.0 + JSF 2.2.

Here are some more tickets for you to "watch" in JIRA in case you are interested:
- https://issues.liferay.com/browse/LPS-64091
- https://issues.liferay.com/browse/LPS-64092
- https://issues.liferay.com/browse/LPS-64093

[8年前 に Neil Griffin によって更新されました。]

Hi Jan,

For an update on JSF support for Liferay Portal 7.0 CE, please read the blog titled
Liferay Faces Project News - April 2016.

Kind Regards,

Neil

[8年前 に Juan Gonzalez によって更新されました。]

Jan Eerdekens:

(secondary question: is it possible to deploy JSF as an OSGI module to be used by multiple JSF OSGI portlet modules?)

About this question, we are thinking on adding support for reusing JSF implementation (as a module like you said), but due to the JSF initialization mechanism we have to create our own mechanism. It's in our queue but probably would be after the release.