Soffid upgrades are managed using the same mechanisms as addon upgrades.
The data upgrade process is performed in three steps:
1. The console is upgraded using soffid installer.
2. On console boot, the data schema is updated. To perform the schema update, a Soffid developed schema updater is used. This schema updater will read the core-ddl.xml and any plugin-ddl.xml file to upgrade at once the core Soffid database objects as well as any addon database object.
3. The application bootstrap process is executed. At this step, any spring bean implementing ApplicationBootService will be invoked. This been is responsible for completing data upgrade. Addons can also define a bean implementing ApplicationBootService for this purpose.
The new Soffid version could have new service beans. The addons should use a prefix in order to avoid name collisions. So, as long as exists a "accountService" bean, there could by any "addon-accountService" bean. This prefix should be used for any service bean or DAO bean.
It's possible to have name collisions on hibernate entity beans. In order to avoid it, the hibernate mapping files should always set the auto-import clause to "false".
Addons cannot replace any Soffid user interface component. In order to customize or modify user interface, addon contains XSL transformation files that are applied onto existing user interface components. This mechanisms guarantees that many addons can introduce changes on the same user interface component, and it also assures that user interface upgrades will proceed smoothly.