November 2018 - slf4j-dev - mailman3.qos.ch

[SLF4J-449] - Unexpected Execution Environment J2SE-1.6
by Larissa Smirnova 15 Nov '18

15 Nov '18

Hello slf4j-dev Mailing List, The bug report https://jira.qos.ch/browse/SLF4J-449 has been submitted to identify and correct an issue with the current 1.8.0-beta2 build of slf4j when it is used with OSGi containers, and specifically Eclipse Tycho and OSGi as plugins and bundles. The Bundle-RequiredExecutionEnvironment in the slf4j-api and slf4j-integration are set to J2SE-1.6. The Standard Eclipse OSGi Execution Environment for Java 6 is JavaSE-1.6 and not J2SE-1.6. Due to this error, builds using the Eclipse OSGi Execution Environment value will have an error of an unrecognized Execution Environment. One example is using Eclipse Tycho to build Eclipse plugins and OSGi bundles. The commit ab389a9b82abe35034a3026c7eb0d4b9a07b4ae7 from J2SE-1.5 to J2SE-1.6, is the commit that migrated the Bundle-RequiredExecutionEnvironment forward in slf4j-api and slf4j-integration manifests to 1.6. It's worth noting that there is another comment associated with a commit that addresses this error: https://github.com/qos-ch/slf4j/commit/5f00780faba08756932de6c165a153dd1dd7…. For the listing of the Standard Execution Environments, please see: The Standard Execution Environments are listed at: https://wiki.eclipse.org/Execution_Environments#Standard_Execution_Environm…. As part of this defect submission, a fix with the changes to correct this issue has been created in my GitHub fork and is available to be reviewed to be included in the next release of the slf4j projects. The GitHub fork URL is: https://github.com/larsmir/slf4j. The specific commit, 928ab902187ebdc78b2262214bd2cb4c36c18a9a, that makes the changes is located at: https://github.com/larsmir/slf4j/commit/928ab902187ebdc78b2262214bd2cb4c36c…. I'm looking forward to working with the developers on this list and project to correct this issue and get the changes into the next release. Thank you. Best regards, Larissa Smirnova

1 0

[JIRA] (SLF4J-449) Unexpected execution environment J2SE-1.6
by QOS.CH (JIRA) 15 Nov '18

15 Nov '18

Larissa Smirnova created SLF4J-449: -------------------------------------- Summary: Unexpected execution environment J2SE-1.6 Key: SLF4J-449 URL: https://jira.qos.ch/browse/SLF4J-449 Project: SLF4J Issue Type: Bug Components: Core API, Implementations Affects Versions: 1.8.0-beta2 Environment: OSGi Execution Environments and specifically, Eclipse Tycho and OSGi plugins and bundles. Reporter: Larissa Smirnova Assignee: SLF4J developers list The Bundle-RequiredExecutionEnvironment in the slf4j-api and slf4j-integration are set to J2SE-1.6. The Standard Eclipse OSGi Execution Environment for Java 6 is JavaSE-1.6 and not J2SE-1.6. Due to this error, builds using the Eclipse OSGi Execution Environment value will have an error of an unrecognized Execution Environment. One example is using Eclipse Tycho to build Eclipse plugins and OSGi bundles. The commit ab389a9b82abe35034a3026c7eb0d4b9a07b4ae7 from J2SE-1.5 to J2SE-1.6, is the commit that migrated the Bundle-RequiredExecutionEnvironment forward in slf4j-api and slf4j-integration manifests to 1.6. It's worth noting that there is another comment associated with a commit that addresses this error: https://github.com/qos-ch/slf4j/commit/5f00780faba08756932de6c165a153dd1dd7…. For the listing of the Standard Execution Environments, please see: The Standard Execution Environments are listed at: https://wiki.eclipse.org/Execution_Environments#Standard_Execution_Environm…. As part of this defect submission, a fix with the changes to correct this issue has been created in my GitHub fork and is available to be reviewed to be included in the next release of the slf4j projects. The GitHub fork URL is: https://github.com/larsmir/slf4j. The specific commit, 928ab902187ebdc78b2262214bd2cb4c36c18a9a, that makes the changes is located at: https://github.com/larsmir/slf4j/commit/928ab902187ebdc78b2262214bd2cb4c36c…. Thank you. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-448) LocLogger doesn't allow use of Markers along with Message Id's
by QOS.CH (JIRA) 15 Nov '18

15 Nov '18

Glen Lockhart created SLF4J-448: ----------------------------------- Summary: LocLogger doesn't allow use of Markers along with Message Id's Key: SLF4J-448 URL: https://jira.qos.ch/browse/SLF4J-448 Project: SLF4J Issue Type: Improvement Components: slf4j-ext Affects Versions: 1.8.0-beta2 Reporter: Glen Lockhart Assignee: SLF4J developers list I would like to use the LocLogger to provide message catalogs in my application. However, I also use Markers with my logger to allow for more complex filtering rules using a turboFilter. I can't use both given the API in org.slf4j.cal10n.LocLogger. Using MDC isn't an option as the code is running inside a Vert.x event loop and use of thread locals doesn't work in that world. I can provide a PR if you're willing to accept one. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-365) CLONE - Provide a BOM of all slf4j artifacts
by QOS.CH (JIRA) 12 Nov '18

12 Nov '18

[ https://jira.qos.ch/browse/SLF4J-365?page=com.atlassian.jira.plugin.system.… ] Jörg Sesterhenn commented on SLF4J-365: --------------------------------------- Please vote for SLF4J-437 if you want this feature. It's a duplicate issue that is not yet closed ;). > CLONE - Provide a BOM of all slf4j artifacts > -------------------------------------------- > > Key: SLF4J-365 > URL: https://jira.qos.ch/browse/SLF4J-365 > Project: SLF4J > Issue Type: New Feature > Reporter: Ceki Gülcü > Assignee: Ceki Gülcü > Fix For: 1.7.22 > > > We have an enterprise parent POM that defines versions of maven artifacts for all products that are built in our enterprise. > We want to define the version of all slf4j artifacts in that parent pom. Idealy we would just import a BOM (https://maven.apache.org/guides/introduction/introduction-to-dependency-mec…) > Instead of importing your BOM we now list all slf4j modules in our parent POM. Which means we have to check for new/changed modules with every version. > One example of a great BOM is [the log4j BOM|http://central.maven.org/maven2/org/apache/logging/log4j/log4j-bom/2.5/…] > Please provide a BOM just like Log4j2 does, so that we can import it in our enterprise parent pom. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 12 Nov '18

12 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Jörg Sesterhenn commented on SLF4J-437: --------------------------------------- @Joachim, @Michael please be nice to one another :) I have described our usecase in https://jira.qos.ch/browse/SLF4J-365 which got closed as won't fix for beeing to much effort. I believe Ceki already sees the value of that feature for users of slf4j (at least he stated it makes sense in LOGBACK-1157). By providing examples and an alternative implementation I hope to have lowered the burden of creating an initial BOM. Maybe if more users see the value in BOMs this issue will get somewhere. @Joachim: Let me explain the advantage of a BOM for us with an example: ------------------------------------------------------------------------------------------------------- Example: slf4j adds another module, or renames a module. Without BOM every project will have to carefully read the releasenotes and then add another entry to their (parent-)pom where the slf4js modules are listed and add/rename a module. In big companys this might be centralized so that you have to do this for a lot of libraries. It's a tedious and error prone task. With BOM every project just raises the version of the BOM in the (parent-)pom to the latest and automatically ensures that all module versions are managed. This is quite convenient and also helps to keep our parent-pom at a somewhat manageable size. There are more examples like just increasing the version, or dropping a module where the same logic applies. @Joachim: Did this help? ------------------------------------------------------------------------------------------------------- Slf4j still needs to deal with the housekeeping of its BOM (best integrate it into the build process) - which is essentially what other companys/teams gain from having a single BOM for a library - less housekeeping. It would simply make an awesome library just a little bit more awesome ;) > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 10 Nov '18

10 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-437: ----------------------------------------- Yeah I see where I went wrong. However, I find "please google" a pretty offensive thing to say; it's no argument, and it's placing the burden of review and finding on the other side, which I consider just cheap. YMMV, but I'll give you a bit of your own medicine: Please google where I went wrong, you'll have to convince Ceki, not me. > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 10 Nov '18

10 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Michael Osipov commented on SLF4J-437: -------------------------------------- Joachim, please google the benefit of that. Basically, it spares me to repeat every single SLF4J dep in my depMgmt section, I simply use the import scope of the BOM and I am done. This works great with Spring framework. > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 09 Nov '18

09 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-437: ----------------------------------------- >From the Maven site, I see that a BOM pom is for multi-part projects with a fixed list of libraries to use. This isn't applicable for SLF4J, because there is no bill of materials involved - every project needs a different subset of the available backend adapters, so SLF4J would have to make a separate BOM for each combination of required and non-required adapters, that's a combinatorial explosion. Having to specify the version explicitly isn't so bad anyway. You don't reconfigure SLF4J dependencies so often. > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-437) Create a BOM POM
by QOS.CH (JIRA) 09 Nov '18

09 Nov '18

[ https://jira.qos.ch/browse/SLF4J-437?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-437: ----------------------------------------- What purpose does a bill-of-materials pom serve? What problem does it solve? The Description says "saves version repetition", but that's easily handled using a Maven property. So I'm wondering what part of the picture I'm missing. > Create a BOM POM > ---------------- > > Key: SLF4J-437 > URL: https://jira.qos.ch/browse/SLF4J-437 > Project: SLF4J > Issue Type: Task > Affects Versions: 1.8.0-beta2 > Reporter: Michael Osipov > Assignee: SLF4J developers list > > Please create a {{slf4j-bom}} POM which can be imported via dependency management. This makes consumer POM less verbose, no need to repeat version. The Spring Framework does this for example. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 12 , JDK 8u202 & Project Panama Early-Access builds available
by Rory O'Donnell 09 Nov '18

09 Nov '18

Hi Ceki, *JDK 12 Early Access build 19 is available at : - jdk.java.net/12/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Release Notes updates since last email o Build 18 – JDK-8211883: Disable anon and NULL cipher suites + Crypto Roadmap <https://java.com/en/jre-jdk-cryptoroadmap.html> Updated o Build 17 – JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume o Build 16 – JDK-8211866: TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms o Build 17 – JDK-8195793 : Remove GTE CyberTrust Global Root o Build 16 - JDK-8191053 : Provide a mechanism to make system's security manager immutable * JEPs proposed for JDK 12 so far: o JEP 230 - Microbenchmark Suite <https://openjdk.java.net/jeps/230> * JEPs targeted to JDK 12, so far o 325: Switch Expressions (Preview) <http://openjdk.java.net/jeps/325> o 326: Raw String Literals (Preview) <http://openjdk.java.net/jeps/326> o 340: One AArch64 Port, Not Two <http://openjdk.java.net/jeps/340> o 341: Default CDS Archives <http://openjdk.java.net/jeps/341> *JDK 8u202 Early Access build 03 is available at : - **http://jdk.java.net/8/* * JDK 8u202 timeline is available [1] o GA is scheduled for January 2019 *Project Panama Early-Access build 0 ***is available at : - http://jdk.java.net/panama/ ** * Early access builds from Project Panama <https://openjdk.java.net/projects/panama/> * Early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Feedback - Please send feedback via e-mail to panama-dev(a)openjdk.java.net <mailto:panama-dev@openjdk.java.net>. * To send e-mail to this address you must first subscribe to the mailing list <http://mail.openjdk.java.net/mailman/listinfo/panama-dev>. *Crypto Roadmap Updated [2] * Rgds,Rory [1] http://openjdk.java.net/projects/jdk8u/releases/8u202.html [2] https://java.com/en/jre-jdk-cryptoroadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0