August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9252) Redundant config restore before quorum configuration

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9252?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-12830 to WFLY-9252: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9252 (was: JBEAP-12830) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Quickstarts (was: Quickstarts) Affects Version/s: 11.0.0.Beta1 (was: 7.1.0.ER3) > Redundant config restore before quorum configuration > ---------------------------------------------------- > > Key: WFLY-9252 > URL: https://issues.jboss.org/browse/WFLY-9252 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 11.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Labels: eap7.1-ok-for-CR1 > > In ER3 there is a new instruction in {{Configure a Quorum for the Singleton Policy}} to restore the singleton election policy to default configuration: > {{If you have tested other election policies that configured the singleton subsystem, see Restoring the Default Singleton Subsystem Configuration for instructions to restore the singleton election policy to the default configuration.}} > I think this step should be either removed or reworded to avoid confusion. The reasons are: > * Quorum can be specified for any election policy, not only for the default one. > * Wording {{If you have tested other election policies}} suggests that this section configures another election policy, which is not true - it only adds quorum to existing election policy. > [~rhusar], what do you think? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1343) Release WildFly Elytron 1.2.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1343: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta1 Key: ELY-1343 URL: https://issues.jboss.org/browse/ELY-1343 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3204) Upgrade WildFly Elytron to 1.2.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3204: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.2.0.Beta1 Key: WFCORE-3204 URL: https://issues.jboss.org/browse/WFCORE-3204 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 4.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-175) Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67

by Matt Mahoney (JIRA)

Matt Mahoney created HAWKULARQE-175: --------------------------------------- Summary: Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67 Key: HAWKULARQE-175 URL: https://issues.jboss.org/browse/HAWKULARQE-175 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: Michael Foley Error/exceptions naming unification on hawkular ruby gem and upgrade to miq side following this. This allows the client code to rescue only one exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-174) Adding link to a VM - MIQ Sprint-67

by Matt Mahoney (JIRA)

Matt Mahoney created HAWKULARQE-174: --------------------------------------- Summary: Adding link to a VM - MIQ Sprint-67 Key: HAWKULARQE-174 URL: https://issues.jboss.org/browse/HAWKULARQE-174 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: Michael Foley Enhancement - adding link to a VM also for middleware servers running in domain mode -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ] Matt Mahoney reassigned HAWKULARQE-173: --------------------------------------- Assignee: Sunil kondkar (was: Michael Foley) > UX Improvement - When adding a datasource - MIQ Sprint-67 > --------------------------------------------------------- > > Key: HAWKULARQE-173 > URL: https://issues.jboss.org/browse/HAWKULARQE-173 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > From MIQ Sprint-67 Demo: > UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Matt Mahoney (JIRA)

Matt Mahoney created HAWKULARQE-173: --------------------------------------- Summary: UX Improvement - When adding a datasource - MIQ Sprint-67 Key: HAWKULARQE-173 URL: https://issues.jboss.org/browse/HAWKULARQE-173 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: Michael Foley >From MIQ Sprint-67 Demo: UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1711) Jitting process may randomly fail during multithreaded execution

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1711: ----------------------------------- Summary: Jitting process may randomly fail during multithreaded execution Key: DROOLS-1711 URL: https://issues.jboss.org/browse/DROOLS-1711 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco The jitting process assumes that the mvel constraint has been evaluated at least once before it kicks in. This may not be the case during a multithreaded execution (especially when running with many threads and a very low jitting threshold) because the jitting process may start when other threads have already requested the constraint evaluation using the mvel interpreted constraint (thus incrementing the jitting counter) but none of them had enough time to complete it. When this happens the jitting process trying to work on an uncompleted AST throwing internally an exception like the following: {code} Exception in thread "drools-worker-1" java.lang.RuntimeException: java.lang.RuntimeException: Null accessor on node: firings at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:346) at org.drools.core.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:82) at org.drools.core.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:313) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: Null accessor on node: firings at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:302) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:159) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:138) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:109) at org.drools.core.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:129) at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:333) ... 5 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1710) Jitting process may randomly fail during multithreaded execution

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1710: ----------------------------------- Summary: Jitting process may randomly fail during multithreaded execution Key: DROOLS-1710 URL: https://issues.jboss.org/browse/DROOLS-1710 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco The jitting process assumes that the mvel constraint has been evaluated at least once before it kicks in. This may not be the case during a multithreaded execution (especially when running with many threads and a very low jitting threshold) because the jitting process may start when other threads have already requested the constraint evaluation using the mvel interpreted constraint (thus incrementing the jitting counter) but none of them had enough time to complete it. When this happens the jitting process trying to work on an uncompleted AST throwing internally an exception like the following: {code} Exception in thread "drools-worker-1" java.lang.RuntimeException: java.lang.RuntimeException: Null accessor on node: firings at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:346) at org.drools.core.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:82) at org.drools.core.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:313) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: Null accessor on node: firings at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:302) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:159) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:138) at org.drools.core.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:109) at org.drools.core.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:129) at org.drools.core.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:333) ... 5 more {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1340) IBM java, 401 is returned instead of 403, when client send invalid ticket

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1340?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1340. --------------------------- Resolution: Rejected As noted in PR discussion, 401 code is appropriate and necessary here. The tests needs to be fixed. > IBM java, 401 is returned instead of 403, when client send invalid ticket > ------------------------------------------------------------------------- > > Key: ELY-1340 > URL: https://issues.jboss.org/browse/ELY-1340 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > In JBEAP-9945 new behaviour was introduced to return 403 when only SPNEGO http mechanismus is configured and client provides invalid ticket. However with IBM java 401 is returned instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017