Liferay Experience Cloud, una piattaforma all-in-one per la creazione di esperienza digitali

Basta polpettoni... basta vi prego...
Ragazzi evolviamoci, oggetti come Liferay non sono diversi dagli altri accrocchi tipo WebSphere Portal e simili, sono sarchiaponi nati vent'anni fa per fare (male) ogni cosa, dal rendering dei contenuti al cms, dalla directory degli utenti alla gestione degli utenti stessi, dal repository dei binari/allegati alla autenticazione/autorizzazione alle applicazioni custom (vero nodo cruciale e fulcro di gran parte dei problemi)

Nei primi anni 2000 la cosa aveva senso perchè non c'erano strumenti per scorporare tutte queste funzionalità e gestirle con strumenti migliori, dedicati e specializzati, ma ora sono almeno 10, per non dire 15 anni che c'è modo di fare tutto questo in modo più efficiente senza che un problema su uno di questi vada a inficiare tutti gli altri.
Far girare tutto su una singola jvm è un crimine e vuol dire andarsi a cercare le rogne, non ha più alcun senso, ora abbiamo eccellenti IAM, directory LDAP di ogni forma e tecnologia diversa, eccellenti CMS, staticizzatori che possono distribuire i contenuti su batterie di webserver, svariati meccanismi di federazione e possibilità di far girare applicazioni custom in modi che allora non ci si sognava nemmeno.

E' ora che questo genere di prodotti sparisca, santa pazienza evolviamoci...

I miei colleghi che hanno avuto a fare con Liferay nei loro progetti ne parlano malissimo...

Vedi, gli aspetti che ho citato prima sono oggettivamente anacronistici e comportano tutta una serie di problemi, ma fanno parte del prodotto e "teoricamente" dovrebbero funzionare.

Il problema è che a tutto questo si sommano sempre le portlet custom (alcune magari nate per sanare mancanze o problemi delle componenti native di Liferay) che sono l'origine di tutti i mali.

Perchè si usano? Semplicemente perchè nessun utente si accontenta delle funzionalità base del prodotto, nessuno vuole solo un "sito vetrina" ("altrimenti avremmo usato Wordpress" è la risposta più frequente che ho sentito, al che di solito rispondo "avreste dovuto farlo", tutti vogliono offrire qualche genere di servizio agli utenti, e la cosa è buona e giusta, l'assurdità è farla girare come portlet, ovvero farla girare sullo stesso processo della stessa jvm su cui gira tutto il polpettone di Liferay con le sue mille funzionalità.

Già ci sono le portlet custom che tocca deployare su Liferay per raddrizzare le mancanze o i problemi delle sue funzionalità native (es banale, attacco il portale a un LDAP, alla prima login Liferay crea l'utente nel suo repository sul db, ma poi se cambia qualche attributo dell'utente non c'è nessun meccanismo di sincronizzazione tra LDAP e il repository locale di Liferay), se poi a queste aggiungo mille portlet che fanno le cose più disparate, magari gestendo "a membro di segugio" le risorse di terze parti (database, repository vari, web services).
In uno scenario del genere è perfettamente normale ritrovarsi il log della jvm pieno zeppo di eccezioni, eccezioni di OutOfMemory o thread starvation o altro sempre dietro l'angolo.

Chiaramente che nel migliore dei mondi possibili le eccezioni dovrebbero essere risolte, ma sappiamo tutti che 9 volte su 10 la gente si limita a killare il processo e dare una riavviata.
Al di la di questo poi il problema è alla base, se quella applicazione custom stesse girando sulla propria jvm, separata da quella di Liferay, magari con una architettura semplice, pulita (chessò Spring boot o un semplice Tomcat):
1) sarebbe più facile fare problem solving
2) se si manifestasse un problema, questo non impatterebbe sul portale Liferay ma solo su quel processo di jvm su cui gira l'applicazione

Ma se proponi una soluzione del genere la gente ti risponde "ma a questo punto tanto vale usare Wordpress per il sito informativo", ecco appunto!