Problem z beanami (nulle)

Problem z beanami (nulle)
SA
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 2 lata
  • Postów:94
0

Mam taką klasę configuracyjną z beanami:

Kopiuj
@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:

Kopiuj
@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.

edytowany 8x, ostatnio: Riddle
ZD
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad rok
  • Postów:2310
0

@Sampeteq:

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


If you put a million monkeys at a million keyboards, one of them will eventually write a Java program - the rest of them will write Perl
ZD
Gdyby było tak, jak przeczuwam, to wstrzykiwanie leży i kwiczy
Grzyboo
To jest cywilizowany sposób na używanie springa, jak najmniej adnotacji porozrzucanych po appce, zamiast tego konkretne konfiguracje beanów.
piotrpo
W połączeniu z @Configuration dostarcza konkretny typ bean'a.
R1
  • Rejestracja:ponad 5 lat
  • Ostatnio:około miesiąc
  • Postów:23
0

Brakuje adnotacji @Configuration w UserConfig

edytowany 1x, ostatnio: rad1317
SA
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 2 lata
  • Postów:94
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.

Grzyboo
  • Rejestracja:ponad 9 lat
  • Ostatnio:5 miesięcy
  • Postów:206
0

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

ZD
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad rok
  • Postów:2310
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 ?


If you put a million monkeys at a million keyboards, one of them will eventually write a Java program - the rest of them will write Perl
edytowany 1x, ostatnio: ZrobieDobrze
ZD
@KamilAdam: czyli jednak problem się zauważa ("jak najmniej adnotacji") :) tyle że lekarstwo jest wymyślone przez nałogowego narkomana
ZD
"Przestać pić na trzy dni? Dobry pomysł, trzeba to oblać" (Chandler)
KamilAdam
Ooo. Fajnie że jestem tu wołany. Czyżbym został forumowym hejterem adnotacji?
KamilAdam
BTW Java dąży do morskiej adnotacji, a w Haskellu i Scali niektórzy dążą do boskiej monady która obsługuje wszystko. Monada App. Trochę odpowiednik adnotacji App XD
RequiredNickname
  • Rejestracja:prawie 5 lat
  • Ostatnio:2 minuty
  • Postów:621
0

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

SA
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 2 lata
  • Postów:94
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ć...

VD
  • Rejestracja:ponad 10 lat
  • Ostatnio:10 miesięcy
  • Postów:72
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 :)

R1
  • Rejestracja:ponad 5 lat
  • Ostatnio:około miesiąc
  • Postów:23
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.

VD
Dlaczego negujesz bez sprawdzenia? Nie masz racji, a wprowadzasz innych w błąd. Podesłałem nawet wyżej link, najpierw może tam wejdź
R1
Nie neguję bez sprawdzania, bazuję na swoim doświadczeniu. Dokumentacja z twojego linku zresztą to potwierdza, więc to raczej ty wprowadzasz kogoś w błąd: Thanks to meta-annotations support, classes annotated with @Configuration, @Controller, @RestController, @Service or @Repository are automatically opened since these annotations are meta-annotated with @Component
VD
Ale to w przypadku korzystania z plugina all-open, który sam "otwiera" klasy. Więc muszą być open, czy to zrobisz sam czy z pomocą plugina to już bez znaczenia
R1
w momencie jak ktoś korzysta z spring boota plugin ten jest domyślnie dołączany, więc nie ma sensu pisać open class, samo class wystarczy, liczy się kod źródłowy, sztuczki kompilatora są bez znaczenia.
VD
Tak czy inaczej klasy muszą być open. Nie wiemy czy kolega korzysta z plugina, bo nie powiedział, a samo używanie spring boota nie oznacza dołączenia plugina. "sztuczki kompilatora są bez znaczenia" - myślę, że jeszcze nie raz niemiło się zaskoczysz :D

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.