My kettle is v8.3,log4j version is 1.2.14
How to update log4j to 2.15?
As others have said, the version of log4j that kettle uses is not vulnerable to this exploit, but it IS still vulnerable to old ones.
FYI - there is an active log4j2 branch on the public github and there will be an upgrade available eventually so you don't need to do it all yourself. https://github.com/pentaho/pentaho-kettle/tree/log4j2
It is a cumbersome task to do on your own, but it is possible. You would need to replace all of the log4j maven dependencies with log4j2 and then refactor every class that imports log4j. Unfortunately there are renamed methods and classes so you will need to make a lot of changes.
If I were you I would follow that log4j2 github branch and either wait for it to be merged or start cherry-picking from it. If you aren't familiar with Git or Java you can just wait for Pentaho to release this update.
Where I work we have had discussions with Hitachi (creator of Pentaho) regarding the fact that pentaho is dependent on log4j 1.x which has been end-of-lifed since 2015 and that log4j 1.x has known vulnerabilities that won't be fixed.
Hitachi has stated they are going to upgrade 8.3 and 9.2 Enterprise Edition to have log2j 2.17+ by 2/28/22. They will update Pentaho Community 9.x in the next major release scheduled for late May 2022. However, note they will not fix the 8.x version in community (ever) and so they will remain on log4j 1.x here.
So if you using pentaho community they are offering a fix in May for 9.2, but you are out of luck with pentaho community 8.2/8.3.
However, we have been able to successfully use the log4j2 bridge in pentaho 8.2 and 8.3 (it would also probably work with pentaho 9.x). The log4j2 bridge provides an extra jar that keeps the log4j 1 interfaces but behind the scenes calls log4j2. In the best case, it is a drop-in replacement for log4j 1.x. However, in Pentaho the bridge does not work for log4j 2.17.1 and lower (RenderMap and LogLog class not found exceptions).
However, log4j 2.17.2-SNAPSHOT does work (I had to compile it from the current log4j sources) as the missing classes are now in the bridge. Here is how it is done...
With the log4j2 bridge you replace the following log4j 1.x jar: log4j-1.2.17.jar
With the following log4j2 jars: log4j-api-2.17.2-SNAPSHOT.jar, log4j-1.2-api-2.17.2-SNAPSHOT.jar (bridge jar), log4j-core-2.17.2-SNAPSHOT.jar
log4j2 bridge links...
General info: https://logging.apache.org/log4j/log4j-2.2/log4j-1.2-api/index.html
Directions for using the log4j bridge: https://logging.apache.org/log4j/2.x/manual/migration.html
Related
I would like to know the difference between RELEASE, SNAPH, and just version number
So, I am working on a project, in which I have to change spring-core dependency version from 5.2.9.RELEASE to 5.3.11
In my maven repository, under org->springframwork->spring-core, I see below
5.2.8.RELEASE
5.2.9.RELEASE
5.3.4
5.3.6
5.3.8
5.3.9
5.3.10
5.3.11
My project builds successfully only with the 5.3.11 version of spring-core. It is ok to release my project to production with non-release version of spring-core?
The Spring Team changed the version scheme of some projects back in April 2020. As documented in this blog from the Spring Team.
So in short the 5.3.x line doesn't have the RELEASE suffix anymore for the final versions, as it was removed.
When upgrading a framework make sure you upgrade all parts of the framework. Not only upgrade spring-core but also all other related Spring Framework modules to the same version, if not this will eventually come back to hunt you with weird issues (memory, performance, transactions, missing methods etc. etc.).
So, https://sling.apache.org/documentation/bundles/configuration-installer-factory.html tells us that the currently recommended way to configure OSGi components is to use .cfg.json files. However, it notes that those are only supported “[…] since Installer Configuration Factory 1.2.0”.
So now I’d like to know:
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
I couldn’t find definite answers on any of these. But Adobe does sometimes also recommend using .cfg.json config files but only in articles about AaaCS. Is this only supported on AaaCS?
Sorry for my snarky tone but the lack of reliable, concise documentation is infuriating…
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
goto /system/console/bundles
search for Apache Sling Installer Configuration Admin Support
This gives you the bundle you are looking for
The number as marked in screenshot is the version used by your AEM.
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
I am on AEM 6.5.6 and the screenshot above is from the same instance. It exports out 1.1.2. The only version above this is 6.5.7, not sure if it has been upgraded to 1.2.0 as you need
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
You can build the bundle or download the already available one and install. However if there is any hard dependency on the existing version, your instance may corrupt. In order to avoid that, you may need to evaluate what all bundles are dependent on the existing version of configuration bundle and see if you can upgrade them all.
Short cut is to create a vanilla instance and deploy the configuration bundle exporting 1.2.0 version of configuration and test if instance comes up and number of active bundles is same and the ones before you upgraded configurations bundle.
What is the recommended way of upgrading the quarkus version used in an existing application?
I have taken a look at my pom.xml, since the quarkus extensions dont specify the version used, I assume that they will get updated based on the main quarkus version.
The properties which look to be relevant in the update are quarkus-plugin.version, quarkus.platform.group-id and surefire-plugin.version.
How can I decide which ones to change, and is there anything else to be aware of?
There is one important thing to know, we have:
Quarkus Core: this is the main Quarkus artifacts + all the core extensions: the quarkus-bom is the one of Core. The Quarkus Maven plugin is part of it too.
Quarkus Platform: it contains more extensions such as Camel Quarkus: the quarkus-universe-bom is the one from the Platform, it contains the Core + the additional extensions
We usually release Quarkus core then Quarkus Platform with a few days between the two as we often need a release of Camel Quarkus, which is an Apache project and organizes a 72 hours vote for each release.
In a newly created project, you have the following properties:
<quarkus-plugin.version>1.1.1.Final</quarkus-plugin.version>
<quarkus.platform.artifact-id>quarkus-universe-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus</quarkus.platform.group-id>
<quarkus.platform.version>1.1.1.Final</quarkus.platform.version>
quarkus-plugin.version is the version of the Quarkus Maven plugin, it should be in line with the version of the core you use
quarkus.platform.artifact-id can right now either be quarkus-universe-bom for the whole Platform or just quarkus-bom for the Core only.
quarkus.platform.version is the version of the BOM.
Usually all these versions should be aligned. But... it could happen that we would need some quick update in the Platform and not of the core and we could then only release a new version of the platform. This hasn't happened yet to be honest.
Let's take an example of what happened today: I released Quarkus Core 1.2.0.Final but we are still waiting for Camel Quarkus to be released to release the Platform.
If you want to update early, you can change the BOM to use the quarkus-bom and update everything to 1.2.0.Final.
Or you can wait for the Platform to be released early next week and stay on the Platform quarkus-universe-bom.
We also only update the website documentation and code.quarkus.io when the full Platform is released.
It used to work to simply issue the command
mvn io.quarkus:quarkus-maven-plugin:1.4.2.Final:create
in the base project directory for it to automatically update the Quarkus versions in the project pom.xml file, but since 1.6.0.Final it errors:
project XXXXX: Unable to generate the project in a directory that already contains a pom.xml -> [Help 1]
I will create an improvement suggestion ticket at Quarkus to restore this functionality, maybe with a dedicated maven goal (like update)
Upgrading a J2EE application from Wildfly 8.2.1.FInal to 9.0.1.Final I
discovered the namespace and versioning change of the Arquillian
Wildfly container.
In the JBoss Developer forum I read
This is working with the Maven "org.wildfly.arquillian" group
artifacts instead, having versions matching the Wildfly J2EE spec
instead of the Wildfly container version, seems more reasonable
both by name and version numbering.
What is the "Wildfly J2EE spec" and how do I go about matching Wildfly
versions with versions of
org.wildfly.arquillian:wildfly-arquillian-container-managed?
Cheers
Mats
Addendum
If someone lands in this page because they have that same problem here is my recommendation: Arquillian Chameleon for the sake of simplicity. Arquillian Chameleon is an automatic container downloader-install-container manager for Arquillian integration tests.
If you're going for the org.wildfly.arquillian:wildfly-arquillian-container-managed, the verion to use with Wildfly 9.0.1.Final is org.wildfly.arquillian:wildfly-arquillian-container-managed:1.0.0.Final.
The easy way to work out what version of Arquillian jars to use with a specific version of WildFly is to look at the WildFly Source on GitHub.
Click on the "Branch: master" button and choose the "Tags" tab.
Look down the list until you find 9.0.1.Final and select it.
Open the pom.xml file and search the page for version.org.wildfly.arquillian.
You will see
<version.org.wildfly.arquillian>1.0.0.Final</version.org.wildfly.arquillian>
which is the version that you're after.
For 10.1.0.Final it says:
<version.org.wildfly.arquillian>1.0.2.Final</version.org.wildfly.arquillian>
which looks like a bug fix release that will likely work just fine with WildFly 9.0.1 as well.
Another way of dealing with versions of container adapters is to use Arquillian Chameleon - it will take care of all the dependencies hurdles for you. The only thing you need to specify is a target container as a property, e.g. wildfly:9.1.0.Final:managed.
For more details have a look in the official repository: https://github.com/arquillian/arquillian-container-chameleon#arquillian-chameleon-container-
Our project is planning to upgrade storm from 0.10.0 to 1.0.2.
Between these versions, storm has changed all package-names from backtype to org.apache
Now we use a couple of 3rd party storm dependencies like storm-jms, https://github.com/HolmesNL/kafka-spout etc.
Some of these projects have plans to upgrade soon to 1.0.2 but some do not have it on their roadmap.
So when we upgrade the storm-version in pom.xml, all those 3rd party dependencies begin to cause compilation errors as they do not find backtype.* packages anymore.
What is the best strategy to proceed in such a case?
Is there a maven-trick published somewhere to change the package names automatically?
In your pom, you can add class relocation (https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html)
The patterns, that you have to use, are in following class -
https://github.com/apache/storm/blob/master/storm-rename-hack/src/main/java/org/apache/storm/hack/StormShadeRequest.java
From Storm web page (https://storm.apache.org/releases/1.0.0/index.html):
NOTE
In the latest version, the class packages have been changed from "backtype.storm" to "org.apache.storm" so the topology code compiled with older version won't run on the Storm 1.0.0 just like that. Backward compatibility is available through following configuration
client.jartransformer.class: "org.apache.storm.hack.StormShadeTransformer"
You need to add the above config in storm installation if you want to run the code compiled with older versions of storm. The config should be added in the machine you use to submit your topologies.
Refer to https://issues.apache.org/jira/browse/STORM-1202 for more details.