I want use struts 2.5 over logback but everything log to file only write to console of tomcat
i used jar as below:
struts 2.5.13
logback-core 1.2.3
logback-classic 1.2.3
log4j-api 2.9.1
log4j-to-slf4j 2.9.1
slf4j-api 1.7.25
Many thanks
Related
While adding instrumentation plugin in pom.xml am getting this error
Plugin execution not covered by lifecycle configuration:org.javalite:activejdbc-instrumentation:1.4.13:instrument (execution: default, phase: process-classes
If added all plugin inside pluginManagement then no error but this package org.javalite.activejdbc.Model not importing can you please assist me.
It is indeed a duplicate of How to solve "Plugin execution not covered by lifecycle configuration" for Spring Data Maven Builds.
However, JavaLite documentation provides a more concrete set of instructions for Eclipse configuration.
I decided to port some program, that uses zlib, using emscripten. Configuration fails, because it complains no zlib is present on my system.
But:
>ls ~/.emscripten_ports/
freetype libpng sdl2 sdl2-image.zip sdl2-ttf.zip zlib
freetype.zip libpng.zip sdl2-image sdl2-ttf sdl2.zip zlib.zip
And:
> ls ~/.emscripten_cache/asmjs/
dlmalloc.bc libc.bc libcxx_noexcept.a sdl2.bc sdl2-ttf.bc
freetype.bc libcxx.a libpng.bc sdl2-image.bc wasm-libc.bc
gl.bc libcxxabi.bc ports-builds sdl2-image-png.bc zlib.bc
And:
> ls ~/.emscripten_cache/asmjs/ports-builds/
freetype include libpng sdl2 sdl2-image sdl2-ttf zlib
I can specify path to zlib with --with-libzlib=dir
How to configure this project? If this information was helpful, I would compile lincity.
I have compiled zlib by myself, using emscripten.
emconfigure ./cofigure --prefix=$PATH_TO_SYSTEM_DIR_IN_EMSCRIPTEN
emmake make
emmake make install
I don't know it works, but configure of lincity doesn't complain about missing zlib. It complains about missing libxml-2 and libxml-2 requires python2, so I give up. Put this in an answer?
I have two Spring MVC applications that share a commons.jar library. This library includes logback logging library (logback 1.2.3 and slf4j 1.7.25) and the logback.xml file.
Both wars include this line in their web.xml file:
<env-entry>
<env-entry-name>applicationName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>nameOfApplicationA|nameOfApplicationB</env-entry-value>
</env-entry>
Each application generates its own log file including hostname, for example: HOST1-nameOfApplicationA.log. Logback configuration is as follows:
<insertFromJNDI env-entry-name="java:comp/env/applicationName" as="APP_NAME" />
<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_PATH}/${HOSTNAME}-${APP_NAME}.log</file>
...
</appender>
Everything was working OK (Spring MVC 4.3.7.RELEASE, Hibernate 4, C3P0 latest), but we decided to upgrade to Hibernate 5.2.10 and change to HikariCP 2.6.1. After that, logback was no longer able to resolve java:comp/env/applicationName:
ERROR in ch.qos.logback.classic.joran.action.InsertFromJNDIAction - [java:comp/env/applicationName] has null or empty value
Resulting in both applications using the same file name HOST1-APP_NAME_IS_UNDEFINED.log.
As we changed at the same time Hibernate and HikariCP we went back to C3P0 to check the root cause, and can confirm that the new version of Hibernate has nothing to do. The change was developed in its own branch so no other change seems to affect (anyway, when returning to C3P0 it works).
I've been doing some tracing in Hikari's and Logback's code but I'm not able to see anything. I'm stuck, no idea of what to look.
Plan B is insert in each war its own logback.xml but I would like to avoid it and understand the problem as it may affect other parts of the application.
Both wars are deployed together in an Apache Tomcat/8.0.38 server. Tried also 8.5.12. It also happens if only one of the wars is deployed alone.
Although I found no solution, #brettw identified the problem (see https://github.com/brettwooldridge/HikariCP/issues/873), and got a workaround.
It seems that because HikariCP depends on slf4j, and HikariCP is also being initialized and registered into JNDI, is that causing Logback to initialize before the <env-entry> entries have registered.
The test made was initalize Hikari datasource with "org.apache.naming.factory.BeanFactory" factory instead of "com.zaxxer.hikari.HikariJNDIFactory". This way it works correctly.
My Java EE 6 application uses slf4j with logback as logging framework. I have openjpa custom logging which is not working on Weblogic while it was ok on glassfish before (whit openjpa 1.2).
When I add my custom log factory to "openjpa.log" property in persistence.xml, weblogic ignores this and doesn't work.
my custom log factory:
<property name="openjpa.Log" value="com.kishware.core.log.openjpa.CustomSLF4JLogFactory"/>
Here is the weblogic console output when ignores the property:
<Aug 17, 2013 11:29:35 AM GMT+04:30> <Warning> <J2EE> <BEA-160202> <You have specified a openjpa.Log setting in your configuration for persistence unit banco-product#pu-channel-manager. This setting will be ignored and all log messages will be sent to the WebLogic Server logging subsystem. Trace-level logging is controlled by the various JPA-specific debug settings in config.xml, or through the WebLogic Server Administration Console.>
I should mention that I'm using JPA 2.1 with Toplink implementation.
I would be happy to get some hints, how this could be solved.
I should mention that I'm using JPA 2.1 with Toplink implementation
Right there is your problem. You're trying to configure Toplink (and I think you mean EclipseLink) with OpenJPA configuration properties.
I'm curious about the differences between Log4J 1.2 and 2.0, because I've been trying to run a demo I found online ( video here ) and I've run into issues. I was especially curious about what is the role of SLF4J in all of this, i.e do you need a certain SLF4J for 1.2 vs 2.0 ?
thanks!
AFAIU from the Apache Log4j 2 web site, the significant is as the following: -
The performance which compare among log4j 1.x, logback and log4j 2.
They provide 2 significant components as the following: -
SLF4J Binding: The SLF4J bindings provided in this Bridge cause all the SLF4J APIs to be routed to Log4j 2.
Log4j 2 to SLF4J Adapter: The Log4j 2 to SLF4J Adapter allows applications coded to the Log4j 2 API to be routed to SLF4J.
Then we may use either the SLF4J as a Logging Facade with log4j 2 instead of logback or use the log4j 2 natively.
I hope this information may be useful.