Sampsa Sohlman

Building Custom Liferay with maven

2011-04-12T21:42:27Z

Overview

Many of us are using maven for the build process, but traditionally Liferay has build with ant. Also Liferay's plugin sdk is based on ant. Liferay has also maven support, which is currently usable limited plugin development. This blog is adding new dimension for Liferay development by building custom Liferay with maven. This works with Community and EE versions as well older Liferay versions. I've done some testing also with 5.1.2.

I usually find out that just creating plugins are not enough - the Liferay API just does not have punch enough - many times there is easily fixable bug in Liferay. Normally you have to build your own Liferay from source or use ext-plugin to override Liferay's core functionality. This blog explains how to build custom Liferay with maven and how to prepare environment.

Solution

The solution is to modify Liferay jar and war packages with maven plugins. There two handy maven plugins: maven-shade-plugin and maven-war-plugin.

Maven shade-plugin can do some refactoring and class replacements. This is useful for modifying Liferay jar files including fixes for Liferay. This requires that you know where classes are located. Liferay also provides hot fixes for EE as source format, which can be included on your build. Shade plugin also allows easy tracking of changes. You only have to include changed files to your maven module. Unlike ext-plugin, shade does not use just classloader to replace classes, but really replacing them with your modified version on target jar file, which is more secure.

Mavenwar-plugin can do same for war files as shade-plugin does for jar archives, so here you can harden your Liferay build and remove example unnecessary filters.

To be able to build Liferay with maven all the Liferay required dependencies should be available. On Liferay 6.0.6 there is 175 dependency jars at lib/portal directory. To find out and maintain real maven version for each of these is too big task. So basically I just import all of them to my maven repository.

How to do it?

To make this also easier, I have created ant script to install and deploy all necessary artifacts to your maven repository.

maven-custom-build.xml

This ant script also uses different group id "liferay" to avoid confict with public Liferay group id - "com.liferay".

When using this script you need to have Liferay source, Liferay war and Liferay tomcat bundle available. Tomcat, because the Liferay dependencies package does not contain support-tomcat.jar, which is included on tomcat bundle.

Unzip packages to following directory structure:

/source/	Here is liferay source
/liferay-portal/tomcat/	here is tomcat with liferay
/portal-web.war	and this is really liferay.war

Copy build-custom-maven.xml to liferay /source/ directory

execute script:

ant -f build-custom-maven.xml install

Script modifies all the group id's for Liferay's standard plugins so those can be installed too.

cd support-maven 	
mvn install

Script also creates maven project called all-portal-dependencies and you have install that too.

cd all-portal-dependencies
mvn install

Now all the dependencies has been installed to your local repository. If you wish to deploy artifacts to your own maven repository server run ant -f build-custom-maven.xml deploy, but remember to check repository settings on build-custom-maven.xml and also you have to modify pom.xml files.

Create project structure for Liferay

Project structure should be following, but you should only include modules that you are modifying and then add Liferay module if there is change.

The portal-web is the liferay web application and it's pom.xml contains following.

<dependency>
      <groupid>liferay.portal</groupid>
      <artifactid>portal-web</artifactid>
      <version>${liferay-version}</version>
      <type>war</type>
      <scope>runtime</scope>
  </dependency>    
..
  <build>
    <plugins>
..
      <plugin>
        <groupid>org.apache.maven.plugins</groupid>
        <artifactid>maven-war-plugin</artifactid>
        <version>2.1</version>
        <configuration>
          <outputfilenamemapping>@{artifactId}@.@{extension}@</outputfilenamemapping>
          <overlays>
            <overlay>
              <!-- empty groupId/artifactId represents the current build -->
            </overlay>
            <overlay>
              <groupid>liferay.portal</groupid>
              <artifactid>portal-web</artifactid>
            </overlay>
          </overlays>
        </configuration>
      </plugin>
    </plugins>
    <finalname>ROOT</finalname>
  </build>

The /src/main/webapp directory contains all the changes that you are doing for the webapp like own custom web.xml. If you like to add new artifact for project just add it to dependencies.

If you need to fix example portal-impl.jar, create module for that and use shade plugin. With shade plugin you only have to code that has been changed, so your version control does not contain original Liferay code, which is makes upgrade more confusing.

To configure shade plugin do following example is portal-impl.

..
      <plugin><groupid>org.apache.maven.plugins</groupid>
        <artifactid>maven-shade-plugin</artifactid>
        <version>1.4</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <artifactset>
                <includes>
                  <include>liferay.portal:portal-impl</include>
                </includes>
              </artifactset>
            </configuration>
          </execution>
        </executions>
      
..
  <dependency>
    <groupid>liferay.portal</groupid>
    <artifactid>portal-impl</artifactid>
    <version>${liferay-version}</version>
    <scope>compile</scope>
  </dependency>
..

All the other dependencies scope should be provided or they would be included also to same jar. Now if you want to override Liferay's default class with your own just add that to /src/main/java folder and your fix has been included.

As an attachment there this empty version of this liferay maven build. It is relying that you are doing the deployment with Liferay version 6.0.6.

custom-liferay.zip

Install to tomcat

To install this, one easy way is to use Liferay 6.0.6 tomcat package as base package and remove <tomcat root>/webapps/ROOT directory and copy portal-web/target/ROOT.war.

Also copy portal-service.jar and support-tomcat.jar to <tomcat root>/lib/ext/. if you have changed those.

Final words

I have had good experiences this kind of Liferay build. It fit's well continous integration and it is make's Liferay customization upgrade easy and trackable. Actually at time of writing the current portal is based on custom-liferay.zip

Google's mod_pagespeed and Liferay

2010-11-04T21:57:20Z

Today I did pop into Google's article Make your websites run faster, automatically -- try mod_pagespeed for Apache". Google has created apache mod for page optimization, so I had to try it and I did install it to my site. This mod_pagespeed did came with excelent installation instructions, so the installation job took less than a minute!!

Installation did add some new mods and configurations to my apache.

/etc/apache2/mods-available/pagespeed.load
/etc/apache2/mods-available/pagespeed.conf

and it did enable that automaticly

/etc/apache2/mods-enabled/pagespeed.load
/etc/apache2/mods-enabled/pagespeed.conf

and following directory was created.

/etc/apache2/mod_pagespeed

Testing

I did some testing and did use Firefox HttpFox plugin to getting results from my home page.

Liferay it self is quite good for optimizing page loading with minimizing and combining css ja javascript. Without mod_pagespeed there where 26 requests and reload most of the requests did return http 304 (not modified).

With mod_pagespeed actually the request amount was only 21, which is five less - nice. Reload was same 21 request with most of 304 (not modified). Nice thing about this is that it knows automaticly how to combine javascripts,css and also images to one file. Strange is that html size did increase. See the results below.

Results

	with page_speed	without page_speed
	Received bytes	Request count	Received bytes	Request count
text/css	19423	2	21135	4
text/javascript	126620	3	128259	4
image/png	86136	13	81402	15
image/gif	8645	1	11565	1
text/html	8456	2	2054	2
	249280	21	244415	26

Conclusion

During the page load tests I did not find out any strange behavior, but when I did log in to Liferay. I did encounter that page load got stuck. When did disable mod_pagespeed, site did worked fine again. So my conclusion for this point is to wait this to get more mature. Anyway idea behind is great and it is clearly do able.

Liferay, jUnit, Mocking and Spring beans

2010-10-11T22:30:13Z

When developing Liferay war plugins with good junit test coverage - the mocking of Liferay api and services is important. Unit testing Liferay API is challenging, because all the API is wrapped on static util classes.

One typical case in Liferay development is to get web content article:

String article = JournalContentUtil.getContent(..);

These static util classes can be mocked with PowerMock(ito), but there are drawbacks. Powermock unit tests are usually quite slow and top of that Powermock contains nasty memory leak, which is increasing by each test and which makes huge amount of unit tests quite memory consuming (exactly permgen space consuming). You can get around this by set maven to fork each test, but that does tests even slower.

This was a problem real problem for me until now, because I took more deeper look on Liferay source code and exactly the design of one of the liferay services. That was JournalArticleServiceUtil.java and it contains following line of code:

service = (JournalArticleService)PortalBeanLocatorUtil.locate(JournalArticleService.class.getName());

When I did look this line, it came to me that I could use Spring FactoryBean to get hold on Liferay spring beans without Util class. Code would be much cleaner and there would not be static util class pollution* on mycode. PortalBeanLocatorUtil it self is allowing to do cross classloader calls which allows us to make use of Liferay's spring beans.

import org.springframework.beans.factory.FactoryBean;
import com.liferay.portal.kernel.bean.PortalBeanLocatorUtil;

public class LiferayFactoryBean implements FactoryBean {
	private Class type;

	public void setType(final Class type) {
		this.type = type;
	}

	@Override
	public Object getObject() throws Exception {
		return PortalBeanLocatorUtil.locate(type.getName());
	}

	@Override
	public Class getObjectType() {
		return type;
	}

	@Override
	public boolean isSingleton() {
		return true;
	}
}

The JournalContentUtil is lacking of the the call PortalBeanLocatorUtil.locate(..), but instead there is just setter. When you are going to look liferay Spring files inside portal-impl/META-INF/util-spring.xml you can find JournalContent also there, so you can use PortalBeanLocatorUtil.locate(..) for that too.

So let's make bean declaration to our portal application's spring applicationContext:

<bean id="journalContent" class="example.spring.LiferayFactoryBean" lazy-init="true">
		<property name="type" value="com.liferay.portlet.journalcontent.util.JournalContent"/>
	</bean>

Create Spring MVC controller (and here we are using autowiring):

@Controller
@RequestMapping("VIEW")
public class ExampleController {
	@Autowired
	private JournalContent journalContent;
	
	.. some code ..

	@ModelAttribute("content")
	public String getContent(RenderRequest request) {
		.. some code ..
		// Old way
		// JournalContentUtil.getContent(groupId, articleId, viewMode, languageId, themeDisplay)
		// New way
		return journalContent.getContent(groupId, articleId, viewMode, languageId, themeDisplay);
	}
}

Now when I create test for my class I can mock easily mock JournalContent without using Powermock.

Little library for java application profiling

2010-09-22T19:25:15Z

I did write little library for java profiling, Library is using Threadlocals for storing profiling information. The purpose of this is to collect all performance logs under same section and see performance bottlenecks from logs.

Example of log:

Timestamp: Start: Elapsed: ToNext: Action: THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.187 0 188 16 root THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.203       16      172       31 -com.sohlman.profiler.test.0.Doit.method0(..) THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.234       47        0       31 --com.sohlman.profiler.test.1.Doit.method0(..) THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.265       78        0       31 --com.sohlman.profiler.test.1.Doit.method1(..) THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.296      109        0       32 --com.sohlman.profiler.test.1.Doit.method2(..) THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.328      141        0       31 --com.sohlman.profiler.test.1.Doit.method3(..) THRESHOLD ROWINDENTIFIER

2010-09-22 20:36:12.359      172       16        0 --com.sohlman.profiler.test.1.Doit.method4(..) THRESHOLD ROWINDENTIFIER

This allows easily pin point performance problems and compare those to example jmeter output. Library also contains support for Spring AOP and has also Liferay filter and I'm currently using this under Liferay.

Liferay filter is where the profiling is started and application profiling calls goes under that.

To install profiler to Liferay

Put profiler-api jar under global class loader example on tomcat <tomcat root>/lib/ext and profiler-liferay under liferay webapp. Tomcat <tomcat root>/webapps/ROOT/WEB-INF/lib. Add following lines top of liferay web.xml

<filter>

<filter-name>Thread Local profiler</filter-name>

<filter-class>com.sohlman.profiler.liferay.filter.ProfilerFilter</filter-class>

</filter>

..

<filter-mapping>

<filter-name>Thread Local profiler</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

and your code put following

Watch watch = ThreadLocalProfiler.start();

..

ThreadLocalProfiler.stop(watch, ..);

You can use also Spring aop and profiler-spring-support or both.

The library is not ment to use on production, because it will generate lot of logs and add little overhead for application execution even though it is designed to minimize gc collection.

Jar file profiler-liferay does not contain any external dependencies so it can be used independently.

More information of this library and download can be found

http://code.google.com/p/java-threadlocal-profiler/

My first entry to personal log

2010-09-18T22:48:37Z

My first home page was on internet on 1996. Most of the years I have had pages available and my own domain name too. This page is now running on Liferay 5.2 and it is fast. Intel platform fits well for Liferay.