Hi,
I do not know about library conflicts as for tests I use clean Liferay. A played a lot around having Richfaces and it's dependencies in the classpath of the Application server. It worked but as my main target is Glassfish V3 the classloading mechanism is much more complicated there due to the possibility of modularization.
the first error about Serialization can be solved if the UserBean implements Serializable. It is only necessary if the managed bean is in session scope. However the portlet works with this error as well. I will upload a modified version that will have a Serializable UserBean.
The second error only happens when somebody places out the portlet onto the screen. There is no need to restart the server only to refresh the page. It seems that the AJAX based portlet insert of Liferay does not like this portlet. An <ajaxable>false</ajaxable> in liferay-portlet.xml can help on this however for me it was more confortable to press an F5 in the browser after placing the portlet out
. In the future if I have some time I might check why this happens.
Regards,
Balazs
I do not know about library conflicts as for tests I use clean Liferay. A played a lot around having Richfaces and it's dependencies in the classpath of the Application server. It worked but as my main target is Glassfish V3 the classloading mechanism is much more complicated there due to the possibility of modularization.
the first error about Serialization can be solved if the UserBean implements Serializable. It is only necessary if the managed bean is in session scope. However the portlet works with this error as well. I will upload a modified version that will have a Serializable UserBean.
The second error only happens when somebody places out the portlet onto the screen. There is no need to restart the server only to refresh the page. It seems that the AJAX based portlet insert of Liferay does not like this portlet. An <ajaxable>false</ajaxable> in liferay-portlet.xml can help on this however for me it was more confortable to press an F5 in the browser after placing the portlet out
. In the future if I have some time I might check why this happens.Regards,
Balazs
Thanks for your reply.
I figured you'd use a clean version of Tomcat and Liferay for testing purposes. Upon discovering that conflict, I simply deleted the libraries temporarily, effectively reverting the server back to default and it worked. You'll probably know how cumbersome it can be to find out which libraries are supposed to be used for an application and which are not. I had it too when working with ADF 11g on Tomcat.
It's good to know that a server restart is not necessary to fix that last error. Thanks for the tip.
You did a nice job with this sample application.
I figured you'd use a clean version of Tomcat and Liferay for testing purposes. Upon discovering that conflict, I simply deleted the libraries temporarily, effectively reverting the server back to default and it worked. You'll probably know how cumbersome it can be to find out which libraries are supposed to be used for an application and which are not. I had it too when working with ADF 11g on Tomcat.
It's good to know that a server restart is not necessary to fix that last error. Thanks for the tip.
You did a nice job with this sample application.
I totally agree! Huge THANKS for your work, Balazs!
Look, maybe you can check my post and see if you can help me on this one? Right now I'm doing research for a new long-term project, and I must choose which technology to incorporate for our portlets - Wicket or JSF (RichFaces or ICEFaces). Also, maybe you have a word on the choice between RichFaces and ICEFaces?
I would be very grateful for any of your help! Thanks in advance.
Look, maybe you can check my post and see if you can help me on this one? Right now I'm doing research for a new long-term project, and I must choose which technology to incorporate for our portlets - Wicket or JSF (RichFaces or ICEFaces). Also, maybe you have a word on the choice between RichFaces and ICEFaces?
I would be very grateful for any of your help! Thanks in advance.
Hi,
sorry, I forgot about the question about RichFaces and ICEFaces.
I did not use ICEFaces much. My colleagues used it for a project because there were an ICEFaces portlet available at that time. However just before the end of the project they switched everything to RichFaces due to a bug they could not solve faster than converting to the other technology. The bug was that if multiple users visited the same page the ajax requests seemed to be randomly use the other user's session. It was pretty strange The conclusion was that it is not impossible to do the switch on the end of a project as the components are almost the same. And luckily we used the MVC patter that is described at http://blog.icefaces.org/blojsom/blog/default/2009/04/23/Making-distinctions-between-different-kinds-of-JSF-managed-beans/ so biggest part of the code remained jsf implementation independent.
I guess that bug has been solved since. We discussed it at that time and we got the impression that ICEFaces hides the AJAX calls a bit more from the developer. There were many AJAX calls and without looking into the javascript of the component we did not know why and when. This is not a bad behavior but we felt that we could not have control over the happenings.
For me at least RichFaces components seem to be a bit more logical, they do what I expect and they send AJAX calls when I expect. Also the a4j:support tag that came with Ajax4Jsf seems to become now a basic tag in JSF2. It is called differently however it is the same.
As I do not have much experience with ICEFaces I think it is important to ask somebody who has. What I can say is that both of them are buggy but if somebody does not afraid to look into the source code it is not such a big problem. The most important question is which one will have better support in the future. I do not know about ICEFaces but RichFaces seems to have a pretty big community or at least the source in SVN changes rapidly.
Regards,
Balazs
sorry, I forgot about the question about RichFaces and ICEFaces.
I did not use ICEFaces much. My colleagues used it for a project because there were an ICEFaces portlet available at that time. However just before the end of the project they switched everything to RichFaces due to a bug they could not solve faster than converting to the other technology. The bug was that if multiple users visited the same page the ajax requests seemed to be randomly use the other user's session. It was pretty strange
The conclusion was that it is not impossible to do the switch on the end of a project as the components are almost the same. And luckily we used the MVC patter that is described at http://blog.icefaces.org/blojsom/blog/default/2009/04/23/Making-distinctions-between-different-kinds-of-JSF-managed-beans/ so biggest part of the code remained jsf implementation independent.I guess that bug has been solved since. We discussed it at that time and we got the impression that ICEFaces hides the AJAX calls a bit more from the developer. There were many AJAX calls and without looking into the javascript of the component we did not know why and when. This is not a bad behavior but we felt that we could not have control over the happenings.
For me at least RichFaces components seem to be a bit more logical, they do what I expect and they send AJAX calls when I expect. Also the a4j:support tag that came with Ajax4Jsf seems to become now a basic tag in JSF2. It is called differently however it is the same.
As I do not have much experience with ICEFaces I think it is important to ask somebody who has. What I can say is that both of them are buggy but if somebody does not afraid to look into the source code it is not such a big problem. The most important question is which one will have better support in the future. I do not know about ICEFaces but RichFaces seems to have a pretty big community or at least the source in SVN changes rapidly.
Regards,
Balazs
Hi,
are you sure the browser downloaded the correct js file? I normally check with firebug what js files are present. In the url it is shown normally in which package the js file is placed. And often turns out that the browser caches the js files, images and css files. Ctrl+F5 normally helps in this situation
Also when richfaces is in a portlet and the cache filter of liferay is turned on it can make troubles. As much as I remember liferay cache filter is mapped to *.js. I sugges to delete it from the web.xml of your portlet.
Regards,
Balazs
are you sure the browser downloaded the correct js file? I normally check with firebug what js files are present. In the url it is shown normally in which package the js file is placed. And often turns out that the browser caches the js files, images and css files. Ctrl+F5 normally helps in this situation
Also when richfaces is in a portlet and the cache filter of liferay is turned on it can make troubles. As much as I remember liferay cache filter is mapped to *.js. I sugges to delete it from the web.xml of your portlet.
Regards,
Balazs
Hi,
again I am happy that somebody find the example useful. It is not my achievement that it works as Jboss guys implemented the portlet bridge.
We also use maven. We have a public repository at http://maven2.everit.biz/repository/public/. That should contain every custom dependencies.
The portletbridge jar does not have to be patched anymore as 2.0.1.CR1 already contains my changes and it seems that it works in liferay well.
The Richfaces implementation contains only one change inside. The jquery js file is appended with a bugfix so the liferay built in chat portlet does not thow exceptions in every couple of seconds due to jquery-json incompatibility. The core functionality would work anyway.
I think at the moment we do not have working archetype but I think we will create one (when we have some time) and I will post it here somewhen.
Here is a snippet from one of our pom.xml that contains every dependency (I hope):
Regards,
Balazs
again I am happy that somebody find the example useful. It is not my achievement that it works as Jboss guys implemented the portlet bridge
.We also use maven. We have a public repository at http://maven2.everit.biz/repository/public/. That should contain every custom dependencies.
The portletbridge jar does not have to be patched anymore as 2.0.1.CR1 already contains my changes and it seems that it works in liferay well.
The Richfaces implementation contains only one change inside. The jquery js file is appended with a bugfix so the liferay built in chat portlet does not thow exceptions in every couple of seconds due to jquery-json incompatibility. The core functionality would work anyway.
I think at the moment we do not have working archetype but I think we will create one (when we have some time) and I will post it here somewhen.
Here is a snippet from one of our pom.xml that contains every dependency (I hope):
<dependency>
<groupid>javax.faces</groupid>
<artifactid>jsf-impl</artifactid>
<version>1.2_13</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>javax.faces</groupid>
<artifactid>jsf-api</artifactid>
<version>1.2_13</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>com.sun.facelets</groupid>
<artifactid>jsf-facelets</artifactid>
<version>1.1.15.B1</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>javax.el</groupid>
<artifactid>el-api</artifactid>
<version>1.2</version>
<type>jar</type>
<scope>provided</scope>
<optional>false</optional>
</dependency>
<dependency>
<groupid>javax.portlet</groupid>
<artifactid>portlet-api</artifactid>
<version>2.0</version>
<type>jar</type>
<scope>provided</scope>
<optional>false</optional>
</dependency>
<dependency>
<groupid>com.liferay.portal</groupid>
<artifactid>portal-service</artifactid>
<version>${liferay.version}</version>
<type>jar</type>
<scope>provided</scope>
<optional>false</optional>
</dependency>
<dependency>
<groupid>org.richfaces.ui</groupid>
<artifactid>richfaces-ui</artifactid>
<version>${richfaces.version}</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>org.richfaces.framework</groupid>
<artifactid>richfaces-impl</artifactid>
<version>${richfaces.impl.version}</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>org.jboss.portletbridge</groupid>
<artifactid>portletbridge-impl</artifactid>
<version>${jboss.portletbridge.impl.version}</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>org.jboss.portletbridge</groupid>
<artifactid>portletbridge-api</artifactid>
<version>${jboss.portletbridge.api.version}</version>
<type>jar</type>
<optional>false</optional>
</dependency>
<dependency>
<groupid>javax.servlet</groupid>
<artifactid>servlet-api</artifactid>
<version>2.5</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
Regards,
Balazs
Hi,
for me it is really funny that we were suffering due to a very similar problem yesterday and today I got a message that others met the same issue.
We tried to open a modalpanel from within tabs. We found out the followings:
- The modalpanel appears but on the modalpanel nothing works.
- If we use ajax tab navigation after we change the tab at least ones everything works fine.
- If we use componentControl to hide the modalpanel we get a blank screen. This is because due to some reason compoenentcontrol sets a "display:none" on the body tag of the full html page.
- Similar problems when we use server side tab navigation with the difference that a tab change does not solve the problem (as the full page is re-rendered)
We have not tried it but if this problem does not occur when using a simple JSF application (without Liferay) then I guess the problem is related to incompatibility with one of javascript libraries that is brought by Liferay.
As we have a really close due date in the project we could not spend much time investigating the issue so we simply avoiding the use of modal panels and have simple page navigation and hope that this will not occur in the next release of richfaces.
However if you find a solution in the future I would be really happy if you could share.
Withing the next weeks we will not have time to investigate this problem.
Regards,
Balazs
for me it is really funny that we were suffering due to a very similar problem yesterday and today I got a message that others met the same issue.
We tried to open a modalpanel from within tabs. We found out the followings:
- The modalpanel appears but on the modalpanel nothing works.
- If we use ajax tab navigation after we change the tab at least ones everything works fine.
- If we use componentControl to hide the modalpanel we get a blank screen. This is because due to some reason compoenentcontrol sets a "display:none" on the body tag of the full html page.
- Similar problems when we use server side tab navigation with the difference that a tab change does not solve the problem (as the full page is re-rendered)
We have not tried it but if this problem does not occur when using a simple JSF application (without Liferay) then I guess the problem is related to incompatibility with one of javascript libraries that is brought by Liferay.
As we have a really close due date in the project we could not spend much time investigating the issue so we simply avoiding the use of modal panels and have simple page navigation and hope that this will not occur in the next release of richfaces.
However if you find a solution in the future I would be really happy if you could share
.Withing the next weeks we will not have time to investigate this problem.
Regards,
Balazs
Hi,
showing the modalpanel was not such a big problem for us but hiding it was not really possible
No ajax calls or any other call worked after a modalpanel was shown.
What took some time to find out before was that there cannot be h:form tag around modalpanel, and it might be true for the tabs as well. (For modalpanel it is in the manual but who reads the full manual always)
Regards,
Balazs
showing the modalpanel was not such a big problem for us but hiding it was not really possible
No ajax calls or any other call worked after a modalpanel was shown.
What took some time to find out before was that there cannot be h:form tag around modalpanel, and it might be true for the tabs as well. (For modalpanel it is in the manual but who reads the full manual always
)Regards,
Balazs
Hi,
we tried the sample plugin on Glassfish and Tomcat. We do not have experience with JBoss AS however the problem might be similar to the classloader problem of Glassfish.
You can find a sun-web.xml in the war file. This contains additional configuration to Glassfish. There are two important things in it:
I think if JBoss AS is similar to Glassfish both of these could cause the problem. The first case when not the bundled (jars in the war) JSF is used for initializing JSF but the classes from the war used later. In that case those classes might think that JSF is not initialized yet as their static fields are not set... The second case is the same due to the reason of classloader delegation.
So please try to find if JBoss AS has the possibility to add these options to the webapp somehow.
I hope this helps.
Regards,
Balazs
we tried the sample plugin on Glassfish and Tomcat. We do not have experience with JBoss AS however the problem might be similar to the classloader problem of Glassfish.
You can find a sun-web.xml in the war file. This contains additional configuration to Glassfish. There are two important things in it:
- Use bundled JSF By default Glassfish uses the JSF implementation of the application server and does not care at all if the jsf jar files present in the war. It simply ignores them. As JSF is part of Java EE specification I can understand this behavior .
- Classloader delegation: By default glassfish tries to find classes with the classloader of Glassfish first and than with the classloader of the web application. This may generate weird behavior. For example: Class A is loaded already from Glassfish classpath. Class B is loaded from the classpath of the webapp. Class B contains a code snippet where it uses reflection to instantiate class A but with the classloader of class B. In this case if there is a casting, there will be a ClassCastException...
I think if JBoss AS is similar to Glassfish both of these could cause the problem. The first case when not the bundled (jars in the war) JSF is used for initializing JSF but the classes from the war used later. In that case those classes might think that JSF is not initialized yet as their static fields are not set... The second case is the same due to the reason of classloader delegation.
So please try to find if JBoss AS has the possibility to add these options to the webapp somehow.
I hope this helps.
Regards,
Balazs