For some reason Intellij 13.1.3 doesn't detect the spring boot beans. Spring boot version is 1.1.1-Release. When i try to inject ObjectMapper in some component i get an error in the IDE "No bean of type ObjectMapper defined", however the application compiles and runs just fine and the ObjectMapper beans is visible in the /beans json.
I have added my application-context and my Application.java files to a spring facet and the IDE recognizes all my other beans that I manually defined, it just ignores the ones that come with Spring boot #EnableAutoConfiguration. Any idea how to solve that since its kinda tedious not to have the correct linking in the IDE and get errors all over the place. I would assume thats a common issue?
Thanks!
As an update for this answer: IntelliJ now supports Spring Boot. Must be at least R14. R15 is including some more integration.
Spring Boot is not supported yet, please watch http://youtrack.jetbrains.com/issue/IDEA-119230
Related
We have a Spring Boot App packaged as a war file and deployed on Wildfly. When I update the Spring Boot version from 2.5.6 to 2.6.2, I see lots of exception with Spring Autowire of variables. The problems being reported are circular dependency.
Has something changes with new version of Spring that changes how the autowiring works? I tried to research and can find no mention to changes in that area.
Thanks
The thing is that with the new Spring Boot version, circular dependencies are not allowed by default. Check the release notes.
You can get back to the previous behaviour setting the following configuration:
spring.main.allow-circular-references: true
However, I would suggest you revisit the application design.
I am in the middle of setting up a Spring Boot application in IntelliJ idea. I was reading about IntelliJ's Spring Boot support and I'm supposed to be able to see a green run icon in the gutter of my #RestController next to my #RequestMapping. The application is working fine and I can even see the mapping in the Run tab under Mappings. I was wondering what I'm missing?
I've created a project using Spring Initializr to show the problem. The issue is reproducible in the DemoController and the project is available on Github
It doesn't work because of the known IntelliJ IDEA bug specific to Spring Boot 2.2.x versions.
In custom Spring Boot Autoconfiguration projects I usually have some dependencies which are marked as optional. As I need them for compilation, but expect users of my autoconfig to include them manually in their own POM, or they will be provided by the Spring Boot dependencies.
How do I ensure that users of different Spring Boot versions can use my autoconfig without dependecy/version problems?
I see two non-optimal solutions; are there more?
Hoping that the API stays the same
Just hope that the API of my dependencies stays stable over minor version changes, so that if I developed and compiled my Autoconfig e.g. with Spring Boot 1.4.x, the API which I used is still the same with 1.5.x, etc.
I then wouldn't necessarily expect it to work e.g. for Spring Boot 2.x, and would put a corresponding note into the readme.
Explicitly tracking each Spring Boot version
Explicitly build a version for at least each minor Spring Boot version, but possibly even for each Patch version? Who knows when a breaking API change could happen. I would then need to document for which exact Spring Boot version my autoconfig is intended. But this is a lot of work.
Of course Spring Boot's own autoconfig project is developed in lockstep with Spring Boot, so that any problems will be fixed in the same release.
But my own autoconfig might have been developed once and not expect many changes afterwards. How do I ensure that my autoconfig keeps working as long as possible even as the "users" of my autoconfig are updating their Spring Boot version dependencies?
I am trying to port an existing Spring application across to Spring Boot. I am NOT using the spring-boot-starter-data-solr starter however I have apache solrj (5.0.0) on my classpath.
During startup the app blows up. It seems that spring boot sees the solr classes and assumes that I also have spring-boot-starter-data-solr on the classpath. In particular I get this error:
java.lang.IllegalArgumentException: #ConditionalOnMissingBean
annotations must specify at least one bean (type, name or annotation)
If I drop the solrj dependency and use spring-boot-starter-data-solr instead it is ok. However I don't need the spring-data-solr integration and doing so will force me to backport our app to the 4.7.x release of solr.
Is anyone aware of a workaround for this?
So it seems the problem was caused by spring boot's dependency on solrj 4.7.x whereas I am using 5.0.0
I fixed it by using
#SpringBootApplication(exclude = {SolrAutoConfiguration.class})
To tell boot to ignore the SolrAutoConfiguration completely.
I am working on an application using Spring 3 and Hibernate 3.5 with Java 1.6.
So far I've been using JBoss 4.2.1 and everything was fine.
Now while migrating to JBoss 5.1, I encountered lot of issues. One of them is that JBoss is ignoring the Spring #Resource annotation. I get the following exception:
java.lang.RuntimeException: mapped-name is required for serviceManager of deployment pol-1.0.war
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlResourceEnvRefs(WebResourceHandler.java:287)
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(WebResourceHandler.java:325)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:550)
at org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:158)
It expects mapped-name for each #Resource like some ejb.
I've seen similar questions but they are without any answer e.g.:
#Resource annotation not working properly with JBoss5.0.1
Please advise.
Adi
Actually your problem is that JBoss doesn't ignore #Resource annotations - it tries to handle them according to EJB rules instead of leaving them to Spring.
Perhaps this feature can be disabled somewhere in JBoss configuration, but the simpliest solution would be to replace #Resource with #Autowired or #Inject.
Sounds like java annotations need namespace support.
Then it would be #Spring:Resource or #EJB:Resource.
Oracle, are you listening?
Short of namespace for Annotations, you could possibly try changing the order of the libraries in your classpath so java would see the Spring annotations first (or last), whichever ends up providing the desired outcome.