Vue combinée Vue Plate Arborescence
Sujets [ Précédent | Suivant ]
Eric Soucy
portlets libraries vs war size : best practices
11 février 2014 10:01

Eric Soucy

Rang: New Member

Publications: 14

Date d'inscription: 8 octobre 2008

Publications Récentes

I have done sample portlets with jsf 2.1.21 and primefaces 4 with liferay 6.2 (liferay faces 3.2.4-ga5-snapshot) . Once packaged into war files those portlets include in their WEB-INF\lib\ about 7 MBs of jar files. see below:

59 590 commons-fileupload-1.2.2.jar
87 776 commons-io-1.3.2.jar
60 841 commons-logging.jar
133 966 jboss-el-2.0.0.GA.jar
635 911 jsf-api-2.1.21.jar
2 007 978 jsf-impl-2.1.21.jar
206 715 liferay-faces-alloy-3.2.4-ga5-SNAPSHOT.jar
30 709 liferay-faces-bridge-api-3.2.4-ga5-SNAPSHOT.jar
531 067 liferay-faces-bridge-impl-3.2.4-ga5-SNAPSHOT.jar
146 248 liferay-faces-util-3.2.4-ga5-SNAPSHOT.jar
346 729 log4j-extras.jar
489 883 log4j.jar
2 026 852 primefaces-4.0.jar
70 530 util-bridges.jar
208 712 util-java.jar
407 193 util-taglib.jar
17 file(s) 7 450 700 bytes

My question is : Do I have to always include all those jars for each portlet I develop ? If I have 10 portlets the total of jars will give 70MB.
Does Liferay suggest a way to put those jars (or some of those jars) in a common place (like tomcat\lib\ext) or do I have to always include them in each portlet.
What are the best practices for that?

Thank you
Neil Griffin
RE: portlets libraries vs war size : best practices
11 février 2014 10:18

Neil Griffin


Rang: Liferay Legend

Publications: 2223

Date d'inscription: 26 juillet 2005

Publications Récentes

Hi Eric,

Since you mentioned tomcat\lib\ext (Tomcat global classpath) I am assuming that you are deploying your portlets to Liferay+Tomcat.

Regarding Mojarra (jsf-api.jar and jsf-impl.jar), you can put the jars in the Tomcat global classpath by following the instructions in the Upgrading Mojarra in Apache Tomcat wiki article.

Regarding the Liferay Faces jars, we haven't done any internal testing with them in the Tomcat global classpath. Since there are servlet context listeners defined in TLD files, those listeners would get auto-registered for all contexts which would not be good. You would have to remove those entries from the TLD files and register the listeners in each portlet/WEB-INF/lib/web.xml descriptor instead. There was a recent post here in the Liferay Faces forums from a developer who tried it with JBoss, and I'm not sure that he was able to get it to work. In general I would recommend against it since the jars are relatively small in size.

Regarding primefaces.jar -- I don't know if can live in the Tomcat global classpath. I did some Google searches and couldn't find any information about it. You would simply have to try it.

Regarding the following jars, I would not recommend that you put them in the Tomcat global classpath because they might conflict with JARs that Liferay Portal already has in tomcat/webapps/ROOT/WEB-INF/lib:
  • commons-fileupload-1.2.2.jar
  • commons-io-1.3.2.jar
  • commons-logging.jar

Finally, the following jars are automatically copied to your portlet's WEB-INF/lib during the deployment process, so you have no choice but to keep them in WEB-INF/lib:
  • log4j.jar
  • util-bridges.jar
  • util-java.jar
  • util-taglib.jar

Kind Regards,

Mika Koivisto
RE: portlets libraries vs war size : best practices
11 février 2014 11:51

Mika Koivisto


Rang: Liferay Legend

Publications: 1505

Date d'inscription: 7 août 2006

Publications Récentes

Instead of creating 10 separate portlet wars why not aggregate them into one war. Putting stuff in the global classloader is generally bad idea.
Eric Soucy
RE: portlets libraries vs war size : best practices
17 février 2014 10:28

Eric Soucy

Rang: Junior Member

Publications: 33

Date d'inscription: 21 janvier 2014

Publications Récentes

to make things clear, I just changed the liferayVersion property in my pom.xml to 6.2.10-GA1.
The content of my web-inf\lib in my compiled war file is :

It seems that when deploying, the following libs are added the web-inf\lib that is exploded in the tomcat webapps directory.