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:
- TABLE now is TABLE_NAME
- DATE now is ACCESS_DATE
- TIME now is ACCESS_TIME
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
- wtpBuild ant target is dropped from OX; you can use 'rebuild' ant target instead. Calling automatically to an ant target from Eclipse Builder is slow, therefore maybe you prefer to call manually to 'rebuild' ant target on demmand (when the XML code of your OX application is changed).
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:
- The user interface application will display clear fields instead of 0, when the form is reset
- In junit test maybe you receive a blank when before it was a 0
- If you use View.getValue() for a Number it can be null
API changes
- Dates.clonWithoutTime() is renamed to Dates.cloneWithoutTime()
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:
- Create the folder hibernate in your project.
- Create the file hibernate.cfg.xml inside hibernate folder.
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
- In spanish versión PEQUEÑA now is PEQUENA. This is for avoid problems with ISO-8859-1 versus UTF-8.
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:
- Delete all generated code
- Regenerate all EJB code
- Build all
- Search and correct all syntax error
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
- On deleting an object in a CRUD OpenXava now shows a javascript windows to confirm, instead of changing to another controller. Hence in your tests in order to remove an object from CRUD module you only need use execute("CRUD.delete"). In this case 'yes' is assumed as confirmation answer.
Others
- Change the name of packages-ejb.properties in gen-src-xava to packages.properties (or you can simply remove packages-ejb.properties and regenerate code).
Migration from OpenXava 1.0 to OpenXava 1.1
APIs
- MetaView.getMetaViewCollection now is MetaView.getMetaCollectionView
- MetaView.getMetaViewReference now is MetaView.getMetaReferenceView
JUnit tests
- Message 'Object deleted successfully' is change by '{0} deleted successfully'. Hence it's required to change the asserts of this messages.