Migration

Migration from OpenXava 2.2.5 to OpenXava 3.0

Default persistence provider is JPA

Since v3.0 OpenXava uses JPA by default for persistence. If you want to continue using Hibernate as persistence provider in your application just put the next line in the xava.properties file of your project:
persistenceProviderClass=org.openxava.model.impl.HibernatePersistenceProvider

MapFacade does not longer throw RemoteException

Now the methods of MapFacade do not throw RemoteException but SystemException, that is a runtime exception.
This has little repercussion on your code, but if you have a code like this:
try {
    MapFacade.validate("Invoice", values);
}
catch (RemoteException ex) {
    ...
}
 
Then you must change the RemoteException by a SystemException:
try {
    MapFacade.validate("Invoice", values);
}
catch (SystemException ex) {
    ...
}
 
Moreover, XavaException is now a runtime exception. But this does not requires any change in your code.

Migration from OpenXava 2.2.4 to OpenXava 2.2.5

MapFacade is not autocommit from now on

Until now, when you write:
MapFacade.create("Customer", customerValues);
MapFacade.create("Invoice", invoiceValues);
These two lines were two transaction. If the invoice creation fails the customer was saved. That is, MapFacade had an autocommit police.
From now on MapFacade is not autocommit by default, that is, the above case will have only a transaction, commited by OX at the end of the action or test. Now, if fails invoice creation customer creation will not be done.
This can change slightly the behaviour of your actions in case of fails, but only if your actions do several call to MapFacade. If you want to preserver the old behaviour you have two options.
First option: add the next line to your properties/xava.properties file:
mapFacadeAutoCommit=true
Second option: commit the transaction manually. For example, the above code can be write in this way:
MapFacade.create("Customer", customerValues);
MapFacade.commit();
MapFacade.create("Invoice", invoiceValues);
MapFacade.commit();

Migration from OpenXava 2.2.3 to OpenXava 2.2.4

Schema for the images table of IMAGES_GALLERY stereotype

Now the schema for the images table is specified specified separately, that is, before you write this in your configuration properties file:
images.table=XAVATEST.IMAGES
Now you write this instead:
images.schema=XAVATEST

images.table=IMAGES

Migration from OpenXava 2.2.2 to OpenXava 2.2.3

Labels of list mode and collections are qualified (for junit tests)

Labels for list mode and collection now are qualified, that is if you have a property customer.name, before the label was Name, and now is Name of Customer. This can be affect some of your junit test, that is, if you have:
assertLabelInList(2, "Name"); // for customer.name
now must write:
assertLabelInList(2, "Name of Customer"); // for customer.name

AccessTracking table schema changed

In the AccessTracking project the schema of the table for access record has changed:
You have to change your current table if you want to update to the AccessTracking 2.2.3
This change is for working in databases with no support for TABLE, DATE and TIME as column names.

Migration from OpenXava 2.2.1 to OpenXava 2.2.2

No issues

Migration from OpenXava 2.2 to OpenXava 2.2.1

MoneyFormatter (for junit tests)

A money formatter is applied by default for format/parser all values of stereotype MONEY, now all money data is always displayed with 2 decimal digits. Therefore you will need to adapt your junit test changing lines as this one:
assertValue("amount", "20");
by this one:
assertValue("amount", "20.00");
Or, if your prefer the old formatting style you can deactivate the formatter or use another editing your editors.xml file.

Action 'Mode.list" not available when the user navigate to another view (for junit tests)

When the user navigates to another view (for example to create or modify a reference) the link for go to list mode is not present now. Maybe you need to change your junit test.
For example in this junit code:
execute("Reference.createNew", "model=Family2,keyProperty=xava.Product2.family.number");
assertAction("Mode.list"); // Since 2.2.1 it fails
The assertAction("Mode.list") has to be removed.

Migration from OpenXava 2.1.5 to OpenXava 2.2

Default behaviour for collection of entities changes

Now, when user click on 'Add' in a collection the entities, he goes to a list where he can choose some entities to add. This may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:
execute("Collection.new", "viewObject=xava_view_customers");
setValue("customers.number", getCustomerNumber2());
assertValueIgnoringCase("customers.name", getCustomer2().getName());
assertCollectionRowCount("customers",0);
execute("Collection.save", "viewObject=xava_view_customers");
assertCollectionRowCount("customers",1);
by this one:
assertCollectionRowCount("customers",0);
execute("Collection.add", "viewObject=xava_view_customers");
assertValueInList(5, 0, getCustomer2().getName());
execute("AddToCollection.add", "row=5");
assertMessage("1 element(s) added to Customers of Seller");
assertCollectionRowCount("customers",1);
Moreover, now the user can add several entities at once, thus a code as this:
execute("Collection.new", "viewObject=xava_view_customers");
setValue("customers.number", getCustomerNumber1());
assertValueIgnoringCase("customers.name", getCustomer1().getName());
assertCollectionRowCount("customers", 0);
execute("Collection.save", "viewObject=xava_view_customers");
assertMessage("Customer associated to Seller");
 
assertCollectionRowCount("customers", 1);
setValue("customers.number", getCustomerNumber2());
assertValueIgnoringCase("customers.name", getCustomer2().getName());
execute("Collection.save", "viewObject=xava_view_customers");
assertCollectionRowCount("customers",2);
can be done in this way:
execute("Collection.add", "viewObject=xava_view_customers");
assertValueInList(4, 0, getCustomer1().getName());
assertValueInList(5, 0, getCustomer2().getName());
checkRow(4);
checkRow(5);
execute("AddToCollection.add");
assertMessage("2 element(s) added to Customers of Seller");
assertCollectionRowCount("customers",2);

Default behaviour for collection of aggregates changes

Now, when a detail of a collection is saved, the view of the detail is not hidden, this may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:
execute("Collection.save", "viewObject=xava_view_section1_details");
execute("Collection.new", "viewObject=xava_view_section1_details"); // To remove
by this one:
execute("Collection.save", "viewObject=xava_view_section1_details");
That is, remove the "Collection.new" call, because after save the detail, the "new" action is automatically executed, thus the user interface is ready to enter a new detail.

Migration from OpenXava 2.1.4 to OpenXava 2.1.5

No issues

Migration from OpenXava 2.1.3 to OpenXava 2.1.4

New actions in collections (for junit tests)

The collections have some new actions available for the users, therefore if you test for all presents actions in your junit tests, you need to modify it in order to take in account the new actions.
That is, if you have something as this in your junit test code:
        String [] actions = {
            "Navigation.previous",
            "Navigation.first",
            "Navigation.next",
            "CRUD.new",
            "CRUD.save",
            "CRUD.delete",
            "CRUD.search",
            "Collection.new",
            "Collection.removeSelected"
        };
 
        assertActions(actions);
you must change it by:
    String [] actions = {
            "Navigation.previous",
            "Navigation.first",
            "Navigation.next",
            "CRUD.new",
            "CRUD.save",
            "CRUD.delete",
            "CRUD.search",
            "Collection.new",
            "Collection.removeSelected",
            "List.filter",        // New
            "List.orderBy",       // New
            "List.customize",     // New
            "List.hideRows",      // New
            "Print.generatePdf",  // New
            "Print.generateExcel" // New
        };
 
        assertActions(actions);

Ant target generarPortlets removed

The ant target generarPorltets has been removed from OpenXava/build.xml because now it's exactly equal to generatePortlets. Therefore, if you have in your build.xml something like this:
<target name="generarPortlets">
    <ant antfile="../OpenXava/build.xml" target="generarPortlets"/>
</target>
Must change it by:
<target name="generarPortlets">
    <ant antfile="../OpenXava/build.xml" target="generatePortlets"/>
</target>

Migration from OpenXava 2.1 to OpenXava 2.1.3

JUnit test and key without value parsed as zero

Since 2.1.3 if a key property of type int, long or short has no value in the view when it is parsed is parsed with null (without value), and not as zero. This has no effect in final user, but possibly you need to modify some JUnit test. For example if you have in a test case:

public void testSomething() throws Exception {
  assertValue("number", "");
  execute("MyControllers.myAction"); // This does not change number value
  assertValue("number", "0"); // because OX parse empty string as 0 (until 2.1.2)
  ...
}
 
You now have to write in this way:
public void testSomething() throws Exception {
  assertValue("number", "");
  execute("MyControllers.myAction"); // This does not change number value
  assertValue("number", ""); // because now (since 2.1.3) OX parse empty string as null
  ...
}
 

Migration from OpenXava 2.0.4 to OpenXava 2.1

WebSphere projects

If you deploy your projects in WebSphere you need to do the next little changes:
First, in the file hibernate/hibernate.cfg.xml of you project add the next blue marked code:
<session-factory>
        <property name="hibernate.connection.datasource">@datasource.prefix@/@datasource@</property>
        <property name="hibernate.dialect">@hibernate.dialect@</property>
        <property name="hibernate.jdbc.use_get_generated_keys">false</property>
        <property name="hibernate.show_sql">false</property>
        @hibernate.properties@
        ...
</session-factory>
Second, in your configuration file for websphere (for example websphere-as400.properties) you have to add:
hibernate.properties=<property name="hibernate.transaction.manager_lookup_class">\n\
\t\t\torg.hibernate.transaction.WebSphereTransactionManagerLookup\n\
\t\t</property>\n\
\t\t<property name="transaction.factory_class">\n\
\t\t\torg.hibernate.transaction.JTATransactionFactory\n\
\t\t</property>

Other changes that requires some migration

Migration from OpenXava 2.0.3 to OpenXava 2.0.4

Parse of numeric values

Now data values of type Number (Integer, BigDecimal, Short, etc) and Boolean (not boolean) are parsed as null if in the User Interface are in blank. Before numeric blank field was parsed as 0. This change does not produce big incompatibility problems because default-converters.xml defines the real conversion before to store in database (the real important matter). That is, this change affects only displaying. You incompatibility issues maybe the next one:

API changes

Migration from OpenXava 2.0.2 to OpenXava 2.0.3

No events on-change when searching are thrown

OpenXava Reference Guide (in the section 7.5) says that CRUD.searchByViewKey does not throw any on-change event, and CRUD.searchExecutingOnChange throw all on-change events. But because of a bug in ox2.0.2 (and previous) the CRUD.searchByViewKey threw on-change events of keys in the references, and CRUD.searchExecutingOnChange does not threw CRUD.searchExecutingOnChange of key in the references. This issue is fixed, therefore if your code rely in this erroneus behaviour you will need to adapt it.

Setting value for references (in combos) with compose key in JUnit tests

Setting value for references (in combos) with compose key in JUnit tests must be done using POJOs, now the use of EJB2 primary key is not supported.
See documentation in Migration from OpenXava 1.2.1 to OpenXava 2 below.

Migration from OpenXava 2.0.1 to OpenXava 2.0.2

Action Collection.hiddenDetail has been renamed to Collection.hideDetail in controllers.xml. You have to rename the action inside your junit tests.

Migration from OpenXava 2.0 to OpenXava 2.0.1

No issues

Migration from OpenXava 1.2.1 to OpenXava 2

Setting value for references (in combos) with compose key in JUnit tests

So far, to set the value to a reference displayed as description-list (as combo), and mapped in database using multiple columns, you write:
DrivingLicenceKey key = new DrivingLicenceKey();
key.setType("C ");
key.setLevel(1);
setValue("drivingLicence.KEY", key.toString());
 
But, if you uses a pure POJOs version, without Key classes, you have to write:
DrivingLicence key = new DrivingLicence();
key.setType("C ");
key.setLevel(1);
setValue("drivingLicence.KEY", key.toString());
 
It's better to use the last way, because it's valid for POJOs and EJBs.

Hibernate: References with not null columns as foreign key

In EJB version if you have a reference to another entity that has primitive types as key, the code is generated in a way that no null is saved to database, even if you assign null to your reference.
In hibernate version if you assign null to the reference, null values are saved in database.
Of course, the behaviour of hibernate version is more correct, but you can in hibernate avoid null in database just using a converter in the reference mapping (see section 6.3 of Reference Guide).
That is, maybe you need to add some converters to your references in order to migrate your application from EJB2 to Hibernate.

Changing the active section

xava_activeSection is not longer used for changing the active section. Now if you want to change the active section you must to call to method setActiveSection of the desired view (org.openxava.view.View).

IAggragetOidCalculator

The setContainerKey method is renamed to setContainer. And its semantic changes too. Now the container object is received instead of the key. In this way this calculator is consistent in EJB2 and POJO (without key classes) versions.

Migration from OpenXava 1.2 to OpenXava 1.2.1

Hibernate generation

Now when the EJB code generation is done, the hibernate code generation is executed too (although the hibernate version still does not work at 100%).
Although you use only EJB version, you have to make this little adaptation in your project:
The hibernate.cfg.xml have to be:
<!DOCTYPE hibernate-configuration PUBLIC
   "-//Hibernate/Hibernate Configuration DTD//EN"
   "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
  <hibernate-configuration>
   <session-factory>
       <property name="hibernate.connection.datasource">@datasource.prefix@/@datasource@</property>
       <property name="hibernate.dialect">@hibernate.dialect@</property>
       <property name="hibernate.show_sql">false</property>
   </session-factory>
</hibernate-configuration>
In addition you have to include the hibernate.dialect property in your configuration files:
hibernate.dialect=org.hibernate.dialect.HSQLDialect

XML OpenXava syntax

Migration from OpenXava 1.1 to OpenXava 1.2

Generated code

Now EJB remote interface has the suffix Remote, and the business interface generated for each component (for example ICustomer) has no all methods of the remote interface.
This is for allowing to the future version 2 of OpenXava work with EJB and Hibernate in the same project and at same time.
In order to adapt you code to this, you must:
For correct syntax error you can change code in this way:
Customer customer = CustomerUtil.getHome().findByName("PEPE");
String name = customer.getName();
By this:
ICustomer customer = CustomerUtil.getHome().findByName("PEPE");
String name = customer.getName();
If you use specific EJB methods then you need cast to remote interface:
Customer customer = CustomerUtil.getHome().findByName("PEPE");
CustomerKey key = customer.getPrimaryKey();
By this:
CustomerRemote customer = CustomerUtil.getHome().findByName("PEPE");
CustomerKey key = customer.getPrimaryKey();
That is, change Customer by ICustomer when possible, if not possible change Customer by CustomerRemote.

JUnit tests

Others

Migration from OpenXava 1.0 to OpenXava 1.1

APIs

JUnit tests