November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-670) Node type is not complete at index 0 after tab completion on an empty resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-670?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-670: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1277320 Bugzilla Update: Perform > Node type is not complete at index 0 after tab completion on an empty resource > ------------------------------------------------------------------------------ > > Key: WFCORE-670 > URL: https://issues.jboss.org/browse/WFCORE-670 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: James Perkins > Assignee: Alexey Loubyansky > Priority: Blocker > Fix For: 1.0.0.CR2 > > > Using something like {{/system-property=<TAB>}} with no system properties set results in future commands no longer working. > {code:title=Example Output} > [standalone@localhost:9990 /] /system-property= > The operation name is missing or the format of the operation request is wrong. > [standalone@localhost:9990 /] > [standalone@localhost:9990 /] exit > Node type is not complete at index 0 > [standalone@localhost:9990 /] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-5596: ---------------------------------------- WFLY-4661 rather. With only 5151 it is still within a management op. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-5596: ---------------------------------------- That is no longer true in WF 10 (WFLY-5151), MdbDeliveryControllerService.start()/stop() call those methods as well. It can be triggered by clustering events changing HA Singleton status. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-5596: ------------------------------------ I remember glancing at this code and thinking it could be better protected. However, IIRC the only usage point is from management ops, and since these ops are declared as write operations they hold the exclusive management write lock. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-390) Improve and enhance ValidationHelper and associated tools for XML/XSD use

by Weston Price (JIRA)

[ https://issues.jboss.org/browse/JBMETA-390?page=com.atlassian.jira.plugin... ] Weston Price updated JBMETA-390: -------------------------------- Component/s: common > Improve and enhance ValidationHelper and associated tools for XML/XSD use > ------------------------------------------------------------------------- > > Key: JBMETA-390 > URL: https://issues.jboss.org/browse/JBMETA-390 > Project: JBoss Metadata > Issue Type: Feature Request > Components: common, ejb > Affects Versions: 10.0.0.Beta1 > Reporter: Weston Price > Assignee: Weston Price > Priority: Optional > Fix For: 10.0.0.Beta2 > > > Currently support for XML validation, XSD maintenance and general XML/XSD handling is quite weak. While a ValidationHelper class exists, it needs to be enhance to remove hard coded references and allow for updating the underling XSD catalogs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1825) ReadWriteLock

by Manuel Dominguez Sarmiento (JIRA)

[ https://issues.jboss.org/browse/JGRP-1825?page=com.atlassian.jira.plugin.... ] Manuel Dominguez Sarmiento commented on JGRP-1825: -------------------------------------------------- Hi Bela, we would appreciate a native ReadWriteLock implementation in JGroups. We are working on improving the EhCache-JGroups replication integration so that cluster consistency can be achieved with replicated read-write caches. ReadWriteLocks are a necessity for many scenarios and corner cases. The alternative seems to be using the current exclusive lock construct, with two different locks (one for reads, another for writes) together with a distributed COUNTER, but this is far from being efficient (too chatty). Perhaps something along the lines of the algorithms described in https://en.wikipedia.org/wiki/Readers–writers_problem > ReadWriteLock > ------------- > > Key: JGRP-1825 > URL: https://issues.jboss.org/browse/JGRP-1825 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6 > > Attachments: JgroupTest.zip > > > Adds a read/write lock to LockService. The impl is attached -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-390) Improve and enhance ValidationHelper and associated tools for XML/XSD use

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/JBMETA-390?page=com.atlassian.jira.plugin... ] Carlo de Wolf updated JBMETA-390: --------------------------------- Fix Version/s: 10.0.0.Beta2 (was: 8.1.2.Final) > Improve and enhance ValidationHelper and associated tools for XML/XSD use > ------------------------------------------------------------------------- > > Key: JBMETA-390 > URL: https://issues.jboss.org/browse/JBMETA-390 > Project: JBoss Metadata > Issue Type: Feature Request > Components: ejb > Affects Versions: 10.0.0.Beta1 > Reporter: Weston Price > Assignee: Weston Price > Priority: Optional > Fix For: 10.0.0.Beta2 > > > Currently support for XML validation, XSD maintenance and general XML/XSD handling is quite weak. While a ValidationHelper class exists, it needs to be enhance to remove hard coded references and allow for updating the underling XSD catalogs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-358) Wrap all LDAP testing in a single suite

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-358: ------------------------------------ Summary: Wrap all LDAP testing in a single suite Key: ELY-358 URL: https://issues.jboss.org/browse/ELY-358 Project: WildFly Elytron Issue Type: Enhancement Components: Testsuite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 If we wrap all these tests in a single suite we can start up the LDAP server one, run all the tests and then stop the server - this will stop us incurring the set-up / tear-down cost for each test case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-357) LegacyPropertiesRealm requires group loading completing

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-357: ------------------------------------ Summary: LegacyPropertiesRealm requires group loading completing Key: ELY-357 URL: https://issues.jboss.org/browse/ELY-357 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 This part of the implementation was never completed as the API was still being designed, we now need this especially as we are using this realm to begin with by default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5615) Security module options not parsed

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5615?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-5615: ---------------------------------------- [~heiko.braun] In the description your CLI read-resource is against "myauth" not "myauth2". Is this a problem if the correct address is used? > Security module options not parsed > ---------------------------------- > > Key: WFLY-5615 > URL: https://issues.jboss.org/browse/WFLY-5615 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.CR4 > Reporter: Heiko Braun > Assignee: Brian Stansberry > Priority: Critical > > I've created a login module with several options and the result appears in standalone.xml. However when I read the resource using the CLI, these options are not shown. > {noformat} > <security-domain name="myDomain" cache-type="default"> > <authentication> > <login-module name="myauth" code="Simple" flag="optional"/> > <login-module name="myauth2" code="SimpleUsers" flag="sufficient"> > <module-option name="foo" value="bar"/> > <module-option name="one" value="two"/> > </login-module> > </authentication> > </security-domain> > {noformat} > {noformat} > [standalone@localhost:9990 /] /subsystem=security/security-domain=myDomain/authentication=classic/login-module=myauth:read-resource(recursive=true) > { > "outcome" => "success", > "result" => { > "code" => "Simple", > "flag" => "optional", > "module" => undefined, > "module-options" => undefined > } > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

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 November 2015