August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1805: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1422216|https://bugzilla.redhat.com/show_bug.cgi?id=1422216] from ASSIGNED to CLOSED > It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1805 > URL: https://issues.jboss.org/browse/WFLY-1805 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Labels: ejb > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[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: ------------------------------- Description: 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. was: 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. > 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, 8 months

1
0
0 / 0

[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: ------------------------------- Steps to Reproduce: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.CR1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} was: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} > 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, 8 months

1
0
0 / 0

[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: ------------------------------- Steps to Reproduce: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} was: * clone Weld WildFly fork ({{git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git}}) and build the project ({{mvn clean install -DskipTests}}) * clone Weld repo ({{git clone git@github.com:weld/core.git}}) and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}}: ## {{export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1}} ## {{mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml}} > 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, 8 months

1
0
0 / 0

[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, 8 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, 8 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, 8 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, 8 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, 8 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, 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