Liferay portals in real projects

Liferay in Real Projects
Common mistakes on Liferay projects and
ways how to avoid them
Aleš Rybák
Portal Specialist / Consultant
IBA CZ, s. r. o.

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

What the customer doesn't see

Themes
Integrations
Customizations

Portlets
Databases
Jobs

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

●

●

●

One portlet per use-case is
good start
merge some to avoid evidently
unnecessary IPC
this needs experience and
sort of sense

Hard to
–

change

–

reuse

–

optimize

●

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

Outnumbered by JavaScript libs

“Exotic” infrastructure
●

Well tested
–

Linux

●

Non-standard deploys

●

“Enterprise stack”
–

Liferay EE

–

Oracle DB

–
–

MySQL & Oracle

–

IBM Websphere AS

–
●

Tomcat
Apache

–

MS Windows Server

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

●

Compatibility problems

●

Extra knowledge required

●

WAS & WebLogic
–

things which take 10 minutes
on Tomcat can take hours

Build
Optimal solution
mvn clean install
...
BUILD SUCCESSFUL

Reality
●
●

●
●

●

●

For anything else have
documentation and e.g.
maven profile
Use CI / automatic builds

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

●

Unification

●

Automatization
–

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

●

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

Portlets mistakes
●

Big data in session

●

Stateful portlets

●

●

unnecessary
weird

Friendly URLs

●

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

–

IPC
–

Learn how to develop
portlets
–

processAction instead
render
–

●

●

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
–

–

formatting dates

–

controllers

–

file handling

Apache Commons

–
●

Spring

–

UI

Standards & RI

–

JMS

–

–

cache

–

Look for suitable
framework first

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
●

–

one global role per organization
●

–

only for small number of users
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

●

●

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 us
www.ibacz.eu
follow us
@IBACZ

Liferay portals in real projects

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Liferay portals in real projects

Similaire à Liferay portals in real projects (20)

Dernier

Dernier (20)

Liferay portals in real projects