October 2017 - jboss-jira - Jboss List Archives

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.sys... ] Jan Kalina updated ELY-85: -------------------------- Description: GSS Proxy is something we should consider being able to support when running on an OS that supports it: - -https://fedorahosted.org/gss-proxy/- https://pagure.io/gssproxy The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation. was: GSS Proxy is something we should consider being able to support when running on an OS that supports it: - https://fedorahosted.org/gss-proxy/ The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation. > Support GSS-Proxy > ----------------- > > Key: ELY-85 > URL: https://issues.jboss.org/browse/ELY-85 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta10 > > > GSS Proxy is something we should consider being able to support when running on an OS that supports it: - > -https://fedorahosted.org/gss-proxy/- > https://pagure.io/gssproxy > The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1773) Some Drools tests fail with JDK 9

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1773: ------------------------------------- Summary: Some Drools tests fail with JDK 9 Key: DROOLS-1773 URL: https://issues.jboss.org/browse/DROOLS-1773 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.4.1.Final Reporter: Tibor Zimányi Assignee: Mario Fusco When Drools repository tests are executed with JDK 9, some of them fail [1]. As you can see, there are currently 2 main areas that fail. - Traits - fail on some invokevirtual codes - Persistence tests failing due to XML APIs not being part of default JDK modules anymore in JDK 9 Please see the linked spreadsheet for more information. I expect that these 2 areas hide some other problems that we will need to solve later. [1] https://docs.google.com/a/redhat.com/spreadsheets/d/1acFYb9utXhHb3KU2t3Fn... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ] Martin Choma edited comment on ELY-124 at 10/25/17 7:37 AM: ------------------------------------------------------------ How exactly is this achieved? ??After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME?? Negotiated property mean it is negotiated between client and server? Who provide value of this property? Client? Also this does not address possibility to specify "*" as principal - described in subtask http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8001104 was (Author: mchoma): How exactly is this achieved? ??After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME?? Negotiated property mean it is negotiated between client and server? Who provide value of this property? Client? > Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value > -------------------------------------------------------------------------------- > > Key: ELY-124 > URL: https://issues.jboss.org/browse/ELY-124 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: David Lloyd > Assignee: Jan Kalina > Fix For: 1.2.0.Beta10 > > > Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. > The release notes say: > {quote} > SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. > {quote} > The updated JavaDoc says: > {quote} > serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. > {quote} > The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 > The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ] Martin Choma edited comment on ELY-124 at 10/25/17 7:38 AM: ------------------------------------------------------------ How exactly is this achieved? ??After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME?? Negotiated property mean it is negotiated between client and server? Who provide value of this property? Client? Also this does not address possibility to specify "*" as principal - described in subtask http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8001104 , right? was (Author: mchoma): How exactly is this achieved? ??After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME?? Negotiated property mean it is negotiated between client and server? Who provide value of this property? Client? Also this does not address possibility to specify "*" as principal - described in subtask http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8001104 > Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value > -------------------------------------------------------------------------------- > > Key: ELY-124 > URL: https://issues.jboss.org/browse/ELY-124 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: David Lloyd > Assignee: Jan Kalina > Fix For: 1.2.0.Beta10 > > > Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. > The release notes say: > {quote} > SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. > {quote} > The updated JavaDoc says: > {quote} > serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. > {quote} > The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 > The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ] Martin Choma commented on ELY-124: ---------------------------------- How exactly is this achieved? ??After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME?? Negotiated property mean it is negotiated between client and server? Who provide value of this property? Client? > Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value > -------------------------------------------------------------------------------- > > Key: ELY-124 > URL: https://issues.jboss.org/browse/ELY-124 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: David Lloyd > Assignee: Jan Kalina > Fix For: 1.2.0.Beta10 > > > Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. > The release notes say: > {quote} > SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. > {quote} > The updated JavaDoc says: > {quote} > serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. > {quote} > The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 > The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) More FEEL runtime cycle detection tests

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugi... ] Fedor Gavrilov updated DROOLS-1770: ----------------------------------- Summary: More FEEL runtime cycle detection tests (was: more FEEL runtime cycle detection tests) > More FEEL runtime cycle detection tests > --------------------------------------- > > Key: DROOLS-1770 > URL: https://issues.jboss.org/browse/DROOLS-1770 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Priority: Minor > > Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology: > A depends on B and C > B and C depend on D -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) more FEEL runtime cycle detection tests

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugi... ] Fedor Gavrilov updated DROOLS-1770: ----------------------------------- Issue Type: Enhancement (was: Bug) > more FEEL runtime cycle detection tests > --------------------------------------- > > Key: DROOLS-1770 > URL: https://issues.jboss.org/browse/DROOLS-1770 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Priority: Minor > > Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology: > A depends on B and C > B and C depend on D -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) more FEEL runtime cycle detection tests

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugi... ] Fedor Gavrilov updated DROOLS-1770: ----------------------------------- Priority: Minor (was: Major) > more FEEL runtime cycle detection tests > --------------------------------------- > > Key: DROOLS-1770 > URL: https://issues.jboss.org/browse/DROOLS-1770 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > Priority: Minor > > Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology: > A depends on B and C > B and C depend on D -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) more FEEL runtime cycle detection tests

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugi... ] Fedor Gavrilov updated DROOLS-1770: ----------------------------------- Description: Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology: A depends on B and C B and C depend on D was: Runtime cycle detecton denies the following valid decision node topology: A depends on B and C B and C depend on D D depends on E The same topology but without E node (=deadly diamond) works well. > more FEEL runtime cycle detection tests > --------------------------------------- > > Key: DROOLS-1770 > URL: https://issues.jboss.org/browse/DROOLS-1770 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > > Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology: > A depends on B and C > B and C depend on D -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) more FEEL runtime cycle detection tests

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugi... ] Fedor Gavrilov updated DROOLS-1770: ----------------------------------- Summary: more FEEL runtime cycle detection tests (was: FEEL runtime cycle detection false positive) > more FEEL runtime cycle detection tests > --------------------------------------- > > Key: DROOLS-1770 > URL: https://issues.jboss.org/browse/DROOLS-1770 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.4.1.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > > Runtime cycle detecton denies the following valid decision node topology: > A depends on B and C > B and C depend on D > D depends on E > The same topology but without E node (=deadly diamond) works well. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

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