Liferay 6.1 - Primefaces - Spring Integration

[Kamesh Sampath, modifié il y a 10 années.]

Hi,

I am working on to integrate Spring (3.1.1.RELEASE) with Liferay faces 3.1.2.ga3 on Liferay Portal EE 6.1.ga2, when I deploy my Portlets the Portlet gets deployed correctly in CE version but when I deploy the same on EE I get the attached stacktrace.


web.xml

<!--?xml version="1.0"?-->

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
	<!-- Set the JSF 2 PROJECT_STAGE to Development so that the JSF implementation 
		will do the following at runtime: -->
	<!-- 1. Log more verbose messages. -->
	<!-- 2. Render tips and/or warnings in the view markup. -->
	<!-- 3. Cause the default ExceptionHandler to display a developer-friendly 
		error page. -->
	<context-param>
		<param-name>javax.faces.PROJECT_STAGE</param-name>
		<param-value>Development</param-value>
	</context-param>
	<!-- context-param> <param-name>primefaces.THEME</param-name> <param-value>#{userSettings.theme}</param-value> 
		</context-param -->
	<!-- Instruct Mojarra to utilize JBoss-EL instead of the EL implementation 
		provided by the servlet container. -->
	<context-param>
		<param-name>com.sun.faces.expressionFactory</param-name>
		<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
	</context-param>
	<!-- Workaround for http://issues.liferay.com/browse/FACES-1194 -->
	<context-param>
		<param-name>com.liferay.faces.bridge.primeFileUploadForceResourceURL</param-name>
		<param-value>true</param-value>
	</context-param>

	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/ljp-context.xml</param-value>
	</context-param>

	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

	<listener>
		<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
	</listener>

	<!-- Although the FacesServlet will not be invoked by any portlet requests, 
		it is required to initialize JSF. -->
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<!-- MyFaces will not initialize unless a servlet-mapping to the Faces Servlet 
		is present. -->
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.xhtml</url-pattern>
	</servlet-mapping>
	<!-- Prevent direct access to Facelet view XHTML by the userAgent (browser). -->
	<security-constraint>
		<web-resource-collection>
			<web-resource-name>Facelet View XHTML</web-resource-name>
			<url-pattern>*.xhtml</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>nobody</role-name>
		</auth-constraint>
	</security-constraint>
	<security-role>
		<role-name>nobody</role-name>
	</security-role>
</web-app>

Can anyone let me know what is the cause of the issue ?

[Kamesh Sampath, modifié il y a 10 années.]

Hello All,

When investigating the differences between Liferay CE deployment and Liferay EE deployment, I found that the EE deployment combines the listener classes defined in the portlet web.xml in to one context-param called "portalListenerClasses"

<context-param>
		<param-name>portalListenerClasses</param-name>
		<param-value>com.liferay.portal.kernel.servlet.SerializableSessionAttributeListener,org.springframework.web.context.ContextLoaderListener,org.springframework.web.context.request.RequestContextListener</param-value>
	</context-param>

Wherein the CE deployment does put in web.xml as is when deploying.

This was causing the improper loading of org.springframework.web.context.ContextLoaderListener and org.springframework.web.context.request.RequestContextListener especially w.r.t JSF context.

So I tried redeploying the same app with the modifications to the web.xml by commenting out the portalListenerClasses context-param and adding the Listeners in the same order as the param values which made my JSF app working in EE

-Kamesh

[Andreas Egal, modifié il y a 10 années.]

Error results from the Patch "liferay-fix-pack-plugin-deployment-1-6120" which is installed by default in Liferay_Developer_Studio_1.6.1.v201212111822-win32-x86_64

See: http://issues.liferay.com/browse/LPS-37483

My solution so far: Just remove this patch ;)

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

Hi Martin, Kamesh,

Thanks so much for contributing in this thread. LPS-37483 was a super high priority issue for us last week and I'm happy to report that we have the issue fixed in the master branch (Liferay 6.2). As you discovered, if you avoid installing liferay-fix-pack-plugin-deployment-1-6120 then the problem won't happen with Liferay Portal 6.1.20 EE GA2.

Kind Regards,

Neil

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

Hi Kamesh,

The fix in LPS-37483 has been reverted (backed-out) from the master branch of the portal.

In order to reproduce the problem you reported, we started working on a jsf2-spring-portlet demo for Liferay Faces. But we have not been able to reproduce the stacktrace -- everything is working OK.

In order to help us test JSF + Spring integration, we would need you to attach a test portlet to this thread. We have a very short window of opportunity to fix any problems, so if you could please attach a test portlet today, that would be fantastic.

Thank you,

Neil

[Kamesh Sampath, modifié il y a 10 années.]

Hi Neil,

The actual issue was because of the portalListenerClasses context-param, after I did the latest fix-pack to my Liferay installation, I found that the web.xml was getting generated correctly and my portlet was deployed and working OK.

Thanks for getting new demo added to the spring demo portlet, please let me know if you still need the demo portlet?

Thank you.

Regards,
Kamesh

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

Hi Kamesh,

When you get a chance, please let me know which fixpacks are currently installed on your working system.

Also, what does the latest web.xml look like? For example, does it have the portalListenerClasses context-param?

Thanks,

Neil

[Kamesh Sampath, modifié il y a 10 années.]

Neil Griffin:

Hi Kamesh,

When you get a chance, please let me know which fixpacks are currently installed on your working system.

Also, what does the latest web.xml look like? For example, does it have the portalListenerClasses context-param?

Thanks,

Neil

Hi Neil,

The current fix pack that is applied to my portal installation is liferay-fix-pack-upgrade-2-6120, this fix pack is generating the web.xml properly without the context-param ""portalListenerClasses"

Attached is the working and non working ones, we can simulate the error with with the liferay-fix-pack-upgrade-1-6120

Thank you.

Regards,
Kamesh

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

Hi Kamesh,

When you get chance, please read the description for FACES-1603. As the issue describes, moving forward, the portalListenerClasses approach will be the standard way of doing things. The good news is that we have been doing lots of testing with our sample-spring-portlet (and new jsf2-spring-portlet) with the master branch (Liferay 6.2) and it is working well. If you could please attach a portlet WAR to this thread, that would be great. It would provide me with the ability to make sure your project will work in future versions of Liferay (including future fixpacks for 6.1 EE).

Thanks,

Neil

[Kamesh Sampath, modifié il y a 10 années.]

Hi Neil,

I will surely attach the portlet war which i am working on, but I don't use Spring portlet but I do the Spring injection alone, so it could act as a different variant. But then do you want me to attach the portlet here in the forum or in the Ticket page ?

-Kamesh

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

Hi Kamesh,

Feel free to attach the portlet here to the forum thread. When you get a chance, could you please provide more details on what you mean by:

I don't use Spring portlet but I do the Spring injection alone

Thanks,

Neil

[Kamesh Sampath, modifié il y a 10 années.]

what i meant here was,

My Portlet class is Generic JSF portlet and I use Spring beans alone here where in I do IoC alone on the Managed Bean class.

But am kind of getting another issue here,

I am trying to a method on load in JSF which also needs the request object to fetch the user emailid for the logged in user the following is the class decleration

@ManagedBean(name = "myController")
@Controller("myController")
@Scope(value = "request")
@ViewScoped
public class MytBean implements Serializable {

 ....

  @PostConstruct
   public void init(){
       
     // I need to get the user email id here
       LiferayFacesContext lfrContext = LiferayFacesContext.getInstance();
     // Get user id or other required attributes ...

     //Some more code 
    }
  
 ...
  
}

but the problem with the above code is that for every JSF event the init() method is called, if I make the @Scope(value="singleton") then I see the data is retained because only one instance of ManagedBean is created. Another approach we tried from here but that is firing validations without us setting the validation ="true"

Can you please help me how to solve this issue?

-Kamesh

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

When you wrote:

for every JSF event the init() method is called

Can you describe what you mean in more detailed by "every JSF event"?

[Kamesh Sampath, modifié il y a 10 années.]

the init() method is my custom method and its annotated with @PostConstruct.

What I meant by every JSF event is that:

I have two drop downs "State" and "City", and one TreeTable which gets filled based on the State and City selections, the ajax events are fired for the "State" and "City" so for each AJAX event I see that the Managed bean is kind of refreshed - it could be either new instance created and populated with updated bean values, the @PostConstruct annotated method is called, ideally I added the annotation just to make it called after the ManagedBean class has been initiatilzed.

Hope I made it clear, if not let me know.

[Kamesh Sampath, modifié il y a 10 années.]

Neil,

I finally got it working some of things learned,

• The ManagedBean and Spring Beans were in not in sync meaning I had the @Scope("request") and the JSF scope to ViewScoped , this made the Managed the managed bean to be recreated on every Ajax events in my case changing the values from the drop down which was causing the bean values to be lost and throwing some weird validation errors and the due to class getting reconstructed the
• When i changed the @Scope("session"), the Managed Bean and Spring Bean were synchronized meaning no new instances were created during the ajax events

So when using Spring with @ManagedBean here is the list of annotations that works

@ManagedBean
@Controller
@Scope("session")
@ViewScoped

Some of the things I don't understand is,

• Why did validation errors were thrown in-spite of me not setting any validations?
• Just has a slight doubt whether the instance values will be shared across users? Theoretically it will not be shared just a confirmation

I will post the sample project when I have it ready so that it helps others.

-Kamesh

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

Hi Kamesh,

When you annotate a class with both @Scope("session") and @ViewScoped, then it will be managed by the Spring BeanFactory and also the JSF Managed Bean Facility. The recommended practice would be to use one or the other, but not both.

If you would like Spring to manage your view scoped managed bean, then you can specify @Scope("view")

For more info, see: ViewScope.java, ApplicantViewBean.java, and applicationContext.xml from the jsf2-spring-portlet demo.

Kind Regards,

Neil

[Kamesh Sampath, modifié il y a 10 années.]

Thanks so much for the insight Neil, let me cleanup my class with your comments.

[Kamesh Sampath, modifié il y a 10 années.]

when i was seeing the demos, i see two directories portal and bridge, I also came across these Portal and Bridge stuff , can you please let me know what is the difference?

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

Hi Kamesh,
The portal demos have dependencies on Liferay Portal, which is why you would find the users portlets within that section. Portlets such as the users portlets deal with Liferay specific features like modifying Liferay portal users. The bridge demos don't have a dependency on Liferay portal, so they can be deployed in other portals such as Pluto.

- Kyle