May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1592) CLI + Kerberos authentication fails in CD13

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1592?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1592: ------------------------------ Affects Version/s: 1.3.2.Final (was: 1.2.4.Final) > CLI + Kerberos authentication fails in CD13 > ------------------------------------------- > > Key: ELY-1592 > URL: https://issues.jboss.org/browse/ELY-1592 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.3.2.Final > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.3.3.CR1 > > Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt > > > Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error > {code} > Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))] > {code} > Attaching logs of server and client for CD12 (OK) and CD13 (NOK) > In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side. > Comparing client logs there is difference > * CD13 > {code} > 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))] > {code} > * CD12 > compared to CD12 > {code} > 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1592) CLI + Kerberos authentication fails in CD13

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1592?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1592: ------------------------------ Fix Version/s: 1.3.3.CR1 (was: 1.2.5.CR1) > CLI + Kerberos authentication fails in CD13 > ------------------------------------------- > > Key: ELY-1592 > URL: https://issues.jboss.org/browse/ELY-1592 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.3.2.Final > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.3.3.CR1 > > Attachments: jboss-cli-CD12.log, jboss-cli-CD13.log, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD12.txt, org.jboss.eapqe.krbldap.eap71.tests.krb.mgmt.KerberosCLIGssapiTestCase-output-CD13.txt > > > Use case: Administrator wants to connect to CLI using kerberos ticket. It is not possible in CD13 with error > {code} > Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))] > {code} > Attaching logs of server and client for CD12 (OK) and CD13 (NOK) > In server log there is missing message {{Server received authentication request}} so it makes me think problem is on client side. > Comparing client logs there is difference > * CD13 > {code} > 11:32:58,924 TRACE [org.jboss.remoting.remote.client] Client authentication failed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))] > {code} > * CD12 > compared to CD12 > {code} > 11:31:16,946 TRACE [org.wildfly.security.sasl.gssapi] GSSContext established, transitioning to negotiate security layer. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10450) Upgrade WILdFly Core 5.0.0.Beta5

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-10450: ---------------------------------- Summary: Upgrade WILdFly Core 5.0.0.Beta5 Key: WFLY-10450 URL: https://issues.jboss.org/browse/WFLY-10450 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 13.0.0.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10450) Upgrade WildFly Core 5.0.0.Beta5

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10450?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-10450: ------------------------------- Summary: Upgrade WildFly Core 5.0.0.Beta5 (was: Upgrade WILdFly Core 5.0.0.Beta5) > Upgrade WildFly Core 5.0.0.Beta5 > -------------------------------- > > Key: WFLY-10450 > URL: https://issues.jboss.org/browse/WFLY-10450 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 13.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3888) Undertow 2.0.8.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3888?page=com.atlassian.jira.plugi... ] Jeff Mesnil resolved WFCORE-3888. --------------------------------- Fix Version/s: 5.0.0.Beta5 Resolution: Done > Undertow 2.0.8.Final > -------------------- > > Key: WFCORE-3888 > URL: https://issues.jboss.org/browse/WFCORE-3888 > Project: WildFly Core > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 5.0.0.Beta5 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2557) Unexpected rule fire by sharing From and pojo without hashCode/equals

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2557?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi reassigned DROOLS-2557: ----------------------------------------- Assignee: Toshiya Kobayashi (was: Mario Fusco) > Unexpected rule fire by sharing From and pojo without hashCode/equals > --------------------------------------------------------------------- > > Key: DROOLS-2557 > URL: https://issues.jboss.org/browse/DROOLS-2557 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Labels: support > > Under the conditions: > - "from" clause with multiple rules > - calling update() > - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() on Child object seems to matter) > A rule is activated/fired unexpectedly. > Please see Unit test for details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2557) Unexpected rule fire by sharing From and pojo without hashCode/equals

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2557?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi reassigned DROOLS-2557: ----------------------------------------- Assignee: Mario Fusco (was: Toshiya Kobayashi) > Unexpected rule fire by sharing From and pojo without hashCode/equals > --------------------------------------------------------------------- > > Key: DROOLS-2557 > URL: https://issues.jboss.org/browse/DROOLS-2557 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > > Under the conditions: > - "from" clause with multiple rules > - calling update() > - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() on Child object seems to matter) > A rule is activated/fired unexpectedly. > Please see Unit test for details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2557) Unexpected rule fire by sharing From and pojo without hashCode/equals

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2557?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-2557: -------------------------------------- Description: Under the conditions: - "from" clause with multiple rules - calling update() - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() in Child object seems to matter) A rule is activated/fired unexpectedly. Please see Unit test for details. was: Under the conditions: - "from" clause with multiple rules - calling update() - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() on Child object seems to matter) A rule is activated/fired unexpectedly. Please see Unit test for details. > Unexpected rule fire by sharing From and pojo without hashCode/equals > --------------------------------------------------------------------- > > Key: DROOLS-2557 > URL: https://issues.jboss.org/browse/DROOLS-2557 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > > Under the conditions: > - "from" clause with multiple rules > - calling update() > - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() in Child object seems to matter) > A rule is activated/fired unexpectedly. > Please see Unit test for details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2557) Unexpected rule fire by sharing From and pojo without hashCode/equals

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2557?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-2557: -------------------------------------- Description: Under the conditions: - "from" clause with multiple rules - calling update() - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() on Child object seems to matter) A rule is activated/fired unexpectedly. Please see Unit test for details. was: Under the conditions: - "from" clause with multiple rules - calling update() - Pojo doesn't implement hashCode/equals (to be precise, only equals() seems to matter) A rule is activated/fired unexpectedly. Please see Unit test for details. > Unexpected rule fire by sharing From and pojo without hashCode/equals > --------------------------------------------------------------------- > > Key: DROOLS-2557 > URL: https://issues.jboss.org/browse/DROOLS-2557 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.7.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Labels: support > > Under the conditions: > - "from" clause with multiple rules > - calling update() > - Pojo doesn't implement hashCode/equals (to be precise, only hashCode() on Child object seems to matter) > A rule is activated/fired unexpectedly. > Please see Unit test for details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10448) Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-10448?page=com.atlassian.jira.plugin... ] R Searls commented on WFLY-10448: --------------------------------- Agreed on the crufty stuff and the pointless stuff. I would like to clear that up for the code going forward. I would like to know if '-server' and '-client' options are still supported in JDK-10's HotSpot. The documentation appears to indicate that of jdk-8 '-client' was being ignored. I have not found any JDK-10 reference to these options. Who might know? > Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh > ------------------------------------------------------------------------------------------------ > > Key: WFLY-10448 > URL: https://issues.jboss.org/browse/WFLY-10448 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 13.0.0.CR1 > Reporter: R Searls > Assignee: R Searls > Priority: Minor > > bin\scripts domain.sh, standalone.sh and appclient.sh have a section of code that uses java option -d32 and -d64 when calling java to check the HotSpot type. These 2 options have been removed from JDK-10. They are marked as deprecated in JDK-9 but still function. > These options are used in determining if '-server' is added to JAVA_OPTS. Enhancements need to be made to the scripts to check the JDK version and take appropriate action is assigning the value '-server'. > The code affected > {code:java} > # Check for -d32/-d64 in JAVA_OPTS > JVM_OPTVERSION="-version" > JVM_D64_OPTION=`echo $JAVA_OPTS | $GREP "\-d64"` > JVM_D32_OPTION=`echo $JAVA_OPTS | $GREP "\-d32"` > test "x$JVM_D64_OPTION" != "x" && JVM_OPTVERSION="-d64 $JVM_OPTVERSION" > test "x$JVM_D32_OPTION" != "x" && JVM_OPTVERSION="-d32 $JVM_OPTVERSION" > # If -server not set in JAVA_OPTS, set it, if supported > SERVER_SET=`echo $JAVA_OPTS | $GREP "\-server"` > if [ "x$SERVER_SET" = "x" ]; then > # Check for SUN(tm) JVM w/ HotSpot support > if [ "x$HAS_HOTSPOT" = "x" ]; then > HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot` > fi > # Check for OpenJDK JVM w/server support > if [ "x$HAS_OPENJDK" = "x" ]; then > HAS_OPENJDK=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i OpenJDK` > fi > # Check for IBM JVM w/server support > if [ "x$HAS_IBM" = "x" ]; then > HAS_IBM=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i "IBM J9"` > fi > # Enable -server if we have Hotspot or OpenJDK, unless we can't > if [ "x$HAS_HOTSPOT" != "x" -o "x$HAS_OPENJDK" != "x" -o "x$HAS_IBM" != "x" ]; then > # MacOS does not support -server flag > if [ "$darwin" != "true" ]; then > PROCESS_CONTROLLER_JAVA_OPTS="-server $PROCESS_CONTROLLER_JAVA_OPTS" > HOST_CONTROLLER_JAVA_OPTS="-server $HOST_CONTROLLER_JAVA_OPTS" > JVM_OPTVERSION="-server $JVM_OPTVERSION" > fi > fi > else > JVM_OPTVERSION="-server $JVM_OPTVERSION" > fi > {code} > Here is the output of the currently supported java versions > Doc for jdk-8 states > > java -help > where options include: > -d32 use a 32-bit data model if available > -d64 use a 64-bit data model if available > Using these options tell if the version supports 32-bit or 64-bit > > java -d32 -version > Error: This Java instance does not support a 32-bit JVM. > Please install the desired version. > > java -d64 -version > java version "1.8.0_72" > Java(TM) SE Runtime Environment (build 1.8.0_72-b15) > Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode) > Doc for jdk-9 states > > java -help > where options include: > -d32 Deprecated, will be removed in a future release > -d64 Deprecated, will be removed in a future release > > java -d32 -version > Error: This Java instance does not support a 32-bit JVM. > Please install the desired version. > > java -d64 -version > openjdk version "9.0.4" > OpenJDK Runtime Environment (build 9.0.4+11) > OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode) > Doc for jdk-10 > > java -help > No documentation for these options listed > > java -d32 -version > Unrecognized option: -d32 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > java -d64 -version > Unrecognized option: -d64 > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 May 2018