I wrote custom log4j appender to send logs from WSO2 AM 1.10.0 to RabbitMQ. there is an exception if I add the custom appender to WSO2 AM server.
The steps of using appender:
Making a stand maven jar package which including all dependencies and put the jar file to lib folder,
Modifying log4j.properties under \repository\conf,
I am pretty sure the appender itself is working well as it has been used in a few apps to send off the logs to the queue.
Could anyone please advise me how to implement the custom log4j appender for WSO2 properly?
Thanks in advance,
Sean
It seems to be a class loading issue. I think that happens because both WSO2 server and your custom jar contain log4j classes. Set scope provided like below for slf4j dependency, and see if it works.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.4</version>
<scope>provided</scope>
</dependency>
Related
We are using wildfly 10 and 16 in production and a zero-day exploit exists CVE-2021-44228 for log4j for some versions.
How can I be sure that none of the code and libraries use a log4j lib that has that issue?
I do not use any log4j property file nor do I add a dependency by myself.
Any help would be greatly appreciated!
The affected log4j versions are:
Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1
WildFly uses log4j shaded via its log4j-jboss-logmanager module. Even the latest 1.2.2.Final version depends on log4j 1.2.17.
This means WildFly <22 is definitely not affected.
There is a log4j2-jboss-logmanager as well - but only WildFly 22+ has it. And as this doc explains:
This will be an implementation of the log4j2 API only. The core log manager for log4j2 will not be supported.
Usage of any org.apache.logging.log4j:log4j-core API’s or implementations will not be supported. In other words the log4j2 log manager implementation, including configuration files, will not be supported.
You can see that the current latest 1.0.0.Final release does not depend on log4j-core at all, only log4j-api.
So WildFly versions >=22 are not affected as well.
The official tweet confirms this.
But what about WFCORE-5743 raising the log4j-core version? Look in the pom:
<!-- This is a test only dependency -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${version.org.apache.logging.log4j}</version>
<scope>test</scope>
</dependency>
It's not bundled with WildFly, only used in WildFly's build for tests.
Fixed in WildFly Core 18.0.0, to be included in WildFly 26.0.0.Final:
https://issues.redhat.com/browse/WFCORE-5743
https://issues.redhat.com/browse/WFLY-15807
If you need to use WildFly 10 or 16 in production, you should use JBoss EAP instead:
https://access.redhat.com/articles/112673#EAP_7
I am starting to migrate an existing project from log4j1 to log4j2, i added the following maven dependencies
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
I also deleted all logj1 jar like they say on the offical migration guide, i don't know if i have to replace all log4j.xml configuration files with log4j2.xml and change the configuration to the new syntax?
If it's the case, how i can do with third parties that use log4j and configure it with log4j.xml ?
First, there can only be a single logging configuration per application. If a third party is providing a logging configuration in a jar to be included in your app that is an issue. If it is a separate third party app then I don't understand why you are porting it from Log4j 1 to Log4j 2. That should be their problem.
Yes, your dependencies are correct. As for whether to use a log4j 1 format configuration or log4j 2 I would always recommend using the log4j 2 format if you can do the work. You can certainly try to use the log4j 1 configurations by following http://logging.apache.org/log4j/2.x/manual/compatibility.html.
I'm currently working on an application which wants to dynamically change the log level of a next java application (is running on the localhost). This external application uses log4j version 1.2.16. I want to use jmx, find all "LoggerConfigAdminMBean" and change level.
In specification (visit https://logging.apache.org/log4j/2.0/manual/jmx.html) is mentioned that it is possible with the log4j 2.
Because I do not want to do much changes in the external application, so I only changed log4j1.2.16.jar by log4j1.2bridge.jar (visit https://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html). But the result of this change is empty list of LoggerConfigAdminMBean.
Is the Jmx MBeans feature completely activated by using log4j 1.2 bridge jar and is there some way to get list of LoggerConfigAdminMBean full or is it possible only by migration from log4j1 to log4j2 version?
Thank you very much for the answers.
You should use these 2 dependencies:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.11.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>2.11.1</version>
</dependency>
And adapt log4j.properties, which must be placed in the project´s classpath. See: https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
I'm follow this docs this docs
and add maven depency:
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-sftp</artifactId>
<version>5.0.0.M6</version>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-java-dsl</artifactId>
<version>1.2.3.RELEASE</version>
</dependency>
But it cannot resolve these method:
does I miss anything?
Starting with Spring Integration 5.0, whole Java DSL project is merged to the core project. So, you don't need that extra spring-integration-java-dsl dependency anymore. More over it isn't compatible with Spring Integration 5.0.
There is no any more such a handleWithAdapter() since there is no single entry point because all the namespace factories are distributed between appropriate modules.
So, right now you have to do this:
.handle(Sftp.outboundGateway(...))
See Migration Guide for more info.
And also follow back to the past from release blog post.
I need to bundle JSF implementation in my WAR file due to known bug in the original mojarra implementation.
I am not allowed to replace the JSF implementation in the modules, so i am using the useBundledJsf property.
Running Payara Version: Payara Server 4.1.1.164 #badassfish (build 28)
This versions should support useBundledJsf properly.
I have added this to my glassfish-web.xml:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
and added the javax.faces dependecy to my pom:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.13</version>
</dependency>
I am getting the following error and all injections are failing.
SEVERE: JSF1051: Service entry 'org.glassfish.faces.integration.GlassFishInjectionProvider' does not extend DiscoverableInjectionProvider. Entry will be ignored.
I have tried to add the weld-integration.jar to my project but it still produces the JSF1051 error following by:
Unable to create a new instance of 'org.jboss.weld.jsf.ConversationAwareViewHandler'
The dependency for the weld-integration i have used:
<dependency>
<groupId>org.glassfish.main.web</groupId>
<artifactId>weld-integration</artifactId>
<version>4.1.2</version>
<exclusions>
<exclusion>
<artifactId>*</artifactId>
<groupId>*</groupId>
</exclusion>
</exclusions>
There is an extra feature to make this easier in Payara Server 171 which was added specifically to make these scenarios work properly.
From the documentation:
It’s possible to configure an extreme isolation level on the class loading delegation for deployed applications. With this extreme isolation behavior, a deployed application can force the server to load only classes from libraries included on Payara Server that belong to whitelisted packages defined on its deployment descriptors.
To configure whitelist packaging you can use the <whitelist-package> element on the glassfish-web.xml (WAR artifacts) or the glassfish-application.xml (EAR artifacts). This element can be included multiple times to whitelist multiple packages. Here is an example of whitelisting both the Google Guava and Jackson packages for a WAR application:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
...
<whitelist-package>com.google.guava</whitelist-package>
<whitelist-package>com.fasterxml.jackson</whitelist-package>
</glassfish-web-app>
The whitelist syntax is simple: Define the name of the package which contains the classes in question. For example writing com.google would whitelist all Google libraries included on the server, while writing com.google.guava would only whitelist the Google Guava library instead.
Extreme Classloading Isolation