Projects:Upgrade Weld/Specs
![]() | Back to Projects:Upgrade_Weld |
Contents |
Goal
Weld is the implementation of CDI: Contexts and Dependency Injection for the Java EE Platform used in Openbravo.
The main objective of this project is to upgrade the Weld library from current 1.1.24 version to the newer 3.1.0.
Functional Requirements
This project will not add new functional features, the changes involved within this project should be transparent in terms of the functional behavior of the application.
Technical Specs
CDI
Weld version 1.1.24 is an implementation of CDI 1.1 (JSR-346). With this project we are upgrading to CDI 2.0 (JSR-365) with the upgrade of Weld to the latest available version, 3.1.0.
Assignability Rules
CDI 2.0 defines under which circumstances the assignability of raw and parameterized types works within an injection point. This is specified with a set of rules defined here.
Weld version 1.1.24 was not adhering to these rules and thus it allowed to define some injection points which are no longer valid using Weld 3.1.0.
This change affects to some parts of the existing code which are making use of dependency injection. See the QA-Test Plan section for further details.
Weld Library Management
For upgrading Weld, the standard library upgrade process must be applied.
Apart from replacing the old libraries with the new ones, this upgrade implies some other changes regarding library management:
- guava-18.jar: it is not directly required by Weld, but we are keeping it in core by moving it inside the main lib/runtime folder as some features of this library are being used in other parts of the application, like here. Note that the testing infrastructure required also to upgrade this library. See the Test Infrastructure section for more details.
- slf4j-ext-1.7.25.jar: Weld no longer uses slf4j for logging. Instead, jboss-logging is now used as its logging facade. Moving also this library to lib/runtime in order to avoid breaking code that could be still using slf4j for logging.
- jboss-logging-3.2.1.Final.jar: Weld requires version 3.2.1 of this library. We are not explicitly adding it as version 3.3.2 is already present in core (it was introduced with the Hibernate upgrade).
- javax.annotation-api-1.2.jar: This library contains exactly the same classes as weld's dependency jboss-annotations-api_1.3_spec-1.0.0.Final.jar, but in a least recent version. For example, the @Priority annotation is allowed in parameters in jboss-annotations-api_1.3_spec-1.0.0.Final but not in javax.annotation-api-1.2. For this reason we are removing javax.annotation-api-1.2 library from core.
More information about the Weld library upgrade process can be found here.
Web Containers
It must be ensured that after the upgrade the application continues working in all the supported web containers.
In this sense, it is important to note that Wildfly requires to exclude the Weld libraries from the deployment. This is because Weld is part of the core WildFly's infrastructure as it implements Java EE 7 specifications. If the Weld libraries included in Openbravo are deployed in WildFly, there are clashes (due to different versions) that prevent the server to boot the application. The existing mechanism to exclude these libraries when deploying Openbravo in Wildfly must continue working.
Test Infrastructure
Openbravo uses arquillian to support CDI within jUnit test cases. The arquillian libraries will also be updated to the latest version available (1.4.1).
This new version requires:
- Upgrade jUnit. Upgraded from version 4.11 to version 4.12.
- Upgrade Guava to version 20.0 at least. It will be indeed upgraded to version 21.0 which is the latest that does not define mandatory dependencies with additional libraries.
- Upgrade arquillian suite extension library. This library is required until this arquillian issue is fixed. It prevents high memory usage problems when running Weld base tests.
Weld Development Mode
After the upgrade, it would be possible to enable the Weld Development Mode which is an special mode that provides several built-in tools suitable for development and testing purposes. By default this mode will be disabled. It should never be used in productive environments because it may have a negative impact on performance.
The Weld Probe is one of these Development Mode tools. Although this tool is included in a separate library which is a dependency of weld-servlet, it is an optional tool.
For this reason we are not going to include the Probe library in core but in a module that contains several Weld testing/development features. This module can be used to enable automatically the Development Mode and because of the mentioned reasons, this module should only be installed in development environments.