February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-6096: ------------------------------------ Assignee: Paul Ferraro (was: Thomas Diesler) > ISPN-5876 changes need to be configurable > ----------------------------------------- > > Key: WFLY-6096 > URL: https://issues.jboss.org/browse/WFLY-6096 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Stephen Fikes > Assignee: Paul Ferraro > > When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default. > For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed. > As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out. > Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Tobias Lehr (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Tobias Lehr commented on WFLY-6097: ----------------------------------- out integrationtests confirm this bug. > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Richard Janík edited comment on WFLY-5932 at 2/1/16 2:40 AM: ------------------------------------------------------------- Hi Stuart, first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately. Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again. (I'm detailing the process in case you have something to say about it) What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems? tl;dr I don't think commit 394c7b8 fixes the issue - I'm still seeing it. edit: After discussion with Stuart, I've realized that the process above is unnecessarily complicated. Still, sso-fix branch doesn't seem to fix the issue. was (Author: rjanik): Hi Stuart, first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately. Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again. (I'm detailing the process in case you have something to say about it) What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems? tl;dr I don't think commit 394c7b8 fixes the issue - I'm still seeing it. > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-5484: ------------------------------------- After discussion with Stuart, we found that the problem was in my testing process. Undertow 1.3.16.Final really does fix this. > Calling HttpServletRequest.logout() with single sign-on enabled only works every second time > -------------------------------------------------------------------------------------------- > > Key: WFLY-5484 > URL: https://issues.jboss.org/browse/WFLY-5484 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Richard Janík > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: reproducer-jbeap-1282.zip > > > See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect > This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6102) Removing of non-existent mapping-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6102?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6102: ------------------------------- Component/s: Domain Management Security (was: CLI) > Removing of non-existent mapping-module finishes with outcome success > --------------------------------------------------------------------- > > Key: WFLY-6102 > URL: https://issues.jboss.org/browse/WFLY-6102 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Alexey Loubyansky > Priority: Minor > > In case when non-existent mapping-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6102) Removing of non-existent mapping-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6102?page=com.atlassian.jira.plugin.... ] Ondrej Lukas reassigned WFLY-6102: ---------------------------------- Assignee: Brian Stansberry (was: Alexey Loubyansky) > Removing of non-existent mapping-module finishes with outcome success > --------------------------------------------------------------------- > > Key: WFLY-6102 > URL: https://issues.jboss.org/browse/WFLY-6102 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when non-existent mapping-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ] Ondrej Lukas reassigned WFLY-6083: ---------------------------------- Assignee: Brian Stansberry (was: Dmitrii Tikhomirov) > Removing of non-existent login-module finishes with outcome success > ------------------------------------------------------------------- > > Key: WFLY-6083 > URL: https://issues.jboss.org/browse/WFLY-6083 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6101) Removing of non-existent policy-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6101?page=com.atlassian.jira.plugin.... ] Ondrej Lukas reassigned WFLY-6101: ---------------------------------- Assignee: Brian Stansberry (was: Alexey Loubyansky) > Removing of non-existent policy-module finishes with outcome success > -------------------------------------------------------------------- > > Key: WFLY-6101 > URL: https://issues.jboss.org/browse/WFLY-6101 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6101) Removing of non-existent policy-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6101?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6101: ------------------------------- Component/s: Domain Management Security (was: CLI) > Removing of non-existent policy-module finishes with outcome success > -------------------------------------------------------------------- > > Key: WFLY-6101 > URL: https://issues.jboss.org/browse/WFLY-6101 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Alexey Loubyansky > Priority: Minor > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-6083: ------------------------------- Component/s: Domain Management Security (was: CLI) > Removing of non-existent login-module finishes with outcome success > ------------------------------------------------------------------- > > Key: WFLY-6083 > URL: https://issues.jboss.org/browse/WFLY-6083 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.Final > Reporter: Ondrej Lukas > Assignee: Dmitrii Tikhomirov > Priority: Minor > > In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 February 2016