May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

1 month, 3 weeks

3
10
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2895: ------------------------------------- Description: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. Also RuntimeCapability should not create a ServiceName even if the cap has no serviceValueType. was: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. As a side task look into why we create a ServiceName even if the cap has no serviceValueType. > Save memory in dynamic RuntimeCapability ServiceName creation > ------------------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName even if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2895: ------------------------------------- Priority: Major (was: Minor) > Save memory in dynamic RuntimeCapability ServiceName creation > ------------------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > As a side task look into why we create a ServiceName even if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2895: ---------------------------------------- Assignee: Brian Stansberry > Save memory in dynamic RuntimeCapability ServiceName creation > ------------------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > As a side task look into why we create a ServiceName even if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2895: ---------------------------------------- Summary: Save memory in dynamic RuntimeCapability ServiceName creation Key: WFCORE-2895 URL: https://issues.jboss.org/browse/WFCORE-2895 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Priority: Minor RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. As a side task look into why we create a ServiceName even if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8867) Legacy protocol property resource operations do not work for legacy protocols

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-8867?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-8867: ------------------------------------ Yes the management model is supposed to retain compatibility. The exception is a major release, and in that case it's ok if we have a migration operation. In the case of elytron we have addressed compatibility by preserving the old and new subsystems. > Legacy protocol property resource operations do not work for legacy protocols > ----------------------------------------------------------------------------- > > Key: WFLY-8867 > URL: https://issues.jboss.org/browse/WFLY-8867 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > QE Cc [~mnovak], [~okalman], [~mstyk], [~pkremens] > Cc [~kabirkhan], [~jason.greene] > See steps to reproduce. The question is, to what degree should CLI commands be backward compatible with 7.0? XML configurations pasted from 7.0 are OK in this case. > I previously thought these changes were OK (once documented in migration guide), but after discussion with the rest of the QE team, the most common opinion is that CLI commands should be 100% backward compatible with 7.0, which is not the case here. > [~bilge] since this is not stated anywhere I know, can you confirm that CLI commands in 7.1 need to be backward compatible with 7.0? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1475) Convert project to use i18n logging and exceptions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1475?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1475: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from MODIFIED to ON_QA > Convert project to use i18n logging and exceptions > -------------------------------------------------- > > Key: JGRP-1475 > URL: https://issues.jboss.org/browse/JGRP-1475 > Project: JGroups > Issue Type: Task > Reporter: James Perkins > Assignee: Bela Ban > Priority: Minor > Fix For: 3.2 > > > As per [ANDIAMO-7|https://issues.jboss.org/browse/ANDIAMO-7] all messages (logged and exceptions) need a unique id. This need to be done using JBoss Logging, [ANDIAMO-2|https://issues.jboss.org/browse/ANDIAMO-2]. See [https://community.jboss.org/docs/DOC-18453] for information on configuring the loggers and message bundles. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2741) ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2741?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2741: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1455588|https://bugzilla.redhat.com/show_bug.cgi?id=1455588] from MODIFIED to ON_QA > ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers > --------------------------------------------------------------------------------------- > > Key: WFCORE-2741 > URL: https://issues.jboss.org/browse/WFCORE-2741 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Critical > Fix For: 3.0.0.Beta22 > > > In a managed domain if you configure a vault with the 'module' attribute set, when the HC launches a server that attribute value is not passed to the server in the relevant operation in the boot operation list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8032: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1195079|https://bugzilla.redhat.com/show_bug.cgi?id=1195079] from MODIFIED to ON_QA > CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL) > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8032 > URL: https://issues.jboss.org/browse/WFLY-8032 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 11.0.0.Beta1 > > > PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception. > This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool. > The scenario is as follows: > # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper. > # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction. > # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i. > # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened. > # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open. > Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2160) Incorrect JBOSS_HOME warning in vault.sh

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2160?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2160: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1410924|https://bugzilla.redhat.com/show_bug.cgi?id=1410924] from MODIFIED to ON_QA > Incorrect JBOSS_HOME warning in vault.sh > ---------------------------------------- > > Key: WFCORE-2160 > URL: https://issues.jboss.org/browse/WFCORE-2160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Alpha16 > Reporter: Dennis Reed > Assignee: Romain Pelisse > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > vault.sh has an incorrect check to make sure JBOSS_HOME is set correctly. > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME/.."; pwd` > if [ "$RESOLVED_JBOSS" != "$SANITIZED_JBOSS_HOME" ]; then > The check will always fail because of the incorrect "/..", which should be removed. > The incorrect value is only used for printing the "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." log, and appears to have been around since at least EAP 6.0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017