You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2022/01/27 17:33:36 UTC
Log4j 1.x replacement
Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the log4j 1.2
support. One of our PMC members has been actively working on migrating his employer’s
applications from Log4j 1.x to log4j-1.2-api and has had great success. We have also
had users experience issues and try the 2.17.2-SNAPSHOT and verify it fixes their problems.
We would love more feedback on the support.
That said, due to the positive experience we have discussed a way to make migration from
log4j 1 to log4j 2 even easier. Our thought has been to publish an artifact as
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j2.version}</version>
This would be part of the log4j 2 release. Thus users could just change the log4j 1 version
in the dependencyManagement section of their parent pom and automatically start using the
bridge.
I’ve personally spoken to a few non-PMC members and gotten positive feedback on the idea,
but I would like more input. One of the issues is what the artifact should contain. Here are
a few options:
1. It is an exact copy of log4j-1.2-api with the binary, source, and javadoc jars renamed to log4j:log4j.
2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
3. Use the relocation trick that SLF4J used to obliterate its log4j-1.2 support. Thus the log4j 1.x
pom.xml would redirect users to the log4j-1.2-api dependency.
Each of these has pros and cons.
1. You have 2 jars with the same stuff. If somehow both are on the classpath one will override
the other, which shouldn’t be a problem if both are the same version.
2. If the jar file is empty it can’t conflict with anything. But it could be confusing to users who
are looking for log4j to find it as an empty jar.
3. It isn’t really clear how well the relocation trick works. SLF4J immediately got 2 Jira issues
created from users who said they were having problems.
So before we implement a solution I would like feedback from the folks who monitor this list.
Thanks,
Ralph
Re: Log4j 1.x replacement
Posted by Matt Sicker <bo...@gmail.com>.
OSGi seems to use re-packaged versions of Log4j2 most of the time
anyways for some reason. See for example
https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499613746/Configuring+Log4J2
On Fri, Feb 18, 2022 at 9:24 AM Ralph Goers <ra...@dslextreme.com> wrote:
>
> It occurs to me that options 1 & 2 may not work well with OSGi and possibly JPMS.
> JPMS will require that the module have a unique name. It would need a module-info
> that specifies it requires org.apache.log4j. But users of this jar would be requesting
> org.apache.log4j and the jar would have to expose some other name. I have no idea
> how well that would work.
>
> I think OSGi would have similar issues that might be even weirder to work around.
>
> Ralph
>
> > On Jan 27, 2022, at 12:30 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > I'd be between options 1 and 2. I'm not a fan of duplicating the jar,
> > though publishing an empty redirect jar isn't ideal either. Given that
> > most of the intractable bugs in v1 were related to how log events are
> > processed which now go through the v2 system, this seems like a good
> > way to continue supporting users stuck on v1 for whatever reason. I
> > assume that as a user, if I'm using 1.2.17, upgrading to 2.17.2 or
> > whatever the next version ends up as, then simply bumping the version
> > will be sufficient to pull in the rest of the Log4j2 dependencies
> > needed here.
> >
> > One potential alternative (though I'm not a fan of this one) would be
> > to combine log4j-api, log4j-core, and log4j-1.2-api into log4j:log4j
> > so it's still a single drop-in jar. That could cause further classpath
> > issues, though, so I'd probably stick in favor of the first two
> > options.
> >
> > On Thu, Jan 27, 2022 at 11:33 AM Ralph Goers <ra...@dslextreme.com> wrote:
> >>
> >> Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the log4j 1.2
> >> support. One of our PMC members has been actively working on migrating his employer’s
> >> applications from Log4j 1.x to log4j-1.2-api and has had great success. We have also
> >> had users experience issues and try the 2.17.2-SNAPSHOT and verify it fixes their problems.
> >>
> >> We would love more feedback on the support.
> >>
> >> That said, due to the positive experience we have discussed a way to make migration from
> >> log4j 1 to log4j 2 even easier. Our thought has been to publish an artifact as
> >>
> >> <groupId>log4j</groupId>
> >> <artifactId>log4j</artifactId>
> >> <version>${log4j2.version}</version>
> >>
> >> This would be part of the log4j 2 release. Thus users could just change the log4j 1 version
> >> in the dependencyManagement section of their parent pom and automatically start using the
> >> bridge.
> >>
> >> I’ve personally spoken to a few non-PMC members and gotten positive feedback on the idea,
> >> but I would like more input. One of the issues is what the artifact should contain. Here are
> >> a few options:
> >>
> >> 1. It is an exact copy of log4j-1.2-api with the binary, source, and javadoc jars renamed to log4j:log4j.
> >> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
> >> 3. Use the relocation trick that SLF4J used to obliterate its log4j-1.2 support. Thus the log4j 1.x
> >> pom.xml would redirect users to the log4j-1.2-api dependency.
> >>
> >> Each of these has pros and cons.
> >> 1. You have 2 jars with the same stuff. If somehow both are on the classpath one will override
> >> the other, which shouldn’t be a problem if both are the same version.
> >> 2. If the jar file is empty it can’t conflict with anything. But it could be confusing to users who
> >> are looking for log4j to find it as an empty jar.
> >> 3. It isn’t really clear how well the relocation trick works. SLF4J immediately got 2 Jira issues
> >> created from users who said they were having problems.
> >>
> >> So before we implement a solution I would like feedback from the folks who monitor this list.
> >>
> >> Thanks,
> >> Ralph
>
Re: Log4j 1.x replacement
Posted by Ralph Goers <ra...@dslextreme.com>.
It occurs to me that options 1 & 2 may not work well with OSGi and possibly JPMS.
JPMS will require that the module have a unique name. It would need a module-info
that specifies it requires org.apache.log4j. But users of this jar would be requesting
org.apache.log4j and the jar would have to expose some other name. I have no idea
how well that would work.
I think OSGi would have similar issues that might be even weirder to work around.
Ralph
> On Jan 27, 2022, at 12:30 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I'd be between options 1 and 2. I'm not a fan of duplicating the jar,
> though publishing an empty redirect jar isn't ideal either. Given that
> most of the intractable bugs in v1 were related to how log events are
> processed which now go through the v2 system, this seems like a good
> way to continue supporting users stuck on v1 for whatever reason. I
> assume that as a user, if I'm using 1.2.17, upgrading to 2.17.2 or
> whatever the next version ends up as, then simply bumping the version
> will be sufficient to pull in the rest of the Log4j2 dependencies
> needed here.
>
> One potential alternative (though I'm not a fan of this one) would be
> to combine log4j-api, log4j-core, and log4j-1.2-api into log4j:log4j
> so it's still a single drop-in jar. That could cause further classpath
> issues, though, so I'd probably stick in favor of the first two
> options.
>
> On Thu, Jan 27, 2022 at 11:33 AM Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the log4j 1.2
>> support. One of our PMC members has been actively working on migrating his employer’s
>> applications from Log4j 1.x to log4j-1.2-api and has had great success. We have also
>> had users experience issues and try the 2.17.2-SNAPSHOT and verify it fixes their problems.
>>
>> We would love more feedback on the support.
>>
>> That said, due to the positive experience we have discussed a way to make migration from
>> log4j 1 to log4j 2 even easier. Our thought has been to publish an artifact as
>>
>> <groupId>log4j</groupId>
>> <artifactId>log4j</artifactId>
>> <version>${log4j2.version}</version>
>>
>> This would be part of the log4j 2 release. Thus users could just change the log4j 1 version
>> in the dependencyManagement section of their parent pom and automatically start using the
>> bridge.
>>
>> I’ve personally spoken to a few non-PMC members and gotten positive feedback on the idea,
>> but I would like more input. One of the issues is what the artifact should contain. Here are
>> a few options:
>>
>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and javadoc jars renamed to log4j:log4j.
>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>> 3. Use the relocation trick that SLF4J used to obliterate its log4j-1.2 support. Thus the log4j 1.x
>> pom.xml would redirect users to the log4j-1.2-api dependency.
>>
>> Each of these has pros and cons.
>> 1. You have 2 jars with the same stuff. If somehow both are on the classpath one will override
>> the other, which shouldn’t be a problem if both are the same version.
>> 2. If the jar file is empty it can’t conflict with anything. But it could be confusing to users who
>> are looking for log4j to find it as an empty jar.
>> 3. It isn’t really clear how well the relocation trick works. SLF4J immediately got 2 Jira issues
>> created from users who said they were having problems.
>>
>> So before we implement a solution I would like feedback from the folks who monitor this list.
>>
>> Thanks,
>> Ralph
Re: Log4j 1.x replacement
Posted by Matt Sicker <bo...@gmail.com>.
I'd be between options 1 and 2. I'm not a fan of duplicating the jar,
though publishing an empty redirect jar isn't ideal either. Given that
most of the intractable bugs in v1 were related to how log events are
processed which now go through the v2 system, this seems like a good
way to continue supporting users stuck on v1 for whatever reason. I
assume that as a user, if I'm using 1.2.17, upgrading to 2.17.2 or
whatever the next version ends up as, then simply bumping the version
will be sufficient to pull in the rest of the Log4j2 dependencies
needed here.
One potential alternative (though I'm not a fan of this one) would be
to combine log4j-api, log4j-core, and log4j-1.2-api into log4j:log4j
so it's still a single drop-in jar. That could cause further classpath
issues, though, so I'd probably stick in favor of the first two
options.
On Thu, Jan 27, 2022 at 11:33 AM Ralph Goers <ra...@dslextreme.com> wrote:
>
> Log4j 2.17.2 is going to contain at least 3 dozen fixes or improvements to the log4j 1.2
> support. One of our PMC members has been actively working on migrating his employer’s
> applications from Log4j 1.x to log4j-1.2-api and has had great success. We have also
> had users experience issues and try the 2.17.2-SNAPSHOT and verify it fixes their problems.
>
> We would love more feedback on the support.
>
> That said, due to the positive experience we have discussed a way to make migration from
> log4j 1 to log4j 2 even easier. Our thought has been to publish an artifact as
>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>${log4j2.version}</version>
>
> This would be part of the log4j 2 release. Thus users could just change the log4j 1 version
> in the dependencyManagement section of their parent pom and automatically start using the
> bridge.
>
> I’ve personally spoken to a few non-PMC members and gotten positive feedback on the idea,
> but I would like more input. One of the issues is what the artifact should contain. Here are
> a few options:
>
> 1. It is an exact copy of log4j-1.2-api with the binary, source, and javadoc jars renamed to log4j:log4j.
> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
> 3. Use the relocation trick that SLF4J used to obliterate its log4j-1.2 support. Thus the log4j 1.x
> pom.xml would redirect users to the log4j-1.2-api dependency.
>
> Each of these has pros and cons.
> 1. You have 2 jars with the same stuff. If somehow both are on the classpath one will override
> the other, which shouldn’t be a problem if both are the same version.
> 2. If the jar file is empty it can’t conflict with anything. But it could be confusing to users who
> are looking for log4j to find it as an empty jar.
> 3. It isn’t really clear how well the relocation trick works. SLF4J immediately got 2 Jira issues
> created from users who said they were having problems.
>
> So before we implement a solution I would like feedback from the folks who monitor this list.
>
> Thanks,
> Ralph
Re: Log4j 1.x replacement
Posted by Ralph Goers <ra...@dslextreme.com>.
Thanks, Ceki. Although the Apache license certainly allows copying code
to anything it is against ASF policy to take code against their author’s wishes.
That said, we have not incorporated anything into log4j-1.2-api that we believe
may have security issues and won’t until we resolve them. Even if we cannot
copy the code that still doesn’t preclude us from coming up with a compatible
solution should we choose to do so.
Ralph
> On Jan 27, 2022, at 1:34 PM, Ceki Gülcü <ce...@qos.ch> wrote:
>
>
> Ralph,
>
> I would like to observe that Vlardimir's JDBCAppender contribution was
> made outside Apache. While the code in question is licensed under the
> ASL, it has not been contributed to the Apache Foundation. Unless the
> foundations rules have changed, you cannot copy the changes without
> Vladimir's permission or mine for that matter. As a person who served in
> the foundation's IP committee, you probably already knew that and it had
> slipped your mind.
>
> In any case and perhaps also in light of the above, the comparison of a
> colleague with a noxious insect in a public mailing list was probably
> not an optimal choice of words.
>
> As for relocating log4j:log4j to log4j12-api, I do not know the exact
> details of the level of compatibility offered by log4j12-api so I will
> refrain from commenting further and risk making a fool of myself.
>
> Best regards,
>
> On 1/27/2022 8:07 PM, Ralph Goers wrote:
>>
>>
>>> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>>
>>>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and
>>> javadoc jars renamed to log4j:log4j.
>>>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>>>
>>> The options are bad as log4j-1.2-api misses several classes that are used a
>>> lot in log4j 1.x deployments.
>>> For instance, org.apache.log4j.jdbc.JDBCAppender.
>>
>> That would put it on par with reload4j 2.18.1. That said, if the JDBCAppender was fixed in
>> reload4j we can either copy it into log4j-1.2-api as a log4j 1.x appender or reimplement
>> it as a log4j 2 appender.
>>
>> If there are other classes that are required you are invited to submit PRs to address them.
>>
>>>
>>> If you release that as log4j:log4j:2.x, then you trigger a lot of
>>> non-workable update suggestions.
>>>
>>> ----
>>>
>>> Then, if you think log4j-1.2-api:2.x is good enough to replace
>>> log4j:log4j:1.x, then you basically say
>>> "all the issues in 1.x can be solved without breaking backward
>>> compatibility".
>>> I am afraid that contradicts Ron's message:
>>> https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
>>
>> It absolutely does not. The issues in Log4j 1.x are in the core of how it processes log
>> events. Log4j 2 doesn’t suffer from any of those issues.
>>
>> Instead of continuing to be a gnat and arguing against Log4j2 you could start being part
>> of the solution and work to improve the bridge.
>>
>> This thread is not about discussing why reload4j is better than log4j-1.2-api. That
>> discussion is over. If you continue on that path you will be put into moderation.
>> However, if you can provide a better way to let users migrate to Log4j2 we will be
>> happy to hear it.
>>
>> Ralph
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Re: Log4j 1.x replacement
Posted by Ceki Gülcü <ce...@qos.ch>.
Ralph,
I would like to observe that Vlardimir's JDBCAppender contribution was
made outside Apache. While the code in question is licensed under the
ASL, it has not been contributed to the Apache Foundation. Unless the
foundations rules have changed, you cannot copy the changes without
Vladimir's permission or mine for that matter. As a person who served in
the foundation's IP committee, you probably already knew that and it had
slipped your mind.
In any case and perhaps also in light of the above, the comparison of a
colleague with a noxious insect in a public mailing list was probably
not an optimal choice of words.
As for relocating log4j:log4j to log4j12-api, I do not know the exact
details of the level of compatibility offered by log4j12-api so I will
refrain from commenting further and risk making a fool of myself.
Best regards,
On 1/27/2022 8:07 PM, Ralph Goers wrote:
>
>
>> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>
>>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and
>> javadoc jars renamed to log4j:log4j.
>>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>>
>> The options are bad as log4j-1.2-api misses several classes that are used a
>> lot in log4j 1.x deployments.
>> For instance, org.apache.log4j.jdbc.JDBCAppender.
>
> That would put it on par with reload4j 2.18.1. That said, if the JDBCAppender was fixed in
> reload4j we can either copy it into log4j-1.2-api as a log4j 1.x appender or reimplement
> it as a log4j 2 appender.
>
> If there are other classes that are required you are invited to submit PRs to address them.
>
>>
>> If you release that as log4j:log4j:2.x, then you trigger a lot of
>> non-workable update suggestions.
>>
>> ----
>>
>> Then, if you think log4j-1.2-api:2.x is good enough to replace
>> log4j:log4j:1.x, then you basically say
>> "all the issues in 1.x can be solved without breaking backward
>> compatibility".
>> I am afraid that contradicts Ron's message:
>> https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
>
> It absolutely does not. The issues in Log4j 1.x are in the core of how it processes log
> events. Log4j 2 doesn’t suffer from any of those issues.
>
> Instead of continuing to be a gnat and arguing against Log4j2 you could start being part
> of the solution and work to improve the bridge.
>
> This thread is not about discussing why reload4j is better than log4j-1.2-api. That
> discussion is over. If you continue on that path you will be put into moderation.
> However, if you can provide a better way to let users migrate to Log4j2 we will be
> happy to hear it.
>
> Ralph
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Re: Log4j 1.x replacement
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jan 27, 2022, at 11:41 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
>> 1. It is an exact copy of log4j-1.2-api with the binary, source, and
> javadoc jars renamed to log4j:log4j.
>> 2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
>
> The options are bad as log4j-1.2-api misses several classes that are used a
> lot in log4j 1.x deployments.
> For instance, org.apache.log4j.jdbc.JDBCAppender.
That would put it on par with reload4j 2.18.1. That said, if the JDBCAppender was fixed in
reload4j we can either copy it into log4j-1.2-api as a log4j 1.x appender or reimplement
it as a log4j 2 appender.
If there are other classes that are required you are invited to submit PRs to address them.
>
> If you release that as log4j:log4j:2.x, then you trigger a lot of
> non-workable update suggestions.
>
> ----
>
> Then, if you think log4j-1.2-api:2.x is good enough to replace
> log4j:log4j:1.x, then you basically say
> "all the issues in 1.x can be solved without breaking backward
> compatibility".
> I am afraid that contradicts Ron's message:
> https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
It absolutely does not. The issues in Log4j 1.x are in the core of how it processes log
events. Log4j 2 doesn’t suffer from any of those issues.
Instead of continuing to be a gnat and arguing against Log4j2 you could start being part
of the solution and work to improve the bridge.
This thread is not about discussing why reload4j is better than log4j-1.2-api. That
discussion is over. If you continue on that path you will be put into moderation.
However, if you can provide a better way to let users migrate to Log4j2 we will be
happy to hear it.
Ralph
Re: Log4j 1.x replacement
Posted by Vladimir Sitnikov <si...@gmail.com>.
>1. It is an exact copy of log4j-1.2-api with the binary, source, and
javadoc jars renamed to log4j:log4j.
>2. The pom.xml has a dependency on log4j-1.2-api and the jar file is empty.
The options are bad as log4j-1.2-api misses several classes that are used a
lot in log4j 1.x deployments.
For instance, org.apache.log4j.jdbc.JDBCAppender.
If you release that as log4j:log4j:2.x, then you trigger a lot of
non-workable update suggestions.
----
Then, if you think log4j-1.2-api:2.x is good enough to replace
log4j:log4j:1.x, then you basically say
"all the issues in 1.x can be solved without breaking backward
compatibility".
I am afraid that contradicts Ron's message:
https://lists.apache.org/thread/dlz8nyrsvffmgq29d354s0l484lfc83w
----
Just in case, as shown in reload4j, all the known CVEs can be **easily**
solved while still being fully backward compatible.
So if you are willing to push something to log4j:log4j:... I would suggest
reconsidering log4j 1.x rather than
faking it with an incompatible jar from 2.x
Vladimir