Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Deploying sample jsf portlets to 4.3.3.x
Hi All!
i got branch 4.3.x from svn and also checked out the plugins... I deployed my ext created from 4.3.x in a tomcat 5.5 bundle with 4.3.3 ... It works fine...
however, when i try to deploy any of the jsf sample plugins, such as the icefaces portlets, i get the same error:
SEVERE: Error listenerStart
Which causes the portlet to be undeployed...
What am i missing? I'm interested to see the progress of IceFaces in Liferay, for my future projects...
Thanks in advance for your responses!
i got branch 4.3.x from svn and also checked out the plugins... I deployed my ext created from 4.3.x in a tomcat 5.5 bundle with 4.3.3 ... It works fine...
however, when i try to deploy any of the jsf sample plugins, such as the icefaces portlets, i get the same error:
SEVERE: Error listenerStart
Which causes the portlet to be undeployed...
What am i missing? I'm interested to see the progress of IceFaces in Liferay, for my future projects...
Thanks in advance for your responses!
It's probably worth checking the tomcat logs thoroughly. I just had this happen and it turned out to be a ClassNotFoundException that was reported in a different log than the "Error listenerStart". (For me it was in localhost.x.log)
Indeed... there were dependencies to apache common's stuff...
I wonder if these are supposed to be copied in libs each of the portlets, or eventually the build will put them there? It is kind of wierd that when i placed commons-digester.jar in the portlets lib folder inside of plugins, the deploy target seems to erase it... I had to put these libs straight in tomcat...
I will research further about how to propperly deal with these dependencies...
I appreciate the tip! The portlet works when i put the dependencies in...
thanks!
I wonder if these are supposed to be copied in libs each of the portlets, or eventually the build will put them there? It is kind of wierd that when i placed commons-digester.jar in the portlets lib folder inside of plugins, the deploy target seems to erase it... I had to put these libs straight in tomcat...
I will research further about how to propperly deal with these dependencies...
I appreciate the tip! The portlet works when i put the dependencies in...
thanks!
Hello,
I know that this thread was already answered, but maybe I can help someone with this reply.
I am using the current Liferay binaries (4.3.4) either with tomcat 5.5 or tomcat 6.0 and got the same error as you got.
For the 'sample-jsf-myfaces-portlet' (in tomcat 5.5) I put the following apache commons into the tomcat common folder:
commons-beanutils.jar
commons-digester-1.8.jar
commons-codec-1.3.jar
For tomcat 6 I also needed the loggings jar:
commons-logging-1.1.jar
For the 'sample-icefaces-myfaces-portlet' portlet I further needed
commons-fileupload-1.2.jar
Greetings,
Hans-Georg
I know that this thread was already answered, but maybe I can help someone with this reply.
I am using the current Liferay binaries (4.3.4) either with tomcat 5.5 or tomcat 6.0 and got the same error as you got.
For the 'sample-jsf-myfaces-portlet' (in tomcat 5.5) I put the following apache commons into the tomcat common folder:
commons-beanutils.jar
commons-digester-1.8.jar
commons-codec-1.3.jar
For tomcat 6 I also needed the loggings jar:
commons-logging-1.1.jar
For the 'sample-icefaces-myfaces-portlet' portlet I further needed
commons-fileupload-1.2.jar
Greetings,
Hans-Georg
Thanks Greg!
So, what i found out is that the build script and properties hava a dependencies portal dependencies setting:
portal.dependency.jars=
inside of liferay-plugin-package.properties
The jars specified in that property are temporarly copied to the war for compilation, but are erased from it before packaging it... I'm not sure that makes sense... That would sound like you are expecting these jars to be globally available on tomcat... But they are explicitly copied from the portal web app (ROOT in case of tomcat) ... So, it feels like there is an expectation that because these jars are in ROOT/WEB-INF/lib, they will be made available to other portlets, and that is not the case...
The part of the build script that does this copying is in build-common-plugin.xml in the plugins root... It is the 'war' target....I've modified it slightly to make it work in this case, and then i put the extra deps i have in the portal.dependency.jars above (such as the digester)..
What I don't know here is what was the original intention of these portal dependencies, and if indeed there was an expectation that they would be makde available to external war portlets in means that are not currently working or what...
Perhaps someone @ liferay could illuminate us?
Thanks!
So, what i found out is that the build script and properties hava a dependencies portal dependencies setting:
portal.dependency.jars=
inside of liferay-plugin-package.properties
The jars specified in that property are temporarly copied to the war for compilation, but are erased from it before packaging it... I'm not sure that makes sense... That would sound like you are expecting these jars to be globally available on tomcat... But they are explicitly copied from the portal web app (ROOT in case of tomcat) ... So, it feels like there is an expectation that because these jars are in ROOT/WEB-INF/lib, they will be made available to other portlets, and that is not the case...
The part of the build script that does this copying is in build-common-plugin.xml in the plugins root... It is the 'war' target....I've modified it slightly to make it work in this case, and then i put the extra deps i have in the portal.dependency.jars above (such as the digester)..
<target name="war" depends="compile">
...
<!-- If we execute this before the zip, dependencies are not put in the war
I wonder if this is on purpose and something else is not working
Or an actual error, For now, since it doesn't work otherwise,
I'm excecuting it after thw war is created
I should ask in the forum
<antcall target="clean-portal-dependencies" />
-->
<zip basedir="${docroot.dir}" destfile="${plugin.file}" />
<!-- so i run this after the packaging so that the deps go with the war file -->
<antcall target="clean-portal-dependencies" />
</target>
What I don't know here is what was the original intention of these portal dependencies, and if indeed there was an expectation that they would be makde available to external war portlets in means that are not currently working or what...
Perhaps someone @ liferay could illuminate us?
Thanks!
Thanks Alex, I use your hack here, and it works. 
> What I don't know here is what was the original intention of these portal dependencies, and if indeed
> there was an expectation that they would be makde available to external war portlets in means that are
> not currently working or what...
>
> Perhaps someone @ liferay could illuminate us?
I wonder too... It can't be right that you have to have all this jars in every portlet? I hope some can make this clear to mee.
> What I don't know here is what was the original intention of these portal dependencies, and if indeed
> there was an expectation that they would be makde available to external war portlets in means that are
> not currently working or what...
>
> Perhaps someone @ liferay could illuminate us?
I wonder too... It can't be right that you have to have all this jars in every portlet? I hope some can make this clear to mee.
Arne Arne:
Thanks Alex, I use your hack here, and it works.
> What I don't know here is what was the original intention of these portal dependencies, and if indeed
> there was an expectation that they would be makde available to external war portlets in means that are
> not currently working or what...
>
> Perhaps someone @ liferay could illuminate us?
I wonder too... It can't be right that you have to have all this jars in every portlet? I hope some can make this clear to mee.
Hmm, I stumbled upon the same problem, came to the same fix (moving the antcall to after the zipping process) and have now found your post. This is still the same as of Liferay 5.2.3. I really wonder if that is not a bug??
Community
Company
Feedback