January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6431?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6431: ---------------------------------- Component/s: Domain Management (was: Console) > Incorrectly evaluated expression when property is defined after the expression in xml > ------------------------------------------------------------------------------------- > > Key: AS7-6431 > URL: https://issues.jboss.org/browse/AS7-6431 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.2.0.Alpha1 > Reporter: Ondřej Chaloupka > Assignee: Brian Stansberry > > There is problem in evaluation of expression in case that property for evaluation is defined after the expression. > In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine. > When you define system properties in xml like: > {code} > <system-properties> > <property name="qa.test.property" value="${qa.test.exp:defaultValue}"/> > <property name="qa.test.exp" value="expression.value"/> > </system-properties> > {code} > you start the container and then you can check the expression evaluation in jboss-cli.sh with command: > {code} > :resolve-expression(expression="${qa.test.property}") > {code} > The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined. > When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created AS7-6431: ------------------------------------- Summary: Incorrectly evaluated expression when property is defined after the expression in xml Key: AS7-6431 URL: https://issues.jboss.org/browse/AS7-6431 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.2.0.Alpha1 Reporter: Ondřej Chaloupka Assignee: Brian Stansberry There is problem in evaluation of expression in case that property for evaluation is defined after the expression. In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine. When you define system properties in xml like: {code} <system-properties> <property name="qa.test.property" value="${qa.test.exp:defaultValue}"/> <property name="qa.test.exp" value="expression.value"/> </system-properties> {code} you start the container and then you can check the expression evaluation in jboss-cli.sh with command: {code} :resolve-expression(expression="${qa.test.property}") {code} The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined. When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1577) UNICAST / UNICAST2: add better synchronization around ReceiverEntries

by Bela Ban (JIRA)

Bela Ban created JGRP-1577: ------------------------------ Summary: UNICAST / UNICAST2: add better synchronization around ReceiverEntries Key: JGRP-1577 URL: https://issues.jboss.org/browse/JGRP-1577 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.3 When A gets unicast messages from B, then A creates a ReceiverEntry in its recv_table for B. The creation (or fetching of the existing ReceiverEntry) is done under a lock, however, the adding and subsequent removal of messages is not done under a lock (well, actually, adding messages to ReceiverEntry.win is locked). What could happen is the following: * B sends messages 1,2,3 (conn-id=5) * B closes the connection to A * B sends messages 1,2,3 to A (new conn-id=6) * A receives messages 1,2,3 with conn-id=5 * A grabs the ReceiverEntry for B and starts adding 1,2,3 to win * Messages 1-3 from B with conn-id=6 are received * This creates a new ReceiverEntry for B * A now starts removing and passing up messages 1-3 from B with the old conn-id 5 * A receives messages 1-3 from B with conn-id=5 * Subsequently, A also receives messages 1-3 from B with conn-id=6 Not sure if this really constitutes a bug, but I nevertheless need to take a look. Possible solution: * Create receiverEntry for B only *once* * Remove ReceiverEntry for B only when the view excludes B, but *not* when B sends messages with a different conn-id * Instead, lock on the ReceiverEntry for B when messages are received: ** When a message with a different conn-id is received, only change the contents of ReceiverEntry (e.g. conn-id, reset win etc), but *don't* remove the ReceiverEntry from recv_table and create a new one -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-722) Too eager shutdown of pools through idle timeout

by Alexander Vinnik (JIRA)

[ https://issues.jboss.org/browse/JBJCA-722?page=com.atlassian.jira.plugin.... ] Alexander Vinnik commented on JBJCA-722: ---------------------------------------- We are experiencing this problem in JBoss 6.1. The workaround is not working for us: The pool is not closed now, but when a 3rd party application is trying to access the idle connection, it fails. Is it possible to make a patch addressing this problem in 6.1? > Too eager shutdown of pools through idle timeout > ------------------------------------------------ > > Key: JBJCA-722 > URL: https://issues.jboss.org/browse/JBJCA-722 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.6.Final, 1.1.0.Alpha4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.7.Final, 1.1.0.Alpha5 > > > In order to cleanup pools with a sparse Subject/CRI coverage we shutdown the pool if it is empty. > However, there is no reason to do so if it is the only pool available. Furthermore we should always try and allocate a connection in order to kick the allocation mechanism into effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-390) Eliminate the threads subsystem

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-390?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated AS7-390: ---------------------------- Fix Version/s: 7.3.0.Alpha1 (was: 7.2.0.CR1) > Eliminate the threads subsystem > ------------------------------- > > Key: AS7-390 > URL: https://issues.jboss.org/browse/AS7-390 > Project: Application Server 7 > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 7.3.0.Alpha1 > > > The threads subsystem should be eliminated, and instead the individual consuming subsystems should utilize common code from the jboss-as-threads module to define and manage thread pools within their own configuration models. > Subtasks for affected subsystems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6430) JSR-236 Java EE 7 concurrency support

by David Lloyd (JIRA)

David Lloyd created AS7-6430: -------------------------------- Summary: JSR-236 Java EE 7 concurrency support Key: AS7-6430 URL: https://issues.jboss.org/browse/AS7-6430 Project: Application Server 7 Issue Type: Task Components: EE Reporter: David Lloyd Fix For: 7.3.0.Alpha1 Provide a mechanism within the EE subsystem to allow the definition and binding of a managed thread pool into JNDI as per the JSR-236 specification. http://download.oracle.com/otndocs/jcp/concurrency_utilities-1_0-pr-spec/... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6429) EJB3 subsystem threads usage

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6429?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-6429: ----------------------------- Fix Version/s: 7.2.0.CR1 (was: 7.0.0.CR1) > EJB3 subsystem threads usage > ---------------------------- > > Key: AS7-6429 > URL: https://issues.jboss.org/browse/AS7-6429 > Project: Application Server 7 > Issue Type: Sub-task > Components: EJB > Reporter: David Lloyd > Assignee: jaikiran pai > Fix For: 7.2.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6429) EJB3 subsystem threads usage

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6429?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-6429: ----------------------------- Component/s: Domain Management JCA > EJB3 subsystem threads usage > ---------------------------- > > Key: AS7-6429 > URL: https://issues.jboss.org/browse/AS7-6429 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management, EJB, JCA > Reporter: David Lloyd > Assignee: jaikiran pai > Fix For: 7.2.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6429) EJB3 subsystem threads usage

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6429?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar reassigned AS7-6429: -------------------------------- Assignee: Tomaz Cerar (was: jaikiran pai) > EJB3 subsystem threads usage > ---------------------------- > > Key: AS7-6429 > URL: https://issues.jboss.org/browse/AS7-6429 > Project: Application Server 7 > Issue Type: Sub-task > Components: Domain Management, EJB, JCA > Reporter: David Lloyd > Assignee: Tomaz Cerar > Fix For: 7.2.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-390) Eliminate the threads subsystem

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-390?page=com.atlassian.jira.plugin.sy... ] Tomaz Cerar updated AS7-390: ---------------------------- Fix Version/s: 7.2.0.CR1 (was: 7.0.0.CR1) > Eliminate the threads subsystem > ------------------------------- > > Key: AS7-390 > URL: https://issues.jboss.org/browse/AS7-390 > Project: Application Server 7 > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 7.2.0.CR1 > > > The threads subsystem should be eliminated, and instead the individual consuming subsystems should utilize common code from the jboss-as-threads module to define and manage thread pools within their own configuration models. > Subtasks for affected subsystems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

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 January 2013