May 2016 - jboss-jira - Jboss List Archives

[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)

8 years, 1 month

1
0
0 / 0

[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)

8 years, 1 month

1
0
0 / 0

[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)

8 years, 1 month

1
0
0 / 0

[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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-525) Support our own Unicode normalizer

by David Lloyd (JIRA)

David Lloyd created ELY-525: ------------------------------- Summary: 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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1145) ClassCastException when detecting a drools runtime

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1145?page=com.atlassian.jira.plugi... ] Andrej Podhradsky closed DROOLS-1145. ------------------------------------- Fix Version/s: 6.4.0.Final Resolution: Done Verified with JBDS 9.1.0.GA + JBDS-IS 9.0.0.GA (contains Drools 6.4.1.Final-v20160503-1355-B205) > ClassCastException when detecting a drools runtime > -------------------------------------------------- > > Key: DROOLS-1145 > URL: https://issues.jboss.org/browse/DROOLS-1145 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: JBDS 9.1.0.GA + JBDS-IS 9.0.0.CR1 (contains Drools plugin 6.4.0.Final) > Reporter: Andrej Podhradsky > Assignee: Andrej Podhradsky > Labels: release_notes, verified_jbdsis-9.0.0 > Fix For: 6.4.0.Final > > Attachments: stacktrace.txt > > > ClassCastException when detecting a drools runtime. This exception causes that no runtime (not only drools) is detected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1145) ClassCastException when detecting a drools runtime

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1145?page=com.atlassian.jira.plugi... ] Andrej Podhradsky updated DROOLS-1145: -------------------------------------- Labels: release_notes verified_jbdsis-9.0.0 (was: release_notes) > ClassCastException when detecting a drools runtime > -------------------------------------------------- > > Key: DROOLS-1145 > URL: https://issues.jboss.org/browse/DROOLS-1145 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: JBDS 9.1.0.GA + JBDS-IS 9.0.0.CR1 (contains Drools plugin 6.4.0.Final) > Reporter: Andrej Podhradsky > Assignee: Andrej Podhradsky > Labels: release_notes, verified_jbdsis-9.0.0 > Attachments: stacktrace.txt > > > ClassCastException when detecting a drools runtime. This exception causes that no runtime (not only drools) is detected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1145) ClassCastException when detecting a drools runtime

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1145?page=com.atlassian.jira.plugi... ] Andrej Podhradsky commented on DROOLS-1145: ------------------------------------------- Note that there is another issue with the runtime detector, please see DROOLS-1163 > ClassCastException when detecting a drools runtime > -------------------------------------------------- > > Key: DROOLS-1145 > URL: https://issues.jboss.org/browse/DROOLS-1145 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: JBDS 9.1.0.GA + JBDS-IS 9.0.0.CR1 (contains Drools plugin 6.4.0.Final) > Reporter: Andrej Podhradsky > Assignee: Andrej Podhradsky > Labels: release_notes > Attachments: stacktrace.txt > > > ClassCastException when detecting a drools runtime. This exception causes that no runtime (not only drools) is detected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1163) Drools runtime detector doesn't detect BRMS 6.3

by Andrej Podhradsky (JIRA)

Andrej Podhradsky created DROOLS-1163: ----------------------------------------- Summary: Drools runtime detector doesn't detect BRMS 6.3 Key: DROOLS-1163 URL: https://issues.jboss.org/browse/DROOLS-1163 Project: Drools Issue Type: Bug Components: eclipse plugin Affects Versions: 6.4.0.Final Environment: JBDS 9.1.0.GA + JBDS-IS 9.0.0.GA Reporter: Andrej Podhradsky Assignee: Robert (Bob) Brodt Drools runtime detector doesn't detect BRMS 6.3 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1154) Add drools runtime dialog doesn't support version naming of the product

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1154?page=com.atlassian.jira.plugi... ] Andrej Podhradsky updated DROOLS-1154: -------------------------------------- Labels: release_notes reported-by-qe verified_jbdsis-9.0.0 (was: reported-by-qe) > Add drools runtime dialog doesn't support version naming of the product > ------------------------------------------------------------------------ > > Key: DROOLS-1154 > URL: https://issues.jboss.org/browse/DROOLS-1154 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: JBDS 9.1.0.GA > Drools plugin 6.4.1-Snapshot > Reporter: Tomas David > Assignee: Robert (Bob) Brodt > Labels: release_notes, reported-by-qe, verified_jbdsis-9.0.0 > Fix For: 6.4.0.Final > > Attachments: add_button.png > > > When you add a drools product runtime and you try to specify a version of runtime (for example "6.4.0.Final-redhat-2"), the Add button of Add Drools runtime dialog is not enabled so it is not possible to complete the runtime adding. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016