Utworzyłem prosty test jednostkowy, ale IntelliJ niepoprawnie wyróżnia go na czerwono. oznaczając to jako błąd
Nie ma fasoli?
Jak widać poniżej przeszedł test? Więc to musi być Autowired?
Utworzyłem prosty test jednostkowy, ale IntelliJ niepoprawnie wyróżnia go na czerwono. oznaczając to jako błąd
Nie ma fasoli?
Jak widać poniżej przeszedł test? Więc to musi być Autowired?
Odpowiedzi:
Miałem ten sam problem podczas tworzenia aplikacji Spring Boot przy użyciu ich @SpringBootApplication
adnotacji. Adnotacja to oznacza @Configuration
, @EnableAutoConfiguration
i @ComponentScan
zgodnie z odniesieniem sprężyny .
Zgodnie z oczekiwaniami nowa adnotacja działała poprawnie, a moja aplikacja działała płynnie, ale Intellij wciąż narzekał na niespełnione @Autowire
zależności. Jak tylko zmieniłem z powrotem do używania @Configuration
, @EnableAutoConfiguration
a @ComponentScan
osobno, błędy przestały. Wygląda na to, że Intellij 14.0.3 (i najprawdopodobniej również wcześniejsze wersje) nie jest jeszcze skonfigurowany do rozpoznawania @SpringBootApplication
adnotacji.
Na razie, jeśli błędy tak bardzo Ci przeszkadzają, wróć do tych trzech oddzielnych adnotacji. W przeciwnym razie zignoruj Intellij ... Twoje rozwiązywanie zależności jest poprawnie skonfigurowane, ponieważ test kończy się pomyślnie.
Zawsze pamiętaj...
Człowiek jest zawsze większy niż maszyna.
@SpringBootApplication
otrzymywałem ten błąd. Postępowałem zgodnie z radą @ Jaõs Matos, używając scanBasePackages
parametru do @SpringBootApplication
i określając pakiet / przestrzenie nazw, które powinny być skanowane.
Dodaj adnotację Spring @Repository
do klasy repozytorium.
Wiem, że powinno działać bez tej adnotacji. Ale jeśli to dodasz, IntelliJ nie pokaże błędu.
@Repository
public interface YourRepository ...
...
Jeśli używasz Spring Data z rozszerzającą Repository
klasą, będą to konfliktowe strony. Następnie należy wskazać strony explicity.
import org.springframework.data.repository.Repository;
...
@org.springframework.stereotype.Repository
public interface YourRepository extends Repository<YourClass, Long> {
...
}
Następnie możesz automatycznie przypisać swoje repozytorium bez błędów.
@Autowired
YourRepository yourRepository;
Prawdopodobnie nie jest to dobre rozwiązanie (chyba dwukrotnie próbujesz zarejestrować repozytorium). Ale pracuj dla mnie i nie pokazuj błędów.
Może w nowej wersji IntelliJ da się naprawić: https://youtrack.jetbrains.com/issue/IDEA-137023
Moja wersja IntelliJ IDEA Ultimate (2016.3.4 Build 163) wydaje się to obsługiwać. Rzecz w tym, że musisz mieć włączoną wtyczkę Spring Data.
Czasami wymagane jest wskazanie, gdzie @ComponentScan ma skanować w poszukiwaniu składników. Możesz to zrobić przekazując pakiety jako parametr tej adnotacji, np .:
@ComponentScan(basePackages={"path.to.my.components","path.to.my.othercomponents"})
Jednak, jak już wspomniano, adnotacja @SpringBootApplication zastępuje @ComponentScan, stąd w takich przypadkach należy zrobić to samo:
@SpringBootApplication(scanBasePackages={"path.to.my.components","path.to.my.othercomponents"})
Przynajmniej w moim przypadku Intellij przestał narzekać.
@SpringBootApplication(scanBasePackages={"com.a.b, com.a.c"})
i chociaż aplikacja działała dobrze, intellijowi się to nie podobało. Zmiana na @SpringBootApplication(scanBasePackages={"com.a.b", "com.a.c"})
naprawioną dla mnie!
Zawsze rozwiązuję ten problem, wykonując następujące czynności ... Ustawienia> Inspekcje> Spring Core> Code, aby przejść od błędu do ostrzeżenia o opcji ważności
Używam spring-boot 2.0 i intellij 2018.1.1 ultimate edition i napotkałem ten sam problem.
Rozwiązałem przez umieszczenie @EnableAutoConfiguration w głównej klasie aplikacji
@SpringBootApplication
@EnableAutoConfiguration
class App{
/**/
}
Redundant declaration: @SpringBootApplication already applies @EnableAutoConfiguration
¯ \ _ (ツ) _ / ¯
Umieszczanie @Component
lub @configuration
w pliku konfiguracyjnym bean wydaje się działać, np. Coś takiego:
@Configuration
public class MyApplicationContext {
@Bean
public DirectoryScanner scanner() {
return new WatchServiceDirectoryScanner("/tmp/myDir");
}
}
@Component
public class MyApplicationContext {
@Bean
public DirectoryScanner scanner() {
return new WatchServiceDirectoryScanner("/tmp/myDir");
}
}
Jeśli nie chcesz wprowadzać żadnych zmian w kodzie tylko po to, aby Twoje IDE było szczęśliwe. Rozwiązałem to, dodając wszystkie komponenty do aspektu Spring.
Tak długo, jak testy przechodzą, jesteś dobry, naciśnij, najeżdżając alt + enter
kursorem na błąd i wewnątrz podmenu pierwszej pozycji, którą znajdziesz, Disable Inspection
wybierz to
Miałem podobny problem w aplikacji Spring Boot. Aplikacja wykorzystuje Feign (syntetyzowanie przez klienta HTTP żądań z interfejsów z adnotacjami). Mając interfejs SomeClient
z adnotacją @FeignClient
, Feign generuje klasę proxy środowiska wykonawczego implementującą ten interfejs. Kiedy jakiś komponent Spring próbuje automatycznie podłączyć ziarno typu SomeClient
, Idea narzeka, że nie SomeClient
znaleziono fasoli typu, ponieważ w projekcie nie ma prawdziwej klasy, a Idea nie jest nauczona rozumieć@FeignClient
adnotacji w żaden sposób.
Rozwiązanie: dodaj adnotacje do interfejsu SomeClient
z @Component
. (W naszym przypadku nie używamy @FeignClient
adnotacji SomeClient
bezpośrednio, raczej używamy metaannotacji, @OurProjectFeignClient
która jest opatrzona adnotacjami, @FeignClient
a dodanie @Component
do niej adnotacji również działa).
@Component
do interfejsu rozwiązuje problem. Ale myślę, że to nie jest właściwa droga ... Moim zdaniem to błąd w IntelliJ IDEA lub żeby nie być tak trudnym IntelliJ IDEA nie jest gotowy na nowsze wersje Feign. Działa bez wcześniejszych @Component
wersji pozorowanych (gdzie @FeignClient
adnotacja była org.springframework.cloud.netflix.feign
zamiast org.springframework.cloud.openfeign
- może to jest przyczyna problemu?). Czy znalazłeś jakieś dalsze szczegóły (może bilet błędu) na ten temat?
@Component
) pochodzi @FeignClient
z org.springframework.cloud.netflix.feign
paczki.
I ostatnia ważna informacja - dodaj ją, ComponentScan
aby aplikacja wiedziała o rzeczach, które musi wykonać. Nie ma to znaczenia w przypadku tego pytania. Jeśli jednak w ogóle nie @autowiring
jest wykonywany, prawdopodobnie jest to Twoje rozwiązanie.
@Configuration
@ComponentScan(basePackages = {
"some_package",
})
public class someService {
Musisz tylko dodać
@ComponentScan("package/include/your/annotation/component")
w AppConfiguration.java
.
Ponieważ myślę, że Twój AppConfiguraion.java
pakiet jest głębszy niż pakiet składnika adnotacji (@Service, @Component ...),
takie jak "package/include/your/annotation/component/deeper/config"
.
Miałem podobny problem w swojej aplikacji. Po dodaniu adnotacji zniknęły nieprawidłowe wyróżnienia.
@ContextConfiguration(classes = {...})
Używam tej adnotacji, aby ukryć ten błąd, gdy pojawia się w IntelliJ v.14:
@SuppressWarnings("SpringJavaAutowiringInspection")
@SuppressWarnings("SpringJavaInjectionPointsAutowiringInspection")
Dla mnie rozwiązaniem było umieszczenie @EnableAutoConfiguration
w klasie Application pod @SpringBootApplication
jej podkreśleniem, ponieważ jest zbędne. Usuń go i voila, wszystkie ostrzeżenia dotyczące brakujących fasoli zniknęły! Głupia wiosna ...
Moim rozwiązaniem tego problemu w mojej aplikacji do rozruchu wiosennego było otwarcie kontekstu aplikacji sprężynowej i ręczne dodanie klasy dla brakującej fasoli autowired!
(dostęp przez menu Project Structure lub okno narzędzi sprężynowych ... edytuj "Spring Application Context")
Więc zamiast SpringApplicationContext zawierającego tylko moją konfigurację sprężyny ExampleApplication zawiera ona również brakującą Bean:
SpringApplicationContext:
et voilà: Komunikat o błędzie zniknął!
Wydaje się, że nadal jest to błąd w najnowszym IntelliJu i ma to związek z możliwym problemem z pamięcią podręczną?
Jeśli dodasz wspomnianą powyżej adnotację @Repository jako mk321, zapisz, a następnie usuń adnotację i zapisz ponownie, to rozwiązuje problem.
Po prostu musiałem użyć @EnableAutoConfiguration, aby go rozwiązać, jednak ten błąd nie miał wpływu na funkcjonalność.
Można to rozwiązać umieszczając @EnableAutoConfiguration w głównej klasie aplikacji rozruchowej Spring.
Czasami - to znaczy w moim przypadku - przyczyną jest zły import. Przypadkowo zaimportowałem
import org.jvnet.hk2.annotations.Service
zamiast
import org.springframework.stereotype.Service
ślepo akceptując pierwszy wybór w sugerowanych importach Idea. Zajęło mi to kilka minut za pierwszym razem :-)
Co zaskakujące, projekt zorientowany na Feign, który z powodzeniem działał z Eclipse, nie mógł działać w InteliJ. Po uruchomieniu aplikacji InteliJ narzekał na klienta Feign, którego próbowałem wstrzyknąć do warstwy serviceImpl, mówiąc: pole personRestClient (mój klient Feign) w ... wymagało fasoli typu ... którego nie można było znaleźć. Rozważ zdefiniowanie fasoli typu „....” w swojej konfiguracji.
Marnowałem dużo czasu, próbując zrozumieć, co jest nie tak. Znalazłem rozwiązanie (dla InteliJ), którego nie do końca rozumiem:
Lub wybierz Eclipse :)
Użyj @AutoConfigureMockMvc dla klasy testowej.
proste, musisz zrobić 2 kroki
==>> change @Autowired to @Resource
IntelliJ IDEA Ultimate
Dodaj swoją główną klasę do kontekstu aplikacji IntelliJ Spring, na przykład Application.java
File
-> Project Structure..
lewa strona: Ustawienia projektu -> Moduły
prawa strona: znajdź w strukturze swojego pakietu
Spring
i dodaj+
Application.java