Spring application fails to start with ActiveJDBC instrumented classes - java

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.

Related

Springboot hangs after removing logback-classic dependency

I am working with a SpringBoot project. Initially, when I am running the application I was getting the "multiple bindings" warning and no log files were getting created but the application started taking the log-back classic dependency and ignoring the slf4j-log4j12 artifact (Both are child dependencies of spring-boot-starter-logging which is in turn a child of spring-boot-starter). However, once I excluded the logback-classic artifact it has started to hang at the line INFO: Initializing Spring embedded WebApplicationContext and no log files are being generated. In this project I see that log4j is being used and the web.xml has been entirely commented out. Is the hanging of the application at startup related to any of the above actions or conditions?
Thanks in advance for the help. Please note that I am new to SpringBoot and nothing seems to work in this framework as mentioned in the docs so I am a bit frustrated as well. Any help will be really appreciated.

HtmlUnit - Unable to derive module descriptor for xalan-2.7.2.jar [duplicate]

I am getting this error message when I try to compile my new modularized Java 11 application:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for C:\Users\inter\.m2\repository\xalan\xalan\2.7.2\xalan-2.7.2.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class org.apache.bsf.BSFManager not in module
This appears to be an issue from a dependency of a dependency. I can't even find which module is pulling it in so I can update it.
I am using openjdk 11.0.2, IntelliJ 2018.3.4, Maven
Any advice how I can troubleshoot or fix this? I have found very little documentation on this issue.
Xalan
I had a look at their bug tracker following their index page and wasn't able to find this reported and not sure how actively is the library being maintained either.
General Explanation
Just to explain what has caused the issue in your code, I would share a screenshot and then try to add details around it.
So within the JAR that for version 2.7.2, there are service declarations (META-INF/services) which include org.apache.xalan.extensions.bsf.BSFManager as one of them. The service file here has to indicate the Provider thereby for itself and the class is supposed to be present on the modulepath to be resolved for reliable configuration of modules.
In this case for the module xalan(automatic module), the service listed doesn't have the provider class packaged within the dependency itself. (See the package org.apache, it doesn't further have package bsf and the class BSFManager thereby. Hence the exception as you get.
Short term hack
One of the tweaks to get that resolved would be to get update the library jar (patch it) and get rid of the service file if you're not using it. Or to add the provider copied from the corresponding artifact.
If you don't directly depend on this artifact or its parent dependencies, you can let those remain on the --classpath and get resolved as an unnamed module for your application.
Long term solve
An ideal way would be to report this to the maintainers and getting it resolved. It depends though on how actively are they maintaining it e.g. the last release for xalan was almost 5 years back, might just want to look for an actively participated alternative in my opinion.
I tried to install update for TestNG in eclipse:
"Help -> Check for updates -> deselect all and select TestNG check box. Then
install latest version i installed the version which starts with 7.2.0.
It fixed the issue for me.

Way to log/alert when Maven 'Dependency mediation' resolves to 'nearest definition' between multiple versions of artifact

I understand that Maven dependency mediation feature determines what version of a dependency will be used when multiple versions are encountered using the "nearest definition" mechanism (closest in the dependency tree). My question is if there is a way to make Maven alert/log it when it does this.
I found that when i was using spring boot & using the starter parent along with other dependencies one of my dependencies got resolved automatically but that caused things to fail at run time which took a while for me to figure out..so was wondering if there is a way to get alerted when Maven does this so i can take some action if needed (explicitly add a dependency, etc.)
Thanks
Muthu

Simple Spring REST service doesn't work

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.

spring-boot-devtools fails on JAR with missing MANIFEST.MF

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.

Categories