You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2017/12/01 14:53:54 UTC
[Log4j] Apache HttpClient 5, Log4j and Slf4j
Hi All:
I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
the mess Java 9 has made of the META-INF folder and our adding support for
Java 9 modules perhaps too soon.
Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on that
thread please.
Gary
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Mikael Ståldal <mi...@apache.org>.
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 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 there really is no way to provide decent support for Java 9 and android at the same time.
>
> According to Gary’s findings, even if HttpClient switches to SLF4J they are going to be in the same boat with the 1.8.x releases.
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 there really is no way to provide decent support for Java 9 and android at the same time.
According to Gary’s findings, even if HttpClient switches to SLF4J they are going to be in the same boat with the 1.8.x releases.
Ralph
> On Dec 2, 2017, at 4:09 AM, Mikael Ståldal <mi...@apache.org> wrote:
>
> I fully understand Oleg's point of view.
>
> If we aim for Log4j 2's API to be the standard logging API/facade for Java/JVM (eventually replacing SLF4J), then we have painted ourselves into a corner by allowing log4j-api to grow out of bounds, and not paying enough attention to the compatibility problems with Android (and possibly fringe platforms) it causes.
>
> It is quite pointless to blame this on Android and its tooling. We can, and should raise issues we find on Android tooling, and hope for them to eventually get fixed. But that can take time, and at the end of the day Android is what it is, and that's what users are going to use. If log4j-api does not work on Android, most users will blame Log4j and not Android.
>
> And if a library with use cases both on standard Java and on Android, like Apache HttpClient, have a required dependency on log4j-api and that causes it to fail on Android, most users will blame HttpClient and not Android (nor Log4j since they may be unaware of it).
>
> If I were maintainer of Apache HttpClient, I would also be very hesitant to make it depend on log4j-api at this point. I don't think it is constructive to just try to convince them given the current state of Log4j and the Android tooling, we need to do some work on our end first (or possibly volunteer to spend some effort on fixing the Android tooling).
>
> I think that the root cause is not Java 9 support, it is that we have allowed too much stuff to go into log4j-api (instead of log4j-core), and that started long before the Java 9 work. JMX is also incompatible with Android, regardless of Java 9.
>
> With a thinner log4j-api, we could have added Java 9 support to log4j-core only, and avoided this problem.
>
>
> On 2017-12-01 15:53, Gary Gregory wrote:
>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>> the mess Java 9 has made of the META-INF folder and our adding support for
>> Java 9 modules perhaps too soon.
>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on that
>> thread please.
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Mikael Ståldal <mi...@apache.org>.
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 solved first.
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> wrote:
>
> 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 <ga...@gmail.com> wrote:
>>
>> 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
>> at org.apache.bcel.classfile.Constant.readConstant (Constant.java:167)
>> at org.apache.bcel.classfile.ConstantPool.<init> (ConstantPool.java:66)
>> at org.apache.bcel.classfile.ClassParser.readConstantPool
>> (ClassParser.java:239)
>> at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:144)
>> at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze
>> (JarClassesAnalysis.java:96)
>> at
>> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails
>> (Dependencies.java:259)
>> at
>> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed
>> (DependenciesRenderer.java:1542)
>> at
>> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails
>> (DependenciesRenderer.java:545)
>> at
>> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
>> (DependenciesRenderer.java:240)
>> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
>> (AbstractMavenReportRenderer.java:83)
>> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
>> (DependenciesReport.java:201)
>> at org.apache.maven.reporting.AbstractMavenReport.generate
>> (AbstractMavenReport.java:255)
>> at
>> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
>> (ReportDocumentRenderer.java:229)
>> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
>> (DefaultSiteRenderer.java:337)
>> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
>> (SiteMojo.java:178)
>> at org.apache.maven.plugins.site.render.SiteMojo.execute
>> (SiteMojo.java:132)
>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
>> (DefaultBuildPluginManager.java:134)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:208)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:154)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:146)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>> (LifecycleModuleBuilder.java:117)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>> (LifecycleModuleBuilder.java:81)
>> at
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>> (SingleThreadedBuilder.java:51)
>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>> (LifecycleStarter.java:128)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke
>> (NativeMethodAccessorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>> (DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke (Method.java:498)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
>> (Launcher.java:289)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
>> (Launcher.java:229)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
>> (Launcher.java:415)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.main
>> (Launcher.java:356)
>>
>> Gary
>>
>> On Sat, Dec 2, 2017 at 11:49 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> 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 <bo...@gmail.com> 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 <ra...@dslextreme.com>
>>>> 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 solved first.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>> On Dec 2, 2017, at 9:38 AM, Ralph Goers <ra...@dslextreme.com>
>>>>> 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 probably wouldn’t be worth
>>>> it
>>>>> to use it. Also, you would have to figure out how to code the lambda
>>>>> expressions without using Lambdas. Adding a log4j-java9 jar for api
>>>> and/or
>>>>> core would probably make us as unpopular with folks migrating to Java 9
>>>> as
>>>>> the current situation is for Android users, but it may be the only
>>>> viable
>>>>> solution. Figuring out how to have the class files be ignored by Android
>>>>> seems reasonable but nothing immediately comes to mind as to how to do
>>>> it.
>>>>>>
>>>>>> I made a log4j-android branch a while back that operates pretty much
>>>> as
>>>>> Remko describes below. It does not include the Java 9 support and
>>>> includes
>>>>> a binding to the android logger. However, I got an immediate complaint
>>>> from
>>>>> an Android user that they were not happy with that as they wanted
>>>> access to
>>>>> core. It is also a problem to have lots of pom files refer to log4j-api
>>>> and
>>>>> to have to exclude that and replace it with log4j-android instead.
>>>>>>
>>>>>> I do not want to drop support for Java 9 but we do need to find a
>>>>> creative solution for StackLocator. The limitations I am aware of with
>>>> this
>>>>> are that having multi-release jars and/or Java 9 classes in the jar
>>>> cause
>>>>> problems with tools. Also, having Java 9 source directly in log4j-api or
>>>>> log4j-core does not play nice with IDEs.
>>>>>>
>>>>>> The only thing that comes to mind with regarding having classes with a
>>>>> different file extension would be to have a custom class loader that
>>>> wraps
>>>>> whatever the class loader is. Going down that road seems like it could
>>>> be
>>>>> full of problems.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> 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) I've already replaced the explicit references to JMX classes in
>>>>>>> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>>>>>>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a
>>>> regression,
>>>>> fixed
>>>>>>> now)
>>>>>>> 2) The tricky bit is StackLocator. Options I can think of:
>>>>>>> a) reflection;
>>>>>>> b) separate log4j-api-java9 jar;
>>>>>>> c) rename java 9 class files to other extension than .class and
>>>> load at
>>>>>>> runtime when running in Java 9
>>>>>>> d) other?
>>>>>>> 3) The PID stuff can be moved to core (would still need some solution
>>>>> like
>>>>>>> for above (2) to allow use in Android).
>>>>>>>
>>>>>>>
>>>>>>> log4j-core
>>>>>>> ----------
>>>>>>> We don't really have a good Android story for core.
>>>>>>>
>>>>>>> One option we can offer is log4j-api-android, which is a drop-in
>>>>>>> replacement for log4j-core that logs to Android's adb, similar to
>>>> what
>>>>>>> "android.util.Log.d" does. However, we've had feedback from users who
>>>>> want
>>>>>>> to use normal log4j-core file logging facilities on Android
>>>> (LOG4J2-1921
>>>>>>> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>>>>>>>
>>>>>>> Maybe we can do the same for log4j-core as for log4j-api: use
>>>>> reflection or
>>>>>>> even separate jars :-( to make log4j-core work in Android.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
>>>>> wrote:
>>>>>>>
>>>>>>>> I fully understand Oleg's point of view.
>>>>>>>>
>>>>>>>> If we aim for Log4j 2's API to be the standard logging API/facade
>>>> for
>>>>>>>> Java/JVM (eventually replacing SLF4J), then we have painted
>>>> ourselves
>>>>> into
>>>>>>>> a corner by allowing log4j-api to grow out of bounds, and not paying
>>>>> enough
>>>>>>>> attention to the compatibility problems with Android (and possibly
>>>>> fringe
>>>>>>>> platforms) it causes.
>>>>>>>>
>>>>>>>> It is quite pointless to blame this on Android and its tooling. We
>>>> can,
>>>>>>>> and should raise issues we find on Android tooling, and hope for
>>>> them
>>>>> to
>>>>>>>> eventually get fixed. But that can take time, and at the end of the
>>>> day
>>>>>>>> Android is what it is, and that's what users are going to use. If
>>>>> log4j-api
>>>>>>>> does not work on Android, most users will blame Log4j and not
>>>> Android.
>>>>>>>>
>>>>>>>> And if a library with use cases both on standard Java and on
>>>> Android,
>>>>> like
>>>>>>>> Apache HttpClient, have a required dependency on log4j-api and that
>>>>> causes
>>>>>>>> it to fail on Android, most users will blame HttpClient and not
>>>> Android
>>>>>>>> (nor Log4j since they may be unaware of it).
>>>>>>>>
>>>>>>>> If I were maintainer of Apache HttpClient, I would also be very
>>>>> hesitant
>>>>>>>> to make it depend on log4j-api at this point. I don't think it is
>>>>>>>> constructive to just try to convince them given the current state of
>>>>> Log4j
>>>>>>>> and the Android tooling, we need to do some work on our end first
>>>> (or
>>>>>>>> possibly volunteer to spend some effort on fixing the Android
>>>> tooling).
>>>>>>>>
>>>>>>>> I think that the root cause is not Java 9 support, it is that we
>>>> have
>>>>>>>> allowed too much stuff to go into log4j-api (instead of log4j-core),
>>>>> and
>>>>>>>> that started long before the Java 9 work. JMX is also incompatible
>>>> with
>>>>>>>> Android, regardless of Java 9.
>>>>>>>>
>>>>>>>> With a thinner log4j-api, we could have added Java 9 support to
>>>>> log4j-core
>>>>>>>> only, and avoided this problem.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2017-12-01 15:53, Gary Gregory wrote:
>>>>>>>>
>>>>>>>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back
>>>> due
>>>>> to
>>>>>>>>> the mess Java 9 has made of the META-INF folder and our adding
>>>>> support for
>>>>>>>>> Java 9 modules perhaps too soon.
>>>>>>>>>
>>>>>>>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and
>>>> comment
>>>>> on
>>>>>>>>> that
>>>>>>>>> thread please.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
>
> 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
> at org.apache.bcel.classfile.Constant.readConstant (Constant.java:167)
> at org.apache.bcel.classfile.ConstantPool.<init> (ConstantPool.java:66)
> at org.apache.bcel.classfile.ClassParser.readConstantPool
> (ClassParser.java:239)
> at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:144)
> at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze
> (JarClassesAnalysis.java:96)
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails
> (Dependencies.java:259)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed
> (DependenciesRenderer.java:1542)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails
> (DependenciesRenderer.java:545)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:240)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:83)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:201)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:255)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:229)
> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> (DefaultSiteRenderer.java:337)
> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:178)
> at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:132)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
>
> Gary
>
> On Sat, Dec 2, 2017 at 11:49 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> 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 <bo...@gmail.com> 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 <ra...@dslextreme.com>
>>> 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 solved first.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>> On Dec 2, 2017, at 9:38 AM, Ralph Goers <ra...@dslextreme.com>
>>>> 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 probably wouldn’t be worth
>>> it
>>>> to use it. Also, you would have to figure out how to code the lambda
>>>> expressions without using Lambdas. Adding a log4j-java9 jar for api
>>> and/or
>>>> core would probably make us as unpopular with folks migrating to Java 9
>>> as
>>>> the current situation is for Android users, but it may be the only
>>> viable
>>>> solution. Figuring out how to have the class files be ignored by Android
>>>> seems reasonable but nothing immediately comes to mind as to how to do
>>> it.
>>>>>
>>>>> I made a log4j-android branch a while back that operates pretty much
>>> as
>>>> Remko describes below. It does not include the Java 9 support and
>>> includes
>>>> a binding to the android logger. However, I got an immediate complaint
>>> from
>>>> an Android user that they were not happy with that as they wanted
>>> access to
>>>> core. It is also a problem to have lots of pom files refer to log4j-api
>>> and
>>>> to have to exclude that and replace it with log4j-android instead.
>>>>>
>>>>> I do not want to drop support for Java 9 but we do need to find a
>>>> creative solution for StackLocator. The limitations I am aware of with
>>> this
>>>> are that having multi-release jars and/or Java 9 classes in the jar
>>> cause
>>>> problems with tools. Also, having Java 9 source directly in log4j-api or
>>>> log4j-core does not play nice with IDEs.
>>>>>
>>>>> The only thing that comes to mind with regarding having classes with a
>>>> different file extension would be to have a custom class loader that
>>> wraps
>>>> whatever the class loader is. Going down that road seems like it could
>>> be
>>>> full of problems.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>>>>
>>>>>> 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) I've already replaced the explicit references to JMX classes in
>>>>>> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>>>>>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a
>>> regression,
>>>> fixed
>>>>>> now)
>>>>>> 2) The tricky bit is StackLocator. Options I can think of:
>>>>>> a) reflection;
>>>>>> b) separate log4j-api-java9 jar;
>>>>>> c) rename java 9 class files to other extension than .class and
>>> load at
>>>>>> runtime when running in Java 9
>>>>>> d) other?
>>>>>> 3) The PID stuff can be moved to core (would still need some solution
>>>> like
>>>>>> for above (2) to allow use in Android).
>>>>>>
>>>>>>
>>>>>> log4j-core
>>>>>> ----------
>>>>>> We don't really have a good Android story for core.
>>>>>>
>>>>>> One option we can offer is log4j-api-android, which is a drop-in
>>>>>> replacement for log4j-core that logs to Android's adb, similar to
>>> what
>>>>>> "android.util.Log.d" does. However, we've had feedback from users who
>>>> want
>>>>>> to use normal log4j-core file logging facilities on Android
>>> (LOG4J2-1921
>>>>>> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>>>>>>
>>>>>> Maybe we can do the same for log4j-core as for log4j-api: use
>>>> reflection or
>>>>>> even separate jars :-( to make log4j-core work in Android.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>> I fully understand Oleg's point of view.
>>>>>>>
>>>>>>> If we aim for Log4j 2's API to be the standard logging API/facade
>>> for
>>>>>>> Java/JVM (eventually replacing SLF4J), then we have painted
>>> ourselves
>>>> into
>>>>>>> a corner by allowing log4j-api to grow out of bounds, and not paying
>>>> enough
>>>>>>> attention to the compatibility problems with Android (and possibly
>>>> fringe
>>>>>>> platforms) it causes.
>>>>>>>
>>>>>>> It is quite pointless to blame this on Android and its tooling. We
>>> can,
>>>>>>> and should raise issues we find on Android tooling, and hope for
>>> them
>>>> to
>>>>>>> eventually get fixed. But that can take time, and at the end of the
>>> day
>>>>>>> Android is what it is, and that's what users are going to use. If
>>>> log4j-api
>>>>>>> does not work on Android, most users will blame Log4j and not
>>> Android.
>>>>>>>
>>>>>>> And if a library with use cases both on standard Java and on
>>> Android,
>>>> like
>>>>>>> Apache HttpClient, have a required dependency on log4j-api and that
>>>> causes
>>>>>>> it to fail on Android, most users will blame HttpClient and not
>>> Android
>>>>>>> (nor Log4j since they may be unaware of it).
>>>>>>>
>>>>>>> If I were maintainer of Apache HttpClient, I would also be very
>>>> hesitant
>>>>>>> to make it depend on log4j-api at this point. I don't think it is
>>>>>>> constructive to just try to convince them given the current state of
>>>> Log4j
>>>>>>> and the Android tooling, we need to do some work on our end first
>>> (or
>>>>>>> possibly volunteer to spend some effort on fixing the Android
>>> tooling).
>>>>>>>
>>>>>>> I think that the root cause is not Java 9 support, it is that we
>>> have
>>>>>>> allowed too much stuff to go into log4j-api (instead of log4j-core),
>>>> and
>>>>>>> that started long before the Java 9 work. JMX is also incompatible
>>> with
>>>>>>> Android, regardless of Java 9.
>>>>>>>
>>>>>>> With a thinner log4j-api, we could have added Java 9 support to
>>>> log4j-core
>>>>>>> only, and avoided this problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2017-12-01 15:53, Gary Gregory wrote:
>>>>>>>
>>>>>>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back
>>> due
>>>> to
>>>>>>>> the mess Java 9 has made of the META-INF folder and our adding
>>>> support for
>>>>>>>> Java 9 modules perhaps too soon.
>>>>>>>>
>>>>>>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and
>>> comment
>>>> on
>>>>>>>> that
>>>>>>>> thread please.
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Gary Gregory <ga...@gmail.com>.
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
at org.apache.bcel.classfile.Constant.readConstant (Constant.java:167)
at org.apache.bcel.classfile.ConstantPool.<init> (ConstantPool.java:66)
at org.apache.bcel.classfile.ClassParser.readConstantPool
(ClassParser.java:239)
at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:144)
at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze
(JarClassesAnalysis.java:96)
at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails
(Dependencies.java:259)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed
(DependenciesRenderer.java:1542)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails
(DependenciesRenderer.java:545)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
(DependenciesRenderer.java:240)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render
(AbstractMavenReportRenderer.java:83)
at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
(DependenciesReport.java:201)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:255)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:229)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:337)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:178)
at org.apache.maven.plugins.site.render.SiteMojo.execute
(SiteMojo.java:132)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Gary
On Sat, Dec 2, 2017 at 11:49 AM, Gary Gregory <ga...@gmail.com>
wrote:
> 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 <bo...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 solved first.
>> >
>> > Ralph
>> >
>> >
>> > > On Dec 2, 2017, at 9:38 AM, Ralph Goers <ra...@dslextreme.com>
>> > 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 probably wouldn’t be worth
>> it
>> > to use it. Also, you would have to figure out how to code the lambda
>> > expressions without using Lambdas. Adding a log4j-java9 jar for api
>> and/or
>> > core would probably make us as unpopular with folks migrating to Java 9
>> as
>> > the current situation is for Android users, but it may be the only
>> viable
>> > solution. Figuring out how to have the class files be ignored by Android
>> > seems reasonable but nothing immediately comes to mind as to how to do
>> it.
>> > >
>> > > I made a log4j-android branch a while back that operates pretty much
>> as
>> > Remko describes below. It does not include the Java 9 support and
>> includes
>> > a binding to the android logger. However, I got an immediate complaint
>> from
>> > an Android user that they were not happy with that as they wanted
>> access to
>> > core. It is also a problem to have lots of pom files refer to log4j-api
>> and
>> > to have to exclude that and replace it with log4j-android instead.
>> > >
>> > > I do not want to drop support for Java 9 but we do need to find a
>> > creative solution for StackLocator. The limitations I am aware of with
>> this
>> > are that having multi-release jars and/or Java 9 classes in the jar
>> cause
>> > problems with tools. Also, having Java 9 source directly in log4j-api or
>> > log4j-core does not play nice with IDEs.
>> > >
>> > > The only thing that comes to mind with regarding having classes with a
>> > different file extension would be to have a custom class loader that
>> wraps
>> > whatever the class loader is. Going down that road seems like it could
>> be
>> > full of problems.
>> > >
>> > > Ralph
>> > >
>> > >
>> > >
>> > >
>> > >> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com>
>> wrote:
>> > >>
>> > >> 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) I've already replaced the explicit references to JMX classes in
>> > >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>> > >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a
>> regression,
>> > fixed
>> > >> now)
>> > >> 2) The tricky bit is StackLocator. Options I can think of:
>> > >> a) reflection;
>> > >> b) separate log4j-api-java9 jar;
>> > >> c) rename java 9 class files to other extension than .class and
>> load at
>> > >> runtime when running in Java 9
>> > >> d) other?
>> > >> 3) The PID stuff can be moved to core (would still need some solution
>> > like
>> > >> for above (2) to allow use in Android).
>> > >>
>> > >>
>> > >> log4j-core
>> > >> ----------
>> > >> We don't really have a good Android story for core.
>> > >>
>> > >> One option we can offer is log4j-api-android, which is a drop-in
>> > >> replacement for log4j-core that logs to Android's adb, similar to
>> what
>> > >> "android.util.Log.d" does. However, we've had feedback from users who
>> > want
>> > >> to use normal log4j-core file logging facilities on Android
>> (LOG4J2-1921
>> > >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>> > >>
>> > >> Maybe we can do the same for log4j-core as for log4j-api: use
>> > reflection or
>> > >> even separate jars :-( to make log4j-core work in Android.
>> > >>
>> > >>
>> > >>
>> > >> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
>> > wrote:
>> > >>
>> > >>> I fully understand Oleg's point of view.
>> > >>>
>> > >>> If we aim for Log4j 2's API to be the standard logging API/facade
>> for
>> > >>> Java/JVM (eventually replacing SLF4J), then we have painted
>> ourselves
>> > into
>> > >>> a corner by allowing log4j-api to grow out of bounds, and not paying
>> > enough
>> > >>> attention to the compatibility problems with Android (and possibly
>> > fringe
>> > >>> platforms) it causes.
>> > >>>
>> > >>> It is quite pointless to blame this on Android and its tooling. We
>> can,
>> > >>> and should raise issues we find on Android tooling, and hope for
>> them
>> > to
>> > >>> eventually get fixed. But that can take time, and at the end of the
>> day
>> > >>> Android is what it is, and that's what users are going to use. If
>> > log4j-api
>> > >>> does not work on Android, most users will blame Log4j and not
>> Android.
>> > >>>
>> > >>> And if a library with use cases both on standard Java and on
>> Android,
>> > like
>> > >>> Apache HttpClient, have a required dependency on log4j-api and that
>> > causes
>> > >>> it to fail on Android, most users will blame HttpClient and not
>> Android
>> > >>> (nor Log4j since they may be unaware of it).
>> > >>>
>> > >>> If I were maintainer of Apache HttpClient, I would also be very
>> > hesitant
>> > >>> to make it depend on log4j-api at this point. I don't think it is
>> > >>> constructive to just try to convince them given the current state of
>> > Log4j
>> > >>> and the Android tooling, we need to do some work on our end first
>> (or
>> > >>> possibly volunteer to spend some effort on fixing the Android
>> tooling).
>> > >>>
>> > >>> I think that the root cause is not Java 9 support, it is that we
>> have
>> > >>> allowed too much stuff to go into log4j-api (instead of log4j-core),
>> > and
>> > >>> that started long before the Java 9 work. JMX is also incompatible
>> with
>> > >>> Android, regardless of Java 9.
>> > >>>
>> > >>> With a thinner log4j-api, we could have added Java 9 support to
>> > log4j-core
>> > >>> only, and avoided this problem.
>> > >>>
>> > >>>
>> > >>>
>> > >>> On 2017-12-01 15:53, Gary Gregory wrote:
>> > >>>
>> > >>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back
>> due
>> > to
>> > >>>> the mess Java 9 has made of the META-INF folder and our adding
>> > support for
>> > >>>> Java 9 modules perhaps too soon.
>> > >>>>
>> > >>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and
>> comment
>> > on
>> > >>>> that
>> > >>>> thread please.
>> > >>>>
>> > >>>
>> > >
>> >
>> >
>> >
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Gary Gregory <ga...@gmail.com>.
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 <bo...@gmail.com> 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 <ra...@dslextreme.com>
> 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 solved first.
> >
> > Ralph
> >
> >
> > > On Dec 2, 2017, at 9:38 AM, Ralph Goers <ra...@dslextreme.com>
> > 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 probably wouldn’t be worth
> it
> > to use it. Also, you would have to figure out how to code the lambda
> > expressions without using Lambdas. Adding a log4j-java9 jar for api
> and/or
> > core would probably make us as unpopular with folks migrating to Java 9
> as
> > the current situation is for Android users, but it may be the only viable
> > solution. Figuring out how to have the class files be ignored by Android
> > seems reasonable but nothing immediately comes to mind as to how to do
> it.
> > >
> > > I made a log4j-android branch a while back that operates pretty much as
> > Remko describes below. It does not include the Java 9 support and
> includes
> > a binding to the android logger. However, I got an immediate complaint
> from
> > an Android user that they were not happy with that as they wanted access
> to
> > core. It is also a problem to have lots of pom files refer to log4j-api
> and
> > to have to exclude that and replace it with log4j-android instead.
> > >
> > > I do not want to drop support for Java 9 but we do need to find a
> > creative solution for StackLocator. The limitations I am aware of with
> this
> > are that having multi-release jars and/or Java 9 classes in the jar cause
> > problems with tools. Also, having Java 9 source directly in log4j-api or
> > log4j-core does not play nice with IDEs.
> > >
> > > The only thing that comes to mind with regarding having classes with a
> > different file extension would be to have a custom class loader that
> wraps
> > whatever the class loader is. Going down that road seems like it could be
> > full of problems.
> > >
> > > Ralph
> > >
> > >
> > >
> > >
> > >> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com>
> wrote:
> > >>
> > >> 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) I've already replaced the explicit references to JMX classes in
> > >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> > >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression,
> > fixed
> > >> now)
> > >> 2) The tricky bit is StackLocator. Options I can think of:
> > >> a) reflection;
> > >> b) separate log4j-api-java9 jar;
> > >> c) rename java 9 class files to other extension than .class and load
> at
> > >> runtime when running in Java 9
> > >> d) other?
> > >> 3) The PID stuff can be moved to core (would still need some solution
> > like
> > >> for above (2) to allow use in Android).
> > >>
> > >>
> > >> log4j-core
> > >> ----------
> > >> We don't really have a good Android story for core.
> > >>
> > >> One option we can offer is log4j-api-android, which is a drop-in
> > >> replacement for log4j-core that logs to Android's adb, similar to what
> > >> "android.util.Log.d" does. However, we've had feedback from users who
> > want
> > >> to use normal log4j-core file logging facilities on Android
> (LOG4J2-1921
> > >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
> > >>
> > >> Maybe we can do the same for log4j-core as for log4j-api: use
> > reflection or
> > >> even separate jars :-( to make log4j-core work in Android.
> > >>
> > >>
> > >>
> > >> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
> > wrote:
> > >>
> > >>> I fully understand Oleg's point of view.
> > >>>
> > >>> If we aim for Log4j 2's API to be the standard logging API/facade for
> > >>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves
> > into
> > >>> a corner by allowing log4j-api to grow out of bounds, and not paying
> > enough
> > >>> attention to the compatibility problems with Android (and possibly
> > fringe
> > >>> platforms) it causes.
> > >>>
> > >>> It is quite pointless to blame this on Android and its tooling. We
> can,
> > >>> and should raise issues we find on Android tooling, and hope for them
> > to
> > >>> eventually get fixed. But that can take time, and at the end of the
> day
> > >>> Android is what it is, and that's what users are going to use. If
> > log4j-api
> > >>> does not work on Android, most users will blame Log4j and not
> Android.
> > >>>
> > >>> And if a library with use cases both on standard Java and on Android,
> > like
> > >>> Apache HttpClient, have a required dependency on log4j-api and that
> > causes
> > >>> it to fail on Android, most users will blame HttpClient and not
> Android
> > >>> (nor Log4j since they may be unaware of it).
> > >>>
> > >>> If I were maintainer of Apache HttpClient, I would also be very
> > hesitant
> > >>> to make it depend on log4j-api at this point. I don't think it is
> > >>> constructive to just try to convince them given the current state of
> > Log4j
> > >>> and the Android tooling, we need to do some work on our end first (or
> > >>> possibly volunteer to spend some effort on fixing the Android
> tooling).
> > >>>
> > >>> I think that the root cause is not Java 9 support, it is that we have
> > >>> allowed too much stuff to go into log4j-api (instead of log4j-core),
> > and
> > >>> that started long before the Java 9 work. JMX is also incompatible
> with
> > >>> Android, regardless of Java 9.
> > >>>
> > >>> With a thinner log4j-api, we could have added Java 9 support to
> > log4j-core
> > >>> only, and avoided this problem.
> > >>>
> > >>>
> > >>>
> > >>> On 2017-12-01 15:53, Gary Gregory wrote:
> > >>>
> > >>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back
> due
> > to
> > >>>> the mess Java 9 has made of the META-INF folder and our adding
> > support for
> > >>>> Java 9 modules perhaps too soon.
> > >>>>
> > >>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment
> > on
> > >>>> that
> > >>>> thread please.
> > >>>>
> > >>>
> > >
> >
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Matt Sicker <bo...@gmail.com>.
Are there other Java 9 ready libraries that are having the same problem in
Android?
On 2 December 2017 at 10:40, Ralph Goers <ra...@dslextreme.com> 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 solved first.
>
> Ralph
>
>
> > On Dec 2, 2017, at 9:38 AM, Ralph Goers <ra...@dslextreme.com>
> 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 probably wouldn’t be worth it
> to use it. Also, you would have to figure out how to code the lambda
> expressions without using Lambdas. Adding a log4j-java9 jar for api and/or
> core would probably make us as unpopular with folks migrating to Java 9 as
> the current situation is for Android users, but it may be the only viable
> solution. Figuring out how to have the class files be ignored by Android
> seems reasonable but nothing immediately comes to mind as to how to do it.
> >
> > I made a log4j-android branch a while back that operates pretty much as
> Remko describes below. It does not include the Java 9 support and includes
> a binding to the android logger. However, I got an immediate complaint from
> an Android user that they were not happy with that as they wanted access to
> core. It is also a problem to have lots of pom files refer to log4j-api and
> to have to exclude that and replace it with log4j-android instead.
> >
> > I do not want to drop support for Java 9 but we do need to find a
> creative solution for StackLocator. The limitations I am aware of with this
> are that having multi-release jars and/or Java 9 classes in the jar cause
> problems with tools. Also, having Java 9 source directly in log4j-api or
> log4j-core does not play nice with IDEs.
> >
> > The only thing that comes to mind with regarding having classes with a
> different file extension would be to have a custom class loader that wraps
> whatever the class loader is. Going down that road seems like it could be
> full of problems.
> >
> > Ralph
> >
> >
> >
> >
> >> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com> wrote:
> >>
> >> 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) I've already replaced the explicit references to JMX classes in
> >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression,
> fixed
> >> now)
> >> 2) The tricky bit is StackLocator. Options I can think of:
> >> a) reflection;
> >> b) separate log4j-api-java9 jar;
> >> c) rename java 9 class files to other extension than .class and load at
> >> runtime when running in Java 9
> >> d) other?
> >> 3) The PID stuff can be moved to core (would still need some solution
> like
> >> for above (2) to allow use in Android).
> >>
> >>
> >> log4j-core
> >> ----------
> >> We don't really have a good Android story for core.
> >>
> >> One option we can offer is log4j-api-android, which is a drop-in
> >> replacement for log4j-core that logs to Android's adb, similar to what
> >> "android.util.Log.d" does. However, we've had feedback from users who
> want
> >> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
> >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
> >>
> >> Maybe we can do the same for log4j-core as for log4j-api: use
> reflection or
> >> even separate jars :-( to make log4j-core work in Android.
> >>
> >>
> >>
> >> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
> wrote:
> >>
> >>> I fully understand Oleg's point of view.
> >>>
> >>> If we aim for Log4j 2's API to be the standard logging API/facade for
> >>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves
> into
> >>> a corner by allowing log4j-api to grow out of bounds, and not paying
> enough
> >>> attention to the compatibility problems with Android (and possibly
> fringe
> >>> platforms) it causes.
> >>>
> >>> It is quite pointless to blame this on Android and its tooling. We can,
> >>> and should raise issues we find on Android tooling, and hope for them
> to
> >>> eventually get fixed. But that can take time, and at the end of the day
> >>> Android is what it is, and that's what users are going to use. If
> log4j-api
> >>> does not work on Android, most users will blame Log4j and not Android.
> >>>
> >>> And if a library with use cases both on standard Java and on Android,
> like
> >>> Apache HttpClient, have a required dependency on log4j-api and that
> causes
> >>> it to fail on Android, most users will blame HttpClient and not Android
> >>> (nor Log4j since they may be unaware of it).
> >>>
> >>> If I were maintainer of Apache HttpClient, I would also be very
> hesitant
> >>> to make it depend on log4j-api at this point. I don't think it is
> >>> constructive to just try to convince them given the current state of
> Log4j
> >>> and the Android tooling, we need to do some work on our end first (or
> >>> possibly volunteer to spend some effort on fixing the Android tooling).
> >>>
> >>> I think that the root cause is not Java 9 support, it is that we have
> >>> allowed too much stuff to go into log4j-api (instead of log4j-core),
> and
> >>> that started long before the Java 9 work. JMX is also incompatible with
> >>> Android, regardless of Java 9.
> >>>
> >>> With a thinner log4j-api, we could have added Java 9 support to
> log4j-core
> >>> only, and avoided this problem.
> >>>
> >>>
> >>>
> >>> On 2017-12-01 15:53, Gary Gregory wrote:
> >>>
> >>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due
> to
> >>>> the mess Java 9 has made of the META-INF folder and our adding
> support for
> >>>> Java 9 modules perhaps too soon.
> >>>>
> >>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment
> on
> >>>> that
> >>>> thread please.
> >>>>
> >>>
> >
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> 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 probably wouldn’t be worth it to use it. Also, you would have to figure out how to code the lambda expressions without using Lambdas. Adding a log4j-java9 jar for api and/or core would probably make us as unpopular with folks migrating to Java 9 as the current situation is for Android users, but it may be the only viable solution. Figuring out how to have the class files be ignored by Android seems reasonable but nothing immediately comes to mind as to how to do it.
>
> I made a log4j-android branch a while back that operates pretty much as Remko describes below. It does not include the Java 9 support and includes a binding to the android logger. However, I got an immediate complaint from an Android user that they were not happy with that as they wanted access to core. It is also a problem to have lots of pom files refer to log4j-api and to have to exclude that and replace it with log4j-android instead.
>
> I do not want to drop support for Java 9 but we do need to find a creative solution for StackLocator. The limitations I am aware of with this are that having multi-release jars and/or Java 9 classes in the jar cause problems with tools. Also, having Java 9 source directly in log4j-api or log4j-core does not play nice with IDEs.
>
> The only thing that comes to mind with regarding having classes with a different file extension would be to have a custom class loader that wraps whatever the class loader is. Going down that road seems like it could be full of problems.
>
> Ralph
>
>
>
>
>> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> 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) I've already replaced the explicit references to JMX classes in
>> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed
>> now)
>> 2) The tricky bit is StackLocator. Options I can think of:
>> a) reflection;
>> b) separate log4j-api-java9 jar;
>> c) rename java 9 class files to other extension than .class and load at
>> runtime when running in Java 9
>> d) other?
>> 3) The PID stuff can be moved to core (would still need some solution like
>> for above (2) to allow use in Android).
>>
>>
>> log4j-core
>> ----------
>> We don't really have a good Android story for core.
>>
>> One option we can offer is log4j-api-android, which is a drop-in
>> replacement for log4j-core that logs to Android's adb, similar to what
>> "android.util.Log.d" does. However, we've had feedback from users who want
>> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
>> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>>
>> Maybe we can do the same for log4j-core as for log4j-api: use reflection or
>> even separate jars :-( to make log4j-core work in Android.
>>
>>
>>
>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>
>>> I fully understand Oleg's point of view.
>>>
>>> If we aim for Log4j 2's API to be the standard logging API/facade for
>>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
>>> a corner by allowing log4j-api to grow out of bounds, and not paying enough
>>> attention to the compatibility problems with Android (and possibly fringe
>>> platforms) it causes.
>>>
>>> It is quite pointless to blame this on Android and its tooling. We can,
>>> and should raise issues we find on Android tooling, and hope for them to
>>> eventually get fixed. But that can take time, and at the end of the day
>>> Android is what it is, and that's what users are going to use. If log4j-api
>>> does not work on Android, most users will blame Log4j and not Android.
>>>
>>> And if a library with use cases both on standard Java and on Android, like
>>> Apache HttpClient, have a required dependency on log4j-api and that causes
>>> it to fail on Android, most users will blame HttpClient and not Android
>>> (nor Log4j since they may be unaware of it).
>>>
>>> If I were maintainer of Apache HttpClient, I would also be very hesitant
>>> to make it depend on log4j-api at this point. I don't think it is
>>> constructive to just try to convince them given the current state of Log4j
>>> and the Android tooling, we need to do some work on our end first (or
>>> possibly volunteer to spend some effort on fixing the Android tooling).
>>>
>>> I think that the root cause is not Java 9 support, it is that we have
>>> allowed too much stuff to go into log4j-api (instead of log4j-core), and
>>> that started long before the Java 9 work. JMX is also incompatible with
>>> Android, regardless of Java 9.
>>>
>>> With a thinner log4j-api, we could have added Java 9 support to log4j-core
>>> only, and avoided this problem.
>>>
>>>
>>>
>>> On 2017-12-01 15:53, Gary Gregory wrote:
>>>
>>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>>>> the mess Java 9 has made of the META-INF folder and our adding support for
>>>> Java 9 modules perhaps too soon.
>>>>
>>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on
>>>> that
>>>> thread please.
>>>>
>>>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Gary Gregory <ga...@gmail.com>.
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 <re...@gmail.com> wrote:
> 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 <re...@gmail.com> wrote:
>
> >
> > > On Dec 3, 2017, at 1:38, Ralph Goers <ra...@dslextreme.com>
> 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 probably wouldn’t be worth
> it
> > to use it. Also, you would have to figure out how to code the lambda
> > expressions without using Lambdas. Adding a log4j-java9 jar for api
> and/or
> > core would probably make us as unpopular with folks migrating to Java 9
> as
> > the current situation is for Android users, but it may be the only viable
> > solution. Figuring out how to have the class files be ignored by Android
> > seems reasonable but nothing immediately comes to mind as to how to do
> it.
> > >
> > > I made a log4j-android branch a while back that operates pretty much as
> > Remko describes below. It does not include the Java 9 support and
> includes
> > a binding to the android logger. However, I got an immediate complaint
> from
> > an Android user that they were not happy with that as they wanted access
> to
> > core. It is also a problem to have lots of pom files refer to log4j-api
> and
> > to have to exclude that and replace it with log4j-android instead.
> > >
> > > I do not want to drop support for Java 9 but we do need to find a
> > creative solution for StackLocator. The limitations I am aware of with
> this
> > are that having multi-release jars and/or Java 9 classes in the jar cause
> > problems with tools. Also, having Java 9 source directly in log4j-api or
> > log4j-core does not play nice with IDEs.
> > >
> > > The only thing that comes to mind with regarding having classes with a
> > different file extension would be to have a custom class loader that
> wraps
> > whatever the class loader is. Going down that road seems like it could be
> > full of problems.
> >
> > We may not need a custom class loader. Idea:
> >
> > The Java 9 classes would be in the log4j-api jar, just with a different
> > extension (so the legacy tooling won’t choke on the version 53 bytecode).
> >
> > We can extract those classes into a temp directly, rename them back to
> the
> > canonical extension, and use the same class loader that loaded the other
> > log4j-api classes to load the Java 9 classes from the temp directory.
> >
> > If this fails, we fall back to the Java 7-compatible implementation.
> >
> > >
> > > Ralph
> > >
> > >
> > >
> > >
> > >> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com>
> wrote:
> > >>
> > >> 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) I've already replaced the explicit references to JMX classes in
> > >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> > >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression,
> > fixed
> > >> now)
> > >> 2) The tricky bit is StackLocator. Options I can think of:
> > >> a) reflection;
> > >> b) separate log4j-api-java9 jar;
> > >> c) rename java 9 class files to other extension than .class and load
> at
> > >> runtime when running in Java 9
> > >> d) other?
> > >> 3) The PID stuff can be moved to core (would still need some solution
> > like
> > >> for above (2) to allow use in Android).
> > >>
> > >>
> > >> log4j-core
> > >> ----------
> > >> We don't really have a good Android story for core.
> > >>
> > >> One option we can offer is log4j-api-android, which is a drop-in
> > >> replacement for log4j-core that logs to Android's adb, similar to what
> > >> "android.util.Log.d" does. However, we've had feedback from users who
> > want
> > >> to use normal log4j-core file logging facilities on Android
> (LOG4J2-1921
> > >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
> > >>
> > >> Maybe we can do the same for log4j-core as for log4j-api: use
> > reflection or
> > >> even separate jars :-( to make log4j-core work in Android.
> > >>
> > >>
> > >>
> > >>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
> > wrote:
> > >>>
> > >>> I fully understand Oleg's point of view.
> > >>>
> > >>> If we aim for Log4j 2's API to be the standard logging API/facade for
> > >>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves
> > into
> > >>> a corner by allowing log4j-api to grow out of bounds, and not paying
> > enough
> > >>> attention to the compatibility problems with Android (and possibly
> > fringe
> > >>> platforms) it causes.
> > >>>
> > >>> It is quite pointless to blame this on Android and its tooling. We
> can,
> > >>> and should raise issues we find on Android tooling, and hope for them
> > to
> > >>> eventually get fixed. But that can take time, and at the end of the
> day
> > >>> Android is what it is, and that's what users are going to use. If
> > log4j-api
> > >>> does not work on Android, most users will blame Log4j and not
> Android.
> > >>>
> > >>> And if a library with use cases both on standard Java and on Android,
> > like
> > >>> Apache HttpClient, have a required dependency on log4j-api and that
> > causes
> > >>> it to fail on Android, most users will blame HttpClient and not
> Android
> > >>> (nor Log4j since they may be unaware of it).
> > >>>
> > >>> If I were maintainer of Apache HttpClient, I would also be very
> > hesitant
> > >>> to make it depend on log4j-api at this point. I don't think it is
> > >>> constructive to just try to convince them given the current state of
> > Log4j
> > >>> and the Android tooling, we need to do some work on our end first (or
> > >>> possibly volunteer to spend some effort on fixing the Android
> tooling).
> > >>>
> > >>> I think that the root cause is not Java 9 support, it is that we have
> > >>> allowed too much stuff to go into log4j-api (instead of log4j-core),
> > and
> > >>> that started long before the Java 9 work. JMX is also incompatible
> with
> > >>> Android, regardless of Java 9.
> > >>>
> > >>> With a thinner log4j-api, we could have added Java 9 support to
> > log4j-core
> > >>> only, and avoided this problem.
> > >>>
> > >>>
> > >>>
> > >>>> On 2017-12-01 15:53, Gary Gregory wrote:
> > >>>>
> > >>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back
> due
> > to
> > >>>> the mess Java 9 has made of the META-INF folder and our adding
> > support for
> > >>>> Java 9 modules perhaps too soon.
> > >>>>
> > >>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment
> > on
> > >>>> that
> > >>>> thread please.
> > >>>>
> > >>>
> > >
> > >
> >
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Remko Popma <re...@gmail.com>.
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 <re...@gmail.com> wrote:
>
> > On Dec 3, 2017, at 1:38, Ralph Goers <ra...@dslextreme.com> 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 probably wouldn’t be worth it
> to use it. Also, you would have to figure out how to code the lambda
> expressions without using Lambdas. Adding a log4j-java9 jar for api and/or
> core would probably make us as unpopular with folks migrating to Java 9 as
> the current situation is for Android users, but it may be the only viable
> solution. Figuring out how to have the class files be ignored by Android
> seems reasonable but nothing immediately comes to mind as to how to do it.
> >
> > I made a log4j-android branch a while back that operates pretty much as
> Remko describes below. It does not include the Java 9 support and includes
> a binding to the android logger. However, I got an immediate complaint from
> an Android user that they were not happy with that as they wanted access to
> core. It is also a problem to have lots of pom files refer to log4j-api and
> to have to exclude that and replace it with log4j-android instead.
> >
> > I do not want to drop support for Java 9 but we do need to find a
> creative solution for StackLocator. The limitations I am aware of with this
> are that having multi-release jars and/or Java 9 classes in the jar cause
> problems with tools. Also, having Java 9 source directly in log4j-api or
> log4j-core does not play nice with IDEs.
> >
> > The only thing that comes to mind with regarding having classes with a
> different file extension would be to have a custom class loader that wraps
> whatever the class loader is. Going down that road seems like it could be
> full of problems.
>
> We may not need a custom class loader. Idea:
>
> The Java 9 classes would be in the log4j-api jar, just with a different
> extension (so the legacy tooling won’t choke on the version 53 bytecode).
>
> We can extract those classes into a temp directly, rename them back to the
> canonical extension, and use the same class loader that loaded the other
> log4j-api classes to load the Java 9 classes from the temp directory.
>
> If this fails, we fall back to the Java 7-compatible implementation.
>
> >
> > Ralph
> >
> >
> >
> >
> >> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com> wrote:
> >>
> >> 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) I've already replaced the explicit references to JMX classes in
> >> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> >> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression,
> fixed
> >> now)
> >> 2) The tricky bit is StackLocator. Options I can think of:
> >> a) reflection;
> >> b) separate log4j-api-java9 jar;
> >> c) rename java 9 class files to other extension than .class and load at
> >> runtime when running in Java 9
> >> d) other?
> >> 3) The PID stuff can be moved to core (would still need some solution
> like
> >> for above (2) to allow use in Android).
> >>
> >>
> >> log4j-core
> >> ----------
> >> We don't really have a good Android story for core.
> >>
> >> One option we can offer is log4j-api-android, which is a drop-in
> >> replacement for log4j-core that logs to Android's adb, similar to what
> >> "android.util.Log.d" does. However, we've had feedback from users who
> want
> >> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
> >> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
> >>
> >> Maybe we can do the same for log4j-core as for log4j-api: use
> reflection or
> >> even separate jars :-( to make log4j-core work in Android.
> >>
> >>
> >>
> >>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org>
> wrote:
> >>>
> >>> I fully understand Oleg's point of view.
> >>>
> >>> If we aim for Log4j 2's API to be the standard logging API/facade for
> >>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves
> into
> >>> a corner by allowing log4j-api to grow out of bounds, and not paying
> enough
> >>> attention to the compatibility problems with Android (and possibly
> fringe
> >>> platforms) it causes.
> >>>
> >>> It is quite pointless to blame this on Android and its tooling. We can,
> >>> and should raise issues we find on Android tooling, and hope for them
> to
> >>> eventually get fixed. But that can take time, and at the end of the day
> >>> Android is what it is, and that's what users are going to use. If
> log4j-api
> >>> does not work on Android, most users will blame Log4j and not Android.
> >>>
> >>> And if a library with use cases both on standard Java and on Android,
> like
> >>> Apache HttpClient, have a required dependency on log4j-api and that
> causes
> >>> it to fail on Android, most users will blame HttpClient and not Android
> >>> (nor Log4j since they may be unaware of it).
> >>>
> >>> If I were maintainer of Apache HttpClient, I would also be very
> hesitant
> >>> to make it depend on log4j-api at this point. I don't think it is
> >>> constructive to just try to convince them given the current state of
> Log4j
> >>> and the Android tooling, we need to do some work on our end first (or
> >>> possibly volunteer to spend some effort on fixing the Android tooling).
> >>>
> >>> I think that the root cause is not Java 9 support, it is that we have
> >>> allowed too much stuff to go into log4j-api (instead of log4j-core),
> and
> >>> that started long before the Java 9 work. JMX is also incompatible with
> >>> Android, regardless of Java 9.
> >>>
> >>> With a thinner log4j-api, we could have added Java 9 support to
> log4j-core
> >>> only, and avoided this problem.
> >>>
> >>>
> >>>
> >>>> On 2017-12-01 15:53, Gary Gregory wrote:
> >>>>
> >>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due
> to
> >>>> the mess Java 9 has made of the META-INF folder and our adding
> support for
> >>>> Java 9 modules perhaps too soon.
> >>>>
> >>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment
> on
> >>>> that
> >>>> thread please.
> >>>>
> >>>
> >
> >
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Remko Popma <re...@gmail.com>.
> On Dec 3, 2017, at 1:38, Ralph Goers <ra...@dslextreme.com> 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 probably wouldn’t be worth it to use it. Also, you would have to figure out how to code the lambda expressions without using Lambdas. Adding a log4j-java9 jar for api and/or core would probably make us as unpopular with folks migrating to Java 9 as the current situation is for Android users, but it may be the only viable solution. Figuring out how to have the class files be ignored by Android seems reasonable but nothing immediately comes to mind as to how to do it.
>
> I made a log4j-android branch a while back that operates pretty much as Remko describes below. It does not include the Java 9 support and includes a binding to the android logger. However, I got an immediate complaint from an Android user that they were not happy with that as they wanted access to core. It is also a problem to have lots of pom files refer to log4j-api and to have to exclude that and replace it with log4j-android instead.
>
> I do not want to drop support for Java 9 but we do need to find a creative solution for StackLocator. The limitations I am aware of with this are that having multi-release jars and/or Java 9 classes in the jar cause problems with tools. Also, having Java 9 source directly in log4j-api or log4j-core does not play nice with IDEs.
>
> The only thing that comes to mind with regarding having classes with a different file extension would be to have a custom class loader that wraps whatever the class loader is. Going down that road seems like it could be full of problems.
We may not need a custom class loader. Idea:
The Java 9 classes would be in the log4j-api jar, just with a different extension (so the legacy tooling won’t choke on the version 53 bytecode).
We can extract those classes into a temp directly, rename them back to the canonical extension, and use the same class loader that loaded the other log4j-api classes to load the Java 9 classes from the temp directory.
If this fails, we fall back to the Java 7-compatible implementation.
>
> Ralph
>
>
>
>
>> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> 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) I've already replaced the explicit references to JMX classes in
>> log4j-api with reflection for Android compatibility. (LOG4J2-2126
>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed
>> now)
>> 2) The tricky bit is StackLocator. Options I can think of:
>> a) reflection;
>> b) separate log4j-api-java9 jar;
>> c) rename java 9 class files to other extension than .class and load at
>> runtime when running in Java 9
>> d) other?
>> 3) The PID stuff can be moved to core (would still need some solution like
>> for above (2) to allow use in Android).
>>
>>
>> log4j-core
>> ----------
>> We don't really have a good Android story for core.
>>
>> One option we can offer is log4j-api-android, which is a drop-in
>> replacement for log4j-core that logs to Android's adb, similar to what
>> "android.util.Log.d" does. However, we've had feedback from users who want
>> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
>> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>>
>> Maybe we can do the same for log4j-core as for log4j-api: use reflection or
>> even separate jars :-( to make log4j-core work in Android.
>>
>>
>>
>>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>
>>> I fully understand Oleg's point of view.
>>>
>>> If we aim for Log4j 2's API to be the standard logging API/facade for
>>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
>>> a corner by allowing log4j-api to grow out of bounds, and not paying enough
>>> attention to the compatibility problems with Android (and possibly fringe
>>> platforms) it causes.
>>>
>>> It is quite pointless to blame this on Android and its tooling. We can,
>>> and should raise issues we find on Android tooling, and hope for them to
>>> eventually get fixed. But that can take time, and at the end of the day
>>> Android is what it is, and that's what users are going to use. If log4j-api
>>> does not work on Android, most users will blame Log4j and not Android.
>>>
>>> And if a library with use cases both on standard Java and on Android, like
>>> Apache HttpClient, have a required dependency on log4j-api and that causes
>>> it to fail on Android, most users will blame HttpClient and not Android
>>> (nor Log4j since they may be unaware of it).
>>>
>>> If I were maintainer of Apache HttpClient, I would also be very hesitant
>>> to make it depend on log4j-api at this point. I don't think it is
>>> constructive to just try to convince them given the current state of Log4j
>>> and the Android tooling, we need to do some work on our end first (or
>>> possibly volunteer to spend some effort on fixing the Android tooling).
>>>
>>> I think that the root cause is not Java 9 support, it is that we have
>>> allowed too much stuff to go into log4j-api (instead of log4j-core), and
>>> that started long before the Java 9 work. JMX is also incompatible with
>>> Android, regardless of Java 9.
>>>
>>> With a thinner log4j-api, we could have added Java 9 support to log4j-core
>>> only, and avoided this problem.
>>>
>>>
>>>
>>>> On 2017-12-01 15:53, Gary Gregory wrote:
>>>>
>>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>>>> the mess Java 9 has made of the META-INF folder and our adding support for
>>>> Java 9 modules perhaps too soon.
>>>>
>>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on
>>>> that
>>>> thread please.
>>>>
>>>
>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Ralph Goers <ra...@dslextreme.com>.
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 code the lambda expressions without using Lambdas. Adding a log4j-java9 jar for api and/or core would probably make us as unpopular with folks migrating to Java 9 as the current situation is for Android users, but it may be the only viable solution. Figuring out how to have the class files be ignored by Android seems reasonable but nothing immediately comes to mind as to how to do it.
I made a log4j-android branch a while back that operates pretty much as Remko describes below. It does not include the Java 9 support and includes a binding to the android logger. However, I got an immediate complaint from an Android user that they were not happy with that as they wanted access to core. It is also a problem to have lots of pom files refer to log4j-api and to have to exclude that and replace it with log4j-android instead.
I do not want to drop support for Java 9 but we do need to find a creative solution for StackLocator. The limitations I am aware of with this are that having multi-release jars and/or Java 9 classes in the jar cause problems with tools. Also, having Java 9 source directly in log4j-api or log4j-core does not play nice with IDEs.
The only thing that comes to mind with regarding having classes with a different file extension would be to have a custom class loader that wraps whatever the class loader is. Going down that road seems like it could be full of problems.
Ralph
> On Dec 2, 2017, at 7:34 AM, Remko Popma <re...@gmail.com> wrote:
>
> 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) I've already replaced the explicit references to JMX classes in
> log4j-api with reflection for Android compatibility. (LOG4J2-2126
> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed
> now)
> 2) The tricky bit is StackLocator. Options I can think of:
> a) reflection;
> b) separate log4j-api-java9 jar;
> c) rename java 9 class files to other extension than .class and load at
> runtime when running in Java 9
> d) other?
> 3) The PID stuff can be moved to core (would still need some solution like
> for above (2) to allow use in Android).
>
>
> log4j-core
> ----------
> We don't really have a good Android story for core.
>
> One option we can offer is log4j-api-android, which is a drop-in
> replacement for log4j-core that logs to Android's adb, similar to what
> "android.util.Log.d" does. However, we've had feedback from users who want
> to use normal log4j-core file logging facilities on Android (LOG4J2-1921
> <https://issues.apache.org/jira/browse/LOG4J2-1921>).
>
> Maybe we can do the same for log4j-core as for log4j-api: use reflection or
> even separate jars :-( to make log4j-core work in Android.
>
>
>
> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
>> I fully understand Oleg's point of view.
>>
>> If we aim for Log4j 2's API to be the standard logging API/facade for
>> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
>> a corner by allowing log4j-api to grow out of bounds, and not paying enough
>> attention to the compatibility problems with Android (and possibly fringe
>> platforms) it causes.
>>
>> It is quite pointless to blame this on Android and its tooling. We can,
>> and should raise issues we find on Android tooling, and hope for them to
>> eventually get fixed. But that can take time, and at the end of the day
>> Android is what it is, and that's what users are going to use. If log4j-api
>> does not work on Android, most users will blame Log4j and not Android.
>>
>> And if a library with use cases both on standard Java and on Android, like
>> Apache HttpClient, have a required dependency on log4j-api and that causes
>> it to fail on Android, most users will blame HttpClient and not Android
>> (nor Log4j since they may be unaware of it).
>>
>> If I were maintainer of Apache HttpClient, I would also be very hesitant
>> to make it depend on log4j-api at this point. I don't think it is
>> constructive to just try to convince them given the current state of Log4j
>> and the Android tooling, we need to do some work on our end first (or
>> possibly volunteer to spend some effort on fixing the Android tooling).
>>
>> I think that the root cause is not Java 9 support, it is that we have
>> allowed too much stuff to go into log4j-api (instead of log4j-core), and
>> that started long before the Java 9 work. JMX is also incompatible with
>> Android, regardless of Java 9.
>>
>> With a thinner log4j-api, we could have added Java 9 support to log4j-core
>> only, and avoided this problem.
>>
>>
>>
>> On 2017-12-01 15:53, Gary Gregory wrote:
>>
>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>>> the mess Java 9 has made of the META-INF folder and our adding support for
>>> Java 9 modules perhaps too soon.
>>>
>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on
>>> that
>>> thread please.
>>>
>>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Mikael Ståldal <mi...@apache.org>.
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 regular users to need a compile dependency on log4j-core
anyway.
So I don't have an easy solution to fix it now, this is more a
retrospective to figure out why we ended up in this unfourtate
situation, and how do avoid that happening again in the future.
If I were to redesign Log4j 2 from scratch, I would consider not putting
this into log4j-api:
- All classes in org.apache.logging.log4j.message (only the interfaces
in API, except ReusableMessage and ThreadInformation)
- Most (or ideally all) stuff in org.apache.logging.log4j.spi
- The org.apache.logging.log4j.status package
- Most (or ideally all) stuff in org.apache.logging.log4j.util (since
they would not be needed anymore)
Some of it would go into log4j-core, some into a new log4j-spi module.
I think that the growing-out-of-bounds started with the garbage-free epic.
log4j-api.jar is now 249 KB, slf4j-api.jar is 41 KB.
On 2017-12-02 15:34, Remko Popma wrote:
> 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.
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Remko Popma <re...@gmail.com>.
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) I've already replaced the explicit references to JMX classes in
log4j-api with reflection for Android compatibility. (LOG4J2-2126
<https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed
now)
2) The tricky bit is StackLocator. Options I can think of:
a) reflection;
b) separate log4j-api-java9 jar;
c) rename java 9 class files to other extension than .class and load at
runtime when running in Java 9
d) other?
3) The PID stuff can be moved to core (would still need some solution like
for above (2) to allow use in Android).
log4j-core
----------
We don't really have a good Android story for core.
One option we can offer is log4j-api-android, which is a drop-in
replacement for log4j-core that logs to Android's adb, similar to what
"android.util.Log.d" does. However, we've had feedback from users who want
to use normal log4j-core file logging facilities on Android (LOG4J2-1921
<https://issues.apache.org/jira/browse/LOG4J2-1921>).
Maybe we can do the same for log4j-core as for log4j-api: use reflection or
even separate jars :-( to make log4j-core work in Android.
On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <mi...@apache.org> wrote:
> I fully understand Oleg's point of view.
>
> If we aim for Log4j 2's API to be the standard logging API/facade for
> Java/JVM (eventually replacing SLF4J), then we have painted ourselves into
> a corner by allowing log4j-api to grow out of bounds, and not paying enough
> attention to the compatibility problems with Android (and possibly fringe
> platforms) it causes.
>
> It is quite pointless to blame this on Android and its tooling. We can,
> and should raise issues we find on Android tooling, and hope for them to
> eventually get fixed. But that can take time, and at the end of the day
> Android is what it is, and that's what users are going to use. If log4j-api
> does not work on Android, most users will blame Log4j and not Android.
>
> And if a library with use cases both on standard Java and on Android, like
> Apache HttpClient, have a required dependency on log4j-api and that causes
> it to fail on Android, most users will blame HttpClient and not Android
> (nor Log4j since they may be unaware of it).
>
> If I were maintainer of Apache HttpClient, I would also be very hesitant
> to make it depend on log4j-api at this point. I don't think it is
> constructive to just try to convince them given the current state of Log4j
> and the Android tooling, we need to do some work on our end first (or
> possibly volunteer to spend some effort on fixing the Android tooling).
>
> I think that the root cause is not Java 9 support, it is that we have
> allowed too much stuff to go into log4j-api (instead of log4j-core), and
> that started long before the Java 9 work. JMX is also incompatible with
> Android, regardless of Java 9.
>
> With a thinner log4j-api, we could have added Java 9 support to log4j-core
> only, and avoided this problem.
>
>
>
> On 2017-12-01 15:53, Gary Gregory wrote:
>
>> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
>> the mess Java 9 has made of the META-INF folder and our adding support for
>> Java 9 modules perhaps too soon.
>>
>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on
>> that
>> thread please.
>>
>
Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j
Posted by Mikael Ståldal <mi...@apache.org>.
I fully understand Oleg's point of view.
If we aim for Log4j 2's API to be the standard logging API/facade for
Java/JVM (eventually replacing SLF4J), then we have painted ourselves
into a corner by allowing log4j-api to grow out of bounds, and not
paying enough attention to the compatibility problems with Android (and
possibly fringe platforms) it causes.
It is quite pointless to blame this on Android and its tooling. We can,
and should raise issues we find on Android tooling, and hope for them to
eventually get fixed. But that can take time, and at the end of the day
Android is what it is, and that's what users are going to use. If
log4j-api does not work on Android, most users will blame Log4j and not
Android.
And if a library with use cases both on standard Java and on Android,
like Apache HttpClient, have a required dependency on log4j-api and that
causes it to fail on Android, most users will blame HttpClient and not
Android (nor Log4j since they may be unaware of it).
If I were maintainer of Apache HttpClient, I would also be very hesitant
to make it depend on log4j-api at this point. I don't think it is
constructive to just try to convince them given the current state of
Log4j and the Android tooling, we need to do some work on our end first
(or possibly volunteer to spend some effort on fixing the Android tooling).
I think that the root cause is not Java 9 support, it is that we have
allowed too much stuff to go into log4j-api (instead of log4j-core), and
that started long before the Java 9 work. JMX is also incompatible with
Android, regardless of Java 9.
With a thinner log4j-api, we could have added Java 9 support to
log4j-core only, and avoided this problem.
On 2017-12-01 15:53, Gary Gregory wrote:
> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to
> the mess Java 9 has made of the META-INF folder and our adding support for
> Java 9 modules perhaps too soon.
>
> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on that
> thread please.