1. 15 Dec, 2020 1 commit
    • Baptiste Mesta's avatar
      fix(classloader): fix refresh of process classloader after BDM update (#1677) · f0f40d00
      Baptiste Mesta authored
      When the user installs a new BDM, even if there are not many changes, the tenant classloader is updated.
      That update replaces the `BonitaClassLoader` linked to the `VirtualClassLoader` of the tenant. All children
      process `VirtualClassLoader`s are notified of that update causing a clearing of them e.g. groovy classloader cache.
      In that case, using classes of the parent tenant from a child process classloader is possible, and it will use the new version of the class.
      
      The issue is that when one of the class of the tenant classloader is loaded in the child process classloader using `Class.forName()`, that version of the class
      is kept even if the classloader has changed.
      
      This is the cause of the issue mentioned above.
      
      Right now classloaders work like that:
      
      ```
        _____________________________
       |     Webapp classloader     |
       ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
                  ↑                        
        _____________________________      ____________________________
       | Global Virtual classloader |  →  | Global Bonita classloader |
       ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔      ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
                  ↑                    
        _____________________________      ____________________________
       | Tenant Virtual classloader |  →  | Tenant Bonita classloader |
       ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔      ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
                  ↑                    
        ______________________________      ____________________________
       | Process Virtual classloader |  →  | Process Bonita classloader |
       ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔      ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
      
      ```
      * Virtual classloaders delegate calls to Bonita classloaders (horizontal arrows)
      * When no Bonita classloader is linked. the virtual classloader delegates its calls to its parent virtual classloader (other arrows)
      
      Fix that by invalidating children classloader on refresh.
      See ADR for impacts.
      
      Closes [BS-17167](https://bonitasoft.atlassian.net/browse/BS-17167)
      Closes [BR-610](https://bonitasoft.atlassian.net/browse/BR-610)
      f0f40d00
  2. 08 Dec, 2020 2 commits
  3. 07 Dec, 2020 1 commit
  4. 02 Dec, 2020 1 commit
  5. 30 Nov, 2020 1 commit
  6. 27 Nov, 2020 2 commits
  7. 23 Nov, 2020 3 commits
    • Baptiste Mesta's avatar
    • Emmanuel Duchastenier's avatar
      chore(recovery): various minor fixes (#1873) · b9d85ba6
      Emmanuel Duchastenier authored
      * change default recovery mechanism triggering each 2 hours
      * add javadoc to explain responsibilities of recovery service and elements
      * renamed method triggerRecoveryAllElements() to triggerRecoveryOfAllElements()
      b9d85ba6
    • Emmanuel Duchastenier's avatar
      fix(BDM): fix BDM generation when using sequences (#1862) · 50ebbe99
      Emmanuel Duchastenier authored
      Considering https://stackoverflow.com/questions/39861098/replace-sequencegenerator-since-its-deprecated
      when using database sequences (h2, oracle, postgreSQL), we now generate the following code:
      
      ```
      @GeneratedValue(generator = "default_bonita_seq_generator")
      @GenericGenerator(
      name = "default_bonita_seq_generator",
      strategy = "org.hibernate.id.enhanced.SequenceStyleGenerator",
      parameters = {
         @Parameter(name = "sequence_name", value = "hibernate_sequence")
      }
      ```
      
      to ensure we do not use "default" values but rather explicit values for sequence generation.
      It also removes a deprecation warning.
      
      = Context =
      In 7.11, 7.10 and earlier versions, Bonita generated for IDs, the following code:
      ```java
      @Id
      @GeneratedValue (which implied "strategy=auto")
      ```
      In 7.12, Bonita generates the following code for H2, Postgres and Oracle:
      ```java
      @Id
      @GeneratedValue(generator = "default_bonita_seq_generator")
      @GenericGenerator(
           name = "default_bonita_seq_generator",
           strategy = "org.hibernate.id.enhanced.SequenceStyleGenerator",
           parameters = {
               @Parameter(name = "sequence_name", value = "hibernate_sequence")
           })
      ```
      
      In 7.12, Bonita generates the following code for MySQL and SQL Server:
      ```java
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      ```
      The only problem is when using Hibernate 5 with no strategy specified (defaults to AUTO) AND when parameter `hibernate.id.new_generator_mappings=true` (new default value in Hibernate 5)
      
      For BDM generated with Bonita 7.12+, the strategy is always specified, so there is no "default" behaviour that does not fit our needs.
      For BDM generated with Bonita in any version before 7.12, and migrating to 7.12+, the BDM is **not** regenerated, so we would face the problem of Hibernate changing its default behaviour, for MySQL and SQL Server, **unless we let the `hibernate.id.new_generator_mappings ` property set to FALSE** (which is the case from 7.11.3).
      
      I checked the migration from 7.11.3 to 7.12.0, the BDM **is** functional. The same would happen for a migration path 7.10.x => 7.12+
      However, Hibernate 5 echoes the following warning:
      `WARN |o.h.o.deprecation| HHH90000014: Found use of deprecated [org.hibernate.id.SequenceGenerator] sequence-based id generator; use org.hibernate.id.enhanced.SequenceStyleGenerator instead.  See Hibernate Domain Model Mapping Guide for details.`
      which is not a great problem, and that will disappear after next BDM generation.
      
      Closes [BR-554](https://bonitasoft.atlassian.net/browse/BR-554)
      50ebbe99
  8. 20 Nov, 2020 5 commits
  9. 19 Nov, 2020 2 commits
  10. 18 Nov, 2020 3 commits
  11. 17 Nov, 2020 4 commits
  12. 16 Nov, 2020 6 commits
  13. 13 Nov, 2020 4 commits
  14. 12 Nov, 2020 3 commits
  15. 10 Nov, 2020 1 commit
    • Baptiste Mesta's avatar
      chore(build): start only once the database container (#1847) · f45bb98d
      Baptiste Mesta authored
      When running multiple tests suites on a specific database, run the docker container of that database only once. It is removed when all tests are finished. (failed of not)
      
      This is done using:
      * Single tasks are created in root project
      * `startContainer` is finalized by the remove task using `finalizedBy`
      * remove of the container run after the database test task using `mustRunAfter`
      * inspect task is still done in the current project and not the root because the properties used that contains the url is used by other task of the project
      f45bb98d
  16. 09 Nov, 2020 1 commit