Eclipse, Selenium, Windows
The import org.apache.log4j cannot be resolved
I have followed all the documented steps I can find, i.e.:
1) the following two jar files are in the project build-path:
log4j-core-2.6.2.jar and log4j-api-2.6.2.jar
2) the above two jar files are located in the following folder:
C:\eclipse\apache-log4j-2.6.2-bin
3) The above folder is in my system CLASSPATH environment variable C:\eclipse\apache-log4j-2.6.2-bin
4) The project contains the following log4j.properties file in the project root
# This sets the global logging level and specifies the appenders
log4j.rootLogger=INFO, theConsoleAppender
# settings for the console appender
log4j.appender.theConsoleAppender=org.apache.log4j.ConsoleAppender
log4j.appender.theConsoleAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.theConsoleAppender.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
5) I have cleaned the project
6) failing import is: import org.apache.log4j.Logger;
Intermittently I am also getting this error message
"The type org.apache.log4j.Logger cannot be resolved. It is indirectly referenced from required .class files" at the first line:
package com.example;
This error disappears when I do a project -> Clean
but the error on import of log4j persists.
Any thoughts would be greatly appreciated.
If you are getting this error it means your application or one of its dependencies uses the Log4j 1.2 API.
The org.apache.log4j package is the Log4j 1.2 namespace. Log4j 2 uses the org.apache.logging.log4j namespace. Log4j 1.2 became End of Life in 2015 and users are recommended to upgrade to Log4j 2.
You already have the correct log4j-api-2.x.jar and log4j-core-2.x.jar in your classpath, the only thing missing is the log4j-1.2-api-2.x.jar. log4j-1.2-api is an adapter module that ensures your application's calls to the Log4j 1.2 API are delegated to the Log4j 2 implementation.
Please ensure the old log4j-1.2.x.jar is removed from the classpath.
Finally, the configuration you showed seems to be for Log4j 1.2 and will not work with Log4j 2. The Log4j 2 manual has many example configurations. (The documentation alone is reason to upgrade, it is so much better in Log4j 2.) See for example the section on the Console appender or the File appender.
Log4j 2 also supports a properties configuration format (but the syntax differs from the log4j 1.2 properties format).
Check your Eclipse version and log4j dependency version. If 1.2.17 is not working then check using 1.2.16.
Related
Apache avro scanning shows the log4j vulnerability.
How to get rid of it?
Tried with:
java -jar target/log4j-detector-latest.jar /c/workspace/sampleApp
-- github.com/mergebase/log4j-detector v2021.12.29 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
C:\workspace\sampleApp\target\SampleApp\WEB-INF\lib\avro-tools-1.9.1.jar contains Log4J-1.x <= 1.2.17 OLD
I have tried to upgrade to avro-tools version 1.11.0 that too shows the same issue.
You can modify the JAR file and delete the following files that belong to log4j 1.x within the JAR file to mitigate the vulnerabilities. They are present in the folder /org/apache/log4j/net/ within the JAR:
JMSAppender.class
SocketServer.class
SocketAppender.class
SMTPAppender.class
SMTPAppender$1.class
Once deleted these classes can no longer be used by a log4j logging configuration (which is the way to trigger the vulnerabilities).
If the application does not work after the modification it needs to be migrated to use a newer log4j 2.x version: Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later)) - see https://logging.apache.org/log4j/2.x/
I am trying to get DropWizard to log to an output file. The file is being created but nothing written to it.
In fact it would appear that the configuration in the provided .yml file is not being used.
I am also getting the following warnings during startup, not sure if they are related:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/conor/.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/conor/.m2/repository/com/conor/project/project-common/0.1-SNAPSHOT/project-common-0.1-SNAPSHOT.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
How can I get dropwizard to pickup the logging config in the yml provided at startup and how can I figure out where the current config is coming from? Thanks.
UPDATE::
I am running DropWizard v0.9.1 and my logging configuration is as follows:
# Logging settings.
logging:
# The default level of all loggers. Can be OFF, ERROR, WARN, INFO, DEBUG, TRACE, or ALL.
level: TRACE
# Logger-specific levels.
loggers:
# Sets the level for 'com.example.app' to DEBUG.
io.dropwizard: INFO
# Redirects SQL logs to a separate file
org.hibernate.SQL:
level: DEBUG
# Logback's Time Based Rolling Policy - archivedLogFilenamePattern: /tmp/application-%d{yyyy-MM-dd}.log.gz
# Logback's Size and Time Based Rolling Policy - archivedLogFilenamePattern: /tmp/application-%d{yyyy-MM-dd}-%i.log.gz
# Logback's Fixed Window Rolling Policy - archivedLogFilenamePattern: /tmp/application-%i.log.gz
appenders:
- type: console
- type: file
threshold: DEBUG
logFormat: "%-6level [%d{HH:mm:ss.SSS}] [%t] %logger{5} - %X{code} %msg %n"
currentLogFilename: output/logs/dropwizard.txt
archivedLogFilenamePattern: output/logs/dropwizard-%d{yyyy-MM-dd}-%i.txt.gz
archivedFileCount: 10
timeZone: UTC
maxFileSize: 10MB
This looks like a typical SLF4J binding issue and is solved easily. First take a look at the relevant section in the URL provided with the warning for an explanation.:
The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random. As of version 1.6.6, SLF4J will name the framework/implementation class it is actually bound to.
Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.
Since the binding choice is random, my guess is that the project-common SLF4J dependency is being bound and not the intended one from logback-classic, a transitive dependency of dropwizard. You should either exclude the one in the project-common in your Maven pom file or better yet, if you have access to the code to project-common, remove it from the pom file as the linked-to web page suggests (i.e. "mend their ways").
From the Exception, I think you are using the two different version of logback classic both in class path which arise the conflicts. Try to find out the jar which are included two times but different version and remove one of them. If you are using the Maven to manage the dependency exclude the jar using the tag
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>the version you want to remove</version>
</exclusion>
</exclusions>
I'm trying to figure out why our Hibernate code is not logging anything to log4j. I put together a simple project that calls one Hibernate service method that logs a log4j message as the first line.
Both the project and the Hibernate service have the following log4j specific code:
private static Logger NTEVENT_LOG = Logger.getLogger("NTEVENT");
NTEVENT_LOG.debug("==== LOG4J logging");
When I run the project (Eclipse->run) I get the following messages in red:
log4j:WARN No appenders could be found for logger (org.hibernate.cfg.annotations.Version).
log4j:WARN Please initialize the log4j system properly.
But immediately after I see the logging from the application itself so some part of log4j did get correctly initialized. However, nothing is being logged by the Hibernate service.
[main] DEBUG NTEVENT - ==== LOG4J logging
This is my log4j.xml
<appender name="NTEVENT" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-4r [%t] %-5p %c %x - %m%n"/>
</layout>
</appender>
<root>
<priority value ="debug" />
<appender-ref ref="NTEVENT" />
</root>
I must be missing something that Hibernate is expecting but I have no idea what.
To configure log4j using xml file you need to use DOMConfigurator.configure() method in your main.
Also for this method you need to import org.apache.log4j.xml.DOMConfigurator package.
public static void main(String[] args) {
DOMConfigurator.configure("log4j.xml");
..//your code
..
}
Hope this helps..!!
The problem was as ThrashBean implied, logging for org.hibernate was not enabled. If you want to see Hibernate debugging output, queries for instance, you need:
I finally got what was happening in my case. It might also help those in Netbeans users facing the same problem coz i have lost a lot of hair for quite some months now. My application had just stopped logging to console so i couldnt debug since the errors were not being displayed.
The answer "There are two log4j jar files in you libraries at different location." was true. Initially i had expected to find 2 files with the name log4xxx.jar of course with different version numbers but no file like that at all was there. You see Netbeans comes prepackaged with Hibernate libraries and many other libraries of course. So when developing in hibernate applications in Netbeans you DON'T need to manually add your own Hibernate Jars unless of course you need a specific version etc, you can just add the Hibernate library to your application via that right click project - Properties - Libraries - Add Library button . This will add many hibernate Jars in the background/classpath when running and also on Compiling in the dist/lib folder BUT NOT in the lib of the application. In my case i had added both the Hibernate Library AND also copied the generated hibernate jars from dist/lib to lib. This had happened by mistake as i copied libraries from previous application to include in my new application for use there.
So take home point, if in Netbeans, go to your lib folder, if you see jars like
hibernate-commons-annotations-x.x.x.Final.jar, hibernate-core-x.x.x.Final.jar,hibernate-entitymanager-x.x.x.Final.jar, hibernate-jpa-2.0-api-x.x.x.Final.jar, hibernate-tools-x.x.x.CR1.jar
Remove them and check if error resolves.
I've made an app init function that I'm using both in Java and GWT applications. I have external logback.xml file that I'm setting the path to the "logback.configurationFile" System property. In pure Java projects, all works as expected, but not in GWT projects.
I've implemented my ServletContextListener and in method contextInitialized I'm setting the System property. Logback does not read it, but falls back to basic (red letters in console).
So, I tried to follow instructions from logback configuration
LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
to reconfigure Logback, but that throws
java.lang.ClassCastException: org.slf4j.impl.SimpleLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
I also tried to put logback.xml in folders: src, war, war/WEB_INF, but it doesn't read it.
I'm switching to slf4j because previous log4j started to throw many "class not found" exceptions (something with commons-logging)
The question is:
What is wrong?
or
How can I get sfl4j (logback) to read the external configuration XML file?
or
How can I get sfl4j (logback) to read any configuration XML file?
Help appreciated
EDIT: Tried to use log4j adapter with slf4j, and it doesn't work either.
EDIT2: I reverted back to pure log4j that didn't work before. However, I added log4j.jar directly in "Installed JRE" in Eclipse in the main system JRE and now the pure log4j works. What seems to me is that there is quite a difference between the OpenJDK and the Sun's JDK, and that is causing problems. I'll try to fix this slf4j issue in a few days. Maybe there is also a need for some jar on some weird place.
EDIT3: slf4j now works with log4j, but I have to manually configure it. Doesn't matter where I put log4j.xml, it doesn't read it. Looks like classloader problem with Sun's JDK. I'll try with Logback soon. It might be similar problem.
I have logback working in my gwt,eclipse, jetty projects. works quite well. Kind of worked out of the box. I am using maven. What I did is:
add slf4j-api and logback as a dependencies.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.4</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.0</version>
</dependency>
in my code I get a logger by using:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
protected Logger log = LoggerFactory.getLogger(this.getClass());
The logback.xml is in my src/main/resources folder. This way it will be placed in target/myproject/WEB-INF/classes after beeing compiled.
Hope this will help you.
There are a number of possible configurations with jetty, slf4j, and logback.
It really depends on what you are trying to accomplish.
1) Having the webapp itself do its own logging to logback.
2) Having a global log at the server level that logs the server events and webapp events to logback.
3) Having a global logback configuration at the server level that creates a log file for the server and individual log files for each webapp.
To accomplish #1, you just have to put the slf4j and logback files in your webapp's WEB-INF/lib directory and deploy the webapp. (be sure you put the configuration files in the webapps WEB-INF/classes or WEB-INF/ directory)
To accomplish #2 and #3 you need to let jetty know that slf4j and logback should be exposed to all webapps, and that all webapps, regardless of the existence of their own (potential) slf4j and logback jars, they are to always use the jar files from the server.
This is done by manipulating the WebAppContext's list of systemClasses and serverClasses via the default web
Slf4j is permitted through the webapp classloader barrier on Jetty, but logback is not.
This can be defined statically in the context/*.xml deployable, or dynamically via a DeploymentManager binding. see the jetty-webapp-logging module on jetty.codehaus.org for details on how to accomplish this (I would link you do this, but codehaus is undergoing a server migration ATM)
So, i gist'd the relevant file here - https://gist.github.com/1409147
package org.mortbay.jetty.webapp.logging;
import org.eclipse.jetty.deploy.App;
import org.eclipse.jetty.deploy.AppLifeCycle;
import org.eclipse.jetty.deploy.graph.Node;
import org.eclipse.jetty.server.handler.ContextHandler;
import org.eclipse.jetty.webapp.WebAppContext;
public class CentralizedWebAppLoggingBinding implements AppLifeCycle.Binding
{
#Override
public String[] getBindingTargets()
{
return new String[]
{ "deploying" };
}
#Override
public void processBinding(Node node, App app) throws Exception
{
ContextHandler handler = app.getContextHandler();
if (handler == null)
{
throw new NullPointerException("No Handler created for App: " + app);
}
if (handler instanceof WebAppContext)
{
WebAppContext webapp = (WebAppContext)handler;
webapp.addSystemClass("org.apache.log4j.");
webapp.addSystemClass("org.slf4j.");
webapp.addSystemClass("org.apache.commons.logging.");
}
}
}
To accomplish #3 you'll need to setup a slf4j MDC handler and sift logging in logback that uses the MDC information to route the appropriate logging event to the logfile of your choice.
I blogged about this at http://webtide.intalio.com/2011/08/sifting-logs-in-jetty-with-logback/ and have example projects for basic logback, sifted logback, and even how to use the logback-access module for NCSA access logging at https://github.com/jetty-project/jetty-and-logback-example
Logback looks for its configuration files in the classpath, not in the file system.
To get to a configuration file in the file system, use file inclusion as described at http://logback.qos.ch/manual/joran.html#fileInclusion. Note that the filename can refer to an environment variable if it makes it easier to point to the file system location of the file.
I am also faced the same problem, found slf4j-simple.jar in the pom/class path. Once it was removed, working fine.
I build a REST web service (using JAX-RS, Spring, Spring JMS, and ActiveMQ). I'm surprised that when I deploy it to Tomcat 5.5.23 I get an exception that JSF jars are required?!
Error configuring application listener of class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.ClassNotFoundException: org.apache.myfaces.webapp.StartupServletContextListener
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3712)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
The web service was working fine until I added log4j functionality in different classes, here's my log4j.properties file (I placed it in WEB-INF/classes):
log4j.rootCategory=INFO, S
log4j.logger.com.dappit.Dapper.parser=ERROR
log4j.logger.org.w3c.tidy=FATAL
#------------------------------------------------------------------------------
#
# The following properties configure the console (stdout) appender.
# See http://logging.apache.org/log4j/docs/api/index.html for details.
#
#------------------------------------------------------------------------------
log4j.appender.S = org.apache.log4j.ConsoleAppender
log4j.appender.S.layout = org.apache.log4j.PatternLayout
log4j.appender.S.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %c{1} [%p] %m%n
Any idea how to resolve this?
I would expect to see this if you have a reference to org.apache.myfaces.webapp.StartupServletContextListener in your web.xml, like:
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
Can you verify that there is no such element?
Sounds like a classloader hierarchy issue. You should enclose log4j in your WAR file, not put it in the shared libraries of Tomcat.
Also, I had some problems with Tomcat 5.5 that was fixed in Tomcat 6.0. You may want to consider upgrading.
Make the following dependencies(if present) in maven as provided:
javax javaee-api 6.0 scope : provided
javax.servlet javax.servlet-api 3.0.1 scope : provided