Error executing upon starting within unit tests

Hi All,

I have the following issue when unit tests are executed (with the default ones created using spring-boot-starter).

Here is the issue :
***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method camundaBpmRestInitializer in org.camunda.bpm.spring.boot.starter.rest.CamundaBpmRestJerseyAutoConfiguration required a bean of type 'org.springframework.boot.autoconfigure.web.servlet.JerseyApplicationPath' that could not be found.

The following candidates were found but could not be injected:
	- Bean method 'jerseyApplicationPath' in 'JerseyAutoConfiguration' not loaded because not a servlet web application


Action:

Consider revisiting the entries above or defining a bean of type 'org.springframework.boot.autoconfigure.web.servlet.JerseyApplicationPath' in your configuration.

StackTrace :

15:27:33.683 [main] ERROR o.s.test.context.TestContextManager - Caught exception while allowing TestExecutionListener [org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener@732f29af] to prepare test instance [ch.vaudoise.camunda.changeaddresses.ProcessScenarioTest@7d0333c8]
java.lang.IllegalStateException: Failed to load ApplicationContext
...
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'camundaBpmRestInitializer' defined in class path resource [org/camunda/bpm/spring/boot/starter/rest/CamundaBpmRestJerseyAutoConfiguration.class]: Unsatisfied dependency expressed through method 'camundaBpmRestInitializer' parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.springframework.boot.autoconfigure.web.servlet.JerseyApplicationPath' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:769)
...
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.springframework.boot.autoconfigure.web.servlet.JerseyApplicationPath' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

Any ideas ? Never had this issue before with other projects …

Thanks for your help !
Best,

Sébastien

I found a way to avoid the issue … but not why it is failing.
It is related to the camundaSpringBoot version :

  • with 3.3.1 : no issue
  • with 3.3.4 : exception described in previous post

Can you share your pom.xml file?

Which java, spring boot and camunda version are you using?

pom.xml (6.0 KB)

pom.xml added.

CamundaBpmRestInitializer bean has been introduced in 3.3.2 version which is why it was working fine before…

trying to set the value of undefined bean does not change anything. I tried to set in the application.yaml (the on within test ressources) this way :

spring:
    #main:
    #  allow-bean-definition-overriding: true
    jersey:
      application-path: /rest/changeaddresses

Properties in yaml file indentation is not correct I hope. It should be 2 spaces for each hierarchy.

spring:
  jersey:
    application-path: /rest/changeaddresses

Seems to be you’re using camunda ee version, so you can raise a support request.

Also remove camunda swagger extension camunda-bpm-swagger-json from pom , which would be incompatible with the latest versions

Not sure I can raise a SR.
This is an evaluation license, as we are strongly considering acquiring it, but no deal yet.

About yaml indentation, it was a copy/paste issue …

@sebrouss Did you remove the compile spring-boot-starter-web dependency? Try adding this dependency and let me know if any issues.

How does you springboot main application class and jersey config class looks like?

main yaml :

spring.datasource:
  url: jdbc:sqlserver://localhost:1433;databaseName=camunda
# initconfig url: jdbc:h2:./camunda-db;DB_CLOSE_DELAY=-1;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE
#shareable h2 database: jdbc:h2:./camunda-db;DB_CLOSE_DELAY=-1;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE;AUTO_SERVER=TRUE
  username: sa
  password: xxxx
camunda.bpm:
  admin-user:
    id: demo
    password: demo
    firstName: Demo
    lastName: Demo
  filter:
    create: All Tasks
  process-engine-name: changeaddresses
  database:
    schema-name: changeaddresses
    schema-update: false
    table-prefix: changeaddresses.
  job-execution:
    deployment-aware: true  
server.port: 8090

spring boot app:

@SpringBootApplication
@EnableProcessApplication("changeaddresses")
public class CamundaApplication {
  public static void main(String... args) {
    SpringApplication.run(CamundaApplication.class, args);
  }
}

this dependency is there (see screenshot attached :

)

Hi @sebrouss,

thanks for your message! Seems like there were some changes introduced into the Spring Boot Starter that causes this problem.

To make the test run again, it should be sufficient to remove the (webEnvironment = WebEnvironment.NONE) from your test.

When it comes to testing in Spring Boot environments, the best practice would be to choose one of the two following options:

  • run the test as a @SpringBootTest , but maybe not with the full application context (to speed up test execution time). This was the goal behind switching off the WebEnvironment initially - but this now breaks with the later version with the starter. So slicing the application context in a custom way would be recommended.

or

  • run a plain JUnit test without Spring Boot by using the ProcessEngineRule

I will try to have our archetypes adjusted in that regard soon.

3 Likes

Hi there,

We have the same issue with our integration tests.

We’re upgrading camunda to the latest, because we need to upgrade our application to Java 11 (using springboot 2.0.5.RELEASE currently).

The application fails with:
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.autoconfigure.web.servlet.JerseyApplicationPath

which was called from: CamundaBpmRestJerseyAutoConfiguration.

I have to use the workaround given from the poster, in which we use 3.3.1 instead before this got introduced. Can we please have this fixed?

Further investigation reveals that JerseyApplicationPath appears to only exist after Springboot 2.0.7.RELEASE tag.