Log4j 1.x migration to log4j2.x using Log4j 1.x bridge (log4j-1.2-api)

[pchawla]

Hi Team,
We are currently on smartClient v10.0p_2015-06-17 version. We are trying to upgrade our product to log4j2. We are trying the same via the log4j bridge approach(https://logging.apache.org/log4j/2.x...Log4j1.2Bridge).

Isomorphic smart client still has log4j1 as its dependency. Even via the bridge approach, we get runtime issues because not all of the log4j1 APIs are supported via log4j1 bridge. Imports like org.apache.log4j.spi.RootLogger, org.apache.log4j.Hierarchy etc will fail.
Eg:

[catalina-exec-1] org/apache/log4j/spi/RootLogger
java.lang.NoClassDefFoundError: org/apache/log4j/spi/RootLogger
at com.isomorphic.base.Config.<clinit>(Config.java:80) ~[com.isomorphic-isomorphic_core_rpc-10.0.5.jar:?]
at com.isomorphic.base.Base.<clinit>(Base.java:54) ~[com.isomorphic-isomorphic_core_rpc-10.0.5.jar:?]



1. Are there any plans to upgrade the log4j1.x to log4j2.x in future smart client releases, If so, could you please provide which release we can expect this change?
2. If #1 is not planned for any near release, can we atleast get some support from the team. so that isomorphic smart client works with the log4j bridge jar? Atleast to fix the runtime issues that we see after using the log4j bridge jar.

[Isomorphic]

Because of weaknesses in the Java VM, the Log4j 1.0 jar must be present on the classpath, even though it is never used (no classes are instantiated).

This has no impact on your application in any way - no security implications, no performance implications, nothing. It's just a file sitting there.

Nevertheless, we will be working around this dependency in the next release.

[pchawla]

I understand that it does not have any security risk.
But, like I mentioned, we are upgrading our entire product to log4j2 using the log4j bridge approach. Using this route, we cannot have both the log4j bridge jar and the log4j1 jar in the class path. It will not work.
Can we atleast get some support patch so that isomorphic works with the bridge? We are just trying to get past the runtime import issue here.
Its fine even if we dont have log4j2 support right away. We will use slf4j for isc logging using the system variable in the meanwhile. So, we just want to fix the runtime classnotfound issues for the packages that are not present in the log4j bridge.
This is really critical to our release. So, any help on this front is really really appreciated.

[Isomorphic]

Sounds like you have not actually tried putting both in the classpath. They are separate packages, so it just works, and there is nothing to fix.

[pchawla]

We have tried it. The bridge as the name suggest is a bridge between the log4j1 and log4j2 APIs.
Including both log4j1 and the bridge will not work because the package names will be same between them since it's a bridge jar. And the calls might not get routed to the bridge depending on which of the jars load first.
And the problem is that few classes like the spi. Rootlogger are not available in the log4j bridge. And hence the request for a patch to support log4j bridge.

[Isomorphic]

Please see the docs - there is no need to use some kind of "bridging" solution because we support slf4j:

https://www.smartclient.com/smartcli....serverLogging

[pchawla]

The log4j bridge is to migrate to log4j2. Since it's critical for us to migrate to log4j2 asap. For components that we can't migrate, we have included the log4j1 bridge provided by log4j.
So, our components will only have log4j2 jars and the log4j bridge jar. It cannot include the log4j1 jar for reasons mentioned in the previous comment.
And isomorphic fails in this approach because some log4j1 APIs that are used internally do not work with the bridge.

I only mentioned slf4j because we felt if we can atleast get some patch to fix the log4j runtime issues and if isomorphic can work with the bridge, we can use slf4j until we can upgrade to the latest isomorphic releases that will have log4j2 if the need arises for the same later on.

[Isomorphic]

Sorry you’re having trouble, but again, please see the docs above: you can use log4j 2.0 via slf4j. You do not need to use the log4j 1.0 bridge. Since you do not need the bridge, it will no longer be a problem that log4j 1.0 needs to be on the classpath. Clear?

[pchawla]

Apologies if the issue is still not clear, I am not sure how else to explain the problem. Let me try again.

I clearly understand that I can use slf4j for isomorphic logging. And that this does not need any bridge and yes we have tried this out.


But, there are many components in my product that use the log4j bridge. It cannot be removed. The log4j 1 jar will be removed from the product. It will not be available in the classpath.


The log4j1 bridge offically provided by log4j helps in cases where we cant fully update the packages etc to log4j2 like third party libraries that the product uses. The minor limitation with this is that some APIs from log4j1 will not work via the log4j bridge.

But since log4j 1 jar is not available in the product for us, we get runtime issues with isomorphic only for the APIs that the bridge does not support. And hence we need a patch to support this use case.


If the issue is still not clear, please do guide me on the next steps on how to take this forward.

[Isomorphic]

Ah OK, so you are saying that some other system needs to use log4j bridging, not our product.

Unfortunately, this is not a bug, security problem, or limitation in our product, so we cannot simply have an engineer jump on it immediately as we do with any actual bugs.

So you have a few paths forward here:

1. Feature Sponsorship: we can use Java Reflection (CRAPI) to work around the JVM's issue where it requires classes we never actually instantiate. This would be 13.x only of course. Should be pretty inexpensive.

2. you could extend the Log4j bridge with additional stub classes. Because we don't actually use these classes, it's likely that it would be enough to just have the classes present on the classpath. You might even be able to just include the original Log4j classes that the bridge doesn't implement, and have that just work.

3. you could possibly modify the code that relies on the log4j 1.0 APIs to use log4j 2.0 APIs or slf4j. We don't know if this code is under your control

4. like #1, but also backported to 10.1 (which is end-of-lifed). This would be a lot of work on our end, basically maintaining a custom project just for you, but it is a service we offer

Let us know how you'd like to proceed.

[Isomorphic]

Correction here: the requirement to have log4j 1.x on the classpath even when unused was actually eliminated 7 years ago (in 2015), for versions 10.1 and up. So #1/#4 isn't actually needed, you could just update to 10.1 or later, and our server code would no longer be referencing Log4j classes that the designers of the bridge decided to omit and/or failed to stub out.

We are curious, however, as to whether you were already able to work around the incomplete bridge by stubbing some additional classes, as we recommended. Did that work?