October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-107: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha10 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-146) Cleanup/fix IPV6 testsuite

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-146?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-146: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > Cleanup/fix IPV6 testsuite > -------------------------- > > Key: WFCORE-146 > URL: https://issues.jboss.org/browse/WFCORE-146 > Project: WildFly Core > Issue Type: Task > Affects Versions: 1.0.0.Alpha8 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 1.0.0.Alpha10 > > > CLI testsuite cannot be ported over to Core as we have problems with IPV6 testsuite. > Testsuite configuration for ipv6 should be unified and simplified to make all this work in core and in full without extra params to build -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-140) The Resource for a deployment whose 'persistent' attribute is 'false' does not return 'true' from isRuntime()

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-140?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-140: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > The Resource for a deployment whose 'persistent' attribute is 'false' does not return 'true' from isRuntime() > ------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-140 > URL: https://issues.jboss.org/browse/WFCORE-140 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha8 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha10 > > > Scanner managed deployments have the deployment resource's 'persistent' attribute set to 'false'. This results in the StandaloneXml not persisting the resource to XML, but that depends on custom logic in StandaloneXml that reads the attribute. > The Resource for these deployments should return 'true' from isRuntime() so callers can decided about this without needing internal knowledge of the resource attributes. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-139) OperationContext should create runtime-only resources for addresses whose registration is runtime only

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-139?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-139: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > OperationContext should create runtime-only resources for addresses whose registration is runtime only > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-139 > URL: https://issues.jboss.org/browse/WFCORE-139 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha10 > > > The OperationContext.createResource method creates and adds a default Resource. The created Resource should return the same value from isRuntime() that the ManagementResourceRegistration associated with the target address returns from MRR.isRuntimeOnly() -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-137) Add Kerberos tests to domain-management module

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-137: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > Add Kerberos tests to domain-management module > ---------------------------------------------- > > Key: WFCORE-137 > URL: https://issues.jboss.org/browse/WFCORE-137 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-151) Update JBoss Remoting

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-151?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFCORE-151: ---------------------------------- Fix Version/s: 1.0.0.Alpha10 (was: 1.0.0.Alpha9) > Update JBoss Remoting > --------------------- > > Key: WFCORE-151 > URL: https://issues.jboss.org/browse/WFCORE-151 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-136) Create a new error message for suffix attribute on size-rotating-file-handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-136?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-136: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1147806|https://bugzilla.redhat.com/show_bug.cgi?id=1147806] from MODIFIED to ON_QA > Create a new error message for suffix attribute on size-rotating-file-handler > ------------------------------------------------------------------------------ > > Key: WFCORE-136 > URL: https://issues.jboss.org/browse/WFCORE-136 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > > As part of WFCORE-113, the suffix attribute on size-rotating-file-handler has a little bit different functionality than on other handlers (seconds or milliseconds are allowed). However the validation error message is the same as on other handlers ("seconds or milliseconds are not allowed"). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-132) BoundedQueueThreadPoolWriteAttributeHandler does not deal with undefined core-threads correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-132?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-132: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1147067|https://bugzilla.redhat.com/show_bug.cgi?id=1147067] from MODIFIED to ON_QA > BoundedQueueThreadPoolWriteAttributeHandler does not deal with undefined core-threads correctly > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-132 > URL: https://issues.jboss.org/browse/WFCORE-132 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha8 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha9 > > > BoundedQueueThreadPoolWriteAttributeHandler doesn't deal with undefined values for core-threads correctly. It assumes the attribute will be defined, and that's not required. > The attribute doesn't have a fixed default value. Instead, the behavior in add is to set the runtime value to match max-threads of core-threads is undefined. BoundedQueueThreadPoolWriteAttributeHandler should do the same. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1215) Only use XidWrapper if needed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1215?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1215: ------------------------------------------------ Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1147419|https://bugzilla.redhat.com/show_bug.cgi?id=1147419] from MODIFIED to ON_QA > Only use XidWrapper if needed > ----------------------------- > > Key: JBJCA-1215 > URL: https://issues.jboss.org/browse/JBJCA-1215 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.28.Final, 1.1.8.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on LOGMGR-95: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1079106|https://bugzilla.redhat.com/show_bug.cgi?id=1079106] from MODIFIED to ON_QA > Log4j Logger.getParent() inconsistent > ------------------------------------- > > Key: LOGMGR-95 > URL: https://issues.jboss.org/browse/LOGMGR-95 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Livingston > Assignee: James Perkins > > Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in. > Consider: > Logger.getLogger("a"); > Logger.getLogger("a.b.c"); > Logger.getLogger("a.b"); > When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

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 October 2014