I want to upgrade log4j version from 1.2 to 2.3 version. But there are many modules in application (almost 100) and I have 100 log4j.xml files. So I can't change my xml files manually. Can You suggest any automatic way?
Related
I am migrating log4j 1.x project to 2.x. Can you please help me by providing a package mapping table where I can find the deprecated packages in 1.x and find the equivalent in 2.x
I have upgrade from log4j-1.2.17 to log4j-2 with needed code changes and then removed log4j and deployed log4j2. service not starting, hence, logs not generating, where I need check
We are trying to mitigate the laetst log4j vulnerability in our application our scans show that jetty-hightide-7.6.1.v20120215/webapps/cometd.war is using the older version of log4j that is log4j.1 need help in ways to mitigate this.
Can we delete it from the webapps.
Your use of jetty-hightide-7.6.1.v20120215 has far more vulnerabilities present than just cometd.
Jetty 7.x
Jetty 7.x was declared EOL (End of Life) back in 2014.
https://www.eclipse.org/jetty/security_reports.php
Log4j 1.x
Log4j 1.x was declared EOL back in 2015.
https://logging.apache.org/log4j/1.2/
Along with 10 years of security updates to the following other projects present in your ancient jetty-hightide archive.
objectweb asm 3.1
javax.annotations 1.1
derby 10.6
javax.activation 1.1
glassfish mail 1.4
sun el 1.0
javax.el 2.1
jstl 1.2
jsp 2.1
glassfish jasper 2.1
glassfish taglibs 1.2
eclipse jdt 3.7
javax.transactions 1.1
atomikos 3.7
jna 3.2.2
setuid native 7.6
spring framework 2.5
cometd 2.4.0.RC3
jackson 1.9
log4j 1.2
bayeux 2.4
dojo 1.7
dojox 1.7
dojiit 1.7
jquery 1.6
Every one of the items listed above have security vulnerabilities associated with them in the past 10 years, every one of them need to be evaluated. (many of the vulnerabilities are actually quite severe, on par with the log4j one you are specifically chasing)
In some projects which used slf4j and log4j I can see dependencies like
compile('org.apache.logging.log4j:log4j-core:version')
compile('org.apache.logging.log4j:log4j-api:version')
compile('org.apache.logging.log4j:log4j-slf4j-impl:version')
But some projects use slf4j-log4j12 instead of log4j-slf4j-impl. To my understanding they are both works like bridges between slf4j and log4j, but what's their difference?
Those artifacts use different versions of Log4j:
slf4j-log4j12 is a bridge between SLF4J and Log4j 1.2. Its versioning follows SLF4J.
log4j-slf4j-impl is a bridge between SLF4J 1.x (up to 1.7.x) and Log4j 2.x. Its versioning follows LOG4J2.
log4j-slf4j2-impl is a bridge between SLF4J 2.x (or higher) and Log4j 2.x. Its versioning follows LOG4J2.
Since Log4j 1.x reached end-of-life more than 7 years ago, there is no sense in using the first one in new software.
Is jsf 2.2 not supported on glassfish 3.1.2?
My viewActions are not being invoked and some simple things do not behave same way as supposed with 2.1.23. So i am not sure about filing issues for 2.2
You can manually update the .jar file located at the Glassfish's /modules directory.
More information: How do I upgrade the JSF API in GlassFish?
By updating jar file some feature is supported. But, some of the feature. e.g. JSON processing is not supported. Use Glassfish 4.0 for best support.