<camel:camelContext id="myCamelContext">
<camel:routeBuilder ref="route"/>
</camel:camelContext>
I try to parse the bean above in Intellij IDEA ("Parse custom bean"), but get the following error:
Cannot find custom handler for namespace 'http://camel.apache.org/schema/spring'
The IDE also displays an error for any corresponding #Autowired annotations in my test code, although the tests run successfully. The application works at runtime, and I have camel-spring as a maven dependency. It only has problems in the IDE.
The camel-spring maven dependency was at "runtime" scope. While technically this is correct, this made it unavailable to Intellij when coding. Changing the maven scope to "compile" enabled Intellij to use the the camel spring bean handler for interpreting the bean.
Related
So I have I built a custom Springboot starter and autoconfiguration and everything builds fine, the code is all their in the local maven repo.
I even checked the generated jars and everything looksgood.
Can't load the generated files into the project but when I look at the generated beens, there is no sign of beans created by autoconfiguration (or the autoconfiguration itself) : https://github.com/orubel/spring-boot-starter-beapi/issues/37
Project code can be sen here: https://github.com/orubel/spring-boot-starter-beapi/blob/main/beapi-lib/build.gradle
what am I doing wrong that implementations can';t see the beans?
I have tried bringing in the dependencies from mavenLocal() with:
implementation "io.beapi:beapi-lib:0.4"
implementation "io.beapi:beapi-spring-boot-starter:0.4"
and with:
implementation "io.beapi:beapi-lib:0.4"
implementation "io.beapi:beapi-spring-boot-autoconfigure:0.4"
Both have the same error of stating that an AUTOWIRED bean (from the autoconfiguration) cannot be found:
Consider defining a bean of type 'io.beapi.lib.service.PrincipleService' in your configuration.
If I comment out the autowired bean, it just throws error that bean is null.
Ok solved my issue.
As I am instantiating the beans from a library I am creating through the starter, I have to do a '#ComponentScan' on those classes.
So just adding:
#ComponentScan(["io.beapi.lib.service"])
To the application main class was enough to resolve this :)
I'm using Spring Batch Admin to launch batches from a batch module of my main project.
The batch module compile as a JAR addedstrong text in the dependency of the Spring Batch Admin project as follow:
<dependency>
<groupId>company.project</groupId>
<artifactId>project-batch</artifactId>
<version>1.10.0-SNAPSHOT</version>
</dependency>
Since I added "#StepScope" on one of my reader classes, I get the following error when deploying Spring Batch Admin
Could not generate CGLIB subclass of class [class com.sun.proxy.$Proxy71]: Common causes of this problem include using a final class or a non-visible class; nested exception is java.lang.IllegalArgumentException: Cannot subclass final class class com.sun.proxy.$Proxy71
I had the same error when running my unit test on the batch module (without Spring Batch Admin) but I resolved it using the following bean declaration in my test configuration:
<bean class="org.springframework.batch.core.scope.StepScope">
<property name="autoProxy" value="false" />
</bean>
But I don't find how to use similar declaration to prevent the error in the Spring Batch Admin project.
I tried to add the bean into a configuration on the module side or on the SBA project side but nothing seems to work.
As far as I can see this error not caused by SBA. This is usual attempt of spring to proxify your bean. Please check your class annotated with #StepScope and remove final from class definition and public method definitions.
when using #EnableCircuitBreaker annotation with spring-cloud-services-dependencies 1.3.0 we are getting
"Caused by: java.lang.NoSuchMethodError:
org.springframework.integration.amqp.support.DefaultAmqpHeaderMapper.outboundMapper()Lorg/springframework/integration/amqp/support/DefaultAmqpHeaderMapper;"
exception. We are not using any Messaging functionality in our
service.
We are using jetty embedded environment.
Can anyone suggest me how can I solve my issue?
The exception is thrown, cause your application tries to use some classes of spring integration for message queue, which cannot be found.
If you go further up the stacktrace you may find some classes with 'AutoConfiguration' that may show, which spring auto configuration has triggered the search for these missing classes.
You can also add the command line parameter --debug to see what auto config is actually doing.
Once you identified the culprit you can exclude it from the auto configuration like this :
#EnableAutoConfiguration(exclude = {...})
TeamCity seems not to recognize Spring Data Repository beans when running the inspections. It works perfectly in IntelliJ IDEA but not in TeamCity.
I receive the following inspection problems:
Warning This custom Spring bean has not yet been parsed And it points to this XML element:
<jpa:repositories base-package="my.base.package" />
And then (obviously) an Error: Could not autowire. No beans of 'MyRepository' type found.
MyRepository extends the Spring Data CrudRepository interface.
As far as I understand, TeamCity launches an IntelliJ instance when running the inspections. Do I have to specify in some way which plugins (Spring Data) IntelliJ has to use when it's running the inspections?
I also tried multiple times to hit the check/reparse button in TeamCity...
Thanks for your help!
By default, autowiring happens by propertyname. It seems if I compile my application with the WAS 6.1 JDK, spring cannot autowire my dependencies by name and then instead reverts to type which is causing an issue because of some ambiguous Validator references in my controllers. The controller properties are all of type Validator and there are 9 validators defined in the context file so spring complains that it finds too many matches. I know one way around this would be to use the actual implementation class as the type for the validator instances in my controller classes, but I want to know if anyone else has encountered this problem with autowiring by name failing when compiled with the WAS 6.1 jdk.