October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3323) Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3323?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-3323: --------------------------------- Affects Version/s: 3.0.3.Final > Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper > --------------------------------------------------------------------------------------- > > Key: WFCORE-3323 > URL: https://issues.jboss.org/browse/WFCORE-3323 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.3.Final > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Minor > > As part of fix JBEAP-12933 in EAP 7.1.0.CR2 there was added attribute {{mapping-mode="first"}} into "default-permission-mapper" {{simple-permission-mapper}} in default configuration. Value {{first}} is default value of {{simple-permission-mapper.mapping-mode}} which means that this attribute disappears after first change in server configuration. It can be confusing since Elytron subsystem configuration in XML is changed even if there was no request for changing that configuration. Attribute {{mapping-mode="first"}} should be removed from default configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3323) Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFCORE-3323: ------------------------------------ Summary: Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper Key: WFCORE-3323 URL: https://issues.jboss.org/browse/WFCORE-3323 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Minor As part of fix JBEAP-12933 in EAP 7.1.0.CR2 there was added attribute {{mapping-mode="first"}} into "default-permission-mapper" {{simple-permission-mapper}} in default configuration. Value {{first}} is default value of {{simple-permission-mapper.mapping-mode}} which means that this attribute disappears after first change in server configuration. It can be confusing since Elytron subsystem configuration in XML is changed even if there was no request for changing that configuration. Attribute {{mapping-mode="first"}} should be removed from default configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ] Masafumi Miura updated JBJCA-1355: ---------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/637, https://github.com/ironjacamar/ironjacamar/pull/638, https://github.com/ironjacamar/ironjacamar/pull/639 (was: https://github.com/ironjacamar/ironjacamar/pull/637, https://github.com/ironjacamar/ironjacamar/pull/638) > set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second > ---------------------------------------------------------------------------------------------------- > > Key: JBJCA-1355 > URL: https://issues.jboss.org/browse/JBJCA-1355 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Masafumi Miura > > {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. > --- > {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. > However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. > Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 2022 /** > 2023 * Check configured query timeout > 2024 * @param ws The statement > 2025 * @param explicitTimeout An explicit timeout value set > 2026 * @exception SQLException Thrown if an error occurs > 2027 */ > 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException > 2029 { > 2030 if (mc == null || dataSource == null) > 2031 return; > 2032 > 2033 int timeout = 0; > 2034 > 2035 // Use the transaction timeout > 2036 if (mc.isTransactionQueryTimeout()) > 2037 { > 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); > 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) > 2040 timeout = explicitTimeout; > 2041 } > 2042 > 2043 // Look for a configured value > 2044 if (timeout <= 0 && explicitTimeout <= 0) > 2045 timeout = mc.getQueryTimeout(); > 2046 > 2047 if (timeout > 0) > 2048 ws.setQueryTimeout(timeout); > 2049 } > {code} > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 190 /** > 191 * Get the time left before a transaction timeout > 192 * @return The amount in seconds; <code>-1</code> if no timeout > 193 * @exception SQLException Thrown if an error occurs > 194 */ > 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException > 196 { > 197 try > 198 { > 199 if (cm instanceof TransactionTimeoutConfiguration) > 200 { > 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); > 202 // No timeout > 203 if (timeout == -1) > 204 return -1; > 205 // Round up to the nearest second > 206 long result = timeout / 1000; > 207 if ((result % 1000) != 0) > 208 ++result; > 209 return (int) result; > 210 } > 211 else > 212 return -1; > 213 } > 214 catch (RollbackException e) > 215 { > 216 throw new SQLException(e); > 217 } > 218 } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ] Masafumi Miura updated JBJCA-1355: ---------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/637, https://github.com/ironjacamar/ironjacamar/pull/638 > set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second > ---------------------------------------------------------------------------------------------------- > > Key: JBJCA-1355 > URL: https://issues.jboss.org/browse/JBJCA-1355 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Masafumi Miura > > {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. > --- > {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. > However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. > Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 2022 /** > 2023 * Check configured query timeout > 2024 * @param ws The statement > 2025 * @param explicitTimeout An explicit timeout value set > 2026 * @exception SQLException Thrown if an error occurs > 2027 */ > 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException > 2029 { > 2030 if (mc == null || dataSource == null) > 2031 return; > 2032 > 2033 int timeout = 0; > 2034 > 2035 // Use the transaction timeout > 2036 if (mc.isTransactionQueryTimeout()) > 2037 { > 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); > 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) > 2040 timeout = explicitTimeout; > 2041 } > 2042 > 2043 // Look for a configured value > 2044 if (timeout <= 0 && explicitTimeout <= 0) > 2045 timeout = mc.getQueryTimeout(); > 2046 > 2047 if (timeout > 0) > 2048 ws.setQueryTimeout(timeout); > 2049 } > {code} > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 190 /** > 191 * Get the time left before a transaction timeout > 192 * @return The amount in seconds; <code>-1</code> if no timeout > 193 * @exception SQLException Thrown if an error occurs > 194 */ > 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException > 196 { > 197 try > 198 { > 199 if (cm instanceof TransactionTimeoutConfiguration) > 200 { > 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); > 202 // No timeout > 203 if (timeout == -1) > 204 return -1; > 205 // Round up to the nearest second > 206 long result = timeout / 1000; > 207 if ((result % 1000) != 0) > 208 ++result; > 209 return (int) result; > 210 } > 211 else > 212 return -1; > 213 } > 214 catch (RollbackException e) > 215 { > 216 throw new SQLException(e); > 217 } > 218 } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by Masafumi Miura (JIRA)

Masafumi Miura created JBJCA-1355: ------------------------------------- Summary: set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second Key: JBJCA-1355 URL: https://issues.jboss.org/browse/JBJCA-1355 Project: IronJacamar Issue Type: Bug Components: JDBC Reporter: Masafumi Miura {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. --- {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... {code} 2022 /** 2023 * Check configured query timeout 2024 * @param ws The statement 2025 * @param explicitTimeout An explicit timeout value set 2026 * @exception SQLException Thrown if an error occurs 2027 */ 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException 2029 { 2030 if (mc == null || dataSource == null) 2031 return; 2032 2033 int timeout = 0; 2034 2035 // Use the transaction timeout 2036 if (mc.isTransactionQueryTimeout()) 2037 { 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) 2040 timeout = explicitTimeout; 2041 } 2042 2043 // Look for a configured value 2044 if (timeout <= 0 && explicitTimeout <= 0) 2045 timeout = mc.getQueryTimeout(); 2046 2047 if (timeout > 0) 2048 ws.setQueryTimeout(timeout); 2049 } {code} - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... {code} 190 /** 191 * Get the time left before a transaction timeout 192 * @return The amount in seconds; <code>-1</code> if no timeout 193 * @exception SQLException Thrown if an error occurs 194 */ 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException 196 { 197 try 198 { 199 if (cm instanceof TransactionTimeoutConfiguration) 200 { 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); 202 // No timeout 203 if (timeout == -1) 204 return -1; 205 // Round up to the nearest second 206 long result = timeout / 1000; 207 if ((result % 1000) != 0) 208 ++result; 209 return (int) result; 210 } 211 else 212 return -1; 213 } 214 catch (RollbackException e) 215 { 216 throw new SQLException(e); 217 } 218 } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Priority: Minor (was: Critical) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9406: --------------------------------- Assignee: Alessio Soldano (was: Martin Kouba) Alessio, assigning to you as asm is only used by cxf / webservices stack. If you are ok with it, I can send PR. > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Component/s: Build System Web Services (was: CDI / Weld) (was: Class Loading) (was: REST) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Fix Version/s: 12.0.0.Alpha1 (was: 11.0.0.Final) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld, Class Loading, REST > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1375) Digest auth uses single use nonces with no Authentication-Info header

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/ELY-1375?page=com.atlassian.jira.plugin.s... ] Stuart Douglas moved JBEAP-13297 to ELY-1375: --------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1375 (was: JBEAP-13297) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) Target Release: (was: 7.backlog.GA) > Digest auth uses single use nonces with no Authentication-Info header > --------------------------------------------------------------------- > > Key: ELY-1375 > URL: https://issues.jboss.org/browse/ELY-1375 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > The results in every single request being retried -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

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