I use logback as dependency in my project and get the following output:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:~/.gradle/caches/4.10/generated-gradle-jars/gradle-api-4.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:~/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.3/7c4f3c474fb2c041d8028740440937705ebb473a/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.gradle.internal.logging.slf4j.OutputEventListenerBackedLoggerContext]
I read a lot of similar questions and answers. Most of them advice to add corresponding exclude to extra dependency. But I can't imagine which of these are relevant to gradle-api-4.10.jar. Looking through dependency tree also yielded no result.
Related
I am trying to use fluent api implementation: https://www.slf4j.org/manual.html#fluent in a spring boot project with logstash-logback-encoder.
implementation ('org.springframework.boot:spring-boot-starter-web')
implementation('net.logstash.logback:logstash-logback-encoder:7.2')
I tried to add slf4j like this.
implementation('org.slf4j:slf4j-api:2.0.3')
Getting the following error:
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
SLF4J: Ignoring binding found at [jar:file:/home/prchowdh/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.7/3e89a85545181f1a3a9efc9516ca92658502505b/logback-classic-1.2.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
I understand, Spring has an internal dependency on logback and logback has a dependency on slf4j.
Any guidance will be helpful.
I am doing spring and hibernate integration example getting the below exception. Please advise me how to solve it.
log4j:WARN No appenders could be found for logger (org.springframework.beans.factory.xml.XmlBeanDefinitionReader).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'd' is defined
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:509)
at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1041)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:273)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:189)
at com.javatpoint.InsertTest.main(InsertTest.java:14)
You will have to share some code snippets before someone can actually help you here!
Looking at the exception it seems you have created a Class property "d" and marked it as #Autowired.
Spring is trying to find a class of type d or name d registered in its context.
You register a class by using #Service or #Component etc annotation.
Update:(after the OP's comment).
Please ensure you are creating d bean using below code in application context.
<bean id="d" class="com.javatpoint.EmployeeDao">
<property name="template" ref="template"></property>
</bean>
In most ClassLoaders
ClassLoader classLoader = Thread.currentThread().getContextClassLoader()
classLoader.getResources("");
will return an enumeration that includes directories that contain the class files as well as any jars on the class path. However when executing this code within a maven surefire execution the only items returned are the class and test-class directories. It seems to make no difference if I use the useSystemClassLoader or useManifestOnlyJar properties to adjust the class loader. In addition the class loader (as seen via an attached debugger) appears to have a number of jars attached.
To make things stranger, the debugger shows that the surefire class loader is an instance of the same type as when not running inside surefire.
Does anyone have any pointers for diagnosing the differences or ideas as to how to fix the problem?
Claude
I have a problem or possibly I found a bug in Spring Boot. I am not sure at the moment.
I have a project with the following dependencies
spring-boot-starter-thymeleaf
spring-boot-starter-web
spring-boot-starter-actuator
spring-boot-starter-mail
spring-cloud-starter-bus-amqp
spring-cloud-starter-config
spring-cloud-starter-eureka
I want to use a messageSource in my Thymeleaf templates and so I set the following in my application.yml:
spring:
messages:
basename: de/mycompany/messages/message
and placed a message.properties and a message_de.properties in the above package. But the replacing did not work.
So I debugged MessageSourceAutoConfiguration and found, that the #Conditional(ResourceBundleCondition.class) did work. It found my Resources and returned true.
So I let print the debug report and found, that it says
MessageSourceAutoConfiguration
- Bundle found for spring.messages.basename: de/mycompany/messages/message (MessageSourceAutoConfiguration.ResourceBundleCondition)
- #ConditionalOnMissingBean (types: org.springframework.context.MessageSource; SearchStrategy: all) found the following [messageSource] (OnBeanCondition)
So there is another messageSource Bean already defined, but i wondered where it did come from. So i investigated further and found the following log output:
AnnotationConfigEmbeddedWebApplicationContext : Unable to locate MessageSource with name 'messageSource': using default [org.springframework.context.support.DelegatingMessageSource#60df7989]
In fact it comes from the class AbstractApplicationContext in method initMessageSource (around line 622).
There it checks for a bean with name "messageSource" and if it doesn't find one, it creates the above mentioned DelegatingMessageSource.
Am I missing something? Do I have to do something to get the MessageSourceAutoConfiguration happen before this AbstractApplicationContext stuff? Or is this really a bug?
For myself I fixed it by simply creating the messageSource myself as a #Bean, but using the AutoConfiguration would be far smarter :)
Greetings Christian
Turns out this is a bug, hopefully it gets resolved soon, tracked here:
https://github.com/spring-cloud/spring-cloud-commons/issues/29
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.