Update dependency org.springframework.boot:spring-boot-starter-parent to v3.4.0

renovate[bot] commented 17 hours ago

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.springframework.boot:spring-boot-starter-parent (source)	`3.3.5` -> `3.4.0`

[!WARNING] Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

spring-projects/spring-boot (org.springframework.boot:spring-boot-starter-parent)

### [`v3.4.0`](https://redirect.github.com/spring-projects/spring-boot/compare/v3.3.6...v3.4.0) [Compare Source](https://redirect.github.com/spring-projects/spring-boot/compare/v3.3.6...v3.4.0) ### [`v3.3.6`](https://redirect.github.com/spring-projects/spring-boot/compare/v3.3.5...v3.3.6) [Compare Source](https://redirect.github.com/spring-projects/spring-boot/compare/v3.3.5...v3.3.6)

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

MasterEvarior commented 8 hours ago

Stand 22.11.24

Beim Upgrade zu 3.4.0 gibt es zwei Probleme, eines davon kann auf verschiedene Weisen gelöst werden. Für das Andere gibt es noch keine Lösung.

Security Filter Chain

Neu wird eine Exception geworfen wenn mehrere SecurityFilterChains erstellt werden, keine davon einen securityMatcher definiert. Dadurch wird jeweils nur die erste Chain angewandt, hier gibt es ein super Beispiel.

Das ist bei uns in der SecurityConfig der Fall und bis jetzt hab ich zwei funktionierende Lösungsvorschläge gefunden. Entweder kann man einfach einen securityMatcher für alles hinzufügen, was einen zum Status Quo zurückführt, einfach expliziter. Man kann auch das zweite Bean entfernen da es sowieso nie aufgerufen wird. Auch wird die setHeaders() Methode weiter oben schon aufgerufen.

    @Bean
    @Order(1) // Must be First order! Otherwise, unauthorized Requests are sent to Controllers
    public SecurityFilterChain apiSecurityFilterChain(HttpSecurity http, @Value("${connect.src}") String connectSrc)
            throws Exception {

        this.connectSrc = connectSrc;
        setHeaders(http);
        http.addFilterAfter(new ForwardFilter(), BasicAuthenticationFilter.class);
        logger.debug("*** apiSecurityFilterChain reached");
        return http
                .securityMatcher("/**") //Variant 1: add this 
                .cors(Customizer.withDefaults())
                .authorizeHttpRequests(e -> e.requestMatchers("/api/**").authenticated().anyRequest().permitAll())
                .exceptionHandling(e -> e.authenticationEntryPoint(new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED)))
                .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults())).build();
    }

    //Variant 2: remove this entire bean
    @Bean
    @Order(2)
    public SecurityFilterChain securityHeadersFilter(HttpSecurity http) throws Exception {
        logger.debug("*** SecurityHeader reached");
        return setHeaders(http).build();
    }

Hibernate Update

Zwischen 3.3.6 und 3.4.0 wurde hibernate-core von 6.5.0.Final zu 6.6.2.Final geupdated. Das führt zu Testfehlern in PersistenceBaseTestIT:

[ERROR]   PersistenceBaseTestIT.saveExistingEntityWithDifferentDataShouldUpdateExistingEntity:135 » ObjectOptimisticLockingFailure Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [ch.puzzle.okr.models.User#205]
[ERROR]   PersistenceBaseTestIT.saveShouldAddNewEntity:103 » ObjectOptimisticLockingFailure Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [ch.puzzle.okr.models.User#205]

Ein User wird Testweise erstellt und dann wieder gelöscht. Wird der User dann in einem weiteren Test wieder erstellt (save() ausgeführt) denkt Hibernate das es der gelöschte User von vorher ist und verweigert die Transaktion.

Das Caching des Context mit @DirtiesContext(classMethod = ClassMethod.AFTER_EACH_TEST_METHOD) zu konfigurieren hat keine Verbesserung gebracht. Ist auch keine Nachhaltige Lösung, da er Fehler in der deployeten Applikation immernoch vorkommen kann.

Ein Downgrade zur alten Version fixed die Tests wieder, ist aber keine wirkliche Lösung.

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.hibernate.orm</groupId>
                    <artifactId>hibernate-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.hibernate.orm</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>6.5.0.Final</version>
        </dependency>

Next Steps

Die nächsten Schritte sind die Changes zwischen den Hibernate Version zu analysieren und zu sehen ob ich etwas finde.

renovate[bot] commented 4 hours ago

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

puzzle / okr