Problem z beanami (nulle)

0

Mam taką klasę configuracyjną z beanami:

@Configuration
class UserConfig {

    @Bean
    fun userFacade(
        userRepository: UserRepository,
        passwordEncoder: PasswordEncoder
    
    ): UserFacade = UserFacade(
            userRepository,
            passwordEncoder,
            UserFactory(passwordEncoder, userRepository)
        )


    @Bean
    fun passwordEncoder(): PasswordEncoder  = BCryptPasswordEncoder()
}

Przykładowy test:

@SpringBootTest
@Transactional
class UserIT {

    @Autowired
    private lateinit var userFacade: UserFacade

    @Test
    fun should_register_user() {
        val registeredUser = userFacade.registerUser(
            RegisterUserDTO("user1", "12345")
        )
        assertThat(
            userFacade.readUserByUsername(registeredUser.username)
        ).isEqualTo(registeredUser)
    }
}

Problem w tym, że w trakcie wykonywania testu (sprawdziłem debuggerem) wszystkie zależności tej fasady są nullami. Jeśli zamiast tej klasy z beanami użyje @Service nad UserFacade to wszystko działa.

Aktualizacja:
Dokładnie to UserFactory jest nullem, nie wiedząc czemu.

0

@Sampeteq:

Adnotacja @Bean nad metodą ? Niby co by miała znaczyć?
ja tam wielki spirngowy nie jestem, ale to mnie razi.

0

Brakuje adnotacji @Configuration w UserConfig

0
ZrobieDobrze napisał(a):

@Sampeteq:

Adnotacja @Bean nad metodą ? Niby co by miała znaczyć?
ja tam wielki spirngowy nie jestem, ale to mnie razi.

To znaczy, że ta metoda zwraca beana i jest to jak najbardziej ok jeśli robi się bardziej ręczne DI.

rad1317 napisał(a):

Brakuje adnotacji @Configuration w UserConfig

Nie, po prostu źle kod przekleiłem. To nie to.

0

Nie wiem, w obecnej formie to się nawet nie skompiluje, bo masz za dużo zamykających nawiasów klamrowych

1

To jest cywilizowany sposób na używanie springa, jak najmniej adnotacji porozrzucanych po appce, zamiast tego konkretne konfiguracje beanów. — Grzyboo dziś, 01:34

To może zgłoszę dla Spirtngowców
Jedna adnotacja dana gdziekolwiek @MakeMeGood

Kiedy to się stało takie chore ?

0

A to podstawowa składania deklaracji funkcji się zmieniła? 0_o
https://kotlinlang.org/docs/basic-syntax.html#program-entry-point

0

Znalazłem takie rozwiązanie, że pola w klasie muszą być open np. UserFacade(open val userRepository: UserRepository), ale wtedy nie mogą być private, nie wiem czemu. Chyba nie do końca tak to powinno wyglądać...

0

Klasy @Configuration muszą być open, zerknij tutaj: https://kotlinlang.org/docs/all-open-plugin.html. Parametry konstruktora nie muszą.
Przy wstawaniu kontekstu Springa w logach powinna być informacja dlaczego nie udało się stworzyć beana, mozesz podrzucić

Fajnie, że w ten sposób konfigurujesz beany :)

0

Klasy @Configuration nie muszą być open. Możliwe, że coś nie tak jest jeszcze skonfigurowane w projekcie, ale bez całego kodu ciężko stwierdzić, w czym może być problem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1