Started testing Java9 with log4j 1.2, SLF4J and logback projects
Hi All, We started testing SLF4J and logback projects using Java 9, more specifically build 154. As such, I would appreciate if you could add the following details onto the Quality Outreach wiki page. Contact: Ceki Gülcü SLF4J mailing list slf4j-dev AT qos DOT ch Logback mailing list logback-dev AT qos DOT ch Initial testing results ======================= Initial testing indicates that log4j version 1.2.x is unable to parse the result of the call System.getProperties("java.version"). The returned string is "9-ea". However, log4j 1.2.x expects a string in the form "1\.*", for example "1.6", "1.7" etc. If the string is not in the correct form, log4j 1.2.x conservatively assumes that it is running under Java 1.1 and disables certain important functions, such as MDC support. The code in question is the static initializer of the org.apache.log4j.helpers.Loader class. Log4j 1.2.x is no longer maintained. However, there are innumerably many projects which still use log4j 1.2.x. I would suggest that the string returned be in the form "1\.9*" such as "1.9EA" so as not to break log4j 1.2.x under Java 9. Many thanks in advance for taking the above into consideration. Best regards, -- Ceki Gülcü
Hi Ceki, Can you read JEP 223 <http://openjdk.java.net/jeps/223> it describes how the new version string is implemented in JDK 9. Is logback working with JDK 9 ? Rgds,Rory On 14/02/2017 10:10, Ceki Gülcü wrote:
Hi All,
We started testing SLF4J and logback projects using Java 9, more specifically build 154. As such, I would appreciate if you could add the following details onto the Quality Outreach wiki page.
Contact: Ceki Gülcü SLF4J mailing list slf4j-dev AT qos DOT ch Logback mailing list logback-dev AT qos DOT ch
Initial testing results =======================
Initial testing indicates that log4j version 1.2.x is unable to parse the result of the call System.getProperties("java.version"). The returned string is "9-ea". However, log4j 1.2.x expects a string in the form "1\.*", for example "1.6", "1.7" etc.
If the string is not in the correct form, log4j 1.2.x conservatively assumes that it is running under Java 1.1 and disables certain important functions, such as MDC support. The code in question is the static initializer of the org.apache.log4j.helpers.Loader class.
Log4j 1.2.x is no longer maintained. However, there are innumerably many projects which still use log4j 1.2.x.
I would suggest that the string returned be in the form "1\.9*" such as "1.9EA" so as not to break log4j 1.2.x under Java 9.
Many thanks in advance for taking the above into consideration.
Best regards,
-- Ceki Gülcü
-- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Hi Rory, Thank you for the pointer to JEP 223. Logback would also fail to parse the new java.version property. I created issue LOGBACK-1260 (See [1]) to track this problem which I expect will be fixed in version 1.2.2, that is the next release of logback. In the context of SLF4J, the build of the slf4j-log4j12 module fails since log4j can no longer correctly detect the version of Java and shuts down MDC support. In short, the changes introduced in JEP 223 have significant consequences for log4j 1.2.x and by ricochet for SLF4J. Best regards, -- Ceki Gülcü [1] https://jira.qos.ch/browse/LOGBACK-1260 On 2/14/2017 11:26, Rory O'Donnell wrote:
Hi Ceki,
Can you read JEP 223 <http://openjdk.java.net/jeps/223> it describes how the new version string is implemented in JDK 9.
Is logback working with JDK 9 ?
Rgds,Rory
On 14/02/2017 10:10, Ceki Gülcü wrote:
Hi All,
We started testing SLF4J and logback projects using Java 9, more specifically build 154. As such, I would appreciate if you could add the following details onto the Quality Outreach wiki page.
Contact: Ceki Gülcü SLF4J mailing list slf4j-dev AT qos DOT ch Logback mailing list logback-dev AT qos DOT ch
Initial testing results =======================
Initial testing indicates that log4j version 1.2.x is unable to parse the result of the call System.getProperties("java.version"). The returned string is "9-ea". However, log4j 1.2.x expects a string in the form "1\.*", for example "1.6", "1.7" etc.
If the string is not in the correct form, log4j 1.2.x conservatively assumes that it is running under Java 1.1 and disables certain important functions, such as MDC support. The code in question is the static initializer of the org.apache.log4j.helpers.Loader class.
Log4j 1.2.x is no longer maintained. However, there are innumerably many projects which still use log4j 1.2.x.
I would suggest that the string returned be in the form "1\.9*" such as "1.9EA" so as not to break log4j 1.2.x under Java 9.
Many thanks in advance for taking the above into consideration.
Best regards,
-- Ceki Gülcü
-- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Hi Ceki, I have updated the wiki. Rgds,Rory On 14/02/2017 11:14, Ceki Gülcü wrote:
Hi Rory,
Thank you for the pointer to JEP 223.
Logback would also fail to parse the new java.version property. I created issue LOGBACK-1260 (See [1]) to track this problem which I expect will be fixed in version 1.2.2, that is the next release of logback.
In the context of SLF4J, the build of the slf4j-log4j12 module fails since log4j can no longer correctly detect the version of Java and shuts down MDC support. In short, the changes introduced in JEP 223 have significant consequences for log4j 1.2.x and by ricochet for SLF4J.
Best regards,
-- Ceki Gülcü
[1] https://jira.qos.ch/browse/LOGBACK-1260
On 2/14/2017 11:26, Rory O'Donnell wrote:
Hi Ceki,
Can you read JEP 223 <http://openjdk.java.net/jeps/223> it describes how the new version string is implemented in JDK 9.
Is logback working with JDK 9 ?
Rgds,Rory
On 14/02/2017 10:10, Ceki Gülcü wrote:
Hi All,
We started testing SLF4J and logback projects using Java 9, more specifically build 154. As such, I would appreciate if you could add the following details onto the Quality Outreach wiki page.
Contact: Ceki Gülcü SLF4J mailing list slf4j-dev AT qos DOT ch Logback mailing list logback-dev AT qos DOT ch
Initial testing results =======================
Initial testing indicates that log4j version 1.2.x is unable to parse the result of the call System.getProperties("java.version"). The returned string is "9-ea". However, log4j 1.2.x expects a string in the form "1\.*", for example "1.6", "1.7" etc.
If the string is not in the correct form, log4j 1.2.x conservatively assumes that it is running under Java 1.1 and disables certain important functions, such as MDC support. The code in question is the static initializer of the org.apache.log4j.helpers.Loader class.
Log4j 1.2.x is no longer maintained. However, there are innumerably many projects which still use log4j 1.2.x.
I would suggest that the string returned be in the form "1\.9*" such as "1.9EA" so as not to break log4j 1.2.x under Java 9.
Many thanks in advance for taking the above into consideration.
Best regards,
-- Ceki Gülcü
-- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
-- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
On 14.02.2017 12:14, Ceki Gülcü wrote:
In the context of SLF4J, the build of the slf4j-log4j12 module fails since log4j can no longer correctly detect the version of Java and shuts down MDC support. In short, the changes introduced in JEP 223 have significant consequences for log4j 1.2.x and by ricochet for SLF4J.
Hi Ceki, general information about Log4J 1.x on JDK9 can be found at https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 . In particular, the blog points to a potential workaround for Log4j 1.x, although, of course, migrating off libraries that are no longer maintained should be the preferred choice for most developers. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Hi Dalibor, Thank you for the useful pointer to a possible workaround. The issue impacting the slf4j-log4j12 module (which relies on log4j 1.2.17) is now fixed. The fix will ship with release 1.7.23 of SLF4J. See also https://jira.qos.ch/browse/SLF4J-393 -- Ceki On 2/14/2017 17:42, dalibor topic wrote:
On 14.02.2017 12:14, Ceki Gülcü wrote:
In the context of SLF4J, the build of the slf4j-log4j12 module fails since log4j can no longer correctly detect the version of Java and shuts down MDC support. In short, the changes introduced in JEP 223 have significant consequences for log4j 1.2.x and by ricochet for SLF4J.
Hi Ceki,
general information about Log4J 1.x on JDK9 can be found at https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 .
In particular, the blog points to a potential workaround for Log4j 1.x, although, of course, migrating off libraries that are no longer maintained should be the preferred choice for most developers.
cheers, dalibor topic
On 14.02.2017 22:57, Ceki Gülcü wrote:
Hi Dalibor,
Thank you for the useful pointer to a possible workaround.
The issue impacting the slf4j-log4j12 module (which relies on log4j 1.2.17) is now fixed. The fix will ship with release 1.7.23 of SLF4J.
See also https://jira.qos.ch/browse/SLF4J-393
Thanks, Ceki - great to hear you could make the concept in the workaround proposed in the Log4j 1.x EOL blog work for your use case as well. cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
participants (3)
-
Ceki Gülcü
-
dalibor topic
-
Rory O'Donnell