Liferay in Real Projects

Portal Specialist / Consultant

IBA CZ, s. r. o.

Common mistakes on Liferay projects and ways how to avoid them

Aleš Rybák

Typical problems

● Disfunctions and non-standard behaviour

● Poor performance

● Stability problems

● Security vulnerabilities

● Overloading of integrated systems

● Usability issues

● Liferay's potential not fully leveraged

● Maintenance and service continuity is expensive

● Multi vendor env. doesn't exist

● Hard to implement changes

● Low business flexibility

Change needed, but how?

What the customer does see

What the customer doesn't see

PortletsThemes

Integrations Databases

Customizations Jobs

Audit

Problem areas

● Architecture & design

● Build & release

● Code & technical realization

– Unit tests

– Frameworks

● Insufficient knowledge about Liferay Portal (not only)

● Governance & processes

Absence of Information architecture

● Gap between applications and customer's needs / final state

● Only developed portlets and customizations. Let the customer to do the rest.

● Content first

● Connection between technology and real world problems

● Define structure of content and context for applications

● Base for usability

Misusing Liferay plugins

● Use plugins for the right purpose

– portlet plugin for new functionality

– themes and layouts for L&F

– hooks for JSP changes, mild changes via exposed APIs

– ext plugin for more drastical changes

● Use as non-invasive approaches as possible

● Avoid JS hooks

Portlet decomposition

● God portlet / Über-portlet

– one big portlet doing everything

– one portlet placed several times in portal with different configuration

● Hard to

– change

– reuse

– optimize

● One portlet per use-case is good start

● merge some to avoid evidently unnecessary IPC

● this needs experience and sort of sense

● when checking roles consider division into more smaller portlets for each role

Outnumbered by JavaScript libs

“Exotic” infrastructure

● Non-standard deploys

● “Enterprise stack”

– Liferay EE

– Oracle DB

– IBM Websphere AS

– MS Windows Server

● Compatibility problems

● Extra knowledge required

● WAS & WebLogic

– things which take 10 minutes on Tomcat can take hours

● Well tested

– Linux

– Tomcat

– MySQL & Oracle

– Apache

● KISS, use “exotic” components only if you know what you're doing (usually you don't)

Build

Optimal solution

mvn clean install...BUILD SUCCESSFUL

● For anything else have documentation and e.g. maven profile

● Use CI / automatic builds

Reality

● Missing artifacts

● Need to build each module separately

● Always needs to connect to VPN

● Side effects (e.g. deleting files on servers, accessing DB)

● Environment variables needed

● OS dependency

Snapshot version in production

● Supplier isn't tagging releases

● All changes go to the trunk which is only source

● Customer has no idea

– what is deployed on production

– what to test / accept

– whether reported bugs are fixed

– what's the state of the project

● Very good excuse for supplier

● FIX: release new versions with change log

Code and file system anarchy

● Mess everywhere● Every single thing in code is

done in different way● No rules for VCS

● Ad-hoc file/class/... naming and structures (depends on creator's fantasy)

● Backups into different places – no one knows if they are still valid/needed

● Unification

● Automatization

– Scripts / tools for most tasks

● In the code - do things

in a same way even

though it's not the best

way!

Code style

● “How to write unmaintainable code”

– http://mindprod.com/jgloss/unmain.html

– if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code

Code style 2

● High complexity – thousands of SLOC per method

● Unreadable code (sometimes it's better to remove all comments and reformat all sources automatically)

● Wrong decomposition and unclear structure

● Cyclic dependencies

● Massive duplication

● Unreachable code

● Code commented-out

● Bypassing conventions

● and many more (also in next slides)

Code and style 3

● Static controls of the code

– CheckStyle

– PMD

– FindBugs

– SonarQube

● Read the book

● Have guidelines

● Do quick code reviews and refactorings

Thread danger (the evil brother of Thread safety)

public class MyPortlet extends GenericPortlet {

private PageData data; // to be displayed in JSP

public void processAction(actionReq, actionResp) {data = prepareData(req);

}

public void doView(renderReq, renderResp) {dispatchToJSP(renderReq, renderResp, data);

}

...}

Resources wasting

● Not closing streams

● Not closing connections

● Missing cleanup actions (e. g. temp files)

● Use tested mature frameworks where possible

● Use static analysis

Logging

● Logging too many messages and unimportant info

● Crucial info is missing

● Missing context info (e.g. user ID, request ID, etc.)

● Logging private data

● Not using LOG.ifDebugEnabled()

● Define rules for logging

● Logs are most used (and sometimes the only) way to find out what went wrong on production

● If using Log4J use LogMF

● Read and analyze your logs – optimize the logging levels

Exceptions

● catching Throwable

● disposing caught Exceptions

– not wrapping exceptions

● exception-driven development

● overusing of controlled Exceptions

● FIX: just don't ;-)

Unit tests

FIXES: ● define, what to test and how and stick to it● make tests standard part of your delivery

Unit tests

FIXES: ● define, what to test and how and stick to it● make tests standard part of your delivery

Portlets mistakes

● Big data in session

● Stateful portlets

● processAction instead render

● IPC

– unnecessary

– weird

● Friendly URLs

● Learn how to develop portlets

– start with standard pure Java portlets (read JSR-286 standard)

– look if framework you are using has support for portlets or portlet bridge

● Stick with best practices

Frameworks non-usage

● Reinventing the wheel in code

● Developing my own framework

– cache

– JMS

– UI

– formatting dates

– controllers

– file handling

● Look for suitable framework first

– Standards & RI

– Spring

– Apache Commons

– Other sources

● Select the mature supported one

JPA / Hibernate

● Doing in Java what DB should do (e. g. list size)

● Combination with pure JDBC

– problem with 2nd level cache

● Cascades

● Explicit entity refresh

● Many requests

– very often can be optimized

Security

OWASP Top 10 is the minimum

Liferay users, roles, groups, permissions...

● One of the most used Liferay's APIs

● “Patterns”

– one role per user

● only for small number of users

– one global role per organization

● define and use organization roles

– one role per document

● never ever do this

Liferay clustering

● Sessions

● Indexes

● Caches

● File storage

● Timers

● Underlying apps. & other frameworks

● web.xml

– distributable

● Session objects

– serializable

Business knowledge of Liferay

● Unable to provide consultancy in required or any quality

● Customer is able to maneuver supplier into unnecessary drastic customizations

– “bender and narrower”

Technical knowledge of Liferay

● Many customizations are done programmatically

– changes in Java code, JSPs, sometimes across whole solution including interfaces

– some of these changes can be done via configuration

● Examples

– Registration

– no-cache headers

– Changes of tag libs

Undefined competences

● Hidden responsibilities and costs for customer

– portal platform

– application servers

– connected systems

– monitoring and maintenance

● Define what is and what isn't part of the project

● Identify risks and owners

Final advices

● Copy-paste code from StackOverflow – it's in acceptable quality

● Don't make tags or release any versions (this one is final)!

● Read “how to write unmaintainable code” and follow it

● Never test your code!

● Write your own frameworks! The more, the better.

– Never test your frameworks!

● Be agile! = Never write any documentation!

● Act like fools and just don't care!

● Copy-paste code from StackOverflow – it's in acceptable quality

● Don't make tags or release any versions (this one is final)!

● Read “how to write unmaintainable code” and follow it

● Never test your code!

● Write your own frameworks! The more, the better.

– Never test your frameworks!

● Be agile! = Never write any documentation!

● Act like fools and just don't care!

● Don't blame Liferay for another application's problems!

visit uswww.ibacz.eu

follow us@IBACZ

the end