Entrades amb etiqueta liferay 6.2 .

Minimizando conflictos de aui en nuestros Themes de Liferay

Data de publicació 28/09/16 18:03

Cuando queremos crear un Theme en Liferay en muchas ocasiones nos podemos encontrar con que los estilos aui entran en conflicto con los estilos que nosotros queremos aplicar. Un caso típico es el choque producido entre el bootstrap que utiliza aui y bootstrap 3.

¿Cómo podemos mantener los estilos Liferay para el propio Liferay sin que afecte a los estilos de nuestra web?

Pues no existe una fórmula mágica, pero podemos mitigar el impacto y que al menos desde fuera no se aprecien los conflictos.

Para ello haremos que los estilos aui no se apliquen a partir de la class "aui" (que se encuentra al inicio, en el <html>) sino a un nivel más bajo.

Esto lo podemos lograr mediante el Theme, modificando el fichero "aui.css" y añadiéndolo a "_diffs/css/":

 

_diffs\css\aui.css:

.aui .lfr-styles {
    ...
}

 

Cambiando .aui {…} por .aui .lfr-styles {…} provocamos que los estilos aui no se apliquen hasta que se encuentre algún elemento con la class lfr-styles, de este modo podemos controlar qué bloques queremos que usen estos estilos.

Como he dicho anteriormente esto sirve para mitigar los conflictos, pero no es perfecto y en el proceso podemos perder estilos genéricos (aui). Por ejemplo, si tenemos un “font-family” que antes aplicaba a “.aui body”, ahora aplicaría a “.aui .lfr-styles body”, si donde colocamos ese “.lfr-styles” está por debajo del body (que como veremos más adelante será lo más normal) ese estilo no se aplicaría.

Con este sistema algún estilo aui propio de Liferay podría verse afectado pero nuestra web y nuestros estilos custom estarían libres de conflictos.

Ahora, para poder seguir utilizando aui en lo que a Liferay se refiere (los portlets propios) podemos usar el mismo Theme y el Hook.

Desde el Theme, si queremos ahorrarnos trabajo del Hook, podemos hacer que aplique también los estilos directamente a los popup generados por Liferay donde se incluiría: el menú de configuración de los portlet, el seleccionar web contents, exportar/importar un portlet, seleccionar estructura o plantilla, etc.

Esto se puede conseguir añadiendo a la línea anterior otra class que está presente en este tipo de contenidos:

 

_diffs\css\aui.css:

.aui .lfr-styles, .aui .portal-popup{
    ...
}

 

Por otro lado, desde el Hook podemos incluir la class antes mencionada a los portlets propios de Liferay que queremos que continúen usando la clase aui. A continuación listamos los más típicos, y que archivo necesitaríamos modificar:

  • Menu Liferay (Dockbar):  \html\portlet\dockbar\view.jsp
  • Menu Liferay: add, edit, preview (Dockbar): \html\js\liferay\dockbar.js
  • Add WebContent, Edit WebContent (Journal): \html\portlet\journal\edit_article.jsp
  • Look and Feel (Portlet CSS): \html\portlet\portlet_css\view.jsp

El proceso para los jsp suele ser el mismo, usaremos uno de ejemplo:

 

\html\portlet\dockbar\view.jsp:

<%@ taglib uri="http://liferay.com/tld/util" prefix="liferay-util" %>
<%@ taglib uri="http://liferay.com/tld/theme" prefix="liferay-theme" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

<liferay-theme:defineObjects />

<liferay-util:buffer var="html">
       <liferay-util:include page="/html/portlet/dockbar/view.portal.jsp" useCustomPage="false"  />
</liferay-util:buffer>

<div class="lfr-styles">
       <%= html %>
</div>

 

De esta forma incluimos un div por encima del contenido que queremos que use aui con nuestra nueva class.

En el caso del dockbar.js lo usamos por simplificar, ya que añadiendo nuestra class a tres líneas de código nos ahorramos hookear tres jsp.

 

\html\js\liferay\dockbar.js:

var TPL_ADD_CONTENT = '<div class="lfr-add-panel lfr-admin-panel lfr-styles" id="{0}" />';
var TPL_EDIT_LAYOUT_PANEL = '<div class="lfr-admin-panel lfr-edit-layout-panel lfr-styles" id="{0}" />';
var TPL_PREVIEW_PANEL = '<div class="lfr-admin-panel lfr-device-preview-panel lfr-styles" id="{0}" />';

 

Se pueden buscar atajos o simplificaciones, pero la cuestión es lograr incluir nuestra clase para que aui afecte sólo al contenido que nosotros queremos que afecte y no provoque conflictos en lo que ve el usuario, que al fin y al cabo, es para el que está pensado nuestro diseño.

Espero que os sirva de ayuda. Como he comentado al principio no es la solución perfecta, pero cuando tienes que forzar 25 estilos para que un simple botón se vea como tú quieres (estilos por defecto, estilos hover, active , focus, responsive, shadows, …) el reducir estos conflictos te pueden ahorrar mucho tiempo y dolores de cabeza.

Saludos.

A fondo: liferay-portlet.xml

Data de publicació 02/12/15 12:57

¡Hola!

 

En esta entrada voy a explorar un poco lo que podemos llegar a hacer con el archivo 'liferay-portal.xml'. Este archivo describe mejoras del portlet JSR-286 en nuestro portal de Liferay.

La información mostrada va referida a la versión 6.2 por lo que no puedo asegurar que todo lo que especifique funcione para otras versiones de Liferay Portal.

 

Cuando generamos un nuevo portlet podemos autogenerar este archivo y ésta es su estructura base:

 

<liferay-portlet-app>

       <portlet>

              <portlet-name>my-greeting</portlet-name>

              <icon>/icon.png</icon>

              <instanciable>false</instanciable>

              <header-portlet-css>/css/main.css</header-portlet-css>

              <footer-portlet-javascript>/js/main.js</footer-portlet-javascript>

              <css-class-wrapper>my-greeting-portlet</css-class-wrapper>

       </portlet>

       <role-mapper>

              <role-name>administrator</role-name>

              <role-link>Administrator</role-link>

       </role-mapper>

       <role-mapper>

              <role-name>guest</role-name>

  <role-link>Guest</role-link>

       </role-mapper>

       <role-mapper>

              <role-name>power-user</role-name>

  <role-link>Power User</role-link>

       </role-mapper>

       <role-mapper>

              <role-name>user</role-name>

              <role-link>User</role-link>

       </role-mapper>

</liferay-portlet-app>

 

 

Para cada portlet tenemos las siguientes etiquetas base:

  • portlet-name: Tiene el nombre especificado para el portlet. Es necesario que tenga el mismo que el especificado en el archivo portlet.xml.
  • icon: Ruta hasta la imagen icono del portlet.
  • instanciable: Indica si un portlet se puede instanciar más de una vez en una misma página.
  • header-portlet-css: Ruta hasta un archivo css. Se añadirá dentro de la etiqueta <head> de la página (debido a la parte del nombre header).*
  • footer-portlet-javascript: Ruta hasta un archivo js. Se añadirá al final de la página, justo antes de la etiqueta </body> (debido a la parte del nombre footer).*
  • css-class-wrapper: Clase que se añade en el html al renderizar el portlet, se suele usar para aplicar estilos propios al portlet.

*Pueden existir varias etiquetas de este tipo en un mismo portlet.

 

Ahora que ya tenemos lo básico, voy a especificar unas cuantas cosas que podemos realizar:

 

Añadir el portlet en el Panel de Control

 

Para conseguir esto deberemos añadir dos etiquetas más: '<control-panel-entry-category>' y '<control-panel-entry-weight>'.

 

La primera etiqueta especifica en que sección de nuestro panel de control se colocará nuestro portlet, tenemos las siguientes:

 
  • Panel de control: ‘users’, ‘sites’, ‘apps’ y ‘configuration’.
  • Administración del sitio web: ‘site_administration.pages’, ‘site_administration.content’, ‘site_administration.users’ y ‘site_administration.configuration’.
  • Mi cuenta: ‘my’.
 

La segunda etiqueta determina el peso que tendra tu portlet dentro de cada sección. A más peso más abajo estará tu portlet en la lista.

 

Hacer un cron

 

Este apartado ya lo especificamos en otra entrada de blog hecha por Sergi.

 

Además

 

A parte de lo mencionado anteriormente, este archivo también sirve para enlazar a clases que hagan una funcionalidad especifica. Por ejemplo, implementar búqueda e indexación, crear notificaciones para los usuarios y especificar friendly url del portlet entre otras cosas.

 

Para finalizar os dejo el listado con todas las etiquetas que pueden ir dentro del archivo 'liferay-portal.xml'.

 

Espero que os haya ayudado, ¡un saludo!


 

Cómo gestionar permisos en nuestros portlets

Data de publicació 03/02/16 14:58

Algo realmente importante a tener en cuenta cuando creamos nuestros portlets con Liferay es cómo gestionar el acceso a los diferentes recursos. La gestión de permisos es algo básico si queremos que algunos roles puedan realizar ciertas acciones pero no otras. En este post vamos a hablar de como integrar los permisos y recursos de nuestros portlets con el sistema de permisos de Liferay.

Primero de todo tenemos crear el archivo default.xml en la carpeta docroot/WEB-INF/src/resource-actions. En este archivo definiremos, para nuestro modelo de datos, que permisos aplicaremos a qué recursos.

Este archivo tiene este aspecto:

<?xml version="1.0"?>
<!DOCTYPE resource-action-mapping PUBLIC "-//Liferay//DTD Resource Action Mapping 6.2.0//EN" 
"http://www.liferay.com/dtd/liferay-resource-action- mapping_6_2_0.dtd">

<resource-action-mapping>
    <portlet-resource>
        <portlet-name>guestbook</portlet-name>
        <permissions>
            <supports>
                <action-key>ADD_TO_PAGE</action-key>
                ...
            </supports>
            <site-member-defaults>
                <action-key>VIEW</action-key>
            </site-member-defaults>
            <guest-defaults>
                <action-key>VIEW</action-key>
            </guest-defaults>
            <guest-unsupported />
        </permissions>
    </portlet-resource>

    <model-resource>
        <model-name>com.liferay.docs.guestbook.model</model-name>
        <portlet-ref>
            <portlet-name>guestbook</portlet-name>
        </portlet-ref>
        <permissions>
        <supports>
            <action-key>ADD_GUESTBOOK</action-key>
            ...
        </supports>
        <site-member-defaults>
            <action-key>ADD_ENTRY</action-key>
        </site-member-defaults>
        <guest-defaults />
        <guest-unsupported>
            <action-key>ADD_GUESTBOOK</action-key>
            ...
        </guest-unsupported>
        </permissions>
    </model-resource>
</resource-action-mapping>

En este archivo definimos las acciones soportadas por cada uno de nuestros portlets (bloques <portlet-resource/>, pueden existir varios) y de nuestras entidades (bloques <model-resource/>, pueden existir varios), así como los permisos por defecto de los miembros del site o del usuario invitado, etc.

Además de crear este archivo, deberemos insertar esta linea en el archivo docroot/WEB-INF/src/portlet.properties (crearlo si aun no existe):

resource.actions.configs=resource-actions/default.xml

voilà! Una vez compilado y desplegado en nuestro servidor de aplicaciones ya podemos acceder al panel de control de Liferay y dar o quitar permisos a lo roles que creamos conveniente.

Solo nos faltaría comprobar antes de realizar una acción (por ejemplo, añadir un Guestbook) que alguno de los roles del usuario contienen el permiso para realizar dicha acción... pero eso mejor lo dejamos para otro dia  ;-)

Inputs con multi-idioma

Data de publicació 18/12/15 02:15

En un blog anterior explicamos cómo “Sacar partido de la configuración de un portlet”, utilizaremos ese ejemplo para, a continuación, explicar cómo gestionar la información de los inputs en varios idiomas.

Si bien podemos utilizar keys dentro del portlet para determinar su valor en los distintos idiomas, una opción menos rígida es introducir los valores en los distintos idiomas a través de la configuración del portlet.

En nuestro ejemplo teníamos portlet con un título, una imagen y un listado. Dicho título era fijo, aunque cambiaras el idioma el título mostrado sería el mismo. Ahora lo que queremos es poder decidir el texto que utilizaremos de título en función del idioma en que se visualice la página.

 

Diferencias respecto a lo que teníamos:

configuration.jsp: cambia el tipo de tag usado para los input, en esta ocasión utilizaremos <liferay-ui:input-localized> envuelta por un <aui:field-wrapper>. También cambia la forma de manejar sus valores, ahora utilizaremos la clase LocalizationUtil para tratarlos.

 

configuration.jsp
String localizedTitle = LocalizationUtil.getLocalizationXmlFromPreferences(portletPreferences, renderRequest, "title");
 
<liferay-ui:panel collapsible="<%= true %>" extended="<%= true %>" id="customText" persistState="<%= true %>" title="Text">
    <aui:fieldset cssClass="title-data" label="Title Text">
        <aui:field-wrapper cssClass="lfr-input-text-container" label="Title">
            <liferay-ui:input-localized name="title" xml="<%= localizedTitle %>" />
        </aui:field-wrapper>
    </aui:fieldset>
</liferay-ui:panel>

 

Es posible definir que solo muestre para elegir los idiomas del Site con “availableLocales”.

configuration.jsp
<liferay-ui:input-localized name="title" availableLocales="<%= LanguageUtil.getAvailableLocales(themeDisplay.getSiteGroupId()) %>" xml="<%= localizedTitle %>" />

 

También se puede definir que el idioma por defecto sea el que tiene el Site con “defaultLanguageId”:

configuration.jsp
Locale defaultLocale = LocaleUtil.getSiteDefault();
String defaultLanguageId = LocaleUtil.toLanguageId(defaultLocale);
<liferay-ui:input-localized name="title" defaultLanguageId="<%= defaultLanguageId %>" xml="<%= localizedTitle %>" />

 

ConfigurationActionImpl.java: Guardamos los datos localizados.

En este caso, es necesario tratar los datos para poder guardarlos.

 

ConfigurationActionImpl.java
PortletPreferences preferences = actionRequest.getPreferences();
  
// Treat preferences
LocalizationUtil.setLocalizedPreferencesValues(actionRequest, preferences, "title");
  
// Store preferences
preferences.store();
super.processAction(portletConfig, actionRequest, actionResponse);

 

view.jsp: Distinto método de obtener el valor en el idioma actual.

 

  • Obtenemos el valor:
view.jsp
String localizedTitle = LocalizationUtil.getPreferencesValue(preferences, "title", themeDisplay.getLanguageId());

 

  • Utilizamos el valor (ejemplo):
view.jsp
<h1> <%=localizedTitle%> </h1>
<% if (showsImage)  { %>
    <img src="<%=imageLink%>" alt="">
<% } %>
<div><%=contentList%></div>

 

Una vez aplicadas las modificaciones tendremos un nuevo campo en la configuración del portlet con la posibilidad de guardar una información distinta por cada idioma.

Configuration

Espero que os sea de utilidad, un saludo.

 

Sacar partido de la configuración de un portlet

Data de publicació 16/09/15 05:01

A menudo tenemos que definir ciertos comportamientos que tiene un portlet en diferentes situaciones. Un ejemplo claro seria un formulario de contacto; pensad en la situación que tenemos tres sitios web que necesitan de este portlet. Y cada uno necesita que el formulario se envíe a un correo electrónico diferente, con un asunto específico según el sitio de dónde se envíe. Para evitar tener que crear un portlet para cada web podemos aprovechar la configuración del portlet para determinar cómo queremos que sea su comportamiento.

Haremos un ejemplo simple en el que mediante el panel de configuración de un portlet, que muestra un título, una imagen y un listado, podamos decidir si queremos que se muestre la imagen.

 

Paso 1: Especificar cuál será el archivo ".jsp" de la configuración en el "portlet.xml".

Añadimos el siguiente código después del tag “<portlet-class>...</portlet-class>” con la localización de nuestro archivo ".jsp" como value.

< init-param >
      < name >config-template</ name >
      < value >/html/configuration.jsp</ value >
</ init-param >

 

Paso 2: Crear el archivo jsp “configuration.jsp”.

Creamos un archivo "configuration.jsp" en el directorio indicado en el portlet.xml, en nuestro caso, en “/html/configuration.jsp”. 

<%@include file="/html/init.jsp" %>
< liferay-portlet:actionURL   portletConfiguration = "true"   var = "configurationURL"   />
<%
boolean showsImage = GetterUtil.getBoolean(portletPreferences.getValue("showsImageCheck", StringPool.TRUE));
%>
< aui:form   action="<%= configurationURL %>" method="post" name="fm">
     < aui:input   name="<%= Constants.CMD %>" type="hidden" value="<%= Constants.UPDATE %>" />
     < liferay-ui:success   key = "success-setup"   message = "you-have-successfully-updated-the-setup"   />
     < liferay-ui:panel   collapsible="<%=true%>" extended="<%=true%>" id="config" persistState="<%= true %>" title="Configuration">
         < aui:fieldset   cssClass = "option-content-data"   label = "Options" >
             < aui:input   label = "Shows Image"   name = "preferences--showsImageCheck--"   type = "checkbox"   value="<%= showsImage %>" />
         </ aui:fieldset >
     </ liferay-ui:panel >
     < aui:button-row >
        < aui:button   type = "submit"   />
     </ aui:button-row >
</ aui:form >

Nota: Es posible estructurar las opciones de la configuración en distintos paneles siempre que el id del panel no se repita o separarlos por fields.

Creamos o añadimos (si es necesario) el archivo "init.jsp" con el siguiente contenido.

<%@ taglib uri=" prefix="c" %>
 
<%@ taglib uri="  prefix="aui" %>
<%@ taglib uri="  prefix="liferay-ui" %>
<%@ taglib uri="  prefix="liferay-portlet" %>
<%@ taglib uri="  prefix="liferay-theme" %>
<%@ taglib uri="  prefix="portlet" %>
 
<%@ page import="com.liferay.portal.kernel.util.Constants" %>
<%@ page import="com.liferay.portal.kernel.util.GetterUtil" %>
<%@ page import="com.liferay.portal.kernel.util.StringPool" %>
<%@ page import="com.liferay.portal.kernel.util.ParamUtil" %>
<%@ page import="com.liferay.portal.kernel.util.Validator" %>
<%@ page import="com.liferay.portlet.PortletPreferencesFactoryUtil" %>
<%@ page import="com.liferay.portal.util.PortalUtil" %>
 
<%@ page import="javax.portlet.ActionRequest" %>
<%@ page import="javax.portlet.PortletPreferences" %>
 
< portlet:defineObjects />
< liferay-theme:defineObjects />
 
<%
PortletPreferences preferences = null;
if (renderRequest != null) {
    preferences = renderRequest.getPreferences();
}
String portletResource = ParamUtil.getString(request, "portletResource");
if (Validator.isNotNull(portletResource)) {
    preferences = PortletPreferencesFactoryUtil.getPortletSetup(request, portletResource);
}
%>

 

 Y añadimos las dependencias necesarias en “liferay-plugin-package.properties”.

portal-dependency-jars=\
    jstl-api.jar,\
    jstl-impl.jar

 

Paso 3: Crear el archivo "ConfigurationActionImpl.java" y configurar el “liferay-portlet.xml”.

Creamos el archivo "ConfigurationActionImpl.java" dentro del package “org.portlet.name.action” y, además, tenemos que especificar “DefaultConfigurationAction” como superclase de ésta.

package org.portlet.name.action;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletConfig;
import javax.portlet.PortletPreferences;
 
import com.liferay.portal.kernel.portlet.DefaultConfigurationAction;
 
public class ConfigurationActionImpl extends DefaultConfigurationAction {
 
    @Override
    public void processAction(PortletConfig portletConfig, ActionRequest actionRequest,
        ActionResponse actionResponse) throws Exception {
 
        PortletPreferences prefs = actionRequest.getPreferences();
        // Treat preferences
 
        // Store preferences
        preferences.store();
        super.processAction(portletConfig, actionRequest, actionResponse);
    }
}

 

Tratamos las preferences si fuera necesario y las guardamos.

Añadimos el elemento al “liferay-portlet.xml” después del tag “<icon>...</icon>”.

 

< configuration-action-class >org.portlet.name.action.ConfigurationActionImpl</ configuration-action-class >

 

Paso 4: Modificamos nuestros archivo ".jsp" para utilizar los valores que extraemos de la configuración del portlet.

- Obtenemos el valor:

<%
boolean showsImage = GetterUtil.getBoolean(portletPreferences.getValue("showsImageCheck", StringPool.TRUE));
%>

 

- Utilizamos el valor (ejemplo):

< h1 > <%=titleText%> </ h1 >
<% if (showsImage)  { %>
    < img   src="<%=imageLink%>" alt="">
<% } %>
< div ><%=contentList%></ div >

Una vez realizado todos los pasos, al acceder a la configuración del portlet tendremos una nueva pestaña con las opciones que hayamos incluido.

Y este sería el resultado:

Un Saludo.

 

Liferay - Actualización de plugins a la 6.2

Data de publicació 31/08/14 18:00

Útil cuando se quiera actualizar un portal y sus plugins a la versión 6.2 de Liferay, se puede usar como orientación para futuras versiones.

Actualizar los plugins

Themes

  • Los themes solo deberían contener las diferencias respecto al theme que extienden
  • Con la 6.2 los themes son responsivos y utilizan bootstrap, por ejemplo el theme base "Classic"
  • Los themes antiguos de la 6.1 deberían funcionar con la 6.2 sin ser responsivos
  1. Compilar el tema para la 6.2
  2. Comprobar el funcionamiento y sus logs
  3. (Opcional) Actualizar el tema para que sea responsivo 
  4. (Opcional) Empezar el tema des de cero con bootstrap

Layouts

  • Ahora incorporan bootstrap y scaffolding
  • Deberían funcionar sin problema con solo compilar para 6.2 sin ser responsivos
  • Es recomendable por su facilidad rehacerlos des de cero

Portlets

  • Ahora disponen de nuevas API
  • Algunas clases y métodos de la API han podido ser deprecados y deberían ser reemplazados
  • Se han añadido nuevas funciones que podrían ser útiles: ADT, papelera reciclaje, sandboxing, ...
  1. Compilar el portlet para la versión 6.2
  2. Comprobar el funcionamiento y sus logs
  3. (Opcional) Utilizar la herramienta Liferay AUI Upgrade Tool para adaptarlo a la 6.2 y añadir responsive design
  4. (Opcional) Volver a compilar y comprobar el funcionamiento

Hooks

  • Nuevos tipos de hook disponibles
  • Más potencia y acceso
  • Se deployan en tiempo de ejecución
  • Los hooks pueden afectar al proceso de actualización, es importante que no estén instalados en ese momento
  • Los hooks pueden tener una fuerte dependencia con la versión del portal
  1. Se recomienda comprobar uno a uno los ficheros (jsps, clases, properties, ...) que modifica el hook con el portal actual respecto la versión anterior.
    Se pueden comparar directamente los ficheros que modifica entre las versiones oficiales del portal, puede ser más fácil que directamente con el hook
  2. En caso que los ficheros originales que modifica el hook difieran de una versión de portal a la otra se debe rehacer el funcionamiento de esa parte para la nueva versión
  3. Compilar el hook para la versión 6.2
  4. En hooks agresivos (modifican permisos, documentos, contenidos, etc) es recomendable probar su funcionamiento con una versión limpia de la versión del portal
  5. Comprobar el funcionamiento y sus logs

Ext / Extlet

  • Probablemente deberán ser rehechos
  • Se recomienda evitarlos y reemplazar los que haya por portlets y/o hooks.
  • Para deployarse correctamente necesitan el reinicio del servidor
  • Pueden afectar al proceso de actualización, es importante que no estén instalados en ese momento
  1. Pensar si puede ser reemplazado por un portlet y/o hook, en caso afirmativo crear uno des de zero.
  2. En caso negativo adaptarlo a los nuevos ficheros del portal, se deberá comprobar cada fichero que modifique si ha cambiado en la nueva versión respecto la anterior
  3. Compilar el ext plugin para la versión 6.2
  4. Instalar y reiniciar el servidor
     

Recomendaciones para el futuro

  • Utiliza el entorno de plugins SDK para desarrollar
  • Sigue las buenas prácticas de programación
  • Evita el uso de plugins EXT
  • Minimiza el uso de hooks en lo posible
     

Nivel de dificultad en la actualización

Puntos de dificultad en la actualización incrementando según la diferenciación de los estándares (ej. JSR-286) y el uso de "malas" prácticas a la hora de personalizar los plugins, hooks y portal.

 

 

Utilizamos esta información como guía para actualizar nuestros plugins. ¡Esperamos que os sea de utilidad!

Liferay. Instalación sobre SQLServer 2000

Data de publicació 16/10/14 16:49

Uno de nuestros clientes tenía el requerimiento de montar un Liferay 6.2 GA2 sobre Microsoft SQLServer 2000. Según documentación de Liferay, el portal es compatible con este SGBD, cierto, pero la instalación mediante wizard funcionará perfectamente sólo a partir de la versión 2005.

 

Básicamente los problemas encontrados son dos:

  1. Tipo de datos de columna nvarchar(max) no existe en SQLServer 2000.
  2. Esta versión tiene tamaño máximo de row de 8KB,como la versión 2005, pero esta última almacena en memoria extra los datos según el tipo de columna. Por el contrario, SQLServer 2000, sea cuál sea el tipo de datos, todo registro se almacenará en estos 8KB.
     

En nuestro caso, la base de datos se encuentra en una máquina remota. Ten en cuenta lo siguiente en caso que así sea:

  1. Instalar el Service Pack 3 para SQLServer 2000. Evitará bastantes problemas para acceder vía TCP a la base de datos.
  2. Habilitar el acceso TCP a la máquina en el SQLServer.
  3. Comprobar que el log así lo refleja (visible en el Enterprise Manager, en la sección Management)
  4. Testear el acceso remoto mediante Telnet a la IP y puerto (1433 por defecto). Debería aparecer pantalla en negro o mensaje conectado pero no el mensaje de "connection refused".

 

En este punto, detallamos a continuación los pasos que necesitan revisión sobre el habitual proceso de instalación de Liferay. La mayoría de ellos pueden realizarse antes de llamar al ./startup.sh, es decir, antes de lanzar el wizard de instalación automática.

 

  1. Preparar la base de datos
  2.  
    1. Crear la base de datos sobre la que se quiera instalar Liferay.
    2. Creación manual del modelo de datos.
      1. Bajarse el script de las tablas desde aquí: http://www.liferay.com/es/downloads/liferay-portal/available-releases (apartado APPLICATION SERVER PLUGINS - DATABASE SCRIPTS)
      2. En el ZIP, localizamos el script portal-tables-sql-server.sql que vamos a modificar para luego ejecutarlo manualmente en el SQLServer (antes de que lo haga Liferay automáticamente en la instalación)
        1. Reemplazar nvarchar(max) por text. (cambio en el tipo de datos de columna en todo el script)
        2. Aún con esto, si lanzáramos en el SQLServer el script modificado, veríamos que nos lanza el siguiente aviso para unas 40 tablas:

  3.  

    The table [Table] has been created, but its maximum row size exceeds the allowed maximum of 8060 bytes. INSERT or UPDATE to this table will fail if the resulting row exceeds the size limit

Aparece el segundo problema comentado al inicio de esta entrada. Para evitar esta situación no queda otra que modificar manualmente las tablas afectadas por superar el límite de tamaño de row de 8KB. Una opción es modificar el tamaño de los nvarchar. Puede comprobarse que el script está listo cuando en su ejecución no resulte ningún warning como el anterior.
Liferay en su instalación, sólo crea las tablas si éstas no existen. Crear el modelo de datos previa instalación es perfectamente válido. Dejaremos las tablas creadas y vamos a preparar Liferay.
 

  1. Preparar Liferay

  2.  

    1. Configuramos la conexión a la BBDD en el portal-ext.properties.

    2. Añadimos en portal-ext.properties la siguiente línea:

       

      verify.processes=
       

      Sobreescribe la propiedad que controla el disparador para la verificación de la base de datos al arrancar y la inhabilita. Por defecto Liferay, la tiene activada. 
      Una de las acciones que realiza el verificador por defecto es crear una columna para cada tabla para después eliminar dicha columna. El motivo por el que inhabilitamos la verificación es por que justamente la columna que añade Liferay es del tipo nvarchar(max), el tipo de datos incompatible. Lo ideal sería montar un verificador a medida para SQLServer 2000 pero se muestra en esta entrada de blog una solución que no implique recompilar Liferay
      Si lanzáramos el ./startup.sh antes de realizar esta acción, nos econtraríamos con el siguiente error en el log:

       

      15:33:05,507 INFO [localhost-startStop-1][VerifySQLServer:107] Updating AnnouncementsEntry.content to use nvarchar(max)
      15:33:05,509 ERROR [localhost-startStop-1][VerifySQLServer:95] java.sql.SQLException: Line 1: Incorrect syntax near 'max'.
       

Ya lo tenemos todo listo para lanzar la instalación.

 

Hasta el día de hoy, tras la instalación correcta de Liferay, únicamente se han detectado problemas con las inserciones de datos básicos que Liferay realiza para tablas de configuración, como por ejemplo, tipos de documento de la Document Library (DLFileEntryType), que es una de las tablas que deben modificarse los tipos de datos en el script. El tipo "Basic Document" no existía en el Back Office.

 

Esperamos que si alguna vez os encontráis con tener de realizar una instalación en este entorno, esta entrada os sirva para ahorraros algún que otro dolor de cabeza.

 

Hasta la próxima.

Liferay - Migración del portal a la 6.2

Data de publicació 06/08/14 14:01

Realizamos la primera entrada de blog en referencia a la actualización/migración de Liferay a la versión 6.2. Esta entrada habla de la actualización del portal, la próxima tratará la actualización de plugins.

Se trata de una entrada más bien a modo de checklist de las tareas a realizar en una migración desde un punto de vista teórico. Vamos con ello...

 

Actualizar el portal. El algoritmo de permisos es muy importante

Previamente al proceso de migración:

1) (Opcional) (Recomendable) Aplicar los parches y actualizaciones pendientes de la versión actual

2) (Opcional) (Recomendable) Resolver los errores actuales del portal, intentar que todo funcione correctamente

3) (Opcional) (Recomendable) Ejecutar el proceso de verificación (*)

4) Hacer un Backup completo

Base de datos

Documentos y media

(Opcional) Índices <- aunque después de actualizar se re-indexa

(Opcional) Portal y su configuración <- aunque en principio no lo sobrescribiremos

5) Utilizar el algoritmo de permisos v6 <- seguramente ya sea el caso, mirar el siguiente punto para confirmación

 

Algoritmo de permisos

Para migrar a la 6.2 es obligatorio que se esté utilizando el algoritmo de permisos en versión nº 6.

Comprobar que estemos utilizando esta versión del algoritmo:

- Panel de control > Administración del servidor > Propiedades > Propiedades del Portal

- Navegar hasta encontrar la propiedad llamada "permissions.user.check.algorithm"

Comprobar que sea la versión 6

Actualizar a la versión 6:

- Esto debe hacerse antes de actualizar el portal a la 6.2

- Panel de control > Administración del servidor > Migración de datos

- Al final de la página se encontrará un apartado "Convertir el antiguo algoritmo de permisos"

 

   El Checkbox es opcional, es para convertir permisos que estaban asociados a usuarios (directamente) a roles asignados a usuarios, ya que el algoritmo v6 no permite asociar permisos directamente a usuarios

Proceso de migración

 

1) Descargar la última versión del portal

2) Configurar el nuevo portal (portal-ext.properties) para que apunte a la antigua base de datos y documentos

3) Revisar y configurar el portal-legacy-XX.properties de vuestra versión (Consultar guía de usuario, enlace al final)

4) (Enterprise Edition) Pedir y/o descargar la licencia para la nueva versión

5) Arrancar el servidor

a)Primero lanzará un proceso de actualización de la base de datos y documentos

b)Luego ejecutará un proceso de verificación de inconsistencias

6) Buscar y aplicar parches pendientes si hay

7) (Recordatorio) No instalar aún los plugins personalizados

Posteriormente al proceso de migración

1) Comprobar que el portal funcione bien, utilizar las funciones más comunes

2) Revisar los logs

3) Instalar posibles plugins oficiales (la nueva versión), a veces con nuevas versiones se pasan funciones del núcleo a portlets, etc. Revisar también si se hecha de menos algo en el portal.

4) Re-indexar los índices

5) Instalar el resto de plugins personalizados (hasta ahora webapps debía estar con los portlets que venían por defecto) <- Se tratará en una entrada de blog para plugins

6) Utilizar el nuevo portal como producción

Resolución de Problemas

documentLibrary.NoSuchFileException

- Posible configuración portal-ext.properties incorrecta en las líneas (dl.store.impl y dl.store.file.system.root.dir)

- posible estado inestable del repositorio

- posible falta de ficheros en el repositorio (eliminar desde el portal los ficheros o añadirlos al repositorio)

Si ha ocurrido cualquier problema la recomendación es arreglarlo (suele ser configuración) y empezar de nuevo restaurando el Backup inicial.

Si se intenta actualizar desde una base de datos corrompida o con actualizaciones a medias, puede ser muy difícil poder entender los errores

Recomendaciones

No aprovechar la actualización para hacer otros cambios, solo puede incrementar y confundir la procedencia los posibles errores

No hacer un cambio de tipo de base de datos (P.ej: MySQL a Oracle)

No hacer un cambio de servidor de aplicaciones (P.ej: Tomcat a JBoss)

No cambiar de servidor o hosting

(Enterprise Edition) Utilizar el servicio oficial de soporte a la migración (customer portal o sales_es@liferay.com)

(Enterprise Edition) Pedir la checklist de tareas para la migración (customer portal o sales_es@liferay.com)

Orden de actualización complejo (información extra para casos puntuales)

Aquí se describe el órden de actualización si se quieren hacer varios cambios en el sistema. Después de cada paso hace falta verificar el correcto funcionamiento y arreglar los errores.

1) Comunity edition (CE) a Entrerprise edition (EE)

2) Actualizar portal con los últimos parches

3) Algoritmo de permisos a versión nº 6

4) Actualizar a la última versión de portal (6.2)

5) Actualizar el software (bbdd, servidor de aplicaciones, etc) uno a uno

 

(*) Proceso de verificación

El proceso de verificación está disponible en todas las versiones y se puede ejecutar sin la necesidad de actualizar el portal.

Para lanzar-lo es necesario parar el servidor y añadir la siguiente linea verify.frequency=-1 en el portal-ext.properties. Ahora basta con arrancar el servidor.

Una vez pasado el proceso es necesario eliminar la línea para evitar volver a lanzar.

 

 

 

Esperamos que esta entrada os sirva de ayuda, a nosotros nos sirve como base para realizar migración de versiones.

 

 

— 20 Items per Page
S'estan mostrant els 8 resultats.

Bloggers recents Bloggers recents

Oscar Rodríguez
Apunts: 9
Estrelles: 2
Data: 28/09/16
David Berruezo
Apunts: 14
Estrelles: 1
Data: 22/07/16
Javi Martín
Apunts: 2
Estrelles: 1
Data: 20/05/16
Javier Torres
Apunts: 5
Estrelles: 3
Data: 11/04/16
Sergi Mingueza
Apunts: 4
Estrelles: 1
Data: 19/10/15
Matilde Gallardo
Apunts: 1
Estrelles: 0
Data: 26/02/15
Adrià Vilà
Apunts: 4
Estrelles: 4
Data: 31/08/14
Elena Ruiz
Apunts: 1
Estrelles: 2
Data: 13/03/14