I'm upgrading a Spring MVC application from Spring 3.1 to 4.3, and Hibernate 3.6 to 5.2. I'll be running this in Wildfly 8. Dependencies are managed by Maven.
Spring uses commons-logging, which looks at the classpath of the application and attempts to choose a suitable logging framework. In my case, it seems to be choosing the wrong one. I have included log4j in my pom.xml, and checking the dependency hierarchy I can see that jboss-logging is not there. Here is the error message I'm getting:
Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf
So even though I don't have jboss logging in my project, commons-logging is finding it somewhere and attempting to use it, but unsuccessfully. After some searching I found jboss-logging-3.1.4.GA.jar in Wildfly.
The reason for the error is that this is an old version of jboss-logging. I added a newer jar to the server and edited module.xml to point to it, and the error went away. That proves that commons-logging is finding jboss-logging on the server.
The problem is that I don't want jboss-logging, I want log4j. How do I force commons-logging to use log4j and ignore what is on the server?
Edit: I followed the link chrisharm put up and added these lines to the standalone.xml file :
<add-logging-api-dependencies value="false"/>
<use-deployment-logging-config value="false"/>
I also changed the module.xml to point to the older jar again, since I would rather see an error if jboss is used. When I run now I get this:
Caused by: java.lang.NoClassDefFoundError: org/jboss/logging/Logger
This may be a step in the right direction, since now Spring doesn't have access to jboss-logging, but it is still trying to use it for some reason.
https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-HowdoIusemyownversionoflog4j%3F
If you need/want to include your version of log4j then you need to do the following two steps.
Disable the adding of the logging dependencies to all your deployments with the add-logging-api-dependencies attribute and disable the use-deployment-logging-config attribute OR exclude the logging subsystem in a jboss-deployment-structure.xml.
Then need to include a log4j library in your deployment.
This only works for logging in your deployment. Server logs will continue to use the logging subsystem configuration.
Related
We have our web app running on tomcat 8.5.39. This app is using log4j2 correctly, applying a system property before log4j2 starts to indicate the log4j.xml configuration file. Something like:
System.setProperty("log4j.configurationFile", "/opt/ventusproxy/logs");
Now we have migrated to tomcat 8.5.83, and after this our webapp is not able to find the configuration file. Asking the log4j team, and after checking log4j debug file, it seems that, for any reason, log4j2 is starting before we set the previous system property.
We also tried 8.5.79 with the same result.
Is there any configuration change that we are missing between 8.5.39 and a later tomcat version that breaks the way log4j2 was working into our webapp until now?
Thanks,
Joan.
I need to understand how to deploy a spring boot webapp on SAP Cloud Platform.
I created a basic webapp using https://start.spring.io/.
I only added spring web as module.
I modified the generated pom excluding
spring-boot-starter-tomcat
jul-to-slf4j because I found a loop can be created by system
Then I added following dependencies as provided
slf4j-api
logback-classic
servlet-api
I added an empty web.xml, I deployed the compiled war on SCP and then I started.
After more or less 5 minutes of loading, the start fails and if I check the logs, I can't find any error.
Has anybody an idea of how I should proceed?
I even followed this tutorial, https://blogs.sap.com/2018/08/28/spring-boot-and-sap-cloud-platform-neo/, without any result.
Java version: 1.8
Tomcat version: 1.8
Spring boot version: 2.1.8.RELEASE
It looks that the problem was due to log level too low. It caused the generation of 15 mb log, apparently blocking the webapp start
My basic question is. How do I configure Netty to use slf4j in Spring? I keep getting the error below in Spring but not eclipse using the slf4j jars with the log4j bridge and api in the path. I am using Spring Tools suite, spring 3.2.3, and Netty 4 (post jboss).
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
The program fails at the line where I instantiate the connection group after I try setting the default logging factory.
I am really new to Netty and slf4j. I have been banging my head against this one for a while and done a bit of research on Stack Overflow and the internet. I managed to get Netty working with slf4j in eclipse and used the Internal Logger Factory. I tried configuring slf4j in a similar way to log4j (A properties file with appenders).
I used the following code for the InternalLoggerFactory in both of the following ways with the appropriate imports.
InternalLoggerFactory.setDefaultFactory(new Slf4JLoggerFactory());
and
InternalLoggerFactory.setDefaultFactory(Slf4JLoggerFactory.getDefaultFactory());
These lines are placed immediately before my initialization of the connection group but I tried them in my Main App/Driver's main method as well.
Thanks for any help. I would and do really appreciate it.
´org.slf4j.LoggerFactory´ is part of ´slf4j-api-1.75.jar´, so it is likely that you have some deployment problem. -- Check that this jar is really in the classpath of you application, or if you have an web application, then check that this jar is deployed to you application server.
One other thing (that is maybe not the cause of your problem) is that you have log4j-1.2.16.jar and log4j-to-slf4j-2.0-beta8.jar. This is will lead to other problems, because log4j-to-slf4j is a log4j-to-slf4j bridge, that forward log4j loggers to slf4j. On the ohter hand you have the real log4j in your classpath too. I would remove log4j-1.2.16.16. I hope this slf4j docu describe it a bit better than me.
An other point that brothers me, is that you use different version of slf4j. I strongly recommend to use the same version for all slf4j libs!
I'm migrating an application that uses Spring security 3.0 to Spring security 3.1.
I have been getting an error about incorrect schema being referenced:
SEVERE: Exception sending context initialized event to listener instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration
problem: You must use a 3.0 schema with Spring Security 3.0.(2.0 or 3.1 versions are not
valid) Please update your schema declarations to the 3.0.3 schema (spring-security-
3.0.3.xsd).
Offending resource: ServletContext resource [/WEB-INF/security-context.xml]
When I look in /lib I see a number of jars that are 3.1 versions are duplicated as 3.0 versions. I suspect this is what is causing the error above.
When I look at the dependency tree of the pom.xml using the Eclipse Maven plugin, I can see where the earlier versions are being referenced (eg spring-security-acl depends on several 3.0 jars) but they are marked as 'omitted for conflict with...'. Does that not mean they should be omitted from the built war file?
I've tried explicitly naming 3.1 versions of those files at the root of my pom but the older versions still get included.
Offending resource: ServletContext resource
[/WEB-INF/security-context.xml]
Actually the message indicates that security-context.xml uses schema/declarations which are incompatible with spring-security-3.1. The message is requesting you to use a 3.0 version of the library instead. You may want to review and update it and retry.
I'm still not sure what was going on, but I tried creating a new project in Eclipse with the same pom and source files and now the project seems to behave itself.
My Java EE 6 application uses slf4j with logback as logging framework.
Now I want to add the SQL traces of OpenJpa to my log files. The OpenJpa-Documentation says, I can use a parameter to this:
<property name="openjpa.Log" value="slf4j"/>
I use the WebSphere Application Server v8.0.0.1 as Java EE container. If I deploy my application to the server, this parameter does not change anything. I can change log levels in WebSphere Admin Console and this works fine. But a cannot bypass the OpenJpa logging to my slf4j framework.
Does anyone uses such configuration and solved the problem?
Btw. I know, that the InformationCenter-Article http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftejb_jpatroubleshoot.html
says, that the parameter will be ignored, but everything should be possible, eh?
I don't know what version of OpenJPA is embedded in WAS 8.0.
In OpenJPA 1.x there was no possibility to use "slf4j". A workaround was copying the class org.apache.openjpa.lib.log.SLF4JLogFactory from OpenJPA 2.x sources to your application and using it directly:
<property name="openjpa.Log" value="org.apache.openjpa.lib.log.SLF4JLogFactory"/>
You can always specify the factory class name directly, the short name is only a convenience trick.
In OpenJPA 2.x the SLF4JLogFactory is present, so it should work with your current settings; perhaps you set it in a place that is overridden by other configuration? For example, if you configure JPA through EntityManagerFactory's propertyMap, it takes precedence over the settings in persistence.xml.
I solved it.
There are four things to do:
Say that OpenJpa logs the statements. That is done by the property entry in the persistence.xml.
Say Slf4j that it has to fetch the logs from JUL too. This can be done by installing the SLF4JBridgeHandler by SLF4J. I installed the bridge via a ServletContextListener which is called at application start.
Configure Logback that it does not log ALL logs from JUL but only the needed Logs. This is done by adding the LevelChangePropagator in the logBack-test.xml
Ask the WebSphere TraceService to hand down the logs from OpenJPA to the application. This is a setting in the WebSphere Administration Console