Liferay portals  in real projects
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Liferay portals in real projects

on

  • 1,399 views

See what pitfalls companies are facing when running Liferay portal. In the previous year, our company has audited 5 real-life projects based on Liferay Portal which are now running in production mode ...

See what pitfalls companies are facing when running Liferay portal. In the previous year, our company has audited 5 real-life projects based on Liferay Portal which are now running in production mode and serving many users. The audits were focused on architecture, infrastructure, technical design and implementation. During the presentation, we will show you common anti-patterns we have found during the audits and their impacts and consequences on the portal.

Statistics

Views

Total Views
1,399
Views on SlideShare
1,298
Embed Views
101

Actions

Likes
2
Downloads
37
Comments
0

4 Embeds 101

https://www.ibacz.eu 97
http://cloud.feedly.com 2
https://cloud.feedly.com 1
http://www.ibacz.eu 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Liferay portals in real projects Presentation Transcript

  • 1. 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.
  • 2. 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
  • 3. Change needed, but how?
  • 4. What the customer does see
  • 5. What the customer doesn't see Themes Integrations Customizations Portlets Databases Jobs
  • 6. Audit
  • 7. Problem areas ● Architecture & design ● Build & release ● Code & technical realization – Unit tests – Frameworks ● Insufficient knowledge about Liferay Portal (not only) ● Governance & processes
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. Outnumbered by JavaScript libs
  • 12. “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
  • 13. 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
  • 14. 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
  • 15. 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!
  • 16. 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
  • 17. 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)
  • 18. Code and style 3 ● Static controls of the code – CheckStyle – PMD – FindBugs – SonarQube ● Read the book ● Have guidelines ● Do quick code reviews and refactorings
  • 19. 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); } ... }
  • 20. Resources wasting ● Not closing streams ● Not closing connections ● Missing cleanup actions (e. g. temp files) ● ● Use tested mature frameworks where possible Use static analysis
  • 21. 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
  • 22. Exceptions ● catching Throwable ● disposing caught Exceptions – not wrapping exceptions ● exception-driven development ● overusing of controlled Exceptions ● FIX: just don't ;-)
  • 23. Unit tests FIXES: ● define, what to test and how and stick to it ● make tests standard part of your delivery
  • 24. Unit tests FIXES: ● define, what to test and how and stick to it ● make tests standard part of your delivery
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. Security OWASP Top 10 is the minimum
  • 29. 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
  • 30. Liferay clustering ● Sessions ● Indexes ● Caches ● File storage ● Timers ● Underlying apps. & other frameworks ● web.xml – ● distributable Session objects – serializable
  • 31. 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”
  • 32. 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
  • 33. 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
  • 34. Final advices
  • 35. ● ● 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!
  • 36. ● ● 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!
  • 37. visit us www.ibacz.eu follow us @IBACZ
  • 38. the end