September 2019 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-472) Should MDCClosable put the old value back into the MDC?
by QOS.CH (JIRA) 04 Sep '19

04 Sep '19

Stephen created SLF4J-472: ----------------------------- Summary: Should MDCClosable put the old value back into the MDC? Key: SLF4J-472 URL: https://jira.qos.ch/browse/SLF4J-472 Project: SLF4J Issue Type: Improvement Reporter: Stephen Assignee: SLF4J developers list Priority: Minor I'm not actually sure about this myself. Currently when you close the MDCClosable it will remove the value from the MDC. The close method doesn't put things back to the way they were. The put method called when MDCClosable is created returns void so this isn't a trivial thing to implement. I imagine that different logging providers might not return the old value like the put method on the map. Should something like this be implemented? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 02 Sep '19

02 Sep '19

[ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.… ] Foo Far commented on SLF4J-471: ------------------------------- [The CharSequence interface|https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequence.…] is implemented by both String (which cannot be easily preallocated) and nio CharBuffer (which can). Java String cannot be easily preallocated because it is strictly immutable. The CharSequence could be implemented by a class with only private mutability, that allocates at time 1, and initializes via a factory method at time 2. > CharSequence and varargs > ------------------------ > > Key: SLF4J-471 > URL: https://jira.qos.ch/browse/SLF4J-471 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Foo Far > Assignee: SLF4J developers list > > Could sl4fj provide an interface that enables avoiding all object allocation? > This is important for low latency applications, which only allocate objects at startup, in order to prevent even minor collection pauses. > The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they initially work with allocations. > For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 02 Sep '19

02 Sep '19

[ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-471: ---------------------------------- As you are aware, SFL4J 2.0 introduced a fluent API. Since the API is still in alpha phase, we could replace the String message/format parameter with a CharSequence with no consequences. However, can you please explain why CharSequence is any better than String with regards to pre-allocation? Any references? > CharSequence and varargs > ------------------------ > > Key: SLF4J-471 > URL: https://jira.qos.ch/browse/SLF4J-471 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Reporter: Foo Far > Assignee: SLF4J developers list > > Could sl4fj provide an interface that enables avoiding all object allocation? > This is important for low latency applications, which only allocate objects at startup, in order to prevent even minor collection pauses. > The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they initially work with allocations. > For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-471) CharSequence and varargs
by QOS.CH (JIRA) 01 Sep '19

01 Sep '19

Foo Far created SLF4J-471: ----------------------------- Summary: CharSequence and varargs Key: SLF4J-471 URL: https://jira.qos.ch/browse/SLF4J-471 Project: SLF4J Issue Type: Bug Components: Core API Environment: Could sl4fj provide an interface that enables avoiding all object allocation? This is important for low latency applications, which only allocation objects at startup, in order to prevent even minor collection pauses. The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they work with allocations. For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface. Reporter: Foo Far Assignee: SLF4J developers list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0