jbonofre's blog

Apache Karaf OSGi runtime 4.4.3 has just been released. Let's take a quick look on the main highlights ;) You can download Karaf here: https://karaf.apache.org/download.html . The full release notes are available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12352267 . Fix threads leak in karaf-maven-plugin:verify The karaf-maven-plugin provides a convenient goal to verify Karaf features. It's simple way to verify that features: are complete, with all requirements resolved reference valid other features can be installed on a runtime without issue Karaf itself (and its subprojects) is using karaf-maven-plugin:verify to verify its own features. You can easily use the verify goal in your project, like this in your pom.xml : <plugin> <groupId>org.apache.karaf.tooling</groupId> <artifactId>karaf-maven-plugin</artifactId> <

Apache Karaf runtime 4.4.0 has been released, and it's a new milestone on the Karaf runtime roadmap. We change the major version numbering when significant changes and updates are including in a release. It's the case for 4.4.0, starting the 4.4.x series. Let's take a quick tour on Karaf 4.4.x. OSGi R8 Karaf 4.4.x is now powered by OSGi R8 specification. It means that Felix Framework and Equinox have been upgraded to support this OSGi release: Apache Felix Framework 7.0.3 Equinox 3.17.200 Karaf 4.4.x also doesn't use OSGi compendium artifact anymore: it now uses artifacts for each "atomic" service bundles. It's much more flexible, installing exactly the required bundle instead of having systematically the "uber" compendium bundle. OSGi R8 core doesn't bring big changes in the Karaf context, but two additions are interesting though: Condition service: in OSGi, a condition is simply a component, that registers the marke

Finally, after several months of work, Apache ActiveMQ 5.17.0 has been released. This is a major milestone in Apache ActiveMQ roadmap, bringing lot of changes, and already preparing ActiveMQ 5.18.x. Let's take a quick tour on some major changes in ActiveMQ 5.17.0. JDK 11+ If ActiveMQ 5.16.x already supported JDK 11+ at runtime, the build was still using JDK 8. ActiveMQ 5.17.0 now requires JDK 11+ for both build and runtime. Spring 5.x Before ActiveMQ 5.17.0, we used Spring 4.x, a deprecated (not maintained) version of Spring. It was a concern as Spring 5.x includes improvements and fixes, especially CVE fixes. So, it made sense to bump to Spring 5.x (latest available major version right now). From an user standpoint, nothing change, the main conf/activemq.xml is basically the same. Log4j 2.x If ActiveMQ 5.16.4 switched from log4j 1.x to reload4j, in order to fix CVE issues (see Apache ActiveMQ 5.16.4, reload4j and more for details). In ActiveMQ 5.17.x, we decided

Apache ActiveMQ 5.16.4 has just been released. This release is an important one on ActiveMQ 5.16.x series, bringing several important changes/fixes. Reload4j replaces log4j Apache ActiveMQ 5.16.3 is using log4j 1.x. If this log4j version is not impacted by log4shell vulnerability, it's affected by several security issue. reload4j ( https://reload4j.qos.ch/ ) is a fork of log4j 1.2.17 with the goal of fixing pressing security issues. Apache ActiveMQ 5.16.4 now uses reload4j 1.2.19, bringing the following security fixes compared to log4j 1.2.17: CVE-2021-4104 (JMSAppender) CVE-2022-23302 (JMSSink) CVE-2019-17571 (SocketServer) CVE-2020-9493 and CVE-2022-23307 (Chainsaw) 2022-23305 (JDBCAppender) broken MDC in newer JDKs XML entity injection attack CVE-2020-9488 (SMTPAppender) There's no impact for users: the conf/log4j.properties configuration file is the same as before, just the jar files changed. If ActiveMQ 5.17.x will use log4j 2.x, ActiveMQ

You probably heard about security issue concerning log4j. This vulnerability in log4j is called log4shell. Basically, log4shell exploit gives attackers a simple way to execute code on any vulnerable machine. To exploit the vulnerability, an attacker has to cause the application to save a special string of characters in the log. The log4j community quickly fix this issue by releasing corrected version, starting from log4j 2.15.0 up to 2.17.0. In Apache Karaf runtime, we don't directly use log4j (or any logging framework). Karaf leverages Pax Logging which abstract/package the logging framework in a central logging service. Pax Logging API bundle reshape log4j, logback, slf4j, etc packages. The first step to do is to upgrade the log4j packages in Pax Logging and cut new Pax Logging releases. It's what we did: Pax Logging 2.0.12 has been released, upgrading to log4j 2.17.0 (fixing CVE-2021-45105 and CVE-2021-44228) and logback 1.2.9 (fixing CVE-2021-42550) Pax Logg

Apache Karaf Decanter 2.8.0 has just been released. This release includes several fixes, improvements, and dependency updates. I encourage all Decanter users to update to 2.8.0 release ;) In this blog post, I will highlight some important changes and fixes we did in this release. Prometheus appender The Prometheus appender has been improved to expose more gauges. As reminder, the Decanter Prometheus appender is basically a servlet that expose Prometheus compliant data, that Prometheus instances can poll to get the latest updated metrics. Prometheus appender only looking for numeric data (coming from the Decanter collectors) to create and expose gauges. Unfortunately, in previous Decanter releases, Prometheus appender only looking for numeric value for "first level" properties. It means if a collected data property value was a Map , no inner data was considered by Prometheus appender, even if inner values were numeric. That's the first improvem

Apache Karaf runtime 4.3.3 has been released. This release contains a bunch of fixes, dependency updates, and improvement. I will share some highlights in this release. You can download Apache Karaf runtime here: http://karaf.apache.org/download.html . The release notes are available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12350142 . JDK17 support for build and runtime Karaf 4.3.3 now fully supports JDK17 both at build time and runtime. For JDK17 support, we did: new ASM version new JDK options at runtime new packages exported by Karaf Cleanly close SSH connection We identified an issue with the Karaf SSH connections. The SSH connections were not cleanly close, and we had to wait the timeout to close the socket. It means that we can have this state once the SSH client disconnects: $ netstat | grep 8101 tcp6 0 0 localhost:8101 localhost:47844 CLOSE_WAIT 4.3.3 fixes