Brian Cheung Introduced the LESA system. It is an internal to Liferay team support system that resolves some of the issues JIRA has (for example multiple language support, issue response ranking to give for example 1 star for an engineer saying "won't fix, period", audit capabilities, simpler interface for example just responding is enough to reassign the issue. I asked if the product would be available as open source however there is not decision still taken on this regard.
Mike Hon spoke about plans for the document library like mounting from other datasources (repositories), windows explorer kind of user interface, version control for layouts, workflow engine integration to control document changing. He went through integration of a workflow backed form engine (Workflow forms). There are improvements on Message Center (which is a more complete solution than the email portlet), Contact Center, Expertise Locator: for large developer teams, Knowledge Base, blog (anti spam for example). He gave an introduction of DSL and Drools for portal assets. He spoke about the upcoming "Workflow Designer for Kaleo" a visual tool that will allow to manage workflows. Currently there are efforts to build a console for tomcat a la Websphere management console. There will be broader support for caching technologies. I asked about Workflow forms and expando and the response was that expando is just one of the possibilities for the workflow forms. I had the opportunity to talk to him about Workflow Engine. As it is today is very limited as it does not support any DSL however that seems to be enough for the needs of the community. In addition the workflow engine integrates very easy with Intalio or JBPM thanks to the pluggable architecture so for more complex needs the architecture is pluggable.
I talked again with Raymond about OSGI modularity and liferay and the lack of documentation on this regard. This is because it is indeed a brand new subject that the Liferay team is considering with very high priority. Raymond talked about improvements in WCM. He presented the new WYSIWYG editor. There are better indexing capabilities. Freemarker support has been added for those looking for a better alternative to talk to Java from templates. More things coming up: Support for local and Remote Live environment support, scheduling publishing to update the site just with the delta changes, locale buckets per articles. He showcased on Content Portlet,
Enhanced SEO support through smart tags, support for custom html header (h1, h2...) styles forward compatibility of exported LARs, support for liferay tags (Alloy UI) from Freemaker, very powerful feature indeed. He talked about Site branches: For example brand new skinning of the site been worked out months ahead a time. The reality is as I pointed out that this is more like a fork rather than real SCM. Merging concept for example does not exist and its indeed not needed. Content people (CSS, HTML) are able to work on this without any help from developers. He talked about the Web Based RAD, a neat product coming up (officially still unnamed) which would allow RAD capabilities right from the Web Interface. About OSGI, Liferay will be able to be patched at runtime for example thanks to OSGI. Java Class loaders will not longer be a problem. This will make Liferay of course a more scalable platform. I asked the question about why not using an existing SCM for WCM branching and the response was that pages have other components associated to them and they are all in the database and so they have developed the SCM themselves.
Ivan and Wesley talked about Liferay best practices: LDAP when a user logs in is a best practice as the data is brought into liferay just when it is needed. HA environment: synch ehcache for consistent data on nodes, clustering indexes for consistent search, centralize document library repository. Recommended of course to use SAN/File System option for file storage over DB. It caught my attention the existence of a Data Migration tool Portlet to mitigate the conversion of files to a new document file system. Hardening Liferay: Change admin password, default timezone and locale, default communities and roles.
nightly or hourly backup of DB. Schedule backups, use SCM to store code and Disaster recovery (remote data backups, secondary servers). Disaster recovery: Have a preproduction environment for minimizing downtime. Swap pre and production environments when new features are considered stable. On data changes: Avoid touching data, go always through the GUI and web service APIs, use absolute paths for deployment directory, specify in portal.properties where the liferay home is (license key, lucene search, deployment folder are stored there). On code maintanance: keep core and custom code separated, apply EE Service packs and emergency patches (hot fixes)
James Min talked about Performance and scalability. There is a white paper with data about benchmarks on the Liferay website. He presented the following showcase: 1 http server (xeon qc 2.4GHz, 2GB RAM) 2 app servers (xeon qc 2.4GHz 8GB RAM), 1 db (xeon qc 2.4GHz 4GB RAM, 1HDD 1500rpm). Got user data (1MM) taken from US census data (max 400MM users) ramp up period of 1 user every 100 msec from multiple injectors, warme up for 5 minutes.
They used Grinder from linux servers. For the Login transaction (one of the most expensive operations in the current Liferay implementation) they simulated 3000 users during 30 min and they got responses of second and a half with a maximum of 81% processor utilization. This is a point where it is clear more servers will be needed in the cluster as over 1.5 sec response time would not be a good user experience. For WCM, Message boards, Blogging and other scenarios data is available as well. He talked about standby times like hot-hot, hot-warm and hot-cold. They use VisualVM as a good tool to measure performance. He recommended several best practices to create scenarios that reflect actual usage like having ready load tester and test scenario (configuration, test script). Disaster recovery procedure should be tested every quarter at a minimum. Caching mechanisms: replicated distributed EhCache is available out of the box, just search for Cluster in portal.properties and that is enough to identify how to use cache. More advanced caching would be using sharded distributed cache: terracota and memcached are examples of it. He went ahead and recommended Mika's blog for terracota.
I spoke to some senior developers and consultants about supporting transactions in Liferay Portal. Now with the increased support at plugin level you can use the Liferay APIs in transactional way. Search for JTA in portal properties to find out how to support transactions in Liferay.
Finally I asked the question to several people backing up the whole environment. Code to svn, WCM in DB etc ... a way for automation? Data Migration tool? and in general that is a difficult task because Liferay is not opinionated but rather is trying to support any environment. I keep on defending that someone must come with a rapid development environment setup (most likely based on Maven) that could allow thousands of developers with scarce resources in their teams to catch up with Liferay way of developing fast enough. America at least is driven by small business and teams of 4 developers are more common than teams of over 20 developers. If the learning curve is high Liferay will not be addressing a broader community that could give up for more agile frameworks and languages in the near future.
One of the aanouncements was aboutFacebookConnect supported as opensso solution (OAth 2.0). I asked the question because I keep on writting and consulting about this: True SSO is not just a transparent login, it must implement keep alive and logout for a complete reach user experience. The Facebook solution is so far a transparent login and not a real SSO solution.
Brian Kim taked about Partner recognition and Brian Cheung concluded with a funny history of the company. I really enjoyed this part. It reminded me my trip to Rome and staying in a hostel very similar to the one he described. I found out how the Liferay logo comes from what we call in spanish "Vitros", those sensational glasses you find in Churches.
Jeff Handa talked about Liferay templates (page and site templates) This is an important step that addresses the issue of creating from scratch whole coomunities, pages and portlets. LAR import/export is not enough. Page templates Admins can define permissions on those templates and also other settings like Page type, layout template, portlet placement and configuraton. All that then can be reused when creating new communities. When creating new pages a drop down allows to pick the template provided you have permissions to view them. Site Templates (similar concept but for a collection of pages) were also visited. These features are available programatically: Service Builder managed entities(LayoutPrototype, LayoutSetPrototype) See the code for default-site-templates-hook to see how to use this programatically. See util classes LayoutLocalServiceUtil LayoutPrototypeLocalServiceUtil. Somne recommendations provided: Establish good naming conventions when building templates and set the right permissions from the beginning. Once the templates are used to create a new community they become final sites and pages and so they not longer get updated after changes.
Greg Amerson presented a workshop on Liferay Development Studio. Showed how to point to the portlet SDK. Support for Maven is coming up before the end of the year. He has published several videos online showing how to use eclipse liferay Interface. He mentioned that under the hood velocity templates are responsible for the magic behind the wizards and he has plans to expose that to the community so developers can create their own more complicated wizards. This will increase productivity for sure. He mentioned he will try to fix in the future the false negatives (red exes) that eclipse shows up on JSPs. Seriously I will follow up on this one with him, JSP support in Eclipse is not good in comparison with Netbeans and that is well simply not fair ;-)
Hope this post was large for something. I congratulate again the Liferay team for the effort they are making and I got a very positive experience from the Simposium. Hopefully Liferay will become an agile tool no matter its completeness and complexity.