openxava / documentación / Migración

Para migrar de OpenXava 7.5 a OpenXava 7.5.1

Para migrar de OpenXava 7.4.5 a OpenXava 7.5

Añadir la entidad LDAPConfiguration al persistence.xml (para XavaPro)

Si usas XavaPro, o planeas usarlo en el futuro, edita el archivo persistence.xml y añade la siguiente entrada a todas tus unidades de persistencia:

<class>com.openxava.naviox.model.LDAPConfiguration</class>

Añadir módulo LDAPConfiguration a rol admin y carpeta Admin (para XavaPro)

Si usas XavaPro con un proyecto existente, necesitas añadir el módulo LDAPConfiguration al rol admin y a la carpeta Admin. Para proyectos nuevos de XavaPro esto no es necesario ya que el módulo ya está incluido. XavaPro no añade automáticamente módulos nuevos a proyectos existentes por razones de seguridad:

1. Añade el módulo LDAPConfiguration al rol admin:

2. Añade el módulo LDAPConfiguration a la carpeta Admin:

Configuración LDAP movida al módulo Admin (para XavaPro)

En XavaPro, la configuración LDAP ya no se realiza en el archivo naviox.properties. Las siguientes propiedades ya no son válidas:

# LDAP Config
ldapHost=192.168.0.0
ldapDomain=XX
ldapDN=DC=XX,DC=XX,DC=XX
ldapPort=389

En su lugar, la configuración LDAP ahora se gestiona a través del módulo Admin. Puede configurar los ajustes de LDAP yendo a Admin > LDAP en el menú de la aplicación. Para información detallada sobre la configuración de LDAP en la versión 7.5, consulte la documentación de configuración LDAP.

Para migrar de OpenXava 7.4.4 a OpenXava 7.4.5

Para migrar de OpenXava 7.4.3 a OpenXava 7.4.4

Para migrar de OpenXava 7.4.2 a OpenXava 7.4.3

Hibernate validator actualizado desde 6.0.23.Final a 6.2.5.Final

Hemos tenido que actualizar la versión de Hibernate validator debido a una vulnerabilidad en versiones anteriores a 6.2.0.Final. Aunque hemos probado que funciona bien sin necesidad de hacer cambios, puede que haya algún problema si usas @SafeHtml o Expression Language for custom violations. Para más información puedes visitar la web oficial de hibernate.

Para migrar de OpenXava 7.4.1 a OpenXava 7.4.2

Para migrar de OpenXava 7.4 a OpenXava 7.4.1

Para migrar de OpenXava 7.3.3 a OpenXava 7.4

Nueva fila en PDF generado en modo lista (para pruebas JUnit)

Ahora los PDF generados en modo lista tienen un nuevo elemento que muestra la cantidad de registros presentes en el reporte, por lo que si compruebas detalles del reporte en pruebas JUnit, es necesario hacer unos cambios, anteriormente era:

assertPopupPDFLinesCount(7);
assertPopupPDFLine(2, "Name");

assertPopupPDFLinesCount(8); // +1
assertPopupPDFLine(2, "Record count: 3"); // SE AGREGÓ ESTA NUEVA FILA
assertPopupPDFLine(3, "Name");

Nueva acción en colecciones (para pruebas JUnit)

Ahora las colecciones tendrán una nueva acción tanto en lista como en cada fila, Collection.deleteSelected, por lo que si comprueban las acciones presentes en las pruebas JUnit, es necesario hacer algunos cambios, agregando la nueva acción y en algunos casos quitando Collection.removeSelected si la colección tiene (cascade=CascadeTYPE.REMOVE). Por ejemplo:

String [] actions = { 
    "Collection.new",
    "Collection.edit",
    "Collection.removeSelected", // QUITA ESTA ENTRADA SI LA COLECCIÓN TIENE ELIMINAR EN CASCADA
    "Collection.deleteSelected" // AÑADE ESTA ENTRADA
};		
assertActions(actions);

public void testDeleteElementInCollection() throws Exception {
	....
	execute("Collection.removeSelected", "row=0,viewObject=xava_view_humans"); // QUITAR
	execute("Collection.deleteSelected", "row=0,viewObject=xava_view_humans"); // CAMBIAR POR
	...
}

Nueva acción en colecciones (para acciones personalizadas)

Collection.deleteSelected también afecta si tienes una colección con (cascade=CascadeType.REMOVE) y @RemoveSelectedAction personalizando la acción de Quitar.
En este caso deberás cambiar la anotación de @RemoveSelectedAction por @DeleteSelectedAction y el extends de la clase de la acción RemoveSelectedInCollectionAction por DeleteSelectedInCollectionAction.
Esto se debe que al tener eliminar en cascada, la acción Collection.removeSelected actúa de la misma forma que Collection.deleteSelected y por tanto el primero no aparecerá en la vista.

@OneToMany (mappedBy="delivery", cascade=CascadeType.REMOVE)
@RemoveSelectedAction(forViews="DEFAULT, MoreSections", value="DeliveryDetail.removeSelected") // QUITAR
@DeleteSelectedAction(forViews="DEFAULT, MoreSections", value="DeliveryDetail.deleteSelected") // CAMBIAR POR @DeleteSelectedAction, 
										       // EL NOMBRE DE LA ACCIÓN EN EL CONTROLADOR NO ES OBLIGATORIO CAMBIARLO
private Collection<Detail> details;	

public class DeleteSelectedDeliveryDetailsAction 
	extends RemoveSelectedInCollectionAction { // QUITAR
	extends DeleteSelectedInCollectionAction { // CAMBIAR POR

Nueva acción en fila de colecciones (para pruebas JUnit)

Ahora cada fila de la colección tiene una nueva acción, CollectionOpenInNewTab.openInNewTab, por lo que si comprueban las acciones presentes en las pruebas JUnit, es necesario modificarlas y agregar la nueva acción. Por ejemplo:

String [] actions = { 
    "Collection.edit",
    "CollectionOpenInNewTab.openInNewTab" // AÑADE ESTA ENTRADA
};		
assertActions(actions);

HtmlUnit actualizado desde 2.70 a 3.3 (para pruebas JUnit)

Hemos tenido que actualizar a la última versión de HtmlUnit debido a una vulnerabilidad de seguridad crítica en las versiones 2.x. Si utilizas los métodos de ModuleTestBase en tus pruebas, no necesitas cambiar nada. Sin embargo, si utilizas la API de HtmlUnit directamente, usando getHtmlPage() o getWebClient() en tus pruebas, tendrás que realizar algunos ajustes de migración.

Sigue las instrucciones de la documentación de HtmlUnit para migrar de HtmlUnit 2.x.x a 3.x.x.

<div style="padding: 20px; background-color: green;">

<div class="mi-fondo">

.mi-fondo {
    padding: 20px; 
    background-color: green;
}

return "<i class='mdi mdi-square' style='color: " + valorHexColor + "'></i>";

return "<font color='" + valorHexColor + "'><i class='mdi mdi-square ox-color-inherit'></i></font>"; 

response.setContentType("text/html"); 

JavaScript en línea en los JSP requiere el atributo nonce

Esto es por razones de seguridad. Rara vez se utiliza JavaScript en línea en el código de las aplicaciones de OpenXava, ya que no funcionan desde OpenXava 3.1 para editores o vistas personalizadas. Sin embargo, si tienes código personalizado fuera de un módulo OpenXava normal, como welcome.jsp, o algún encabezado o pie de página personalizado para tu aplicación, tal vez tengas algunos scripts en línea. En este caso, debes agregar un atributo nonce a tu script en línea utilizando la nueva etiqueta <xava:nonce/> de la biblioteca de etiquetas.

Por ejemplo, si tu página welcome.jsp tiene este código:

<script type="text/javascript"> 
    var button = document.getElementById('welcome_go_signin');
    button.onclick = function () { window.location='m/SignIn'; }
</script>

Deberías cambiarlo por:

<%@include file="../xava/imports.jsp"%>
    
    ...
    
<script type="text/javascript" <xava:nonce/>> 
    var button = document.getElementById('welcome_go_signin');
    button.onclick = function () { window.location='m/SignIn'; }
</script>

Fíjate en el nuevo elemento <xava:nonce> y que has de incluir imports.jsp.

Aún mejor, podrías buscar una alternativa que no use ningún script en línea. En este caso, por ejemplo, podríamos cambiar el evento onclick con un window.location por un simple <a ref="" />, si es posible.

Ya no se soportan eventos en línea en elementos HTML

Los eventos en línea todavía funcionan en los editores y vistas personalizadas en v7.1, sin embargo, si tienes código personalizado fuera de un módulo OpenXava normal, como welcome.jsp, tal vez tengas eventos en línea como onclick, onfocus, onblur, etc., que ya no van a funcionar. Esto es por razones de seguridad. Tienes que eliminar los eventos del HTML y moverlos a un archivo JS.

Es decir, si tienes un código como este:

<input type="button" tabindex="1" onclick="window.location='m/SignIn'" value="<xava:label key='SignIn'/>">

Quita el evento onclick y añade un id al elemento, dejándolo de esta manera:

<input id="welcome_go_signin" type="button" tabindex="1" value="<xava:label key='SignIn'/>">

Después añade un archivo JS, digamos eventos.js (o cualquier otro nombre que prefieras), en src/main/webapp/xava/editors/js (crea la carpeta si todavía no existe) de tu proyecto, con el siguiente contenido:

var button = document.getElementById('welcome_go_signin');
button.onclick = function () { window.location='m/SignIn'; }

Observa cómo utilizamos el ID para añadir el evento usando código JavaScript, un código seguro porque es descargado desde el servidor que aloja la aplicación.

IForwardAction ya no se puede utilizar para ejecutar JavaScript

Dadas las nuevas restricciones de seguridad, no es posible redirigir a JavaScript, por lo que si utilizas IForwardAction para redirigir a una URL que comienza con javascript: para ejecutar código, eso no funcionará. En su lugar, utiliza IJavaScriptPostAction para ejecutar JavaScript. Es decir, si tienes una acción como esta:

public class DecirHola extends BaseAction implements IForwardAction {    

    public void execute() throws Exception {
    }

    public String getForwardURI() {
    	return "javascript:alert('Hola')";
    }

    public boolean inNewWindow() {
        return false;
    }

}

Reescríbela de esta manera:

public class DecirHola extends BaseAction implements IJavaScriptPostAction {

    public void execute() throws Exception {
    }

    public String getPostJavaScript() {
	return "alert('Hola')";
    }

}

Las etiquetas en inglés ahora tienen otro orden (para las pruebas JUnit)

Notamos que las etiquetas en listas y colecciones, cuando están traducidas a inglés, si bien se entendían, podían estar mejor. Para esto, cambiamos el orden de las palabras y afecta al código JUnit que use métodos como assertValue(), assertLabelInList(), assertValueInCollection(), entre otros que se usen para verificar etiquetas. Por ejemplo, si tienes algo así:

assertLabelInList(0, "Year of invoice");

Cambiala por:

assertLabelInList(0, "Invoice year");

Si antes las etiquetas eran:

customer.address = Address of customer
customer.address.street = Street of address of customer
customer.address.street.number = Number of street of address of customer 

Ahora son:

customer.address = Customer address
customer.address.street = Customer address street
customer.address.street.number = Customer address street number

Recargar página necesario para usar CSS en las pruebas (para pruebas JUnit)

getWebClient().getOptions().setCssEnabled(true); // Si haces esto...
reload(); // ...has de añadir esta línea

Nueva acción en referencias y @DescriptionsList (para pruebas JUnit)

String [] acciones= {
	"CRUD.new",
	"CRUD.save",
	"CRUD.refresh",
	"Mode.list",
	"Reference.search",
	"Reference.createNew",
	"Reference.modify",
	"Reference.clear", // AÑADE ESTA ENTRADA
	"Sections.change"
};
assertActions(acciones); 

<class>com.openxava.naviox.model.SSORecord</class>

setConditionValues("", "AUTOMÓVIL");

Aquí estás cambiando el id por la descripción o el nombre. Haz lo mismo con el código JUnit que verifica el contenido del combo. Cambia:

String [][] valoresValidos = {
    { "", "" },
    { "2:_:FAROLA", "FAROLA" },
    { "0:_:CASA", "CASA" },
    { "3:_:PUERTA", "PUERTA" },
    { "1:_:AUTOMÓVIL", "AUTOMÓVIL" }
};
assertValidValues("conditionValue___3", valoresValidos);        

Por:

String [][] valoresValidos = {
    { "", "" },
    { "FAROLA", "FAROLA" },
    { "CASA", "CASA" },
    { "PUERTA", "PUERTA" },
    { "AUTOMÓVIL", "AUTOMÓVIL" }
};
assertValidValues("conditionValue___3", valoresValidos);

Nota como hemos quitado el prefijo id:_: en la parte de la clave del mapa. Ahora, las claves y los valores son iguales.

<artifactId>almacenes</artifactId>

<artifactId>Almacenes</artifactId>

<finalName>almacenes</finalName>

<finalName>Almacenes</finalName>

<aplicacion nombre="almacenes">

<aplicacion nombre="Almacenes">

AppServer.run("almacenes");

AppServer.run("Almacenes");

Hibernate actualizado desde 5.3 a 5.6

Hemos trabajado duro adaptando OpenXava para que funcione bien con Hibernate 5.6. Sin embargo, puedes encontrar problemas en tu propio código JPA/Hibernate. Si usas la API de JPA todo debería funcionar tal cual, pero hay nuevos bug en Hibernate 5.6 que pueden hacer que tu código falle. Hemos encontrado algunos.

Join requerido en referencias en clave

Con Hibernate 5.3 cuando usas una propiedad de una referencia y esta es parte de la clave, no necesitas añadir un join explicito en la consulta. Esto es de esta forma no importa el nivel de profundidad. En Hibernate 5.6, no necesitas añadir un join si tienes sólo un nivel de referencia, pero si tienes un segundo nivel, has de añadirlo, si el segundo nivel tiene una clave compuesta.

Diciéndolo con código. Si tienes:

@Entity
public class CargoTransporte {
	
    @Id @ManyToOne
    private Albaran albaran;

    ...
	
}

@Entity
public class Albaran {
	
    @Id 
    private int numero;

    @Id @ManyToOne
    private Factura factura;

    ...
	
}

@Entity
public class Factura {
	
    @Id 
    private int anyo;
	
    @Id 
    private int numero;

    ...
	
}

Con el código de arriba la siguiente consulta funciona bien con Hibernate 5.3:

String consulta="from CargoTransporte c where c.albaran.factura.anyo = :albaran_factura_anyo";
Query query = XPersistence.getManager().createQuery(consulta);
query.setParameter("albaran_factura_anyo", 2022);

Pero falla con Hibernate 5.6. Curiosamente si ejecutas la consulta contra Albaran preguntando por factura.anyo funciona, sólo falla con 2 niveles o más. Además, si Factura hubiera tendido clave simple, en lugar de compuesta, hubiera funcionado también. Hibernate 5.6 falla cuando combinas más de un nivel con claves compuestas.

No te preocupes, la solución es sencilla, simplemente añade un join explicito para la primera referencia. Es decir, de la siguiente forma funciona con Hibernate 5.6:

String consulta="from CargoTransporte c join fetch c.albaran a where a.factura.anyo = :albaran_factura_anyo";
Query query = XPersistence.getManager().createQuery(consulta);
query.setParameter("albaran_factura_anyo", 2022);

La solución es el join fetch c.albaran a. Moraleja, si alguna consulta te falla con Hibernate 5.6 prueba añadir un join explicito para tu referencia.

Esquema no creado automáticamente

Un nuevo bug en Hibernate 5.6 es que ya no reconoce javax.persistence.create-database-schemas, por lo que si tienes la siguiente configuración en tu persistence.xml:

<persistence-unit name="default">
    ...
    <properties>
        <property name="javax.persistence.schema-generation.database.action" value="update"/>
        <property name="javax.persistence.create-database-schemas" value="true"/> 
        <property name="hibernate.default_schema" value="MIESQUEMA"/>
    </properties>
</persistence-unit>

Con Hibernate 5.3 crea el esquema MIESQUEMA y después las tablas dentro, sin embargo con Hibernate 5.6 el esquema MIESQUEMA no se crea, por ende las tablas tampoco se crean. La solución es crear el esquema MIESQUEMA a mano. Has de contectarte a tu base de datos con tu explorador de base de datos y ejecutar una sentencia CREATE SCHEMA MYSCHEMA (o equivalente). Después, puedes arrancar tu aplicación y las tablas serán creadas.

uploadFile("scripts", "informes/Corporacion.html");

uploadFile("scripts", "src/main/resources/informes/Corporacion.html");

HtmlUnit actualizado de 2.32 a 2.63 (para las pruebas JUnit)

HtmlElement tarjeta = body.getElementsByAttribute("div", "class", "ox-card").get(2);
assertEquals("Precio unitario: 0.00, Precio unitario en pesetas: 0"), tarjeta.asText());

HtmlElement tarjeta = body.getElementsByAttribute("div", "class", "ox-card").get(2);
assertEquals("Precio unitario: 0.00, Precio unitario en pesetas: 0"), tarjeta.asNormalizedText());

assertDiscussionCommentText("discusion", 0, Strings.multiline("admin - Ahora", "Hola, soy yo")); 

assertDiscussionCommentText("discusion", 0, "admin - Ahora\nHola, soy yo");

assertValueInList(2, "XAVA\r\n3\r\nPrecio unitario: 0");

assertValueInList(2, "XAVA\n3\nPrecio unitario: 0");

assertEquals(
    "javascript:openxava.executeAction('openxavatest', 'Carrier', 'Effacer l" 
        + (char) 145 // ANSI  
        +"entité courante: Etes-vous sûr(e) ?', false, 'CRUD.delete')", 
    deleteLink.getHrefAttribute());

assertEquals(
    "javascript:openxava.executeAction('openxavatest', 'Carrier', 'Effacer l" 
        + (char) 8216 // UNICODE
        +"entité courante: Etes-vous sûr(e) ?', false, 'CRUD.delete')", 
    deleteLink.getHrefAttribute());

assertValue("descripcion", "Esto es una gran discusión sobre jUnit");

assertValue("descripcion", "<p>Esto es una gran discusión sobre jUnit</p>");

assertValue("poblacion", "46540 ");

assertValue("poblacion", "46540");

getWebClient().getOptions().setCssEnabled(true); // Si haces esto...
reload(); // ...has de añadir esta línea

CellType.NUMERIC // En lugar de Cell.CELL_TYPE_NUMERIC
HyperlinkType.FILE // En lugar de Hyperlink.LINK_URL
FillPatternType.SOLID_FOREGROUND // En lugar de CellStyle.SOLID_FOREGROUND
HSSFColor.HSSFColorPredefined.RED // En lugar de HSSFColor.RED
BorderStyle.THIN // En lugar de CellStyle.BORDER_THIN
HorizontalAlignment.LEFT // En lugar de CellStyle.ALIGN_LEFT

Cell cell ... 
// cell.setCellType(Cell.CELL_TYPE_FORMULA); // Ya no existe, no es necesario
cell.setCellFormula(text);

font.setBoldweight(Font.BOLDWEIGHT_BOLD);

font.setBold(true);