October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7282) Deadlock in BasicAction when jboss remoting and JTA is used

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-7282: ----------------------------- Fix Version/s: (was: 10.2.0.Final) > Deadlock in BasicAction when jboss remoting and JTA is used > ----------------------------------------------------------- > > Key: WFLY-7282 > URL: https://issues.jboss.org/browse/WFLY-7282 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Fix For: 11.0.0.Alpha1 > > > At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock. > Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20... > Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem. > If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back. > IIOP/JTS does not suffer with this flaw. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7305) Getting identity by DN in Elytron ldap-realm should be case insensitive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.... ] Ondrej Lukas edited comment on WFLY-7305 at 10/17/16 9:13 AM: -------------------------------------------------------------- About second point. It has been already reported in WFLY-7302. was (Author: olukas): About second point. This has been already reported in WFLY-7302. > Getting identity by DN in Elytron ldap-realm should be case insensitive > ----------------------------------------------------------------------- > > Key: WFLY-7305 > URL: https://issues.jboss.org/browse/WFLY-7305 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. > LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7305) Getting identity by DN in Elytron ldap-realm should be case insensitive

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.... ] Ondrej Lukas commented on WFLY-7305: ------------------------------------ About second point. This has been already reported in WFLY-7302. > Getting identity by DN in Elytron ldap-realm should be case insensitive > ----------------------------------------------------------------------- > > Key: WFLY-7305 > URL: https://issues.jboss.org/browse/WFLY-7305 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. > LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ] Ondrej Lukas commented on WFLY-7322: ------------------------------------ In case when Elytron is able to work with referral based on added filter-name then no additional logic for *follow* will be needed in the code. However some logic which handles *throw* should be added as well. I am not sure, but from quick code review I think it results to throwing Exception to Undertow, which will result to Internal Server Error. > LDAP referrals does not work in Elytron ldap-realm > -------------------------------------------------- > > Key: WFLY-7322 > URL: https://issues.jboss.org/browse/WFLY-7322 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > > LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all: > * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object) > * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals > Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7313) Impossible to use environment variables or system properties in permissions.xml

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-7313: ------------------------------ Component/s: Security Manager (was: EE) > Impossible to use environment variables or system properties in permissions.xml > ------------------------------------------------------------------------------- > > Key: WFLY-7313 > URL: https://issues.jboss.org/browse/WFLY-7313 > Project: WildFly > Issue Type: Feature Request > Components: Security Manager > Affects Versions: 10.1.0.Final > Reporter: Adrian Boangiu > Assignee: Jason Greene > > Without this feature it is impossible to migrate "variable" Java file permissions such as: > {noformat} > permission java.io.FilePermission "${java.io.tmpdir}","read"; > permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete"; > permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete"; > {noformat} > that were defined in Java policy file in previous verions of JBoss. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1326) Stateful working memory regression OCT-2016: nurserostering long_hint01.xml

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1326: ------------------------------------------ Great :) Talk about tracking down the needle in the haystack! > Stateful working memory regression OCT-2016: nurserostering long_hint01.xml > --------------------------------------------------------------------------- > > Key: DROOLS-1326 > URL: https://issues.jboss.org/browse/DROOLS-1326 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Blocker > > Something regressed in Drools master between 27-SEP and 11-OCT. > See: > https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtl... > I 'll ask [~jlocker] to isolate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7313) Impossible to use environment variables or system properties in permissions.xml

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-7313: ------------------------------ Description: Without this feature it is impossible to migrate "variable" Java file permissions such as: {noformat} permission java.io.FilePermission "${java.io.tmpdir}","read"; permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete"; permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete"; {noformat} that were defined in Java policy file in previous verions of JBoss. was: Without this feature it is impossible to migrate "variable" Java file permissions such as: permission java.io.FilePermission "${java.io.tmpdir}","read"; permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete"; permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete"; that were defined in Java policy file in previous verions of JBoss. > Impossible to use environment variables or system properties in permissions.xml > ------------------------------------------------------------------------------- > > Key: WFLY-7313 > URL: https://issues.jboss.org/browse/WFLY-7313 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 10.1.0.Final > Reporter: Adrian Boangiu > Assignee: Jason Greene > > Without this feature it is impossible to migrate "variable" Java file permissions such as: > {noformat} > permission java.io.FilePermission "${java.io.tmpdir}","read"; > permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete"; > permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete"; > {noformat} > that were defined in Java policy file in previous verions of JBoss. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1326) Stateful working memory regression OCT-2016: nurserostering long_hint01.xml

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugi... ] Jiri Locker commented on DROOLS-1326: ------------------------------------- [~ge0ffrey] reproduced, thanks for the hints! > Stateful working memory regression OCT-2016: nurserostering long_hint01.xml > --------------------------------------------------------------------------- > > Key: DROOLS-1326 > URL: https://issues.jboss.org/browse/DROOLS-1326 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Blocker > > Something regressed in Drools master between 27-SEP and 11-OCT. > See: > https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtl... > I 'll ask [~jlocker] to isolate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBEE-168) Release new version of jboss-annotations-api_1.2_spec

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on JBEE-168: ---------------------------------- I don't know if we can update this to a newer spec version and still be compliant with Java EE 7. > Release new version of jboss-annotations-api_1.2_spec > ----------------------------------------------------- > > Key: JBEE-168 > URL: https://issues.jboss.org/browse/JBEE-168 > Project: JBoss JavaEE Spec APIs > Issue Type: Task > Components: jboss-annotations-api > Reporter: Tomas Remes > Assignee: Scott Marlow > > There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently > change log > {noformat} > Added @Target(PARAMETER) to the Priority annotation. > Made Resource and DataSourceDefinition annotations repeatable. > Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications. > Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7305) Getting identity by DN in Elytron ldap-realm should be case insensitive

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7305: ---------------------------------- 1) When I am now looking on it, maybe we could also skip nameFilter when user entry is defined by DN... 2) I now see bigger problem: the check compare test only if the RDN is at begin of DN - but without "=" - for example username "uidahaar" will be interpreted as DN, because it starts by "uid". > Getting identity by DN in Elytron ldap-realm should be case insensitive > ----------------------------------------------------------------------- > > Key: WFLY-7305 > URL: https://issues.jboss.org/browse/WFLY-7305 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. > LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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