October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-348) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-348?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse deleted ELY-348: --------------------------------- > Ensure consistent Builder initialisation > ---------------------------------------- > > Key: ELY-348 > URL: https://issues.jboss.org/browse/ELY-348 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > > Where we have builders ensure they can be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-349) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-349: ------------------------------------ Summary: Ensure consistent Builder initialisation Key: ELY-349 URL: https://issues.jboss.org/browse/ELY-349 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha2 All builders should be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-348) Ensure consistent Builder initialisation

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-348: ------------------------------------ Summary: Ensure consistent Builder initialisation Key: ELY-348 URL: https://issues.jboss.org/browse/ELY-348 Project: WildFly Elytron Issue Type: Release Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Alpha2 Where we have builders ensure they can be instantiated using a static builder() method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-927) Option roleRecursion does not work in LdapRolesMappingProvider

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/SECURITY-927?page=com.atlassian.jira.plug... ] Ryan Emerson reassigned SECURITY-927: ------------------------------------- Assignee: Ryan Emerson (was: Peter Skopek) > Option roleRecursion does not work in LdapRolesMappingProvider > -------------------------------------------------------------- > > Key: SECURITY-927 > URL: https://issues.jboss.org/browse/SECURITY-927 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_5_0_0.Alpha2 > Reporter: Ondrej Lukas > Assignee: Ryan Emerson > > Option roleRecursion does not work in org.jboss.security.mapping.providers.role.LdapRolesMappingProvider. Only entries without recursion are found. No recursive search is done by LdapRolesMappingProvider since LdapRolesMappingProvider.rolesSearch method tries to make a recursive search with same parameters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-927) Option roleRecursion does not work in LdapRolesMappingProvider

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/SECURITY-927?page=com.atlassian.jira.plug... ] Ryan Emerson moved WFLY-5491 to SECURITY-927: --------------------------------------------- Project: PicketBox (was: WildFly) Key: SECURITY-927 (was: WFLY-5491) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: JBossSX (was: Security) Affects Version/s: PicketBox_5_0_0.Alpha2 (was: 10.0.0.CR2) > Option roleRecursion does not work in LdapRolesMappingProvider > -------------------------------------------------------------- > > Key: SECURITY-927 > URL: https://issues.jboss.org/browse/SECURITY-927 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_5_0_0.Alpha2 > Reporter: Ondrej Lukas > Assignee: Peter Skopek > > Option roleRecursion does not work in org.jboss.security.mapping.providers.role.LdapRolesMappingProvider. Only entries without recursion are found. No recursive search is done by LdapRolesMappingProvider since LdapRolesMappingProvider.rolesSearch method tries to make a recursive search with same parameters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5556) Configure remote tx timeout via system property

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5556?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5556: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1265300|https://bugzilla.redhat.com/show_bug.cgi?id=1265300] from POST to MODIFIED > Configure remote tx timeout via system property > ----------------------------------------------- > > Key: WFLY-5556 > URL: https://issues.jboss.org/browse/WFLY-5556 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Fix For: 10.0.0.CR4 > > > Description of problem: > The hardcoded 5 minute timeout period was replace with Integer.MAX_VALUE for the timeout period of "remote" distributed transaction branches. > - https://issues.jboss.org/browse/WFLY-2789 > - https://bugzilla.redhat.com/show_bug.cgi?id=1056585#c1 > An "infinite" timeout is a problem as this value is also passed to the database to control statement execution. This means that database statements may run uncontrolled in most cases. Too, in one case we have seen that the database driver or the database is mishandling the value and aborting almost immediately (e.g. after only 2 or 3 seconds). > Version-Release number of selected component (if applicable): > How reproducible: > Consistently > Steps to Reproduce: > 1. Start a transaction in server "one" > 2. Using JTA/EJB remoting, propagate that transaction to a remote server > 3. The timeout for the transaction on the remote can be seen to be Integer.MAX_VALUE > Actual results: > Either an "infinite" timeout period for database statement execution or else an immediate abort > Expected results: > A "reasonable" smaller value must be used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5348) Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5348?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5348: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1265300|https://bugzilla.redhat.com/show_bug.cgi?id=1265300] from POST to MODIFIED > Propagate transaction timeout value for distributed transaction when using JTA and EJB remoting > ----------------------------------------------------------------------------------------------- > > Key: WFLY-5348 > URL: https://issues.jboss.org/browse/WFLY-5348 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Beta2 > Reporter: Stephen Fikes > Assignee: Panagiotis Sotiropoulos > Labels: ejb3, jta, transactions > Fix For: 10.0.0.CR4 > > > When a transaction begins in "server 1" and an EJB remoting request is made to "server 2" the timeout value for the transaction branch in "server 2" is initially set to {{Integer.MAX_VALUE}} which means {{set-tx-query-timeout}} does not work properly on datasources enlisted in the distributed branch of the transaction in server 2. This essentially requests that statement execution not be timed out at all (though in some cases the large value seems to result in abnormally fast timeout after a couple of seconds). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5449: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from POST to MODIFIED > Custom socket factory for JGroups subsystem not set correctly > ------------------------------------------------------------- > > Key: WFLY-5449 > URL: https://issues.jboss.org/browse/WFLY-5449 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Dennis Reed > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.0.0.CR4 > > > Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. > This is not the correct API to use, and it gets overwritten when the JGroups channel starts. > A custom socket factory should be set on the JChannel. > The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1064) Creating named multicast socket doesn't properly register socket using name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1064?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1064: ------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from POST to MODIFIED > Creating named multicast socket doesn't properly register socket using name > --------------------------------------------------------------------------- > > Key: WFCORE-1064 > URL: https://issues.jboss.org/browse/WFCORE-1064 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > Fix For: 2.0.0.CR8 > > > I'm not sure why this is, but the socket binding manager ignores the name of the multicast socket and registers the socket using the unnamed registry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1063) Creating named datagram socket throws ISE

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1063?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1063: ------------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from POST to MODIFIED > Creating named datagram socket throws ISE > ----------------------------------------- > > Key: WFCORE-1063 > URL: https://issues.jboss.org/browse/WFCORE-1063 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > Fix For: 2.0.0.CR8 > > > The DatagramSocket createDatagramSocket(String name, SocketAddress address) method of org.jboss.as.network.SocketBindingManagerImpl creates a ManagedDatagramSocketBinding with a null name, yet registers the socket using the NamedManagedBindingRegistry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 October 2015