How to fix exception: Failed to instantiate SLF4J LoggerFactory? - java

I am trying to write a java web crawler for semantic web using jena library. I have build project using Netbeans. I am receiving two errors:
Failed to instantiate SLF4J LoggerFactory
Reported exception:
java.lang.NoClassDefFoundError: org/apache/log4j/Level
Could not initialize class com.hp.hpl.jena.rdf.model.impl.ModelCom
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128)
I have included slf4j-api and slf4j-log both libraries.

You should also include log4j library as slf4j-log4j is just a static binder.

You should include slf4j-api-x.x.x.jar and slf4j-simple-x.x.x.jar in your classpath.

As error suggested:
Failed to instantiate SLF4J LoggerFactory
you need to place your corresponding slf4j-*-*.jar binding files into your classpath folder.
You can locate them by locate slf4j if present.
As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests.
Tomcat
If using Tomcat, these files you can copy either into /usr/share/tomcat7/lib or your webapp folder /var/lib/tomcat7/webapps/*/WEB-INF/lib.
Solr
If you're using Solr or you want use the files from there (which are included by default), you can find them in dist/solrj-lib and example/lib/ext.
See: The Simple Logging Facade for Java (SLF4J) user manual

I tried all permutation and combination but finally slf4j-api- and slf4j-simple- worked well.

Related

how to fix and execute this sample Hibernate program for create table

I have a simple hibernate program in java. It is throwing an exception and I can't understand.
My code is :
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.tool.hbm2ddl.SchemaExport;
public class TestEmployee {
public static void main(String[] args) {
AnnotationConfiguration config = new AnnotationConfiguration();
config.addAnnotatedClass(Employee.class);
config.configure("hibernate.cfg.xml");
new SchemaExport(config).create(true, true);
}
}
The error is :
SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding.
SLF4J: Your binding is version 1.5.5 or earlier.
SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.impl.StaticLoggerBinder.getSingleton()Lorg/slf4j/impl/StaticLoggerBinder;
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:197)
at com.Hibernate.chapter1.TestEmployee.main(TestEmployee.java:10)**
Note : There is a line on AnnotationConfiguration() in my eclipse.
What is the cause and How do I fix it?
The reason for your problem is given clearly with the error
SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding.
SLF4J: Your binding is version 1.5.5 or earlier.
SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x
An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j.
Mixing mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.12.jar, then you should also use slf4j-simple-1.7.12.jar, using slf4j-simple-1.5.5.jar will not work.
From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine.
To make hibernate work you would have added hibernate related jar files to your project. It includes jars whose names start with "slf4j". To fix the error you need to make sure all slf4j jars are of same version.ie ( if you are using slf4j-api-1.7.12.jar, then you should also use slf4j-simple-1.7.12.jar, using slf4j-simple-1.5.5.jar will not work. )
Updating all your slf4j jars to latest version should fix this or you could check all slf4j jars and replace the offending one.
The link to download the slf4j is below
http://www.slf4j.org/download.html
More about the error and jar can be found at
http://www.slf4j.org/codes.html

java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class pat

Can anyone tell me the difference between slf4j-log4j and log4j-over-slf4j? Which is more standard to use in a Java web application? I currently have both on the classpath and that is causing a runtime exception as the web server is trying to prevent a StackOverFlowException from happening.
Exception:
java.lang.IllegalStateException:
Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path
slf4j-log4j is using log4j as an implementation of slf4j.
log4j-over-slf4j causes calls to the log4j API to be 'routed' to slf4j.
You cannot use both of these JAR's at the same time.
Both are valid libraries to use and are equally 'standard', it depends on the project.
In general, if your project is using log4j already and you don't have the ability to update all of your log4j Loggers to slf4j Loggers; log4j-over-slf4j is a quick fix to be able to start using slf4j immediately.
However, if your project is new or does not have an existing logging mechanism and you choose to use slf4j, slf4j-log4j would be the way to go as it is just specifying slf4j should be bound to log4j.
That being said, I agree with c12's comment. Stop using log4j and instead use slf4j and logback.
in my project , org.slf4j.impl.Log4jLoggerFactory is in
activemq-all-5.7.0.jar
not in slf4j-log4j12.jar
the exception message mislead me

Using Coda Hale Yammer Metrics library in Websphere Application Server 7

I am trying to add metrics library to existing webservice on WAS 7. I am getting below error
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [AdminServlet]: com.yammer.metrics.reporting.AdminServlet was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime class path SRVE0234I
What are the other run-time dependencies required for metrics-servlet-2.2.0?
I have metrics-core-2.2.0.jar and metrics-servlet-2.2.0.jar in my WEB-INF\lib folder.
Threads, ping and healthcheck servlets work fine.
I think your missing some more required jars, are you not using maven or gradle for dependency management
Please refer here to know all required jars that metrics-servlet-2.2.0.jar depends on. http://mvnrepository.com/artifact/com.yammer.metrics/metrics-servlets/3.0.0-BETA1
My suggestion is, it is always difficult to maintain dependencies without Maven/Gradle or any other build tools :).

NoSuchProviderException: smtp with log4j SMTP appender

I am using log4j to send an email when there is an exception. below is my log4j properties file configuration.
log4j.rootLogger=WARN, R, email
log4j.appender.R=org.apache.log4j.ConsoleAppender
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d{HH:mm:ss} %-5p [%c{1}]: %m%n
log4j.appender.email=org.apache.log4j.net.SMTPAppender
log4j.appender.email.BufferSize=10
log4j.appender.email.SMTPHost=myhost.com
log4j.appender.email.From=abc#some.com
log4j.appender.email.To=abc#some.com
log4j.appender.email.Subject=Error
log4j.appender.email.layout=org.apache.log4j.PatternLayout
mine is maven project i have added dependencies for mail.jar, activation.jar and smtp.jar. But on application server startup itself i get below error:
[ERROR] log4j:ERROR Error occured while sending e-mail notification.
[ERROR] javax.mail.NoSuchProviderException: smtp
[ERROR] at javax.mail.Session.getService(Session.java:782)
[ERROR] at javax.mail.Session.getTransport(Session.java:708)
[ERROR] at javax.mail.Session.getTransport(Session.java:651)
[ERROR] at javax.mail.Session.getTransport(Session.java:631)
[ERROR] at javax.mail.Session.getTransport(Session.java:686)
[ERROR] at javax.mail.Transport.send0(Transport.java:166)
Am i missing any thing here? What is the root cause of the error? is it because of incorrect SMTP host name? or is it because of any missing/conflicting dependencies?
You don't need smtp.jar and mail.jar - everything in smtp.jar is also in mail.jar. Get rid of smtp.jar, although I doubt that will solve your problem.
Also, make sure you don't have any other jar files with JavaMail classes in your classpath, such as javaee.jar or j2ee.jar.
This is most likely a classpath problem of some sort. JavaMail uses the class loader to find the configuration file that configures the providers such as "smtp". If the class loader handles resource lookups incorrectly, this problem can occur.
Upgrade your JavaMail to 1.5.3 which contains the fix for Bug 6668 -skip unusable Store and Transport classes. From the bug report:
In complex class loading situations, it can be possible for there to be
multiple copies of the JavaMail classes. A Store or Transport defined
by one copy may be loaded by another copy, but it won't be usable because
they're in different ClassLoaders. In this case, JavaMail should skip
over the unusable class and try to load the class from another ClassLoader.
This can happen, for example, in GlassFish if the application includes the
JavaMail classes, the application class loader is configured to prefer
application classes over system classes, and the app server itself tries
to use JavaMail when running in the context of the application.
You can download the latest snapshot and official releases from the JavaMail reference implementation home page.
You probably want to export smtp.jar to be usable by your webapp.

removing commons-logging and using slf4j causes errors in spring

Specifically, I use spring only for configuring my project through ApplicationContext. In my spring xml I load some bean properties through PropertyPlaceholderConfigurer. Whenever in the dependencies I swap commons-logging-x.x with jcl-slf4j.jar the loading of the context fails with ClassNotFoundExceptions on the placeholder substitutions. Example:
In my spring.xml there is:
<bean id="testbean" class="${testbean.implementingClass}"/>
where testbean.implementingClass is defined in spring.properties:
testbean.implementingClass=my.implementation.TestClass
If I run the project using commons-logging jar all works perfectly. If I change it to jcl-slf4j then I get ClassNotFoundException that the class [${testbean.implementingClass}] was not found, i.e. it does not do the placeholder substituion. Has anyone observed this?
EDIT: My problem doesnt have to do with the jars because:
From http://www.slf4j.org/legacy.html :
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL but without the class loader headaches plaguing JCL. The underlying logging framework can be any of the frameworks supported by SLF4J. Often times, replacing commons-logging.jar with jcl-over-slf4j.jar will immediately and permanently solve class loader issues related to commons logging.
When you use jcl-slf4j, you have to make sure you have excluded all commons-logging dependencies from your project. Make sure there is no commons-logging jar anywhere in the classpath.

Categories

Resources