AdoptOS

Assistance with Open Source adoption

ECM

Fut a Liferay - Interjú Vilivel

Liferay - 13 hours 18 min ago

A mostani epizódban Vilit, a Liferay egy régi motorosát faggattam, milyen is az élet a magyar irodában. 

 

Kérlek nevezd meg a pozíciódat és mondd el, ez mit takar. - Az eszkalációs, velem együtt két fős "csapat" vezetője vagyok és Escalation Engineer pozicióban dolgozom. Ez azt jelenti, ha valami technikailag nagyon bonyolult problémával fordul hozzánk az ügyfél, amit a Support Engineer első körben nem tud reprodukálni, vagy olyan komplex környezetben lehetne csak rekreálni, amit nem tudnak gyorsan összeállítani, akkor továbbítják hozzánk az ügyet és mi dolgozunk rajta. Illetve ad-hoc jelleggel konzultálni is  szoktam.    Mióta dolgozol a Liferaynél és miként jutottál el az Escalation Engineer pozícióba?  - 2010 Novembere óta vagyok a cégnél. BZ-t korábbról már ismertem a Liferay Community fórumról, mivel az előző cégemnél is Liferay-t használtunk és voltak kérdéseim, amikre Ő válaszolt a fórumon még mielőtt a Liferay Hungary Kft. megalakult volna. Mivel elég sok stresszel járt az előző munka, szerettem volna valami nyugodtabb légkört, ahol a munkával jól megfér az, hogy valakinek családja, kisgyereke van és a 8 óra tényleg 8 óra és akár a home office is megoldható esetenként. Szerencsére a Liferay pont ilyen volt, így amikor megfogalmazódott bennem a döntés, hogy váltsak, megkérdeztem BZ-t (aki megsúgta már korábban, hogy lesz magyar iroda), hogy keresnek-e embert, és igen volt a válasz. Az interjún Ivan-nel is kellett beszélnem angolul, ami nem lett volna gond, hiszen angol tagozatos gimnáziumban végeztem, de előző helyemen 8 évig szinte csak olvasásra használtam, így azért volt némi lámpaláz bennem. Szerencsére nem fagytam le, gördülékenyen ment a társalgás, a technikai tudásom pedig BZ számára már ismert volt, hiszen volt, hogy hétvégi pecázás közben a tóparton közösen debuggoltunk valamit amivel nagyon mély Liferay specifikus tudás nélkül nem lehetett volna boldogulni.    Mit szeretsz a munkádban a legjobban? - Szeretek segíteni másoknak, és szerencsére a kollégáim olyanok, hogy nem félnek kérdezni és tanulni a másiktól ha valaki esetleg tapasztaltabb. Mindig is szerettem új dolgokat megtanulni és szinte soha nincs két egyforma issue-nk. Az ügyfelek leleményesek, a meglévő technológiák mellé még nagyon sok mást bevonnak a projektjeikbe, így ilyen esetekben rövid időn belül fel kell zárkózni, hogy érdemben el tudjam dönteni, lehet-e ráhatása a bejelentett problémára és ha igen, akkor mi az. Mielőtt ide jöttem, a Tomcat servlet container és JBoss application server kivételével nem sok tapasztalatom volt. Mára alaposan megismertem már a Weblogicot és bizonyos fokig a Websphere-t, Glassfish-t is. Ezek mellé 2-3 adatbázis kezelővel is össze kellett barátknoznom a MySQL és MSSQL után.   Mit szeretsz a Liferayben a legjobban?  - Nagyon rugalmas, és a kollektíva is olyan, hogy segítik egymást az emberek. Például ha valaki épp költözne és nem lenne segítsége pakolni, csak megemlíti a konyhában és pár órán belül szinte biztosan megszerveződne egy brigád akik segítenének neki. Nagyon szeretek utazni és jó pár alkalmam volt rá céges utak keretein belül.    Aki esetleg azon gondolkodik, hogy jelentkezne a Liferay-hez, miért ajánlanád neki a céget?  - Ha már dolgoztál nagy vállalatnál projekten, és tudod milyen érzés a beledet kihajtani, hogy aztán fél év után kidobják a munkád és kezdhesd elölről, de ezt nem szereted, akkor gyere hozzánk! Nálunk nem fogsz túlórázni, időben haza érsz a családodhoz és lesz időd a magánéletedre, mindezt nem éhbérért.    Több kolléga hobbija a futás, de Te űzöd ezt a legkomolyabban. Miért pont a futás? - A feleségem elkezdett futni pár éve és a gyerekek kérdezték, hogy apa te miért nem futsz? Bele gondolva jó kérdés volt. Korábban évekig lőttem légpuskával, de az ugye technikai sport, semmi mozgással, viszont ennek köszönhetően a gimnáziumban bekerültem egy csapatba, amit a Komlói Polgári Védelem vezetője szervezett, hogy a diákok ismerkedjenek a Polgári Védelem (ma már Katasztrófa Védelem) feladataival, és ehhez volt meghirdetve verseny középiskolásoknak. Az eredeti csapatból kimaradtam betegség miatt, sőt nem is tudtam, hogy lesz ilyen, viszont az egyik csapattag lesérült és kiderült, a következő versenyen lövészet is  lesz. Egy másik csapattag régi lövész csapattársam volt, engem ajánlott a pozícióra. Ezen a versenyen, ami egy akadály pálya volt állomásokkal, futva kellett megtenni a távot, közben elsősegélyt nyújtani, "radioaktív vagy vegyi szennyezett" területről embereket menteni vegyvédelmi ruhában, tüzet oltani és még pár érdekes akadályt legyőzni. A futással már ott sem volt problémám, viszont az évek alatt eléggé eltunyultam a munka során és 2007-ben még egy féloldalas bénulást is sikerült átvészelnem, ami a túl sok stressz miatt alakult ki. Így pont időszerű lett a mozgás, hogy a kilók lemenjenek és a keringési rendszerem is helyre álljon.     Tavaly lefutottál 2015 kilométert, idén is van különleges cél?  - Idén több cél is van, bár mostanában sajnos engem is megtaláltak a sérülések. Az egyik cél a 2016 kilométer ami motivál és elég sok kilométert "tesz" a lábamba, hogy az októberi maratont végig tudjam futni. Igaz tavaly a 30km-es távot gond nélkül lefutottam, de aki már futott maratont, azt mondja, hogy a maraton 30km-nél kezdődik igazán, mert mentálisan és fizikailag onnan lesz igazán nehéz. Általában 25-30 km között jön a fal, bár ez gondolom az edzettségtől is függ. Emellett még a félmaratoni időmet szeretném javítani. A cél 1:55:00, hivatalos távon eddig 1:58:31 volt a legjobb, de futottam már 1:55:41-et is a 2015-ös Night Run-on. Bár ott a GPS-em szerint hiányzott 400 méter a teljes távból.   Andrea Tamás 2016-04-29T10:13:36Z
Categories: CMS, ECM

How can I build Liferay 7.0 from source?

Liferay - Wed, 04/27/2016 - 11:09
How can I build Liferay 7.0 from source?

To build Liferay 7.0 from source:

  1. Obtain the source code:*

    git clone https://github.com/liferay/liferay-portal.git --depth 1
  2. Navigate to your new liferay-portal directory:

    cd liferay-portal/
  3. In your app.server.${yourname}.properties file, set the location where you want Liferay 7.0 to be built:

    echo "app.server.parent.dir=/path/to/liferay-portal" > "app.server.$(whoami).properties"
  4. Optional: If you want to build the Wildfly 10 bundle rather than the default Tomcat bundle:

    1. Add app.server.type=wildfly to app.server.${yourname}.properties:

      echo "app.server.type=wildfly" >> "app.server.$(whoami).properties"
    2. Download and unzip Wildfly in your ${app.server.parent.dir} directory:

      ant -f build-dist.xml unzip-wildfly
  5. Build Liferay 7.0:

    ant clean all

Now you should be able to start up Tomcat (or Wildfly), and Liferay 7.0 should be accessible at localhost:8080.

* I recommend getting a shallow clone since Liferay is a huge project with massive amounts of history and commits. Shallow cloning speeds up the clone process quite a bit.

Kyle Joseph Stiemann 2016-04-27T16:09:51Z
Categories: CMS, ECM

Ízes élet a magyar irodában - Interjú Zsagával

Liferay - Wed, 04/27/2016 - 04:19
Egy interjúsorozat keretein belül szeretnék egy kis betekintést nyújtani a Liferay Magyarország irodájába, annak működésébe, dolgozóinak mindennapjaiba.     Első alanyom volt Zsaga, aki a magyar csapat oszlopos tagja.      Mi a pozíciód a Liferay-en belül?  - Technical Support Engineer vagyok, UI hibák javításával foglalkozom.   Mióta dolgozol a Liferay-nél?  - 2010 április 1 (a kezdeteket óta), ezelőtt egy külsős cég dolgozott Liferay projekteken, már itt foglalkoztam a Liferay portállal, majd mikor megalakult a Liferay Magyarország, váltottam.    Miért döntöttél úgy hogy a Liferay-nél folytatod? - Az előző cégnél Java fejlesztő voltam, majd mikor megalakult a Liferay, automatikusan átkerültem az új céghez. Nem igazán az én döntésem volt. Akkoriban még alig tudtam valamit a Liferay-ről.    Miért ajánlanád az állást keresőknek a Liferay-t? - Mert én itt nagyon jól érzem magam, szerintem más is jól érezné magát. :)   És miért érzed jól magad itt? - Nem fontossági sorrendben fogom sorolni. Nagyon szép irodában dolgozunk. Biztos munkahely és bár esetenként előfordul monotonitás, minimális a stressz és nyugodt a munkakörnyezet. A cégen belül lehetőség van arra, hogy a saját utadat keresd és az általad kiválasztott területen fejlődj. Nem utolsósorban, az évek alatt szoros viszonyom alakult ki több kollégámmal is.    Mi teszi egyedivé a Liferay-t? - Nincs különösebb összehasonlítási alapom, hiszen IT területen ezen kívül csak egy cégnél dolgoztam. Én úgy gondolom, ha egy helyen jól érzem magam, nem érdemes máshova menni.    Mi a kedvenced (bármi) a Liferayben?  - Amikor sütögetünk a kollégákkal, vagyis én sütök nekik. :)   Te vagy a hamburger-mester, ez hogy alakult ki?  - Alapvetően szeretek segíteni másoknak, tenni másokért. A cég vett egy grillsütőt és BZ-vel  kitaláltuk, hogy sütögessünk. De ha már sütés-főzés, nyilván süssünk-főzzünk mindenkinek. Csináltunk már hamburgeren kívül babgulyást, rántottát, bundás kenyeret.    Elárulod a híres hamburger receptet? - Összedobálom a következőket: 2:1 arányban darált marha és sertés, tojás, zsemlemorzsa, hogy összeálljon, ketchup, mustár, só, bors, chilli és ízlés szerinti fűszerek, és persze vöröshagyma, fokhagyma. Mindig jól átsütöm, mert mindent jól átsütve szeretek. :) Andrea Tamás 2016-04-27T09:19:23Z
Categories: CMS, ECM

Creating service builder mvc portlet in Liferay 7 with Liferay IDE 3.

Liferay - Tue, 04/26/2016 - 11:14

Liferay IDE Download Page: https://web.liferay.com/downloads/liferay-projects/liferay-ide

Liferay IDE 3 has massive change regarding to Liferay 7. One of the change is it streamlines the creation of OSGi modual portlet by utilizing Liferay Blade tool, gradle elipse plugin and bnd tool.

One of the most concerned question by the Liferay developers is how we develop Service Builder with MVC portlet in new Liferay 7 development pattern.

With Liferay IDE 3 it's quite easy!

First we need to create a Liferay Space project.

A Liferay Workspace is a project container for Liferay porjects, within the Liferay workspace, we can develop and manage Liferay plugins.

And next we need to create a new Module Project by clicking File -> New -> Liferay Module Project, and choose the Project Template Name servicebuilder.

In the Liferay Workspace perspective 

We can see there are 2 gradle project under the service builder project. API project containse the service definition and interfaces, as the service path folder in 6.2. Service project contains the actual implementation of the service, as the service code in src folder in 6.2.

It contains a default service.xml. You can change the xml according to your need. After that, you can run buildservice task of service-builder-project-service in Gradle Task Window. 

After running buildService then run build task, the service will be ready to use.

 

How can we reference this service module in a mvc portlet module?

We use gradle to manage dependency.

We can create a mvc portlet Liferay Module Project. And modify build.gradle file. In our case we can add the following code to the dependency declaration.

compile project(":modules:service-builder-project:service-builder-project-api")

The service will be available to the mvc portlet. If the editor still complain about the dependency you can right click to the project -> gradle -> refreash gradle project to refreash the project.

When you deploy the project, remember to deploy 3 jars for api, service and mvc portlet.

Neil Jin 2016-04-26T16:14:32Z
Categories: CMS, ECM

Get latest Valamis EE patches here!

Liferay - Wed, 04/20/2016 - 00:40

As you know, Valamis Learning Experience Platform is available from Liferay Marketplace. This package is updated four times a year when a new version of Valamis EE is released. But between these main releases we are also doing smaller releases to the product which you're not able to get from Liferay Marketplace. These smaller patches usually contain various smaller updates that are easy to patch on top of the previous patch. The latest Valamis EE version package is always available from our Valamis website. We also release newest version of Valamis first to our website. In case you want to know when a new Valamis release is done, subscribe to our news watch.

Henri Korhola 2016-04-20T05:40:51Z
Categories: CMS, ECM

Liferay 7 GA1 Doxygen

Liferay - Sat, 04/16/2016 - 23:39
Doxygen Output for Liferay 7 CE GA1

Visualize Liferay Classes, Methods; with the help of UML Inheritance, Collaboration diagrams for Classes; and Call, Caller graphs for methods; generated using Doxygen tool.

Check out the following link to try it:
http://liferay.seebgroup.com/7ce/doxygen/output/html/

Below's a summary of what you'll find. Also, instructions on how this was done.

 

Summary of the Doxygen Output

  • View class's inheritance diagram; via standard UML notation.

 

 

 

 

 

 

 

 

 

 

 

  • View class collaboration diagram; via standard UML notation.

 

 

 

 

 

 

 

 

 

 

 

 

  • View some additional method details: method source code, call graph, and caller graph.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Helps digesting complex Liferay methods; such as MainServlet.service method; by visualizing method's call graph. The red boxes mean the node has over maximum allowed child nodes; I have chosen 100 for maximum allowed child nodes; others can adjust that value as needed ; see instructions at bottom to do so.

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Additional features thrown in the mix: list all variabels, methods, and more.

 

 

 

 

 

 

 

 

  • View markdown files included in source code...

 

 

 

 

 

 

 

 

 

  • Browse packages included in source code...

 

 

 

 

 

 

 

 

 

 

 

 

 

How to generate the output yourself

Prerequisites: doxygen 1.8.12 (the main tool which generates output),  graphviz (used to generate the UML diagrams via 'dot' command)

1. Install prerequisites: Doxygen  and Graphviz

2. Unzip Liferay 7 CE GA1 source code to a directory.

3. Open attached Doxygen configuration file (tested with version 1.8.12)

Update Line 782 from this:

INPUT                  =/opt/lr/7ce/liferay-portal-src-7.0-ce-ga1/

To point to the folder where you have Liferay 7 (or any other version's) source code.

4. Finally run the following command:

/opt/doxygen/build/bin/doxygen liferay-portal-src-7.0-ce-ga1

With the options in the settings file, this may take several hours to run depending on the machine's processor speed. The resulting output is about 18GB.

There are lots of options in Doxygen. One way to see what options are set is to do the following:

/opt/doxygen/build/bin/doxygen -g default diff default liferay-portal-src-7.0-ce-ga1

This will show all fields modified by the custom configuration.

Thank you to Liferay and community.

 

 

 

Originating blog post's link is this: https://www.bvakili.com/blog/-/blogs/liferay-7-ce-ga1-notes

Bijan Vakili 2016-04-17T04:39:55Z
Categories: CMS, ECM

日本ライフレイによるSIer様向けセミナーのご案内

Liferay - Fri, 04/15/2016 - 02:55

こんにちは! 日本ライフレイでマーケティングを担当しています、梅野です。日本におけるLiferayの認知度向上および日本のLiferayファンを一人でも多く増やしたいと思い、日本語のブログを始めています。

さて、本日はちょっと告知を…。今回はシステムインテグレータ(SIer)様向けイベントのご案内です。実は日本ライフレイでは、昨年からSIer様向けのイベントを隔月のペースでセミナーを実施しています。今年に入って内容をリフレッシュして、よりエンドユーザ様へのシステム提案がしやすくるなる具体例を含めるようにしました。今度は5月20日に開催します。

 

無償のこのセミナー、「以前からちょっと興味を持っていた」とか「お客様にLiferayって言われたけど…」など様々な背景の方が参加されています。ぜひこの機会にご参加ください。 もし、今回ご都合が合わなかった場合は、ぜひ次回に! 次回は6月を予定しています。

セミナーの詳細およびお申し込みは、オープンソース活用研究所のマジセミをご覧ください。

皆様にお目にかかるのをお待ちしております。

では、また次回!
Until next time!

Emiko Umeno 2016-04-15T07:55:02Z
Categories: CMS, ECM

Liferay Symposium NA Call for Proposals is Open!

Liferay - Thu, 04/14/2016 - 13:31

 

Each year, the Liferay Symposium attracts top Liferay users and experts to share their experiences on business and technology. It's a forum to discuss new and inventive ways on how to maximize Liferay investments in light of quickly changing customer and business needs.

We're looking for exciting presenters to speak about digital transformation, customer experience, connected technologies, vertical-specific solutions, applications, and use cases. If you have an interesting story to share, we want to hear from you!

 

Submit a Proposal

 

We look forward to your submissions!

 

Team Registration

Bring the team to divide and conquer. Register with a group of 3 or more to save $250 each off the standard price.

Post-Symposium Training

Sign up for post-symposium training to learn directly from Liferay experts and maximize your conference experience.

#LSNA16

                    

 

Angela Wu 2016-04-14T18:31:14Z
Categories: CMS, ECM

Liferay Symposium NA Call for Proposals is Open!

Liferay - Thu, 04/14/2016 - 13:31

 

Each year, the Liferay Symposium attracts top Liferay users and experts to share their experiences on business and technology. It's a forum to discuss new and inventive ways on how to maximize Liferay investments in light of quickly changing customer and business needs.

We're looking for exciting presenters to speak about digital transformation, customer experience, connected technologies, vertical-specific solutions, applications, and use cases. If you have an interesting story to share, we want to hear from you!

 

Submit a Proposal

 

We look forward to your submissions!

 

Team Registration

Bring the team to divide and conquer. Register with a group of 3 or more to save $250 each off the standard price.

Post-Symposium Training

Sign up for post-symposium training to learn directly from Liferay experts and maximize your conference experience.

#LSNA16

                    

 

Angela Wu 2016-04-14T18:31:14Z
Categories: CMS, ECM

Liferay - 6 éve Magyarországon

Liferay - Mon, 04/11/2016 - 05:22
(This blog entry in only available in Hungarian).  

Április elsején lett 6 éves a Liferay magyar irodája. Alapítótagként visszaemlékezve ennek nagyon hosszú időnek kellene érződnie, de valahogyan nem az. Még mindig emlékszem arra a percre amikor megkaptuk az első ticketet és elkezdtünk dolgozni mint egy csapat. Azóta nagyon sok minden történt velünk: felépítettünk egy remekül működő 45 fős irodát, több nemzetközi projektet mi indítottunk útjára és rengeteg ügyfélnek segítettünk abban, hogy a projektjeik sikeresek legyenek.

 

 

A nemzetközi cégcsoportnak is ugyanazon a napon van az évfordulója, 12 éves lett a Liferay. Ezzel a korral, mi a cég történetének a felében már részt vettünk, egy meghatározó iroda lettünk. Irodánkból támogatjuk az EMEA régió ügyfeleit, a budapesti csapat fejleszti az egyik legkritikusabb komponenst (staging) és mi vagyunk felelősek az összes kiadott hibajavításért, ideértve a biztonsági javításokat is.


6 évvel ezelőtt 5-en kezdtük el a céget, mára 47-en vagyunk és folyamatosan veszünk fel új munkatársakat. Sikerült egy olyan csapatot kiépíteni, ahova mindenki szivesen jön be nap mint nap dolgozni. Hogy bemutassuk a csapatunkat, a következkező néhány hétben megosztok majd interjúkat nálunk dolgozó kollégákról, itt a blogon.


Amennyiben érdekes lehet számodra, hogy milyen Magyarországon dolgozni egy Open Source cégnél, kövess minket twitteren: @Liferay_hu.

  Zsolt Balogh 2016-04-11T10:22:47Z
Categories: CMS, ECM

Liferay - 6 éve Magyarországon

Liferay - Mon, 04/11/2016 - 05:22
(This blog entry in only available in Hungarian).  

Április elsején lett 6 éves a Liferay magyar irodája. Alapítótagként visszaemlékezve ennek nagyon hosszú időnek kellene érződnie, de valahogyan nem az. Még mindig emlékszem arra a percre amikor megkaptuk az első ticketet és elkezdtünk dolgozni mint egy csapat. Azóta nagyon sok minden történt velünk: felépítettünk egy remekül működő 45 fős irodát, több nemzetközi projektet mi indítottunk útjára és rengeteg ügyfélnek segítettünk abban, hogy a projektjeik sikeresek legyenek.

 

 

A nemzetközi cégcsoportnak is ugyanazon a napon van az évfordulója, 12 éves lett a Liferay. Ezzel a korral, mi a cég történetének a felében már részt vettünk, egy meghatározó iroda lettünk. Irodánkból támogatjuk az EMEA régió ügyfeleit, a budapesti csapat fejleszti az egyik legkritikusabb komponenst (staging) és mi vagyunk felelősek az összes kiadott hibajavításért, ideértve a biztonsági javításokat is.


6 évvel ezelőtt 5-en kezdtük el a céget, mára 47-en vagyunk és folyamatosan veszünk fel új munkatársakat. Sikerült egy olyan csapatot kiépíteni, ahova mindenki szivesen jön be nap mint nap dolgozni. Hogy bemutassuk a csapatunkat, a következkező néhány hétben megosztok majd interjúkat nálunk dolgozó kollégákról, itt a blogon.


Amennyiben érdekes lehet számodra, hogy milyen Magyarországon dolgozni egy Open Source cégnél, kövess minket twitteren: @Liferay_hu.

  Zsolt Balogh 2016-04-11T10:22:47Z
Categories: CMS, ECM

Content-driven applications: A Marriage Between CMS Templates and RESTful services

Liferay - Sun, 04/10/2016 - 08:32

I've been busy building web application content.

  • A simple form with three fields
  • Under the form, a table shows the previously added records
  • The data in the table can grow to several hundred
  • Blah blah blah

We've done this many times. And we've got enough tools from here to the mooon and back to get it all done pretty well.

But of late, I've been bitten by the CMS template bug. The sheer power of CMS templates and the vantage point they offer to being able to examine the entire technology landscape AND interact with it is not a thing to be ignored.

Parts of my web application

A CMS structure

Here is where I define all the fields I can use to configure my application. Example fields include:

  • Caption
  • Header text
  • Footer text
  • Preferred style for buttons
  • Default page size for table records
  • Payment gateway request URL
  • Payment gateway success URL
  • Payment gateway failure URL
  • etcetera

A CMS template coded in velocity

This has equal parts Javascript and HTML. I use AUI, jQuery and a cocktail of them both wherever I feel the best of both worlds can be had.

My CMS template basically has a bunch of javascript at the top that is pulling in relevant fields from the structure.

The javascript is followed by some very tight (and light) HTML markup peppered with bootstrap classes and some minute inline javascript I didn't care to get rid of.

A journal article using this structure and template

This is where the structure becomes concrete. I specify values for the fields in the backing structure. These are the values that will configure my application.

An auxiliary suite of servlets

This is a web application containing a suite of simple, focused HttpServlets that are wrapped by Liferay's magical PortalDelegateServlet. If you don't know what that is, definitely look it up.

These servlets let me sneak under the portal's authentication hood and examine various session data. I can test that the user is authenticated (via CAS). If my servlets decide that user is not authenticated (or authorized as the case may be), my CMS template can roll over and play dead.

A RESTful service layer

...powered by my preferred JAX-RS implementation, Jersey. Lots of API resources here for all the little (and big) operational units we need to execute. There are POJO's (for use by JAXB) and various utility classes.

Now, for the over-dramatized monologue. Why use CMS when, really, this should be a portlet?

It IS a portlet. It is the Web Content Display portlet that Liferay gave us out of the box.

Yeah, yeah. But then you're tied to the configuration that the Web Content Display portlet comes with. Right?

Yes. Exactly. It's content. I like to call it - stares off into space thoughtfully, then snaps back in an epiphanic moment -  I like to call it application content.

Alright, wise guy, how do you configure YOUR Web Content Display portlet?

I TOLD YOU. The journal article I created above lets me populate all those fields in the backing structure. Those fields are what I rely on to configure my (not going to say 'portlet') application content. There's a meta-shift in thought here.

What about the JSR-286 portlet spec and the cool lifecycle of a portlet?

Dude. Liferay's Web Content Display portlet follows the JSR-286 spec. It lives that lifecycle. It's all that already. Except I don't care about those parts. What I've done is essentially coded up a Single Page Application into my CMS template instead of into the portlet JSP.

Okay. But why?

Because I wanted to use all that ajax goodness anyway. Why would I want to put that into portlet JSPs when I can talk to my REST layer directly from velocity-enriched HTML. It's done all over the place.

Besides, when we upgrade to Liferay 7, this application content won't need any special migration. It should (hopefully) be supported as part of the standard CMS upgrade. And then, if I want to avail of Senna.js to write a real portlet-aware SPA application, it will be a lot easier to port my REST-conversant javascript over to an SPA.

The end is met

The means are fair

Or so I think. I would love to hear from the larger community and have this approach taken apart. Only good can come from any constructive criticism.

In the meantime though, this is soooo liberating. Frees me up to divert all my Java into a rich, flexible REST layer.

And all my UI code is slimmed down to HTML5 + Javascript + CSS - exactly what it ought to be.

Like I said: I've been busy building web application content.

Javeed Chida 2016-04-10T13:32:55Z
Categories: CMS, ECM

Content-driven applications: A Marriage Between CMS Templates and RESTful services

Liferay - Sun, 04/10/2016 - 08:32

I've been busy building web application content.

  • It has a simple form with three fields
  • Under the form, a table shows the previously added records
  • The data in the table can grow to several hundred
  • Blah blah blah

We've done this many times. And we've got enough tools from here to the mooon and back to get it all done pretty well.

But of late, I've been bitten by the CMS template bug. The sheer power of CMS templates and the vantage point they offer to being able to examine the entire technology landscape AND interact with it is not a thing to be ignored.

Parts of my web application

A CMS structure

Here is where I define all the fields I can use to configure my application. Example fields include:

  • Caption
  • Header text
  • Footer text
  • Preferred style for buttons
  • Default page size for table records
  • Payment gateway request URL
  • Payment gateway success URL
  • Payment gateway failure URL
  • etcetera

A CMS template coded in velocity

This has equal parts Javascript and HTML. I use AUI, jQuery and a cocktail of them both wherever I feel the best of both worlds can be had.

My CMS template basically has a bunch of javascript at the top that is pulling in relevant fields from the structure.

The javascript is followed by some very tight (and light) HTML markup peppered with bootstrap classes and some minute inline javascript I didn't care to get rid of.

A journal article using this structure and template

This is where the structure becomes concrete. I specify values for the fields in the backing structure. These are the values that will configure my application.

An auxiliary suite of servlets

This is a web application containing a suite of simple, focused HttpServlets that are wrapped by Liferay's magical PortalDelegateServlet. If you don't know what that is, definitely look it up.

These servlets let me sneak under the portal's authentication hood and examine various session data. I can test that the user is authenticated (via CAS). If my servlets decide that user is not authenticated (or authorized as the case may be), my CMS template can roll over and play dead.

A RESTful service layer

...powered by my preferred JAX-RS implementation, Jersey. Lots of API resources here for all the little (and big) operational units we need to execute. There are POJO's (for use by JAXB) and various utility classes.

Now, for the over-dramatized monologue. Why use CMS when, really, this should be a portlet?

It IS a portlet. It is the Web Content Display portlet that Liferay gave us out of the box.

Yeah, yeah. But then you're tied to the configuration that the Web Content Display portlet comes with. Right?

Yes. Exactly. It's content. I like to call it - stares off into space thoughtfully, then snaps back in an epiphanic moment -  I like to call it application content.

Alright, wise guy, how do you configure YOUR Web Content Display portlet?

I TOLD YOU. The journal article I created above lets me populate all those fields in the backing structure. Those fields are what I rely on to configure my (not going to say 'portlet') application content. There's a meta-shift in thought here.

What about the JSR-286 portlet spec and the cool lifecycle of a portlet?

Dude. Liferay's Web Content Display portlet follows the JSR-286 spec. It lives that lifecycle. It's all that already. Except I don't care about those parts. What I've done is essentially coded up a Single Page Application into my CMS template instead of into the portlet JSP.

Okay. But why?

Because I wanted to use all that ajax goodness anyway. Why would I want to put that into portlet JSPs when I can talk to my REST layer directly from velocity-enriched HTML. It's done all over the place.

Besides, when we upgrade to Liferay 7, this application content won't need any special migration. It should (hopefully) be supported as part of the standard CMS upgrade. And then, if I want to avail of Senna.js to write a real portlet-aware SPA application, it will be a lot easier to port my REST-conversant javascript over to an SPA.

The end is met

The means are fair

Or so I think. I would love to hear from the larger community and have this approach taken apart. Only good can come from any constructive criticism.

In the meantime though, this is soooo liberating. Frees me up to divert all my Java into a rich, flexible REST layer.

And all my UI code is slimmed down to HTML5 + Javascript + CSS - exactly what it ought to be.

Like I said: I've been busy building web application content.

Javeed Chida 2016-04-10T13:32:55Z
Categories: CMS, ECM

Liferay Portal 7 CE - App Server, Database & Clustering Support

Liferay - Thu, 04/07/2016 - 13:55

Today I’d like to let you know that Liferay Portal 7 Community does not have "out of the box" support for clustering, non-open source app servers (Oracle WebLogic, IBM WebSphere), and non-open source databases (Oracle Database, Microsoft SQL Server, IBM DB2, Sybase DB). Support for these non-open source systems will be found in Liferay's current and future commercial releases, which are available by Subscription, or you can develop your own OSGi module independently to support these features.

It’s a huge decision and we think it may raise concerns from some community members, so we want to be upfront and explain our thinking. Why are we doing this?

With this decision, we hope to maximize the success people have with Liferay in production.

Here’s an outline of a common situation that leads to a bad Liferay experience for companies:

  • A systems integrator (SI) hired by a company to build a solution makes a proposal that includes Liferay CE. The SI provides an all-inclusive service including new development, configuration and customization of Liferay, deployment, and support of the solution.

  • The solution proposed is built on Liferay CE, but the SI makes no mention of Liferay or our subscription offering. This prevents the company from knowing they can have a formal relationship with Liferay as the software vendor.

  • The SI sometimes does many things that lead to a poor experience, including:

    • re-implement features from scratch because they haven’t invested enough time into deeply understanding what’s available out of the box with Liferay. This makes their customers (who aren’t familiar with Liferay) pay the SI more than they need to for the solution. It also means those custom features may not work as well with the rest of the Liferay platform.

    • charge their customers for one-off support and maintenance of the project. SIs don’t have the same scale of customers that Liferay does, they don’t have as many fixes, and the support costs they charge their customer aren’t shared across multiple installations. So those companies pay more for less coverage of defects and improvements.

    • implement Liferay with non-standard practices or customize the code in non-standard ways, leading to unstable projects and a poor experience. This also makes it difficult or impossible to use standard apps from the Marketplace and to upgrade.

The net effect is that many companies have a bad experience with Liferay, and this hurts the Liferay eco-system: our community, partners, and our company. These companies usually don’t know that having a Liferay subscription is an option; they don’t know that the SIs aren’t following best practices; and they don’t know about all the standard features they’re missing out on. We think companies should have the chance to consider a relationship with the Liferay eco-system and make an informed decision whether they will use our community or commercial offerings. So by removing the compatibility and features that are essential for business-critical deployments, we are (in a brute force sort of way) making companies aware that a better option (for most) is available.

Now, when discussing this decision internally, some of us at Liferay rightly raised that this might be an annoyance to the community who now have to go build their own modules, and that SIs will just build their own connectors anyway to the goal wouldn’t be achieved. Meanwhile, we may lose potential community members, for example non-profit organizations that received Oracle licenses for free but want to use Liferay open source. Companies who would have tried Liferay Community on their proprietary infrastructure for a POC and then contacted sales later, now may never do so.

Those supporting the change said there isn’t enough incentive for these SIs to become contributing community members. Taking out commercial infrastructure and clustering support is one step in encouraging the SIs learn how to develop Liferay modules. They also feel that companies who can afford integrator services and proprietary infrastructure should pay for Liferay. Not doing more to monetize these companies is a disservice to the hard work of our community.

While we can’t know with certainty whether the net effect will be negative or positive, we’d like to go forward with the change and bring about a conversation. We want to understand who uses Liferay Portal Community on proprietary infrastructure without taking the Subscription. As they share their stories, we’ll better understand their needs and evolve our mix of free and commercial technologies and services to better meet the needs of all our users.

Of course we also want to see whether this decision does indeed help more companies to know our Enterprise subscription exists and to take an informed decision on engaging with Liferay.

I’m sure some of you will disagree with this change, whether for idealistic (FOSS) or pragmatic reasons (I can’t afford a Subscription). I know this isn’t the ideal solution for the problem. And you may feel that Liferay is unjustly burdening the community with our business issues.

So we want to do as much as we can to limit the effects of this change only to those who aren’t giving back. If you’ve been an active member of our community, or you really have a constrained budget but need to use Liferay with proprietary software, or you’re an existing customer putting together a POC for your upgrade, we can make exceptions and provide connectors privately.

One of my team members, who is very passionate about Liferay and about the community, voiced his disagreement, saying, “we (Liferay) are increasing our sales. I mean, I could understand these decisions if Liferay is going down.”

And it’s true that Liferay is profitable and increasing our sales, but to me it’s also a matter of principle. I want Liferay (the community and company) to decide how to distribute value from what we’ve built, not a random third party. Sure, it’s great that some companies are getting good open source software, and that SIs are getting a lot of value out of our software, but we should have some influence on the allocation of that value.

I also want to invest more back into Liferay. In 2010, we were very worried about how changing the license from MIT to LGPL would impact the community. That decision had its share of dissenters and supporters, both among our employees and in the community once it was announced. But what we heard more than anything else was that people wanted Liferay to invest more in our community. Pay attention to our contributions. Moderate our forums. Give us a way to vote on features.

We’ve responded to those requests, and there’s more we want to do. Our Community Manager Emeritus James Falkner launched programs like the BugSquad, Liferay Ideas, Community Expedition, Top Contributors, Community Pulse Awards, Official User Groups, and Community Verifiers.

We also launched our Marketplace, which now has over 512 Apps, 1,500 Registered Developers, 482,896 Downloads, and has allowed community members to sell their Apps and get recognition for their work.

From DevCon and Symposiums around the world, to our documentation team and dev.liferay.com, to more open source projects like AlloyEditor and Metal.js, we are taking seriously our commitment to invest our success back in our community, and excited to do much more. Unlike other open source companies, we have zero outside investors to answer to, so we can invest in our community on our own terms.

What’s next?

Like I said, we want this to be a conversation. So if you’ll trust us with this decision, we’ll continue to do our best to understand your needs, see how the market responds, and make adjustments as necessary.

Meanwhile, we have a lot of ideas in the works for the Liferay community. We are already looking for a new Community Manager to replace James Falkner (feel free to apply—job posting here), and we’re establishing a new Community Action Team to provide additional support to the Community Manager. We’d like to establish a formal onboarding process to help new community members get up to speed quickly. And we’ve been working with Bitergia to understand where our community needs more attention.

With Liferay Portal 7 Community now available, I hope you will see that your investment and dedication to Liferay is worthwhile. I look forward to hearing your thoughts.

 

Questions

If it's pluggable, can I plug in my own implementation in CE?

Yes! Indeed, it is possible to provide "DIY" support for clustering and your commercial infrastructure (or any other database/app server/clustering technology). People have been doing this for years for other systems (think Siebel, Salesforce.com, Endeca). With Liferay 7, it's even easier thanks to modularity and OSGi. For databases, check out https://issues.liferay.com/browse/LPS-61156 which extracts FOSS support into modules, and implement your own in this pattern. For app servers, check out the DeploymentExtension class, and implement your own subclass for your chosen app server.

 

Tell me more about clustering?

Although it is technically possible to cluster previous versions of Liferay CE (like 6.2), it has always suffered from scalability problems because its cache replication technique is not tuned at all, and it is up to you to tune it (and support it) for CE. So it wasn't that useful out of the box, and most people that used it were doing so through an enterprise subscription anyway (which included plugins to enhance clustering and support for configuration of a cluster). Clustering has been modularized and abstracted in 7, and now the "out of the box" distribution includes a boilerplate implementation module provided (via https://issues.liferay.com/browse/LPS-61123). If you need scalable, highly available Liferay because you are supporting thousands or hundreds of thousands of users, and your business or state depends on it, you will need to implement this (along with the other clustering configuration that you've always needed to do for your database, app server, load balancer, document store, etc).

Bryan Cheung 2016-04-07T18:55:13Z
Categories: CMS, ECM

Liferay Portal 7 CE - App Server, Database & Clustering Support

Liferay - Thu, 04/07/2016 - 13:55

Today I’d like to let you know that Liferay Portal 7 Community does not have "out of the box" support for clustering, non-open source app servers (Oracle WebLogic, IBM WebSphere), and non-open source databases (Oracle Database, Microsoft SQL Server, IBM DB2, Sybase DB). Support for these non-open source systems will be found in Liferay's current and future commercial releases, which are available by Subscription, or you can develop your own OSGi module independently to support these features.

It’s a huge decision and we think it may raise concerns from some community members, so we want to be upfront and explain our thinking. Why are we doing this?

With this decision, we hope to maximize the success people have with Liferay in production.

Here’s an outline of a common situation that leads to a bad Liferay experience for companies:

  • A systems integrator (SI) hired by a company to build a solution makes a proposal that includes Liferay CE. The SI provides an all-inclusive service including new development, configuration and customization of Liferay, deployment, and support of the solution.

  • The solution proposed is built on Liferay CE, but the SI makes no mention of Liferay or our subscription offering. This prevents the company from knowing they can have a formal relationship with Liferay as the software vendor.

  • The SI sometimes does many things that lead to a poor experience, including:

    • re-implement features from scratch because they haven’t invested enough time into deeply understanding what’s available out of the box with Liferay. This makes their customers (who aren’t familiar with Liferay) pay the SI more than they need to for the solution. It also means those custom features may not work as well with the rest of the Liferay platform.

    • charge their customers for one-off support and maintenance of the project. SIs don’t have the same scale of customers that Liferay does, they don’t have as many fixes, and the support costs they charge their customer aren’t shared across multiple installations. So those companies pay more for less coverage of defects and improvements.

    • implement Liferay with non-standard practices or customize the code in non-standard ways, leading to unstable projects and a poor experience. This also makes it difficult or impossible to use standard apps from the Marketplace and to upgrade.

The net effect is that many companies have a bad experience with Liferay, and this hurts the Liferay eco-system: our community, partners, and our company. These companies usually don’t know that having a Liferay subscription is an option; they don’t know that the SIs aren’t following best practices; and they don’t know about all the standard features they’re missing out on. We think companies should have the chance to consider a relationship with the Liferay eco-system and make an informed decision whether they will use our community or commercial offerings. So by removing the compatibility and features that are essential for business-critical deployments, we are (in a brute force sort of way) making companies aware that a better option (for most) is available.

Now, when discussing this decision internally, some of us at Liferay rightly raised that this might be an annoyance to the community who now have to go build their own modules, and that SIs will just build their own connectors anyway to the goal wouldn’t be achieved. Meanwhile, we may lose potential community members, for example non-profit organizations that received Oracle licenses for free but want to use Liferay open source. Companies who would have tried Liferay Community on their proprietary infrastructure for a POC and then contacted sales later, now may never do so.

Those supporting the change said there isn’t enough incentive for these SIs to become contributing community members. Taking out commercial infrastructure and clustering support is one step in encouraging the SIs learn how to develop Liferay modules. They also feel that companies who can afford integrator services and proprietary infrastructure should pay for Liferay. Not doing more to monetize these companies is a disservice to the hard work of our community.

While we can’t know with certainty whether the net effect will be negative or positive, we’d like to go forward with the change and bring about a conversation. We want to understand who uses Liferay Portal Community on proprietary infrastructure without taking the Subscription. As they share their stories, we’ll better understand their needs and evolve our mix of free and commercial technologies and services to better meet the needs of all our users.

Of course we also want to see whether this decision does indeed help more companies to know our Enterprise subscription exists and to take an informed decision on engaging with Liferay.

I’m sure some of you will disagree with this change, whether for idealistic (FOSS) or pragmatic reasons (I can’t afford a Subscription). I know this isn’t the ideal solution for the problem. And you may feel that Liferay is unjustly burdening the community with our business issues.

So we want to do as much as we can to limit the effects of this change only to those who aren’t giving back. If you’ve been an active member of our community, or you really have a constrained budget but need to use Liferay with proprietary software, or you’re an existing customer putting together a POC for your upgrade, we can make exceptions and provide connectors privately.

One of my team members, who is very passionate about Liferay and about the community, voiced his disagreement, saying, “we (Liferay) are increasing our sales. I mean, I could understand these decisions if Liferay is going down.”

And it’s true that Liferay is profitable and increasing our sales, but to me it’s also a matter of principle. I want Liferay (the community and company) to decide how to distribute value from what we’ve built, not a random third party. Sure, it’s great that some companies are getting good open source software, and that SIs are getting a lot of value out of our software, but we should have some influence on the allocation of that value.

I also want to invest more back into Liferay. In 2010, we were very worried about how changing the license from MIT to LGPL would impact the community. That decision had its share of dissenters and supporters, both among our employees and in the community once it was announced. But what we heard more than anything else was that people wanted Liferay to invest more in our community. Pay attention to our contributions. Moderate our forums. Give us a way to vote on features.

We’ve responded to those requests, and there’s more we want to do. Our Community Manager Emeritus James Falkner launched programs like the BugSquad, Liferay Ideas, Community Expedition, Top Contributors, Community Pulse Awards, Official User Groups, and Community Verifiers.

We also launched our Marketplace, which now has over 512 Apps, 1,500 Registered Developers, 482,896 Downloads, and has allowed community members to sell their Apps and get recognition for their work.

From DevCon and Symposiums around the world, to our documentation team and dev.liferay.com, to more open source projects like AlloyEditor and Metal.js, we are taking seriously our commitment to invest our success back in our community, and excited to do much more. Unlike other open source companies, we have zero outside investors to answer to, so we can invest in our community on our own terms.

What’s next?

Like I said, we want this to be a conversation. So if you’ll trust us with this decision, we’ll continue to do our best to understand your needs, see how the market responds, and make adjustments as necessary.

Meanwhile, we have a lot of ideas in the works for the Liferay community. We are already looking for a new Community Manager to replace James Falkner (feel free to apply—job posting here), and we’re establishing a new Community Action Team to provide additional support to the Community Manager. We’d like to establish a formal onboarding process to help new community members get up to speed quickly. And we’ve been working with Bitergia to understand where our community needs more attention.

With Liferay Portal 7 Community now available, I hope you will see that your investment and dedication to Liferay is worthwhile. I look forward to hearing your thoughts.

 

Questions

If it's pluggable, can I plug in my own implementation in CE?

Yes! Indeed, it is possible to provide "DIY" support for clustering and your commercial infrastructure (or any other database/app server/clustering technology). People have been doing this for years for other systems (think Siebel, Salesforce.com, Endeca). With Liferay 7, it's even easier thanks to modularity and OSGi. For databases, check out https://issues.liferay.com/browse/LPS-61156 which extracts FOSS support into modules, and implement your own in this pattern. For app servers, check out the DeploymentExtension class, and implement your own subclass for your chosen app server.

 

Tell me more about clustering?

Although it is technically possible to cluster previous versions of Liferay CE (like 6.2), it has always suffered from scalability problems because its cache replication technique is not tuned at all, and it is up to you to tune it (and support it) for CE. So it wasn't that useful out of the box, and most people that used it were doing so through an enterprise subscription anyway (which included plugins to enhance clustering and support for configuration of a cluster). Clustering has been modularized and abstracted in 7, and now the "out of the box" distribution includes a boilerplate implementation module provided (via https://issues.liferay.com/browse/LPS-61123). If you need scalable, highly available Liferay because you are supporting thousands or hundreds of thousands of users, and your business or state depends on it, you will need to implement this (along with the other clustering configuration that you've always needed to do for your database, app server, load balancer, document store, etc).

Bryan Cheung 2016-04-07T18:55:13Z
Categories: CMS, ECM

Content Delivery Network : Handshake with Liferay

Liferay - Thu, 04/07/2016 - 01:10

Content is at the heart of every system in this cutting-edge digital world and no doubt, every individual in this fraternity has to deal with it on a day-to-day basis. Classification of this content like static, dynamic, structured, unstructured- defines system boundaries many-a-times and plays a vital role in providing top-notch digital experience to the end user.  However, delivering this content with high performance and high availability is really crucial to maintain this experience and keep your end users happy.

Most of the time, this content includes JavaScript, CSS, Images and other resources which are static in nature and heavier in size. And if such heavy content is to be made accessible faster across the globe then one definitely needs to consider the distance for the data to travel between origin and destination. 

Having single server node sitting in one corner of the world delivering content to the user sitting in the opposite corner will definitely incur delays due to network latency. That is precisely where content delivery networks come into picture – by providing alternative server nodes which are geographically closer to the user enabling faster response and download time of the content.

The diagram below provides a quick view of Content Delivery Network (CDN) –

Origin Content Provider – origin server (for this blog – we can consider it as Liferay server)

CDN Provider – selects replica server to serve the requested objects/resources to the end user

Replicated server – serves the content to the end user based on the request. Content is pushed/pulled from origin server on/by replicated servers through CDN provider

Users – entities requesting contents.

 

CDN Request Routing

Every CDN contains a request routing system which is responsible for directing client requests to an appropriate replicated web server for the delivery of the content. Following diagram shows how this request routing happens within CDN –

The overall request routing flows like this – User requests content from the origin server by providing its URL in the browser. Upon receipt of the request, the origin server decides to send skeleton/basic index page back to user and propagate the request to the CDN provider to fetch requested embedded objects/resources. CDN provider based on the selection algorithm decides on the closest replica server, which serves the requested resource to the end user.

Liferay and CDN : Handshake

Though Liferay can be configured to work with CDN, Liferay does not have a provision out of the box to upload static resources (like CSS, JS, Images) on Content Delivery Networks. In order to upload static resources from portlets, themes and hooks on CDN, a custom component needs to be built. However, modern day CDNs (like AKAMAI) have capability to dynamically retrieve content from underlying origin servers and Liferay works with them seamlessly.

The diagram below shows how the handshake of Liferay and Content Delivery Network happens- 

Usually, Content Delivery Network is established as interceptor proxy within architecture. It sits between end user and Liferay portal server.  Every resource request being made by end user is intercepted by the CDN first, to deliver the resource. The overall request flows like following -

  • User sends a request through web client / web browser.
  • The request is received by Liferay Main Servlet which in turn triggers Liferay events (including ServicePreAction) upon reception of the request.
  • ServicePreAction Event checks if Liferay is configured to enable CDN to serve resources.

a.       Following properties need to be configured to enable CDN

  • CDN Host HTTP (retrieve content via CDN for requests made over HTTP protocol)
  • CDN Host HTTPS(retrieve content via CDN for requests made over HTTPS protocol)
  • CDN Dynamic Resources Enabled (to serve dynamically generated CSS, JS, images via CDN)
  • Once CDN is configured, ServicePreAction event checks every resource being delivered as a pat of the response and replaces the host name with specified CDN host.
  • Liferay Main servlet then sends this skeleton response back to the browser with newly generated URLs for resources
  • Upon reception of the skeleton response, browser requests resources from specified CDN.
  • If the resource does not exist on CDN, then CDN retrieves resources from underlying origin server
  • Once retrieved, CDN consequently serves the resource request.
  • The resource is then cached on replia servers for subsequent request serving

Most of CDNs and related Replica servers have a provision to configure dynamic retrieval of these resources (like CSS, JS, Images) from underlying origin server i.e. Liferay portal server. They also have a periodic provision to invalidate cached resources so that new content can be pushed to the client as an when it changes on the origin server.

Benefits of CDN –

  • Reduced Latency - Delivering content as quickly as possible ensuring shortest distance for data to travel. Serving content from servers which ae geographically closer to the end user.
  • More Parallel Downloads – Using multiple subdomains concept (domain sharding) of CDNs for handling resources enables faster and parallel downloads of resource resulting in faster performance.
  • Effective Browser Cache – Caching from the same CDN and using it for different sites. When browser picks up one coomon library like Jquery from commonly used CDN, it caches that file. If some other website requests same file from the same CDN, then this request is served with the same cached version of the file making it available faster.

Liferay with CDN: When to Use and Not to Use (Most Idle scenarios)

 

  • Building site for Geographically Distributed user base

  • Dynamic Data vs Static Data

  • Intranet/Intenal Application

  • Sites targetted at Mobile Devices (Depends on use case basis)

Choosing CDN for Sites targeted at mobile devices depends on use case basis, as content being delivered through mobile also have to consider other factors like provider network, network speed and latency introduced at data provider/receptor end.

 

Conclusion

CDN these days play a crucial part of the overall architecture in order to deliver the faster digital experience to end users. However, implementation of these CDN depends on websites goals, preferences, priorities and cost. The power of CDN can make and break your websites. So make your choice wisely while implementing one!!!

Rahul Mantri 2016-04-07T06:10:03Z
Categories: CMS, ECM

Content Delivery Network : Handshake with Liferay

Liferay - Thu, 04/07/2016 - 01:10

Content is at the heart of every system in this cutting-edge digital world and no doubt, every individual in this fraternity has to deal with it on a day-to-day basis. Classification of this content like static, dynamic, structured, unstructured- defines system boundaries many-a-times and plays a vital role in providing top-notch digital experience to the end user.  However, delivering this content with high performance and high availability is really crucial to maintain this experience and keep your end users happy.

Most of the time, this content includes JavaScript, CSS, Images and other resources which are static in nature and heavier in size. And if such heavy content is to be made accessible faster across the globe then one definitely needs to consider the distance for the data to travel between origin and destination. 

Having single server node sitting in one corner of the world delivering content to the user sitting in the opposite corner will definitely incur delays due to network latency. That is precisely where content delivery networks come into picture – by providing alternative server nodes which are geographically closer to the user enabling faster response and download time of the content.

The diagram below provides a quick view of Content Delivery Network (CDN) –

Origin Content Provider – origin server (for this blog – we can consider it as Liferay server)

CDN Provider – selects replica server to serve the requested objects/resources to the end user

Replicated server – serves the content to the end user based on the request. Content is pushed/pulled from origin server on/by replicated servers through CDN provider

Users – entities requesting contents.

 

CDN Request Routing

Every CDN contains a request routing system which is responsible for directing client requests to an appropriate replicated web server for the delivery of the content. Following diagram shows how this request routing happens within CDN –

The overall request routing flows like this – User requests content from the origin server by providing its URL in the browser. Upon receipt of the request, the origin server decides to send skeleton/basic index page back to user and propagate the request to the CDN provider to fetch requested embedded objects/resources. CDN provider based on the selection algorithm decides on the closest replica server, which serves the requested resource to the end user.

Liferay and CDN : Handshake

Though Liferay can be configured to work with CDN, Liferay does not have a provision out of the box to upload static resources (like CSS, JS, Images) on Content Delivery Networks. In order to upload static resources from portlets, themes and hooks on CDN, a custom component needs to be built. However, modern day CDNs (like AKAMAI) have capability to dynamically retrieve content from underlying origin servers and Liferay works with them seamlessly.

The diagram below shows how the handshake of Liferay and Content Delivery Network happens- 

Usually, Content Delivery Network is established as interceptor proxy within architecture. It sits between end user and Liferay portal server.  Every resource request being made by end user is intercepted by the CDN first, to deliver the resource. The overall request flows like following -

  • User sends a request through web client / web browser.
  • The request is received by Liferay Main Servlet which in turn triggers Liferay events (including ServicePreAction) upon reception of the request.
  • ServicePreAction Event checks if Liferay is configured to enable CDN to serve resources.

a.       Following properties need to be configured to enable CDN

  • CDN Host HTTP (retrieve content via CDN for requests made over HTTP protocol)
  • CDN Host HTTPS(retrieve content via CDN for requests made over HTTPS protocol)
  • CDN Dynamic Resources Enabled (to serve dynamically generated CSS, JS, images via CDN)
  • Once CDN is configured, ServicePreAction event checks every resource being delivered as a pat of the response and replaces the host name with specified CDN host.
  • Liferay Main servlet then sends this skeleton response back to the browser with newly generated URLs for resources
  • Upon reception of the skeleton response, browser requests resources from specified CDN.
  • If the resource does not exist on CDN, then CDN retrieves resources from underlying origin server
  • Once retrieved, CDN consequently serves the resource request.
  • The resource is then cached on replia servers for subsequent request serving

Most of CDNs and related Replica servers have a provision to configure dynamic retrieval of these resources (like CSS, JS, Images) from underlying origin server i.e. Liferay portal server. They also have a periodic provision to invalidate cached resources so that new content can be pushed to the client as an when it changes on the origin server.

Benefits of CDN –

  • Reduced Latency - Delivering content as quickly as possible ensuring shortest distance for data to travel. Serving content from servers which ae geographically closer to the end user.
  • More Parallel Downloads – Using multiple subdomains concept (domain sharding) of CDNs for handling resources enables faster and parallel downloads of resource resulting in faster performance.
  • Effective Browser Cache – Caching from the same CDN and using it for different sites. When browser picks up one coomon library like Jquery from commonly used CDN, it caches that file. If some other website requests same file from the same CDN, then this request is served with the same cached version of the file making it available faster.

Liferay with CDN: When to Use and Not to Use (Most Idle scenarios)

 

  • Building site for Geographically Distributed user base

  • Dynamic Data vs Static Data

  • Intranet/Intenal Application

  • Sites targetted at Mobile Devices (Depends on use case basis)

Choosing CDN for Sites targeted at mobile devices depends on use case basis, as content being delivered through mobile also have to consider other factors like provider network, network speed and latency introduced at data provider/receptor end.

 

Conclusion

CDN these days play a crucial part of the overall architecture in order to deliver the faster digital experience to end users. However, implementation of these CDN depends on websites goals, preferences, priorities and cost. The power of CDN can make and break your websites. So make your choice wisely while implementing one!!!

Rahul Mantri 2016-04-07T06:10:03Z
Categories: CMS, ECM

Exploring Liferay 7: Dragging and dropping portlets

Liferay - Tue, 04/05/2016 - 03:18

Yay - Liferay 7 CE is out.

As the exploration begins, I'm sure everybody first looks for their pet peeves. There's something that's been nagging me in 6.1 and 6.2 - and unfortunately I couldn't get my fixed theme regression merged into master - partly because of my missing CSS design skills, partly because I started lobbying too late, when only critical fixes were accepted. And partly because there was an impending update to the DOM which would have rendered the fix invalid almost immediately after committing it.

Turns out that my 6.2 patch is not invalidated by whatever has been introduced in Liferay 7, and it's trivial for you to fix the issue - and easy to bring into your own themes (everybody has their own theme anyways - right?). Here's the problem again:

When you drag and drop portlets on the page, Liferay does not provide an indicator, where you can drop it. While that's easy and intuitive for your stereotype 2-columns layout, it gets more tricky with the more complex layouts that provide multiple rows. Like in this example (showing the fixed version where you can see the dropzones once you start dragging):

As you can see, the visual appearance could use some improvement, but the technical requirement has been met. That's the caveat of having me work on theme issues: I'm able to make things look different - if you want them to look nice, you better ask someone else ;). Well, the arena is open and your suggestions for improvement are accepted and welcome.

The good news: The CSS that worked for 6.2 still works for 7.0 - no need to re-learn anything about the DOM for Liferay 7 - just add this CSS to the page (e.g. through the "Public Pages / Configuration / Look and Feel / CSS", alternatively private or individual pages) or to your own theme, and you're set:

You might also want to vote for LPS-40571 and LPS-53664 to get this feature out-of-the-box again.

Olaf Kock 2016-04-05T08:18:09Z
Categories: CMS, ECM

Liferay Portal 7.0 CE Release

Liferay - Mon, 04/04/2016 - 12:04

Today Liferay released the next version of its flagship software: Liferay Portal 7.0 CE! 
[Download] [Quick Start]

After many months of hard work from the Liferay product and engineering teams along with the aid of the awesome Liferay community, it is my pleasure to announce the immediate availability of Liferay Portal 7.0 CE.  Liferay Portal 7.0 CE is an amazing release packed with many new features and enhancements.  Read on for more!

Release Nomenclature

Following Liferay's versioning scheme established in 2010, this release is Liferay 7.0 CE GA1.  The internal version number is 7.0.0 (i.e. the first release of 7.0).  Future CE releases of 7.0 will be designated GA2, GA3, .. and so on.  See below for upgrade instructions from 6.1, 6.0, and 5.x.

Downloads

You can find the 7.0 release on the usual downloads page.  If you need additional files (for example, the source code, or dependency libraries), visit the additional files page.

Source Code

As Liferay is an open source project, many of you will want to get at its guts. The source is available as a zip archive on the downloads page, or on its home on GitHub. Many community contributions went into this release, and hopefully many more in future releases! If you're interested in contributing, take a look at our contribution page.

Support Matrix

Liferay's general policy is to update our support matrix for each release, testing Liferay against newer major releases of supporting operating systems, app servers, browsers, and databases (we regularly update the bundled upstream open source libraries to fix bugs or take advantage of new features in the open source we depend on). 

Liferay 7.0 CE was tested extensively for use with the following Application/Database Servers: 

Liferay CE Application Servers:

  • Apache Tomcat 8.0 with Java 8
  • Wildfly 10.0 with Java 8

Liferay CE Databases:

  • HSQLDB 2 (only for demonstration, development, and testing)
  • MySQL 5.6
  • MariaDB 10
  • PostgreSQL 9.3
New Features Summary
  • Modularity inside: The #1 feature of Liferay 7 is not a feature, but a way to empower you to build more powerful, adaptable, lightweight and innovative systems for the digital world that is coming. Liferay 7's functionality has been modularized into hundreds of modules, allowing you to use what you need for each project and take away the rest, giving you an extensibility unthinkable until now, and a much more elegant development model. And all of this based on rock solid standards of the OSGi family. 
     
  • New Forms Experience: Liferay 7 includes a brand new application that allows defining and publishing advanced dynamic forms. The forms can have complex multi-column layouts and span several pages. They can be published in any Liferay site just by dropping the form into a page or also Google Forms style, by providing a URL that links directly to a full page form. Many field types are included out of the box and custom types can be added by deploying custom modules. Forms can also be integrated with Liferay's workflow system to submit forms through a predefined process. 
     
  • Optimized Content Authoring: As content management systems get more complicated and get more options, the more complex writing content might get. But it doesn't have to. We have rethought the authoring experience to let the authors, from web content to blogs, focus on writing great content, while still having available the full power that Liferay's applications provide when they are really necessary. All this thanks to our brand new WYSIWYG editor: Alloy Editor. In addition to this, many small improvements have been added such as the ability to organize web content in folders, visual content diffs, reuse of content structures and templates across sites, and more.
     
  • Geolocate any content: Liferay 7 provides out of the box the ability to geolocate all web content, data lists, documents & media. It also provides the ability to leverage the power of Liferay's Asset Publisher to create lists of geolocalized content and publish them in a Map.
     
  • Advanced modern sites easier than ever: Nowadays sites are more complex, dynamic and visually stunning than ever before. Liferay 7 contains a series of improvements  to provide more power to site administrators to create modern sites faster. As a proof of what is now possible Liferay now includes out of the box a new site template showcasing a modern product site, leveraging Liferay 7's new features such as application decorators, new application display templates, sets of pages and more. Additional site templates & themes will be delivered in the next few months in the marketplace.
     
  • Improved blogs, forum and wiki: When you need to host your own blog it's hard to compete with the simplicity of the online platforms like wordpress.com or Medium, but Liferay 7 makes it much easier. Beautiful and streamlined by default but with all of Liferay's power underneath. Our beloved Forum and Wiki applications have also seen incremental improvements targeted towards encouraging usage and engagement.
     
  • Easier to use staging, even for the most advanced scenarios: Publishing from staging to live is now as easy as clicking one button. And for more advanced publishing scenarios, it's now possible to save advanced configurations and reuse them to ensure successful publications every time.

     
  • New image, file and media selector: Whether you are writing a web content, a blog entry, a wiki page, … being able to select an already uploaded picture, upload one now, or even take a picture or video right now to be added to your content is becoming more common than ever before. Liferay's new media selector has been designed to make these common operations easy. Not only that, it's highly extensible so that new sources of media such as google, flickr, youtube, ... can be added to any application using the selector.
     
  • Faster loading and reduced bandwidth usage: Liferay 7 provides a much faster perceived performance for its users thanks to a new technology that automatically converts all applications (even custom ones) as well as the navigation across pages of a site into Single Page Applications. This means that only the pieces of a page that are necessary are loaded avoiding full page refreshes, reducing bandwidth usage, load times and rendering time in the browser. 
     
  • Stunning visual and usability improvements in all of the out of the box applications: The User Experience in Liferay 7 has improved so much that we have even created a new design language along the way, Lexicon. You will notice its presence in the stunning new look of all of Liferay's applications which have redesigned to make the best use of the screen real estate for screens of all sizes, make its features easier to find and learn and perform tasks faster than ever before. Liferay 7 provides an implementation of Lexicon as a CSS framework based on Bootstrap that can be used as well for third party applications to achieve the same effect with much less effort than ever before.
     
  • Optimized product navigation: A new menu provides a unified way for administrators and registered users to access all administrative and personal applications from a single place, leaving all the screen real estate available for the site navigation and decorations. The product navigation is fully extensible to allow customizing it for any need.
     
  • Better developer experience: By leveraging modularity and state of the art tooling, developing for Liferay 7 is going to be easier and more powerful than ever before. We are embracing Gradle and Maven and creating plugins and some additional command line and Eclipse tools on top. 
     
  • Infrastructure improvements: Many improvements have been incorporated at the core platform level, including replacing Lucene with ElasticSearch as the default search engine (providing better monitoring, tuning and clustering), JAX-RS infrastructure to build custom and secured RESTful Web Services, a device manager, a new Configuration API to make any application configurable with less effort, a brand new data upgrade framework, etc.

And more: there is much more than we can list here since this release has over 1750 new features and improvements. Not only that, in the next months we plan to leverage modularity to keep delivering features on top of the base Liferay 7 platform, such as a new image editor that will be integrated into Liferay's Documents and Media and the Image Selector.

Documentation

The Liferay Documentation Team has been hard at work updating all of the documentation for the new release.  This includes updated (and vastly improved/enlarged) javadoc and related reference documentation, and and updated installation and development documentation can be found on the Liferay Developer Network. Our community has been instrumental in identifying the areas of improvement, and we are constantly updating the documentation to fill in any gaps.

Deprecated Plugins

Several plugins have been deprecated in Liferay 7 and will be available in the Marketplace as a labs application after the Liferay 7 Release.  The list of deprecated plugins are:

  • Shopping Portlet
  • Mail Portlet
  • Invitation Portlet
  • Software Catalog

Bug Reporting

As always, the project continues to use issues.liferay.com to report and manage bug and feature requests.  If you believe you have encountered a bug in the new release (shocking, I know), please be cognizant of the bug reporting standards and report your issue on issues.liferay.com, selecting the "7.0.0 CE GA1" release as the value for the "Affects Version/s" field.

Upgrading

Good news for those of you on 6.0 or prior! Liferay introduced the seamless upgrade feature with Liferay 6.1. Seamless upgrades allow Liferay to be upgraded more easily. In most cases, pointing the latest version of Liferay to the database of the older version is enough. There are some caveats though, so be sure to check out the Upgrading section on the Liferay Developer Network for more detail on upgrading to 7.0.

Getting Support

Support for Liferay 7.0 CE comes from the wonderful and active community, from which Liferay itself was nurtured into the enterprise offering it is today.  Please visit the community pages to find out more about the myriad avenues through which you can get your questions answered.

Liferay and its worldwide partner network also provides services, support, training, and consulting around its flagship enterprise offering, which is due to be released shortly after this CE release.

Also note that customers on existing releases such as 6.1 and 6.2 continue to be professionally supported, and the documentation, source, and other ancillary data about these releases will remain in place.

What's Next?

Of course we in the Liferay Community are interested in your take on the new features in Liferay 7.0.  Work has already begun on the next evolution of Liferay, based on user feedback and community ideas.  If you are interested in learning more about how you can get involved, visit the Liferay Community pages and dig in.

Kudos!

This release was produced by Liferay's worldwide portal engineering team, and involved many hours of development, testing, writing documentation, translating, testing some more, and working with the wider Liferay community of customers, partners, and open source developers to incorporate all sorts of contributions, both big and small. We are glad you have chosen to use Liferay, and hope that it meets or exceeds your expectations!

In addition to Liferay's engineering staff, a special thanks goes to the many open source developers who participated in the Community Expedition who volunteered their time and energy to help with the release, whether it was bugfixing, idea generation, documentation, translations, or other contribution that helped to improve this release. 

Jamie Sammons 2016-04-04T17:04:05Z
Categories: CMS, ECM

Liferay Portal 7.0 CE Release

Liferay - Mon, 04/04/2016 - 12:04

Today Liferay released the next version of its flagship software: Liferay Portal 7.0 CE! 
[Download] [Quick Start]

After many months of hard work from the Liferay product and engineering teams along with the aid of the awesome Liferay community, it is my pleasure to announce the immediate availability of Liferay Portal 7.0 CE.  Liferay Portal 7.0 CE is an amazing release packed with many new features and enhancements.  Read on for more!

Release Nomenclature

Following Liferay's versioning scheme established in 2010, this release is Liferay 7.0 CE GA1.  The internal version number is 7.0.0 (i.e. the first release of 7.0).  Future CE releases of 7.0 will be designated GA2, GA3, .. and so on.  See below for upgrade instructions from 6.1, 6.0, and 5.x.

Downloads

You can find the 7.0 release on the usual downloads page.  If you need additional files (for example, the source code, or dependency libraries), visit the additional files page.

Source Code

As Liferay is an open source project, many of you will want to get at its guts. The source is available as a zip archive on the downloads page, or on its home on GitHub. Many community contributions went into this release, and hopefully many more in future releases! If you're interested in contributing, take a look at our contribution page.

Support Matrix

Liferay's general policy is to update our support matrix for each release, testing Liferay against newer major releases of supporting operating systems, app servers, browsers, and databases (we regularly update the bundled upstream open source libraries to fix bugs or take advantage of new features in the open source we depend on). 

Liferay 7.0 CE was tested extensively for use with the following Application/Database Servers: 

Liferay CE Application Servers:

  • Apache Tomcat 8.0 with Java 8
  • Wildfly 10.0 with Java 8

Liferay CE Databases:

  • HSQLDB 2 (only for demonstration, development, and testing)
  • MySQL 5.6
  • MariaDB 10
  • PostgreSQL 9.3
New Features Summary
  • Modularity inside: The #1 feature of Liferay 7 is not a feature, but a way to empower you to build more powerful, adaptable, lightweight and innovative systems for the digital world that is coming. Liferay 7's functionality has been modularized into hundreds of modules, allowing you to use what you need for each project and take away the rest, giving you an extensibility unthinkable until now, and a much more elegant development model. And all of this based on rock solid standards of the OSGi family. 
     
  • New Forms Experience: Liferay 7 includes a brand new application that allows defining and publishing advanced dynamic forms. The forms can have complex multi-column layouts and span several pages. They can be published in any Liferay site just by dropping the form into a page or also Google Forms style, by providing a URL that links directly to a full page form. Many field types are included out of the box and custom types can be added by deploying custom modules. Forms can also be integrated with Liferay's workflow system to submit forms through a predefined process. 
     
  • Optimized Content Authoring: As content management systems get more complicated and get more options, the more complex writing content might get. But it doesn't have to. We have rethought the authoring experience to let the authors, from web content to blogs, focus on writing great content, while still having available the full power that Liferay's applications provide when they are really necessary. All this thanks to our brand new WYSIWYG editor: Alloy Editor. In addition to this, many small improvements have been added such as the ability to organize web content in folders, visual content diffs, reuse of content structures and templates across sites, and more.
     
  • Geolocate any content: Liferay 7 provides out of the box the ability to geolocate all web content, data lists, documents & media. It also provides the ability to leverage the power of Liferay's Asset Publisher to create lists of geolocalized content and publish them in a Map.
     
  • Advanced modern sites easier than ever: Nowadays sites are more complex, dynamic and visually stunning than ever before. Liferay 7 contains a series of improvements  to provide more power to site administrators to create modern sites faster. As a proof of what is now possible Liferay now includes out of the box a new site template showcasing a modern product site, leveraging Liferay 7's new features such as application decorators, new application display templates, sets of pages and more. Additional site templates & themes will be delivered in the next few months in the marketplace.
     
  • Improved blogs, forum and wiki: When you need to host your own blog it's hard to compete with the simplicity of the online platforms like wordpress.com or Medium, but Liferay 7 makes it much easier. Beautiful and streamlined by default but with all of Liferay's power underneath. Our beloved Forum and Wiki applications have also seen incremental improvements targeted towards encouraging usage and engagement.
     
  • Easier to use staging, even for the most advanced scenarios: Publishing from staging to live is now as easy as clicking one button. And for more advanced publishing scenarios, it's now possible to save advanced configurations and reuse them to ensure successful publications every time.

     
  • New image, file and media selector: Whether you are writing a web content, a blog entry, a wiki page, … being able to select an already uploaded picture, upload one now, or even take a picture or video right now to be added to your content is becoming more common than ever before. Liferay's new media selector has been designed to make these common operations easy. Not only that, it's highly extensible so that new sources of media such as google, flickr, youtube, ... can be added to any application using the selector.
     
  • Faster loading and reduced bandwidth usage: Liferay 7 provides a much faster perceived performance for its users thanks to a new technology that automatically converts all applications (even custom ones) as well as the navigation across pages of a site into Single Page Applications. This means that only the pieces of a page that are necessary are loaded avoiding full page refreshes, reducing bandwidth usage, load times and rendering time in the browser. 
     
  • Stunning visual and usability improvements in all of the out of the box applications: The User Experience in Liferay 7 has improved so much that we have even created a new design language along the way, Lexicon. You will notice its presence in the stunning new look of all of Liferay's applications which have redesigned to make the best use of the screen real estate for screens of all sizes, make its features easier to find and learn and perform tasks faster than ever before. Liferay 7 provides an implementation of Lexicon as a CSS framework based on Bootstrap that can be used as well for third party applications to achieve the same effect with much less effort than ever before.
     
  • Optimized product navigation: A new menu provides a unified way for administrators and registered users to access all administrative and personal applications from a single place, leaving all the screen real estate available for the site navigation and decorations. The product navigation is fully extensible to allow customizing it for any need.
     
  • Better developer experience: By leveraging modularity and state of the art tooling, developing for Liferay 7 is going to be easier and more powerful than ever before. We are embracing Gradle and Maven and creating plugins and some additional command line and Eclipse tools on top. 
     
  • Infrastructure improvements: Many improvements have been incorporated at the core platform level, including replacing Lucene with ElasticSearch as the default search engine (providing better monitoring, tuning and clustering), JAX-RS infrastructure to build custom and secured RESTful Web Services, a device manager, a new Configuration API to make any application configurable with less effort, a brand new data upgrade framework, etc.

And more: there is much more than we can list here since this release has over 1750 new features and improvements. Not only that, in the next months we plan to leverage modularity to keep delivering features on top of the base Liferay 7 platform, such as a new image editor that will be integrated into Liferay's Documents and Media and the Image Selector.

Documentation

The Liferay Documentation Team has been hard at work updating all of the documentation for the new release.  This includes updated (and vastly improved/enlarged) javadoc and related reference documentation, and and updated installation and development documentation can be found on the Liferay Developer Network. Our community has been instrumental in identifying the areas of improvement, and we are constantly updating the documentation to fill in any gaps.

Deprecated Plugins

Several plugins have been deprecated in Liferay 7 and will be available in the Marketplace as a labs application after the Liferay 7 Release.  The list of deprecated plugins are:

  • Shopping Portlet
  • Mail Portlet
  • Invitation Portlet
  • Software Catalog

Bug Reporting

As always, the project continues to use issues.liferay.com to report and manage bug and feature requests.  If you believe you have encountered a bug in the new release (shocking, I know), please be cognizant of the bug reporting standards and report your issue on issues.liferay.com, selecting the "7.0.0 CE GA1" release as the value for the "Affects Version/s" field.

Upgrading

Good news for those of you on 6.0 or prior! Liferay introduced the seamless upgrade feature with Liferay 6.1. Seamless upgrades allow Liferay to be upgraded more easily. In most cases, pointing the latest version of Liferay to the database of the older version is enough. There are some caveats though, so be sure to check out the Upgrading section on the Liferay Developer Network for more detail on upgrading to 7.0.

Getting Support

Support for Liferay 7.0 CE comes from the wonderful and active community, from which Liferay itself was nurtured into the enterprise offering it is today.  Please visit the community pages to find out more about the myriad avenues through which you can get your questions answered.

Liferay and its worldwide partner network also provides services, support, training, and consulting around its flagship enterprise offering, which is due to be released shortly after this CE release.

Also note that customers on existing releases such as 6.1 and 6.2 continue to be professionally supported, and the documentation, source, and other ancillary data about these releases will remain in place.

What's Next?

Of course we in the Liferay Community are interested in your take on the new features in Liferay 7.0.  Work has already begun on the next evolution of Liferay, based on user feedback and community ideas.  If you are interested in learning more about how you can get involved, visit the Liferay Community pages and dig in.

Kudos!

This release was produced by Liferay's worldwide portal engineering team, and involved many hours of development, testing, writing documentation, translating, testing some more, and working with the wider Liferay community of customers, partners, and open source developers to incorporate all sorts of contributions, both big and small. We are glad you have chosen to use Liferay, and hope that it meets or exceeds your expectations!

In addition to Liferay's engineering staff, a special thanks goes to the many open source developers who participated in the Community Expedition who volunteered their time and energy to help with the release, whether it was bugfixing, idea generation, documentation, translations, or other contribution that helped to improve this release. 

Jamie Sammons 2016-04-04T17:04:05Z
Categories: CMS, ECM
Syndicate content