April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-133) Use StackWalker to get extended log record information

by David Lloyd (JIRA)

David Lloyd created LOGMGR-133: ---------------------------------- Summary: Use StackWalker to get extended log record information Key: LOGMGR-133 URL: https://issues.jboss.org/browse/LOGMGR-133 Project: JBoss Log Manager Issue Type: Sub-task Reporter: David Lloyd Fix For: 2.1.0.Beta1 Under Java 9, you can use a StackWalker to efficiently traverse the stack and return information about callers. Using this mechanism should be substantially better-performing than snapshotting the stack to acquire the calling class information for the extended log record class. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-132) Remove extended stack trace functionality

by David Lloyd (JIRA)

David Lloyd created LOGMGR-132: ---------------------------------- Summary: Remove extended stack trace functionality Key: LOGMGR-132 URL: https://issues.jboss.org/browse/LOGMGR-132 Project: JBoss Log Manager Issue Type: Sub-task Reporter: David Lloyd Fix For: 2.1.0.Beta1 Java 9 stack traces include module name and version number. All our extended stack trace hacky code should be deleted and both format characters should yield a standard stack trace under Java 9. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version

by David Lloyd (JIRA)

David Lloyd created LOGMGR-131: ---------------------------------- Summary: 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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1483) Recursive removal doesn't deal with reload-required cleanly

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1483: ---------------------------------------- Summary: Recursive removal doesn't deal with reload-required cleanly Key: WFCORE-1483 URL: https://issues.jboss.org/browse/WFCORE-1483 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required. The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed. This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive reload, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-130) JDK9 Support

by David Lloyd (JIRA)

David Lloyd created LOGMGR-130: ---------------------------------- Summary: JDK9 Support Key: LOGMGR-130 URL: https://issues.jboss.org/browse/LOGMGR-130 Project: JBoss Log Manager Issue Type: Feature Request Reporter: David Lloyd Fix For: 2.1.0.Beta1 A few enhancements become possible, desirable, and/or necessary when moving to JDK 9. This is an umbrella parent issue to cover them all. Note that some of these features may require multi-version JAR building, which Maven cannot yet do. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (REMJMX-106) Resources leak when an exception is thrown in "connect"

by Dominique Toupin (JIRA)

[ https://issues.jboss.org/browse/REMJMX-106?page=com.atlassian.jira.plugin... ] Dominique Toupin updated REMJMX-106: ------------------------------------ Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/20 > Resources leak when an exception is thrown in "connect" > ------------------------------------------------------- > > Key: REMJMX-106 > URL: https://issues.jboss.org/browse/REMJMX-106 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.1.Final > Environment: Wildfly 10.0.0.Final > Reporter: Dominique Toupin > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (REMJMX-106) Resources leak when an exception is thrown in "connect"

by Dominique Toupin (JIRA)

Dominique Toupin created REMJMX-106: --------------------------------------- Summary: Resources leak when an exception is thrown in "connect" Key: REMJMX-106 URL: https://issues.jboss.org/browse/REMJMX-106 Project: Remoting JMX Issue Type: Bug Components: Connection Affects Versions: 2.0.1.Final Environment: Wildfly 10.0.0.Final Reporter: Dominique Toupin Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1129) osgi bundle have wrong metadata info

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1129?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1129: ----------------------------------- Assignee: Petr Široký (was: Mario Fusco) > osgi bundle have wrong metadata info > ------------------------------------ > > Key: DROOLS-1129 > URL: https://issues.jboss.org/browse/DROOLS-1129 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.4.0.Final > Reporter: Hiep Lq > Assignee: Petr Široký > > 1. bundle reteoo have wrong Bundle-SymbolicName. > now is Bundle-SymbolicName: org.drools.core > it should is Bundle-SymbolicName: org.drools.reteoo > 2. base in standard of P2 repository. almost source bundle have wrong value at Bundle-SymbolicName and Eclipse-SourceBundle > example:drools-compiler-6.4.0.Final-sources > current value of: Bundle-SymbolicName = drools-compiler.source > should be:Bundle-SymbolicName = org.drools.compiler.source > current value of: Eclipse-SourceBundle=drools-compiler > should be:Eclipse-SourceBundle=org.drools.compiler > or we can keep source bundle, and change at binary bundle > example change Bundle-SymbolicName of org.drools.compiler to drools-compiler -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1129) osgi bundle have wrong metadata info

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1129?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1129: ------------------------------------- reteoo Bundle-SymbolicName fixed by https://github.com/droolsjbpm/drools/commit/f06e6c3749807cb258f65a8726c9a... > osgi bundle have wrong metadata info > ------------------------------------ > > Key: DROOLS-1129 > URL: https://issues.jboss.org/browse/DROOLS-1129 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 6.4.0.Final > Reporter: Hiep Lq > Assignee: Mario Fusco > > 1. bundle reteoo have wrong Bundle-SymbolicName. > now is Bundle-SymbolicName: org.drools.core > it should is Bundle-SymbolicName: org.drools.reteoo > 2. base in standard of P2 repository. almost source bundle have wrong value at Bundle-SymbolicName and Eclipse-SourceBundle > example:drools-compiler-6.4.0.Final-sources > current value of: Bundle-SymbolicName = drools-compiler.source > should be:Bundle-SymbolicName = org.drools.compiler.source > current value of: Eclipse-SourceBundle=drools-compiler > should be:Eclipse-SourceBundle=org.drools.compiler > or we can keep source bundle, and change at binary bundle > example change Bundle-SymbolicName of org.drools.compiler to drools-compiler -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ELY-383) Update ServerAuthenticationContext to carry an identity from start to end

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-383?page=com.atlassian.jira.plugin.sy... ] David Lloyd reopened ELY-383: ----------------------------- > Update ServerAuthenticationContext to carry an identity from start to end > ------------------------------------------------------------------------- > > Key: ELY-383 > URL: https://issues.jboss.org/browse/ELY-383 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta4 > > Attachments: Blank Flowchart - ServerAuthenticationContext.png > > > The {{ServerAuthenticationContext}} should capture the identity in force for its domain when it is constructed. Any authorization attempt should always apply to the current identity - either the captured identity, or whatever the last successfully authorized identity was in the context. > The attached state diagram should accurately summarize how authorization identity flows through. Authentication identity is only available during the "NAME ASSIGNED" state; once authorization occurs, the authentication identity is no longer useful and is disposed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2016