RE: Deploying sample jsf portlets to 4.3.3.x

thumbnail
245809, modified 18 Years ago. Liferay Master Posts: 640 Join Date: 11/5/07 Recent Posts
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!
272551, modified 18 Years ago. New Member Post: 1 Join Date: 11/14/07 Recent Posts
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)
thumbnail
245809, modified 18 Years ago. Liferay Master Posts: 640 Join Date: 11/5/07 Recent Posts
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!
35271, modified 18 Years ago. Junior Member Posts: 36 Join Date: 6/30/07 Recent Posts
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
thumbnail
245809, modified 18 Years ago. Liferay Master Posts: 640 Join Date: 11/5/07 Recent Posts
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)..


<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!
413131, modified 18 Years ago. Junior Member Posts: 26 Join Date: 1/22/08 Recent Posts
Thanks Alex, I use your hack here, and it works. emoticon


> 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.
thumbnail
3326983, modified 16 Years ago. New Member Posts: 13 Join Date: 6/15/09 Recent Posts
Arne Arne:
Thanks Alex, I use your hack here, and it works. emoticon

> 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??