Develop Reference

log4j vulnerability with avro-tools-1.9.1.jar

Apache avro scanning shows the log4j vulnerability.
How to get rid of it?
Tried with:
java -jar target/log4j-detector-latest.jar /c/workspace/sampleApp
-- github.com/mergebase/log4j-detector v2021.12.29 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
C:\workspace\sampleApp\target\SampleApp\WEB-INF\lib\avro-tools-1.9.1.jar contains Log4J-1.x <= 1.2.17 OLD
I have tried to upgrade to avro-tools version 1.11.0 that too shows the same issue.

You can modify the JAR file and delete the following files that belong to log4j 1.x within the JAR file to mitigate the vulnerabilities. They are present in the folder /org/apache/log4j/net/ within the JAR:
JMSAppender.class
SocketServer.class
SocketAppender.class
SMTPAppender.class
SMTPAppender$1.class
Once deleted these classes can no longer be used by a log4j logging configuration (which is the way to trigger the vulnerabilities).
If the application does not work after the modification it needs to be migrated to use a newer log4j 2.x version: Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later)) - see https://logging.apache.org/log4j/2.x/

BundleException while trying to start an osgi bundle

I'm trying to install & start a bundle from a osgi jar in the filesystem
Bundle bundle = context.installBundle("reference:file:" + fullPath);
bundle.start();
it worked for another simple bundle, but another more complex bundle has
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
in its manifest
this causes the following exception
(org.osgi.framework.BundleException) org.osgi.framework.BundleException: Unresolved constraint in bundle
Unable to resolve 42.0: missing requirement [42.0] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))
how do I add this capability to my project?
also how would I remove this require from the other project?
all similiar questions I found didn't answer my question
thanks in advance for any answers and for helping me not pull out my hair :)
Edit:
as christian suggested I tried finding the configuration to felix in netbeans, as the felix framework is loaded by netbeans. I found some configurations inside the maven POM file, but could not use the "org.osgi.framework.system.capabilities" framework property which was mentioned by christian, which I couldn't find in the documentation.
I am putting a bounty as this is really important for me to resolve and is the only thing preventing me from using OSGi as far as I can see

The capability you identified:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
is a requirement for the osgi.ee namespace. This is the namespace which defines the execution environment for your framework. The filter then says that you need the execution environment to be JavaSE, and that you need the version attribute to be 1.8. This (unsurprisingly) corresponds to Java SE 8.
As others have indicated, this capability should be provided by the OSGi framework. You should not need to do anything to get this to happen. There are two main reasons that this capability would not be present.
You are using an older, or non SE, version of Java. This could easily happen if your NetBeans launch configuration is not using a Java 8 installation.
You are using a Felix framework which does not understand "new" versions of Java. This could be because your Felix framework is old (the latest version is 5.6.4) or because your Java version is very new (are you using a pre-release Java 9 build?).
This really should just work if you can run a newish Felix framework on top of Java 8. Do you have any more details about your environment?
Edit:
You can see the osgi.ee capability provided by the system bundle as follows:
// Get the wiring for the system bundle
BundleWiring wiring = context.getBundle(0).adapt(BundleWiring.class);
// Get the osgi.ee capability for the system bundle
List<Capability> eecaps = wiring.getCapabilities("osgi.ee");
// There must be exactly one capability to show
System.out.println(eecaps.get(0).getAttributes());

This is a capability that needs to be provided by your framework. It means that your project needs to run on Java 8.
It is configured in the framework property:
org.osgi.framework.system.capabilities=osgi.ee; osgi.ee="JavaSE"; version:List<Version>="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"
That said normally this is already configured when you for example start the felix distro.

This is a known felix bug which has been fixed in 2.0.4. From http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.bundlerepository-2.0.10/doc/changelog.txt ,
Changes from 2.0.2 to 2.0.4
---------------------------
** Bug
* [FELIX-3097] - LocalRepository is not updated when bundles are
* [FELIX-4571] - NullPointerException when using Repository impl with Aries subsystem impl
* [FELIX-4616] - BundleRepository ResourceComparator violates comparison contract
* [FELIX-4640] - missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
** Improvement
* [FELIX-4812] - BundleRepository can be quite CPU intensive when starting a lot of bundles

Log4j 2.8 cannot load custom converters in OSGi environment

I'm currently switching to log4j2 and I'm working in OSGi environment. There's been couple of issues with OSGi in log4j 2.7 branch which encouraged me to grab 2.8 as the final library.
The thing is I have couple of custom PatternConverters implemented in my project and I can't manage to have them loaded and recognized
DEBUG Initializing configuration XmlConfiguration[location=C:\Program Files\...\etc\log4j2.xml]
.
.
DEBUG Took 0,001043 seconds to load 0 plugins from package common.audit.sink.impl.log4j2.converter
although there's at least 10 of them. This later results in errors like:
DEBUG Building Plugin[name=layout, class=org.apache.logging.log4j.core.layout.PatternLayout].
DEBUG PatternLayout$Builder(pattern="%ED;...
ERROR Unrecognized format specifier [ED]
ERROR Unrecognized conversion specifier [ED] starting at position 3 in conversion pattern.
I have pretty much everything set up as necessary (it worked with 2.7 anyways).
The plugin implementation annotated and both newInstance, format methods implemented according to this guide
The packages declaration in log4j2.xml:
<Configuration status="trace" name="Systemtest_Server" packages="common.audit.sink.impl.log4j2.converter">
The plugins metadata is generated and present in *.jar bundle containing plugins
META-INF\org\apache\logging\log4j\core\config\plugins\Log4j2Plugins.dat
The log4j-core-2.8.jar bundle is activated together with log4j-api-2.8.jar at the startup of Equinox container. The configuration file is pointed by system property and works (obviously from the debug message I receive).
However, I found this issue reported on log4j Jira, which is kind of my problem as I was facing the same exception until I modified log4j-api-2.8.jar to make it import org.apache.logging.log4j.core.util package so my server would start normally. There are some comments suggesting that this might lead to non-extensibility of log4j2 in OSGi.
So is there some way how to overcome this issue (quick fix is enough)? Alternatively, is there something that I might be forgetting to configure here?
Thanks a lot for any help.

Ok, so I'm gonna answer this for myself and maybe it will help somebody too. I did a lot of playing around and the fault was in OSGi with which I'm not so familiar, to be honest.
I found out in the end that you have to ensure these things:
The bundle has to be activated in OSGi container. Inactive bundles are not scanned for plugins. The fact that you mark bundle for activation in your configuration doesn't necessarily mean it will actually happen. E.g., some fault in my bundle's manifest prevent this from happening. So to be sure I build bundle with
Export-Package: common.audit.sink.impl.log4j2.*
Import-Package: *
At least one of following has to hold to get your plugins loaded:
Your bundle with custom plugins is a fragment of log4j-core by stating this in its manifest:
Fragment-Host: org.apache.logging.log4j.core
Probably the right approach.
Your bundle is activated with the same priority as log4j bundles (not only API but also Core needs to be active to enable plugin-search)
Of course the configuration mentioned in my question is needed as well. After this I got no errors and saw a trace like this:
DEBUG Oracle Nashorn Version: 1.8.0_102, Language: ECMAScript, Threading: Not Thread Safe, Compile: true, Names: {nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript}
DEBUG Took 0,008133 seconds to load 16 plugins from package common.audit.sink.impl.log4j2.converter
DEBUG PluginManager 'Core' found 112 plugins
DEBUG PluginManager 'Level' found 0 plugins
...
DEBUG Building Plugin[name=layout, class=org.apache.logging.log4j.core.layout.PatternLayout].
DEBUG PatternLayout$Builder(pattern="%ED;%EU;%EL;...
DEBUG Building Plugin[name=appender, class=org.apache.logging.log4j.core.appender.FileAppender].

LogConfigurationException when using HttpClient

When my code executes this line:
DefaultHttpClient httpclient = new DefaultHttpClient();
I'm getting this Exception:
org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JLogger does not implement Log
does somebody know how can I solve that?
Maybe is not important (or maybe it is), but the app is a plugin for Jira, and is using Maven for the dependencies.
Thanks !
EDIT:
EDIT 2:
Could this be related with OSGi from Jira?
How can I use commons-logging in an OSGi environment?
From here:
http://wiki.apache.org/commons/Logging/FrequentlyAskedQuestions
Commons-logging was not designed with OSGi in mind. This is why it is
difficult to get commons-logging working in OSGi environments:
LogFactory loads Log implementations by name (see
Class.forName(String)). This is usually not possible in OSGi since
every bundle classloader can only see the classes a bundle defines
imports for. The bundle class loader that loads the commons-logging
bundle will not have access to user provided
commons-logging.properties files. commons-logging-api.jar contains
classes that are also included in commons-logging.jar. This is
contrary to traditional OSGi application architectures where one
bundle defines an API and other bundles provide implementations for
that API. There alternatives to using commons-logging directly in OSGi
are:
Rebundled versions that contain proper OSGi meta data are available
from Apache Felix, SpringSource and Eclipse Orbit. Using Pax logging.
Further information about this topic is available in the archives of
the commons dev ML and the felix dev ML and in Jira.
and when I try to access to the OSGi tab from Jira (going to JIRASERVER/plugins/servlet/upm/osgi#osgi) I can see an exception:
classNotFoundException: org.apache.commons.logging.impl.SLF4JLogFactory
And also I can see from the IDE (when searching for Log4JLogger class) that I have two definitions:
package org.apache.commons.logging.impl.Log4JLogger
public class Log4JLogger implements Log, Serializable {
and
package com.atlassian.extras.common.log;
class Log4jLogger implements com.atlassian.extras.common.log.Logger.Log {
this is really confusing....

I'm not sure, but could it be that the logger you configured does not correspond to the logger in your pom dependencies? Perhaps a different version?

java.util.logging, ResourceBundles, SAAJ: exception on loading Glassfish OSGi webapp bundle

I'm being driven out of my mind by the following exception:
java.lang.IllegalArgumentException:
com.sun.xml.messaging.saaj.soap.LocalStrings != com.sun.xml.internal.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:357)
at com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMetaFactoryImpl.java:41)
It's occurring when I try to deploy a WAB (web application OSGi bundle) to Glassfish (3.1.1).
I'm trying to use an up-to-date version of SAAJ (com.sun.xml.messaging.saaj...) rather than the old JDK one (which is the com.sun.xml.internal.saaj... one), by putting the string com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl in the file META-INF/services/javax.xml.soap.MessageFactory.
It appears there is some logging going on before the OSGi classloading kicks in, and therefore the 'wrong' ResourceBundle is being returned during initialization of the static log field of com.sun.xml.messaging.saaj.soap.MessageFactoryImpl (SAAJ's implementation of javax.xml.soap.MessageFactory).
Anyone seen this / any workarounds on offer?

Never got to the bottom of this, but manifest voodoo eventually made it go away (with all of the javax.xml.ws / javax.ws.rs packages in Import-Package rather than on the bundle classpath WEB-INF/lib).
It was also possible to work around it by using
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
on Glassfish startup, though obviously this forces that implementation on all users of MessageFactory.

See: JDK-6741342 : Logger.getLogger() throws java.lang.IllegalArgumentException on saaj classes.
Instead, it's related to the introduction of saaj into JDK 6.....and the workaround involved re-ordering jars.