August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9240) WeldSecurityServices not able to obtain the current SecurityDomain anymore

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9240?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-9240: ------------------------------- Affects Version/s: 11.0.0.CR1 > WeldSecurityServices not able to obtain the current SecurityDomain anymore > -------------------------------------------------------------------------- > > Key: WFLY-9240 > URL: https://issues.jboss.org/browse/WFLY-9240 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 11.0.0.Beta1, 11.0.0.CR1 > Reporter: Martin Kouba > Assignee: Darran Lofthouse > Priority: Critical > > The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. > The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. > Note that this worked on WildFly 11.0.0.Alpha1. > It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9278) EJB Acces Timeout is ignored on SFSBs when using distributed caches

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-9278: ------------------------------ Component/s: Clustering > EJB Acces Timeout is ignored on SFSBs when using distributed caches > ------------------------------------------------------------------- > > Key: WFLY-9278 > URL: https://issues.jboss.org/browse/WFLY-9278 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 11.0.0.CR1 > Reporter: Bernhard Hablesreiter > Attachments: wildfly-request-test.zip > > > When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds". > The configuration: > {code:xml} > <session-bean> > <stateless> > <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> > </stateless> > <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> > <singleton default-access-timeout="2000"/> > </session-bean> > <pools> > <bean-instance-pools> > <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > </bean-instance-pools> > </pools> > <caches> > <cache name="simple"/> > <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/> > </caches> > ... > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > ... > <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan"> > <local-cache name="passivation"> > <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/> > <transaction mode="BATCH" /> > <file-store passivation="true" purge="true"/> > </local-cache> > </cache-container> > ... > </subsystem> > {code} > With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache. > I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds. > If the cache-ref is set to "simple" the configured access timeout works as exptected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9280) WorkerFailoverTestCase not working in multi PC environment

by Matus Madzin (JIRA)

Matus Madzin created WFLY-9280: ---------------------------------- Summary: WorkerFailoverTestCase not working in multi PC environment Key: WFLY-9280 URL: https://issues.jboss.org/browse/WFLY-9280 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 11.0.0.CR1 Reporter: Matus Madzin Assignee: Matus Madzin Priority: Critical Test case fails when balancer is running on different IP address than workers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9279) WorkerFailoverTestCase not working in multi PC environment

by Matus Madzin (JIRA)

Matus Madzin created WFLY-9279: ---------------------------------- Summary: WorkerFailoverTestCase not working in multi PC environment Key: WFLY-9279 URL: https://issues.jboss.org/browse/WFLY-9279 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 11.0.0.CR1 Reporter: Matus Madzin Assignee: Matus Madzin Priority: Critical Test case fails when balancer is running on different IP address than workers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3212) Make 'required' attributes clearer when using tab completion within CLI

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-3212: ---------------------------------- Summary: Make 'required' attributes clearer when using tab completion within CLI Key: WFCORE-3212 URL: https://issues.jboss.org/browse/WFCORE-3212 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Darran Lofthouse Assignee: Jean-Francois Denise The following is some example output pressing tab to reveal the parameters of 'add': - {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( ! alias-filter credential-reference path provider-name providers relative-to required type }} >From this is it not clear which are actually required. Suggestions to make it clearer: - * Show required / optional in different colours. * Add something to the required attributes e.g. '*' * Add something to the optional requirements e.g. {optional_arg} Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3213) CLI, Help match open/close characters

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-3213: ---------------------------------- Summary: CLI, Help match open/close characters Key: WFCORE-3213 URL: https://issues.jboss.org/browse/WFCORE-3213 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise In a context where we have a nesting of complex objects as operation parameters, it is difficult to match the '{' and '[' with their closing counterparts. We could imagine something similar to IDE editor where such characters are automatically matched and colorised. When moving the cursor onto a closing character, the opening character should be highlighted. If no match is found, then the current closing character should be also highlighted (e.g.: in red to make it clear that it is an error). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3211) Auto more/less in CLI for multi-page output

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-3211: ---------------------------------- Summary: Auto more/less in CLI for multi-page output Key: WFCORE-3211 URL: https://issues.jboss.org/browse/WFCORE-3211 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Darran Lofthouse Assignee: Jean-Francois Denise Where the result of a management operation in the CLI returns multiple screens of output it would be nice if this could be automatically wrapped in a more/less type behaviour. Similar to how git handles git log compared to how svn handles svn log. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Tibor Zimányi reassigned DROOLS-1692: ------------------------------------- Assignee: Dominik Hanak (was: Tibor Zimányi) > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Dominik Hanak > Fix For: 7.3.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1717: ---------------------------------- Description: Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e was: Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1717: ------------------------------------- Summary: Concurrency problems with enum constraints in MVEL Key: DROOLS-1717 URL: https://issues.jboss.org/browse/DROOLS-1717 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.2.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco Having a test case like this [1], it sometimes fails on java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] [Near : {... enumValue == AnEnum.SECOND ....}] ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

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 August 2017