On this page
- New Installation
- Updating Conversion and ADx
- Configuration Changes
- Known Issues
This is a patch release to ADx 2.2, fixing a critical repository access control problem where users could access all repositories (even repositories with access set to denied).
Complimentary to the above, we introduced new runtime properties related to the default configuration of repository access control. Please read about Configuration Changes for a detailed description of the new properties.
As a result of new access control implementation, only active repositories are visible in ADx landing page.
For information about the 2.2 release, please read ADx 2.2 Release Notes.
You can install this release from the provided package. Follow the Installation Instructions if you're installing from scratch.
For information on how to update the previously installed Conversion and ADx, see the following:
Note that this release includes configuration changes - please update your settings file accordingly if you want to re-use it.
This patch introduces new ADx runtime properties related to default repository access control.
In this release, new runtime properties related to repository access configuration are added to the installation settings file. These properties allow you to do the following:
- Set default access rights (grant or deny);
- Grant repository access to selected roles;
- Deny repository access from selected roles.
These properties are explained in the New Runtime Properties section. Please keep in mind that these properties affect only new repositories (created after these properties are set).
If you don't change the default settings, new ADx repositories will still be accessible to all users.
The following runtime properties are added in this release:
|ADX_DEFAULT_REPOSITORY_CONNECTIVITY_PERMISSION||Sets the "Connect Default" property in the Access Control Configuration. Possible values are GRANT (default) and DENY.||GRANT|
|ADX_DEFAULT_REPOSITORY_CONNECTIVITY_ROLES_GRANT||A comma-separated list of the roles that should automatically get CONNECT access granted (regardless of the current repository setting). For example: ||Empty list (no roles assigned)|
|ADX_DEFAULT_REPOSITORY_CONNECTIVITY_ROLES_DENY||A comma-separated list of the roles that should automatically get CONNECT access denied (regardless of the current repository setting). For example: ||Empty list (no roles assigned)|
The above properties only affect repositories created after the properties were set. In simple terms, the above properties work as follows:
|Repository Permission||User with role in ROLES_GRANT||User with role in ROLES_DENY||User with role not listed anywhere|
|GRANT||Can access repository||Cannot access repository||Can access repository|
|DENY||Can access repository||Cannot access repository||Cannot access repository|
If you want to check the full list of runtime properties available for ADx and Conversion, go to the Runtime Properties page.
Issues mentioned below have been reported in the previous releases - we are currently working on fixing them.
|AD-321||CRITICAL||Add missing indices|
|AD-354||CRITICAL||ADx Admin: Problem when synchronizing Type Definitions form DCTM/CMIS|
|AD-1096||MAJOR||Stopping ADx Tomcat process may take multiple minutes|
|AD-348||MAJOR||ADx Admin: Repository Modification-Status not updated on Update|
|AD-1204||MAJOR||Repository Filters Don't Return Any Results|
|AD-1222||MAJOR||It's necessary to activate a repository twice after changing settings|
|AD-342||MINOR||Hibernate warnings in the log files|
|AD-341||MINOR||Java warnings with Java 9 and later during startup|
|AD-311||MINOR||Oracle - DbLockManager prints Oracle constraint message|
Due to cache database being shared between repositories, it's not possible for now to run multiple migration jobs from a single legacy repository at the same time. You need to wait for the previous migration to finish before running a new one.
After starting newly installed ADx with Standard repository and trying use Open API, an error occurs:
This problem only occurs on clustered ADx installations. After restarting the ADx node, it should be gone (you can also switch to Swagger 2.0 which works in all situations).
|AD-338||CRITICAL||Introduce roles for conversion|
|AD-337||MAJOR||Make TF Conversion workbench consistent to ADx|
|AD-501||MAJOR||tf-conversion user has the admin role assigned|
|EXTDOCS-71||MINOR||Fix wrong encoding on opening resource in Browser|
The following error currently appears in ADx console output. It doesn't affect ADx functionality or performance.
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. Set system property 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2 internal initialization logging.
The following warning is sometimes thrown by Tomcat when stopping the service:
./tribefire-console-stop.sh ... Tomcat did not stop in time. PID file was not removed. To aid diagnostics a thread dump has been written to standard out. Tribefire Host stopped.
This happens when shutdown takes longer than Tomcat expects. Shutdown may take several minutes, which will result in this message being printed out. This warning could appear on both Conversion and ADx.
When using Java 9 or later, the following warning may appear in application logs and also during installation procedure:
WARNING: An illegal reflective access operation has occurred WARNING : Illegal reflective access by com.braintribe.model.processing.itw.asm.AsmClassLoaderWrapper$1 (file:/path/to/instant-type-weaving-1.0.28.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte,int,int) WARNING: Please consider reporting this to the maintainers of com.braintribe.model.processing.itw.asm.AsmClassLoaderWrapper$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release
The log files may contain Hibernate-related warnings. They can be identified based on the fully qualified class which starts with
org.hibernate, as in:
WARNING org.hibernate.tuple.entity.EntityMetamodel 'HHH000084: Entity [com.braintribe.model.user.User] is abstract-class/interface explicitly mapped as non-abstract; be sure to supply entity-names' [TribefireServices-2.0:tribefire-services#initialize,ApplicationLoader:/tribefire-services#initialize]
These warnings do not affect the functionality of the application and can be ignored. We are working on a fix.