Re: [logging-log4j2] branch release-2.x updated: LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of formatted message data

ache.org/repos/asf/logging-log4j2.git > > > The following commit(s) were added to refs/heads/release-2.x by this push: > new 487588b LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of > formatted message data > 487588b is described below > > commit 487588b7c34bc0b

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

OK. I was not aware of this. I thought that it was the Java 9 implementation (StackLocator/ProcessIdUtil) that caused the problem. On 2017-12-03 06:30, Ralph Goers wrote: Let’s go back to this post. Assume we figured out how to get rid of all the stuff you consider to be not required to be

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Yes, log4j-core-android would be a good idea. But yes, we have to solve the API problem first. On 2017-12-02 17:40, Ralph Goers wrote: FWIW, it would make sense to me to make a log4j-core-android that is a subset of what is in core, if that is possible. Of course, the API problem has to be

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

The problem is that we cannot just remove stuff from log4j-api now, since that would break binary/source compatibility for existing users. If I understand it correctly, due to the Java 9 modules, if we move stuff from log4j-api to log4j-core we have to change package, right? And we don't want

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Let’s go back to this post. Assume we figured out how to get rid of all the stuff you consider to be not required to be in the API. Even if we did that it still would not work in Android so long as the API contains module-info.java, because that class can only be compiled for Java 9. So

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

JNA does the same kind of magic to extract DLLs IIRC but that is for the lib path, not the classpath. Gary On Sat, Dec 2, 2017 at 5:01 PM, Remko Popma wrote: > On second thought, without a custom class loader we’d first need to copy > these classes into the classpath. >

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

On second thought, without a custom class loader we’d first need to copy these classes into the classpath. This may not always be possible and sounds like a bad idea anyway. So please ignore my previous email. On Sun, Dec 3, 2017 at 8:38 Remko Popma wrote: > > > On Dec

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

> On Dec 3, 2017, at 1:38, Ralph Goers wrote: > > I see several issues: > > StackLocator: >This cannot be removed from the API is the API as LogManager.getLogger() > calls it. Converting the Java 9 version to use Reflection would add enough > overhead that it

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

I suppose we could have the log4j-api have a transitive dependency on log4j-api-java9 only when the build target is Java 9. Ralph > On Dec 2, 2017, at 3:03 PM, Ralph Goers wrote: > > So this is the other problem. It is complaining that it doesn’t support Java > 9

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

So this is the other problem. It is complaining that it doesn’t support Java 9 class files. That would be module-info.java I am sure. Ralph > On Dec 2, 2017, at 2:02 PM, Gary Gregory wrote: > > Here you go, from one of my work projects: > > [WARNING] Unable to process

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Here you go, from one of my work projects: [WARNING] Unable to process class module-info.class in JarAnalyzer File C:\Users\ggregory\.m2\repository\org\slf4j\slf4j-api\1.8.0-alpha2\slf4j-api-1.8.0-alpha2.jar org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

I think Slf4j 1.8-alpha has the same problem, not 100% sure. Gary On Sat, Dec 2, 2017 at 11:03 AM, Matt Sicker wrote: > Are there other Java 9 ready libraries that are having the same problem in > Android? > > On 2 December 2017 at 10:40, Ralph Goers

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Are there other Java 9 ready libraries that are having the same problem in Android? On 2 December 2017 at 10:40, Ralph Goers wrote: > FWIW, it would make sense to me to make a log4j-core-android that is a > subset of what is in core, if that is possible. Of course,

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

FWIW, it would make sense to me to make a log4j-core-android that is a subset of what is in core, if that is possible. Of course, the API problem has to be solved first. Ralph > On Dec 2, 2017, at 9:38 AM, Ralph Goers wrote: > > I see several issues: > >

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

I see several issues: StackLocator: This cannot be removed from the API is the API as LogManager.getLogger() calls it. Converting the Java 9 version to use Reflection would add enough overhead that it probably wouldn’t be worth it to use it. Also, you would have to figure out how to

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Ok, you have some fair points there. Main take-away for me is that if we want Log4j2's API to become ubiquitous it needs to be at least painless for everyone. Don't known about the "too much stuff" in log4j-api - bit vague and not actionable. What can we do, concretely? log4j-api - 1)

Re: log4j-to-slf4j

It would be impossible to support Logback without pulling in slf4j-api, and the extra jars is what causes the perception of a problem. On 26 September 2017 at 03:20, Remko Popma wrote: > Sounds to me that Ralph's analysis shows that doing the binding ourselves > may not

Re: log4j-to-slf4j

Sounds to me that Ralph's analysis shows that doing the binding ourselves may not be worth doing since we can't get an advantage by either improving people's perception nor improve performance. Unless I'm missing something. > On Sep 26, 2017, at 16:34, Mikael Ståldal

Re: log4j-to-slf4j

I don't think we should support binding to Logback specifically. We should support binding to any SLF4J implementation (including Logback). We should probably test this with Logback though, since it's one of the most popular SLF4J implementations. On 2017-09-26 03:58, Matt Sicker wrote:

Re: log4j-to-slf4j

> On Sep 25, 2017, at 6:58 PM, Matt Sicker <boa...@gmail.com> wrote: > > Would it be possible to make a log4j-api provider that binds directly to > logback instead? > > On 25 September 2017 at 18:54, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >>

Re: log4j-to-slf4j

Would it be possible to make a log4j-api provider that binds directly to logback instead? On 25 September 2017 at 18:54, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I have been looking at the log4j-to-slf4j binding and am rethinking > changing it. There really isn’t much to SL

Re: log4j-to-slf4j

Understood about the log4j-to-slf4j diagram. About updating the performance page, I haven't been able to spend much time on Log4j2 recently. When I did have time it has gone mostly into bug fixes. If you have done this before you probably know this, but doing these performance investigations

Re: log4j-to-slf4j

m/a/41500347/1446916 > <https://stackoverflow.com/a/41500347/1446916> show some people perceive the > log4j-to-slf4j module as a facade for a facade. > > If we bind directly, perhaps I should update this diagram to have a direct > arrow from log4j-to-slf4j to SLF4J implementation? &

Re: log4j-to-slf4j

Ok I see now. It would certainly be good to have more ammunition to argue for using the Log4j2 API directly. Comments on StackOverflow https://stackoverflow.com/a/41500347/1446916 show some people perceive the log4j-to-slf4j module as a facade for a facade. If we bind directly, perhaps I

log4j-to-slf4j

In looking at the implementations of log4j-slf4j-impl and log4j-to-slf4j is strikes me that log4j-to-slf4j is binding to the SLF4J API while log4j-slf4j-impl is binding the SFL4J API to the log4j implementation using SLF4J’s binding mechanism. So it seems to me that instead of having log4j

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

Darn! I should have written LOG4J2-796 instead of 807. Is there any way to fix a commit message? On Fri, Sep 5, 2014 at 1:18 AM, rpo...@apache.org wrote: Repository: logging-log4j2 Updated Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

, Sep 5, 2014 at 1:18 AM, rpo...@apache.org wrote: Repository: logging-log4j2 Updated Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/33fdc826 Tree: http://git

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

instead of 807. Is there any way to fix a commit message? On Fri, Sep 5, 2014 at 1:18 AM, rpo...@apache.org wrote: Repository: logging-log4j2 Updated Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/33fdc826 Tree

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

written LOG4J2-796 instead of 807. Is there any way to fix a commit message? On Fri, Sep 5, 2014 at 1:18 AM, rpo...@apache.org wrote: Repository: logging-log4j2 Updated Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

message? On Fri, Sep 5, 2014 at 1:18 AM, rpo...@apache.org wrote: Repository: logging-log4j2 Updated Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/33fdc826 Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/33fdc826

Re: [1/3] git commit: LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger

Branches: refs/heads/master 114ae7526 - e54cb498d LOG4J2-807: Fixed issue where log4j-to-slf4j did not work correctly with SLF4J Simple Logger Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/33fdc826

[jira] [Resolved] (LOG4J2-334) rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j

earlier and no one else has shown interest. rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j Key: LOG4J2-334 URL: https://issues.apache.org/jira/browse/LOG4J2-334

[jira] [Created] (LOG4J2-334) rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j

Hervé Boutemy created LOG4J2-334: Summary: rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j Key: LOG4J2-334 URL: https://issues.apache.org/jira/browse/LOG4J2-334 Project: Log4j 2

[jira] [Commented] (LOG4J2-334) rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j

several months ago to have all artifacts start with log4j- rename Log4j 2 SLF4J binding from log4j-slf4j-impl to slf4j-to-log4j Key: LOG4J2-334 URL: https://issues.apache.org/jira

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

that exception. IMO, this seems incorrect. Log4JLoggerFactory should just be allowed to propagate. I really think ONLY ClassNotFoundException should be caught here. Any other exceptions should be allowed to propagate. Preempt StackOverflowEx when both slf4j-impl jar and log4j

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

be allowed to propagate. + NoClassDefFoundError should just be allowed to propagate. Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

the logic now only catches ClassNotFoundEx. Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key: LOG4J2-230

[jira] [Comment Edited] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key: LOG4J2-230 URL: https://issues.apache.org/jira/browse/LOG4J2-230

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

ever make it past that catch statement?) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key: LOG4J2-230 URL

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

; } catch (Throwable classNotFoundIsGood) { // org.slf4j.helpers.Log4JLoggerFactory is not on classpath. Good! } if (misconfigured) { throw new IllegalStateException(slf4j-impl jar is mutually exclusive with log4j-to-slf4j jar

[jira] [Resolved] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

standalone test now throws the expected error, so I'm marking this issue as fixed. Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

org.slf4j.Logger; import org.slf4j.LoggerFactory; // at a minimum, set classpath to include: // slf4j-api-1.7.2.jar // log4j-api-2.0-beta6-SNAPSHOT.jar // log4j-slf4j-impl-2.0-beta6-SNAPSHOT.jar // log4j-to-slf4j-2.0-beta6-SNAPSHOT.jar public class Slf4jTest { public static void main(String[] args

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

! Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key: LOG4J2-230 URL: https://issues.apache.org/jira/browse

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

. D) In a finally block, delete the %temp%/%unitTestName% directory. Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key

[jira] [Commented] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

NoClassDefFoundError. Actually I kind of like having the variable there, makes it more self-documenting. 2) I was thinking of a different solution but I realized that my idea would only work during the maven build. When the JUnit tests for either log4j-to-slf4j or for slf4j-impl are run in isolation

[jira] [Created] (LOG4J2-230) Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath

Remko Popma created LOG4J2-230: -- Summary: Preempt StackOverflowEx when both slf4j-impl jar and log4j-to-slf4j jar are on the classpath Key: LOG4J2-230 URL: https://issues.apache.org/jira/browse/LOG4J2-230

Re: svn commit: r1431434 - in /logging/log4j/log4j2/trunk: core/src/main/java/org/apache/logging/log4j/core/config/plugins/ core/src/main/java/org/apache/logging/log4j/core/net/ log4j-to-slf4j/src/tes

/trunk/log4j-to-slf4j/src/test/java/org/apache/logging/slf4j/LoggerTest.java logging/log4j/log4j2/trunk/log4j12-api/src/test/java/org/apache/log4j/LoggerTest.java Modified: logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java URL

Re: svn commit: r1431434 - in /logging/log4j/log4j2/trunk: core/src/main/java/org/apache/logging/log4j/core/config/plugins/ core/src/main/java/org/apache/logging/log4j/core/net/ log4j-to-slf4j/src/tes

/config/plugins/ResolverUtil.java logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SMTPManager.java logging/log4j/log4j2/trunk/log4j-to-slf4j/src/test/java/org/apache/logging/slf4j/LoggerTest.java logging/log4j/log4j2/trunk/log4j12-api/src/test/java/org

Re: svn commit: r1431434 - in /logging/log4j/log4j2/trunk: core/src/main/java/org/apache/logging/log4j/core/config/plugins/ core/src/main/java/org/apache/logging/log4j/core/net/ log4j-to-slf4j/src/tes

/src/main/java/org/apache/logging/log4j/core/net/SMTPManager.java logging/log4j/log4j2/trunk/log4j-to-slf4j/src/test/java/org/apache/logging/slf4j/LoggerTest.java logging/log4j/log4j2/trunk/log4j12-api/src/test/java/org/apache/log4j/LoggerTest.java Modified: logging/log4j/log4j2/trunk

Re: svn commit: r1431434 - in /logging/log4j/log4j2/trunk: core/src/main/java/org/apache/logging/log4j/core/config/plugins/ core/src/main/java/org/apache/logging/log4j/core/net/ log4j-to-slf4j/src/tes

. Modified: logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java logging/log4j/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/net/SMTPManager.java logging/log4j/log4j2/trunk/log4j-to-slf4j/src/test/java/org/apache/logging

cvs commit: logging-log4j/src/slf4j/org/slf4j LoggerFactory.java

carnold 2005/05/17 21:36:25 Modified:.build.properties.sample build.xml src/slf4j/org/apache/log4j ULogger.java src/slf4j/org/slf4j LoggerFactory.java Log: Bug 34883: SLF4J support updated for beta3 (o.s.Logger instead of o.s.ULogger

cvs commit: logging-log4j/src/slf4j/org - New directory

carnold 2005/05/11 20:46:10 logging-log4j/src/slf4j/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: logging-log4j/src/slf4j/org/slf4j - New directory

carnold 2005/05/11 20:46:24 logging-log4j/src/slf4j/org/slf4j - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: logging-log4j/src/slf4j/org/apache - New directory

carnold 2005/05/11 20:46:57 logging-log4j/src/slf4j/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: logging-log4j/src/slf4j/org/apache/log4j - New directory

carnold 2005/05/11 20:47:06 logging-log4j/src/slf4j/org/apache/log4j - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]