[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-131:
--------------------------------------
Ah right good point. I forgot about that for some reason.
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Beta1
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGMGR-131:
------------------------------------
It'd be no different to how we resolve class name, method name, line number, and file name, in org.jboss.logmanager.ExtLogRecord#calculateCaller().
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Beta1
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-131:
--------------------------------------
I guess this could be tricky with an {{AsyncHandler}}. The {{java.util.logging.LogRecord}} doesn't seem to have a way to get the module name so we'd have to somehow resolve it if there is no exception available.
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Beta1
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-136) java.util.logging.LogManager removed deprecated property change listeners
by James Perkins (JIRA)
James Perkins created LOGMGR-136:
------------------------------------
Summary: java.util.logging.LogManager removed deprecated property change listeners
Key: LOGMGR-136
URL: https://issues.jboss.org/browse/LOGMGR-136
Project: JBoss Log Manager
Issue Type: Sub-task
Reporter: James Perkins
Both the {{addPropertyChangeListener(PropertyChangeListener}} and {{removePropertyChangeListener(PropertyChangeListener}} were deprecated in Java 8 and removed in Java 9. There are two new replacement methods {{addConfigurationListener(Runnable)}} and {{removeConfigurationListener(Runnable)}} that have been added as replacements.
For the JBoss Log Manager these could likely be no-ops like the originals were.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGMGR-131:
------------------------------------
Yes, because this is for actual log format fields, not for stack traces.
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Beta1
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-131:
--------------------------------------
It looks like the {{StackTraceElement.toString()}} will already include the module and version.
{code:java}
public String toString() {
String mid = "";
if (moduleName != null) {
mid = moduleName;
if (moduleVersion != null)
mid += "@" + moduleVersion;
mid += "/";
}
return getClassName() + "." + methodName + "(" + mid +
(isNativeMethod() ? "Native Method)" :
(fileName != null && lineNumber >= 0 ?
fileName + ":" + lineNumber + ")" :
(fileName != null ? ""+fileName+")" : "Unknown Source)")));
}
{code}
Do we still want format options for it?
> Add format characters for module name, module version
> -----------------------------------------------------
>
> Key: LOGMGR-131
> URL: https://issues.jboss.org/browse/LOGMGR-131
> Project: JBoss Log Manager
> Issue Type: Sub-task
> Reporter: David Lloyd
> Fix For: 2.1.0.Beta1
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-525) Support our own Unicode normalizer
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-525?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-525:
----------------------------
Component/s: Utils
> Support our own Unicode normalizer
> ----------------------------------
>
> Key: ELY-525
> URL: https://issues.jboss.org/browse/ELY-525
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: David Lloyd
> Priority: Minor
>
> We should do our own Unicode normalizer, because the JDK one is not good performance-wise or memory-wise, and doesn't integrate well with the authentication mechanisms which require normalization.
> It would be accessible off of {{CodePointIterator}} as a few methods:
> * {{decomposeCanonical}}
> * {{decomposeCompatibility}}
> * {{composeCanonical}}
> These methods could be chained in various ways to achieve the standard defined normalization types:
> * NFD = {{decomposeCanonical}}
> * NFC = {{decomposeCanonical}} + {{composeCanonical}}
> * NFKD = {{decomposeCompatibility}}
> * NFKC = {{decomposeCompatibility}} + {{composeCanonical}}
> The types and behaviors are defined here: http://www.unicode.org/reports/tr15/tr15-43.html
> The implementations should be lazy. If possible they should be implemented in code as opposed to data tables, possibly one class per operation type per Unicode version so that only the necessary transformations are loaded/initialized. The code could potentially be generated from tables and rules by a Maven plugin or annotation processor (see https://github.com/jdeparser/jdeparser2 for one option).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-525) Support our own Unicode normalizer
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-525?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-525:
----------------------------
Description:
We should do our own Unicode normalizer, because the JDK one is not good performance-wise or memory-wise, and doesn't integrate well with the authentication mechanisms which require normalization.
It would be accessible off of {{CodePointIterator}} as a few methods:
* {{decomposeCanonical}}
* {{decomposeCompatibility}}
* {{composeCanonical}}
These methods could be chained in various ways to achieve the standard defined normalization types:
* NFD = {{decomposeCanonical}}
* NFC = {{decomposeCanonical}} + {{composeCanonical}}
* NFKD = {{decomposeCompatibility}}
* NFKC = {{decomposeCompatibility}} + {{composeCanonical}}
The types and behaviors are defined here: http://www.unicode.org/reports/tr15/tr15-43.html
The implementations should be lazy. If possible they should be implemented in code as opposed to data tables, possibly one class per operation type per Unicode version so that only the necessary transformations are loaded/initialized. The code could potentially be generated from tables and rules by a Maven plugin or annotation processor (see https://github.com/jdeparser/jdeparser2 for one option).
was:
We should do our own Unicode normalizer, because the JDK one is not good performance-wise or memory-wise, and doesn't integrate well with the authentication mechanisms which require normalization.
It would be accessible off of {CodePointIterator} as a few methods:
* {decomposeCanonical}
* {decomposeCompatibility}
* {composeCanonical}
These methods could be chained in various ways to achieve the standard defined normalization types:
* NFD = {decomposeCanonical}
* NFC = {decomposeCanonical} + {composeCanonical}
* NFKD = {decomposeCompatibility}
* NFKC = {decomposeCompatibility} + {composeCanonical}
The types and behaviors are defined here: http://www.unicode.org/reports/tr15/tr15-43.html
The implementations should be lazy. If possible they should be implemented in code as opposed to data tables, possibly one class per operation type per Unicode version so that only the necessary transformations are loaded/initialized. The code could potentially be generated from tables and rules by a Maven plugin or annotation processor (see https://github.com/jdeparser/jdeparser2 for one option).
> Support our own Unicode normalizer
> ----------------------------------
>
> Key: ELY-525
> URL: https://issues.jboss.org/browse/ELY-525
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: David Lloyd
> Priority: Minor
>
> We should do our own Unicode normalizer, because the JDK one is not good performance-wise or memory-wise, and doesn't integrate well with the authentication mechanisms which require normalization.
> It would be accessible off of {{CodePointIterator}} as a few methods:
> * {{decomposeCanonical}}
> * {{decomposeCompatibility}}
> * {{composeCanonical}}
> These methods could be chained in various ways to achieve the standard defined normalization types:
> * NFD = {{decomposeCanonical}}
> * NFC = {{decomposeCanonical}} + {{composeCanonical}}
> * NFKD = {{decomposeCompatibility}}
> * NFKC = {{decomposeCompatibility}} + {{composeCanonical}}
> The types and behaviors are defined here: http://www.unicode.org/reports/tr15/tr15-43.html
> The implementations should be lazy. If possible they should be implemented in code as opposed to data tables, possibly one class per operation type per Unicode version so that only the necessary transformations are loaded/initialized. The code could potentially be generated from tables and rules by a Maven plugin or annotation processor (see https://github.com/jdeparser/jdeparser2 for one option).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years