Edit: I've been told by my lead that the test that called the class I was having issues with utilized BPMS and that BPMS is no longer used for the project. Thank you for all of the replies.
Background:
I'm working with an existing codebase, which still isn't fully functional. Specifically, I've been tasked with getting the project's unit tests completed, but I've had no previous experience with Spring or dependency managers at all.
Problem:
The code given below is causing my tests to not compile, saying there's no qualifying bean of ProducerTemplate.
#Component
public class QueueService {
#Produce
private ProducerTemplate producerTemplate;
public QueueService(ProducerTemplate producerTemplate) {
this.producerTemplate = producerTemplate;
}
}
I'm sorry if this is a dumb question, but I haven't been able to find another instance of this in a question.
Stack Trace
Spring Boot component provides auto-configuration for Apache Camel. For integration using Apache Camel you must add a starter dependency:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
<version>2.22.1</version>
</dependency>
See here for more info. A tutorial on the subject.
Related
I'm trying to ensure that one Spring Boot Starter is loaded before another. In this case, I have a custom spring boot starter written by my organization and the spring-boot-starter-data-jpa starter. It's crucial that the custom starter's bean is ran before spring-boot-starter-data-jpa is initialized. An example snippet of the dependencies in pom.xml:
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>spring-boot-starter-my-customer-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
</dependencies>
How would one go about this? The solution I'm currently considering is adding a #Primary annotation to the top of the bean initialized in my company's custom starter, not sure if this would work and looking for best practice here. The bean I'm attempting to load in the custom starter before spring-boot-starter-jpa's beans are loaded is responsible for setting proxy settings, therefore must be loaded first so that traffic to the database can be routed via proxy.
Not really sure as to what you are trying to achieve here, but a way of controlling bean creation could be done using the DependsOn annotation.
In you case, since you would like to initialize your custom bean before the actual database connection is made, I think that adding this to your database configuration class should be enough.
When I start to learn the spring-webflux, I have the question about this component.
I built a simple project, using maven to manage it. I addded the dependencies related to spring-boot-starter-web and spring-boot-starter-webflux, like :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
But it doesn't work. When removing the spring-boot-starter-web dependency, it can work well.
As explained in the Spring Boot reference documentation section about the web environment, adding both web and webflux starters will configure a Spring MVC web application.
This is behaving like that, because many existing Spring Boot web applications (using MVC) will depend on the webflux starter to use the WebClient. Spring MVC partially support reactive return types, so this is an expected use case. The opposite isn't really true, since a reactive application is not really likely to use Spring MVC bits.
So using both web and webflux starters is supported, but it will configure a Spring MVC application. You can always force the Spring Boot application to be reactive with:
SpringApplication.setWebApplicationType(WebApplicationType.REACTIVE)
But it's still a good idea to clean up dependencies as it would be easy to use a blocking feature in your reactive web application.
I had a similar issue using spring-boot-starter-webflux and spring-data-geode causing
DEBUG [http-nio-8082-exec-2] org.sprin.web.servl.resou.ResourceHttpRequestHandler 454 handleRequest: Resource not found
It was resolved by changing the application type
#SpringBootApplication
public class Web {
public static void main(String[] args) {
SpringApplication app = new SpringApplication(Web.class);
app.setWebApplicationType(WebApplicationType.REACTIVE);
SpringApplication.run(Web.class, args);
}
}
The whole class looks like this
After setting the application type, if I don't then call the SpringApplication in a static way, I get this:
I need in my spring boot application FF4j. I try
<dependency>
<groupId>org.ff4j</groupId>
<artifactId>ff4j-spring-boot-starter</artifactId>
<version>1.8</version>
</dependency>
and in this case my application is broken because of swagger.
can I exclude org.ff4j.spring.boot.web.api.config.SwaggerConfig from my configuration?
I tried to manage it but cant reach final solution because of new different issues.
In case you configure swagger in your application in usual case it will be failed because of different reasons. Possible next ones:
spring needs resolve which swagger bean should be used;
cg-lib conflict in case you used bean name api;
swagger conflict because two different Docket beans in same spring context;
Firstly I tried to exclude ff4j-spring auto configuration configuring steps in similar way but excluding swagger for example. Application can't start ff4j without their swagger. That's confused a lot.
Looking different solutions I tried follow some recommendations like but I'm getting different issue with missed class for my application. Missed class is in thymeleaf5. I can't use thymeleaf5 because of it uses same name interface but different arguments. Additional workarounds make my application failed because of hibernate.
Swagger solution is:
in your configuration inject swagger Docket from ff4j:
#Autowired
Docket api;
and rewrite api with your configuration in #PostConstruct block. This solution is not elegant, but provides fix for swagger configs.
#PostConstruct
public void reconfigureSwagger() {
api....
}
P.S.
After swagger issue I've got more unresolved elements (but that's will be a different questions).
P.S.2.
FF4j library provides great UI and ideas and this is general reason why I do not avoid of its headache.
I am trying to mock the final class which is available in our company's internal library using Mockito 2.18.3 framework, unfortunately we don't have access to change the code in the library. But whenever I run I get below error:
java.lang.NoClassDefFoundError: Could not initialize class org.mockito.Mockito
at org.springframework.boot.test.mock.mockito.MockReset.get(MockReset.java:107)
at org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener.resetMocks(ResetMocksTestExecutionListener.java:69)
at org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener.resetMocks(ResetMocksTestExecutionListener.java:55)
at org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener.afterTestMethod(ResetMocksTestExecutionListener.java:50)
at org.springframework.test.context.TestContextManager.afterTestMethod(TestContextManager.java:319)
This is my dependency:
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.18.3</version>
<scope>test</scope>
</dependency>
This is the test class:
#RunWith(SpringRunner.class)
#TestPropertySource("classpath:application-test.properties")
#SpringBootTest
public class JwtTokenTest {
#Autowired
private class JwtValidatorService jwtValidatorService;
#Mock
private JwtTokenDetails jwtTokenDetails;
#Test
public void jwtGenerateTest() {
//Code to test JWT generation
}
}
Also as per this link: https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2#unmockable I have created org.mockito.plugins.MockMaker file with contents: mock-maker-inline.
I tried searching in other Stackoverflow posts and Google, but still not solution. Can anyone kindly help me in this? Looks like I am missing something, but failed to identify it. Since I don't have much expertise in Mockito, tried to use powermock but it is posing different challenges in downloading dependencies in company's network.
Please let me know if I need to add more code or more details.
Spring Boot 1.5.11 is compatible with Mockito 1.x. Specifically, it uses 1.10.19. Rather than overriding the version of Mockito to a new major version, you should let Spring Boot's dependency management specify the version. Doing so will ensure that you use a compatible version. If Mockito 1.10 doesn't meet your needs, you'll need to find an alternative solution.
Spring Boot uses Mockito 1.x by default. However, it's possible to override it with Mockito 2.x, as Spring Boot can also use it without any problems (see this commit).
To do so, just add this modification to your POM file properties:
<properties>
<mockito.version>2.18.3</mockito.version>
</properties>
I'm trying to upgrade a system that's using Spring 3.2 and Jersey from Jersey version 1.17 to Jersey version 2.4. I'm running into an annoying problem with #Autowired where Jersey basically complains it cannot find the bean for a given (generic) type.
We have a base class (BaseService<T>) for database-backed services that provides a basic CRUD-style interface (get, save, delete). We also have a base class for the REST resources that looks similar to this:
public abstract class BaseResource<S extends BaseService<T>>
{
protected S service;
// ... common functions used by BaseService descendants ...
#Autowired
public void setBaseService(S baseService)
{
this.service = baseService;
}
}
And then we have a number of concrete classes that inherit from BaseResource, provide their unique logic, etc. Under Jersey 1.17 this works fine.
After upgrading my environment to Jersey 2.4 and including the jersey-spring3 project, I get different behavior. During service startup I can verify that the setBaseService() routine gets called by Spring and the supplied parameter is not null. However when a client makes a call and an actual REST resource is executed, Jersey logs the following warning
org.glassfish.jersey.server.spring.AutowiredInjectResolver getBeanFromSpringContext
WARNING: No beans found. Resolution failed for type S.
This actually results in Jersey passing a null parameter to the setBaseService() routine, which of course causes NPEs. Now I can work around the null parameter with a check, but I'd like to know why Jersey is having this problem and how I can avoid it.
Interesting fact is that I have another REST resource that does not inherit from BaseResource but does contain its own #Autowired setService() routine. This one works perfectly fine; it gets called correctly by Spring at startup and correctly by Jersey with a non-null parameter upon each call. It's just the generic-based setter that has the problem.
Anyone have any ideas? Thanks.
Please try the following.
Add the following dependency: jersey-spring3
The above allows Spring DI support into JAX-RS classes with spring xml.
If you are using Maven, add the following into your pom.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>`
<artifactId>jersey-spring3</artifactId>`
<version>2.4.1</version>
<scope>runtime</scope>
</dependency>
See https://jersey.java.net/documentation/latest/spring.html