December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9636) EJB lookup over HTTP times out connection after 60 seconds

by peter craddock (JIRA)

peter craddock created WFLY-9636: ------------------------------------ Summary: EJB lookup over HTTP times out connection after 60 seconds Key: WFLY-9636 URL: https://issues.jboss.org/browse/WFLY-9636 Project: WildFly Issue Type: Bug Components: EJB, IO, Naming Affects Versions: 11.0.0.Final Environment: I work with https://developer.jboss.org/people/jaikiran on https://developer.jboss.org/thread/276635 so my Wildfly 11 environment has this fix in it. Reporter: peter craddock The code examples and trace logging can be found here https://developer.jboss.org/thread/276840 I have work round the problem but was asked to raise it for further investigation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2198) [GSS](6.4.z) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache

by Martin Weiler (JIRA)

Martin Weiler created DROOLS-2198: ------------------------------------- Summary: [GSS](6.4.z) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache Key: DROOLS-2198 URL: https://issues.jboss.org/browse/DROOLS-2198 Project: Drools Issue Type: Bug Components: core engine Reporter: Martin Weiler Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2197) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2197?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2197. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/31be4b3979d7ea9aebfdbe6917f5e6b... > When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache > ---------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2197 > URL: https://issues.jboss.org/browse/DROOLS-2197 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2197) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2197?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-2197: ------------------------------------- When a declared type is modified during an incremental compilation the compiled class of the old version isn't evicted from the TypeResolver cache and then the knowledge builder keep seeing that older version. > When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache > ---------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2197 > URL: https://issues.jboss.org/browse/DROOLS-2197 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2197) When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2197: ----------------------------------- Summary: When a declared type is modified during an incremental compilation the old version isn't evicted from the TypeResolver cache Key: DROOLS-2197 URL: https://issues.jboss.org/browse/DROOLS-2197 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-283: -------------------------------- Ok, I have no idea what was the problem with minor, but it looks it is irrelevant after resolving ELY-1472 (which was actually also variable initialization bug in JDK). The gssproxy is now successfully working, after applying OpenJDK patch [^jkalina-openjdk-native-gss.patch] :) > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-283: --------------------------- Attachment: jkalina-openjdk-native-gss.patch > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1472) [native kerberos] setting channelBinding of gssContext when not used

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1472: --------------------------------- Following path of OpenJDK fixes the issue: {code} src/java.security.jgss/share/native/libj2gss/GSSLibStub.c: // initialize addrtype in CB first cb->initiator_addrtype = GSS_C_AF_NULLADDR; cb->acceptor_addrtype = GSS_C_AF_NULLADDR; + // addresses needs to be initialized to empty + cb->initiator_address.length = 0; + cb->initiator_address.value = NULL; + cb->acceptor_address.length = 0; + cb->acceptor_address.value = NULL; {code} > [native kerberos] setting channelBinding of gssContext when not used > -------------------------------------------------------------------- > > Key: ELY-1472 > URL: https://issues.jboss.org/browse/ELY-1472 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.2.0.Beta11 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: kerberos > > Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used. > This lead to following error when using native Kerberos library: > {code} > [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0 > [GSSLibStub_acceptContext] before3: inToken.length=515 > [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0 > [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12 > [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12 > c/r/s = 0/4/0 > {code} > Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied. > This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3480) ls output is unfriendly if any element in return contents is longer than terminal width

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3480?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3480: ---------------------------------------------- Good catch! The fix for AESH-435 was not applied to aesh-readline, I fixed it and opened a PR. We will need to upgrade to aesh-readline 1.3 > ls output is unfriendly if any element in return contents is longer than terminal width > --------------------------------------------------------------------------------------- > > Key: WFCORE-3480 > URL: https://issues.jboss.org/browse/WFCORE-3480 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha5 > Reporter: Marek Kopecký > Assignee: Jean-Francois Denise > Priority: Blocker > > When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values. > Expected: no empty lines between printed attributes so the output does not take like 4 screen size. > *Steps to reproduce:* > # prepare WF based on wf-core > # start WF > # ls /subsystem=elytron/provider-loader=elytron > # see very long output with many empty lines between particular attribute records printed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3480) ls output is unfriendly if any element in return contents is longer than terminal width

by Marek Kopecký (JIRA)

Marek Kopecký created WFCORE-3480: ------------------------------------- Summary: ls output is unfriendly if any element in return contents is longer than terminal width Key: WFCORE-3480 URL: https://issues.jboss.org/browse/WFCORE-3480 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 4.0.0.Alpha5 Reporter: Marek Kopecký Assignee: Jean-Francois Denise Priority: Blocker When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values. Expected: no empty lines between printed attributes so the output does not take like 4 screen size. *Steps to reproduce:* # prepare WF based on wf-core # start WF # ls /subsystem=elytron/provider-loader=elytron # see very long output with many empty lines between particular attribute records printed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

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