I am trying out Spring Boot to create a simple MongoDB REST service, but for the life of me cannot figure out why it is so resistant to start. I had these dependencies compiling at runtime with Gradle
compile('org.mongodb:bson:3.3.0')
compile 'org.mongodb:mongodb-driver:3.3.0'
compile('org.springframework.boot:spring-boot-starter-data-mongodb')
compile('springframework:spring-web:1.2.6')
And the app was exiting early with some cryptic message:
Closing org.springframework.context.annotation.AnnotationConfigApplicationContext
So then I tried to add some more dependencies to see if that would help...god, I had dependencies:
compile("org.springframework.boot:spring-boot-starter-web")
compile("org.springframework.boot:spring-boot-starter-tomcat")
And that resulted in an even more cryptic message:
java.lang.NoSuchMethodError: org.springframework.web.context.support.ServletContextAwareProcessor: method <init>()V not found
I feel like this process is unceccessarily complex to start such a simple service...I have done this with Express, Revel, and Django very simply, but Spring Boot just doesn't seem to make it easy. What am I missing about this process?
Thanks!
Remove
compile('springframework:spring-web:1.2.6')
from your Gradle file. This artifact is ages old. The Spring Boot dependencies bring in all necessary Spring dependencies, so it is usually not necessary, to specify Spring dependencies itself.
Related
I'm using Java Spring as backend and Angular as frontend.
I have a system test for the Frontend that requires that the backend has already started.
In gradle I already have a npm-task that starts the frontend tests.
How can I configure gradle or which plugin do you recommend for starting the backend before that test-task and stopping it after it has finished?
I found the gretty-plugin, but I don't manage to make it work.
V4 of the plugin depends on JDK11 (I use JDK8) and all older major version throw an error in gradle like "Cannot change dependencies of dependency configuration". I judge the plugin to be not well maintained and documented.
I'm not sure if this is the best place to post such a question, but here it is. I'm a test automation engineer that works primarily with backend, spring boot command line apps. My tests, at a high level, are designed to ensure that any type of data that is thrown at the app will be handled correctly. We are a Java shop.
As with any "good" testing practice, I am treating the app like a blackbox, in that I do not pull in the model objects to run my tests. I simply supply the app with data, execute a command line type script (run.sh) that takes my data and processes it. My tests are comprised mostly of JDBC (to interact with the database) and a slew of ArrayList utilities that I have put together to sort out result sets and get specific db information.
Thus far, I have been deploying my tests as a JAR. I bundle everything up and deploy it to the environment with a script that will execute the tests. The tests do not run when the app is run. Though they do live inside of the project, they are a separate entity with separate launcher classes. However, I am finding that managing dependencies in a JAR is a real headache. Is there a better way to deploy automation / integration tests for command line apps?
I'm pulling in maven shade plugin to bundle all of my dependencies into a "God JAR", but that isn't helping me to resolve the issues that occur when I attempt to execute the JAR. I get multiple bean instantiation errors, relating to the app itself, and not my tests. For this reason, I pull in the app model, and the app itself as dependencies. When I ran the tests in my initial testing, they worked just fine. Deployed to environment and they continued to work correctly. Fast forward a couple of months, a few changes made to the app, and now it's a dependency nightmare when I build the new JAR.
TLDR: I'm having trouble managing dependencies in a maven project, integration tests JAR. Is there a better way to deploy automation / integration tests for command line apps where dependency management is easier?
(Note: I'm relatively new to this world, so pardon me if the question seems a bit vague).
I think the error happens when you use the shade plugin to re-package the spring boot jar. The way spring boot works is to add dependencies into the jar as jars itself and configure its own class loader (in the meta config) that is capable of reading classes from jar files inside the jar file. The standard java class loader does not do this - thats probably why the shade plugin misses out some jars (probably the ones embedded in the spring boot uber jar).
what I would try is to create a test-version of the spring boot app that contains the test-classes in the compile scope and a dependency to the original spring boot jar (you don't need the uber jar - therefore you may have to add a classifier to the original (app) spring boot plugin config to have that jar still available as it is replaced by default) and use the spring boot plugin to package the test version of it (using the dependency and its classifier above you used for the original app).
I am using Java 8, ActiveJDBC 1.4.13 and Spring Boot 2.0.0.RC1 with Spring 5.
On application startup I am getting this error:
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: FooActiveModel.class;
This problem appeared when I upgraded from Spring Boot 2.0.0.M7 to 2.0.0.RC1.
I have found a few references to this error but no mention of ActiveJDBC. In my case classes extended from the activejdbc.Model class (instrumented classes) are causing the problem.
As per answers and suggestions in these...
SPRING4: Failed to read candidate component class CouchbaseConfig.class
Server fails to start, Spring throws BeanDefinitionParsingException
BeanDefinitionStoreException Failed to read candidate component class
ArrayOutOfBoundsException on Bean creation while using Java 8 constructs
I have...
made sure I'm using Java 8
searched for conflicting dependencies
cleaned and rebuilt my project
deleted local maven repo that "might" have been corrupted
re-imported all the dependencies
upgraded all dependencies to their latest version
These options did not help.
Finally managed to solve this problem by excluding the problematic classes(the ones extended from activejdbc.Model that were being instrumented) from the spring component scan.
To make sure that this was actually the reason for the error, I even reverted to my original pom.xml with all my previous dependency versions, re-imported everything, cleaned, rebuilt and sure enough I'm no longer having this issue.
This was an extremely frustrating and time consuming problem, hope it helps somebody.
I am trying to execute spring jdbc program,but at the time running the application getting exceptions like
"Exception in thread "main" java.lang.NoSuchMethodError:
org.springframework.core.convert.converter.ConverterRegistry.addConverter(Ljava/lang/Class;Ljava/lang/Class;Lorg/springframework/core/convert/converter/Converter;)V"
How to resolve this issue? I added below jar.
spring-core-3.1.0.RELEASE
spring-core-3.0.3.RELEASE
spring-context-4.1.6.RELEASE
spring.beans-3.1.1
Ensure that all your spring dependencies are the same version. In your case, you are mixing core 3.1.0 and 3.0.3 with context 4.1.6 and beans 3.1.1. Keep them consistent. If you want to use the highest version in your dependencies then make all of them 4.1.6.RELEASE.
Perhaps you should also consider using spring-io-platform to get a managed set of dependencies with versions that will not conflict. This can be found at http://platform.spring.io/platform/
I have simple Spring Boot application using 1.4.0.M2 which works fine. When I add spring-boot-devtools to the mix the application refuses to start:
Exception in thread "main" java.lang.NullPointerException
at org.springframework.boot.devtools.restart.ChangeableUrls.…
getUrlsFromClassPathAttribute(ChangeableUrls.java:121)
The culprit is javax.inject:javax.inject:1 which does not contain a MANIFEST.MF. Of course one might argue that it’s a faulty JAR, but unfortunately it’s quite a common one. It looks like a bug in Spring Boot to me to react this way.
How can I circumvent this behaviour short of not using javax.inject?
This issue has been fixed on master and will be available in Spring Boot 1.4.0.M3.