September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2284) Discovery protocol for members in the same process

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2284?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2284: --------------------------- Fix Version/s: 4.0.15 (was: 4.0.14) > Discovery protocol for members in the same process > -------------------------------------------------- > > Key: JGRP-2284 > URL: https://issues.jboss.org/browse/JGRP-2284 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.15 > > > Discovery protocol that works for members in the same process. Something like SHARED_LOOPBACK_PING, but without the requirement for SHARED_LOOPBACK as transport, but it should work over UDP, TCP, TCP_NIO2 etc. > Similar to TEST_PING in Infinispan. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11013) Hash encoding Exception when using @DatabaseIdentityStoreDefinition

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-11013?page=com.atlassian.jira.plugin... ] Martin Choma commented on WFLY-11013: ------------------------------------- {code}echo -n "admin" | openssl dgst -md5 -binary | openssl base64{code} would be not enough. I really expect in DB <algorithm>:<iterations>:<base64(salt)>:<base64(hash)>, it means something like PBKDF2WithHmacSHA256:64:ISMvKXpXpadD...:ISMvKXpXpadD... I would expect that is what would be returned by {{pbkdf2PasswordHash.generate("HelloWorld".toCharArray())}} > Hash encoding Exception when using @DatabaseIdentityStoreDefinition > ------------------------------------------------------------------- > > Key: WFLY-11013 > URL: https://issues.jboss.org/browse/WFLY-11013 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.0.Final > Environment: WildFly 14. Generic Linux. JDK 8/9 > Reporter: Francesco Marchioni > Assignee: Darran Lofthouse > Attachments: javaee8-secure-servlet.zip > > > When deploying one application using @DatabaseIdentityStoreDefinition, upon successful login, the following exception is thrown > {code:java} > java.lang.IllegalArgumentException: Bad hash encoding > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.decode(Pbkdf2PasswordHashImpl.java:209) > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.<init>(Pbkdf2PasswordHashImpl.java:191) > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl.verify(Pbkdf2PasswordHashImpl.java:147) > at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:121) > at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:101) > at org.jboss.weldx.security.enterprise.identitystore.IdentityStore$635317201$Proxy$_$$_WeldClientProxy.validate(Unknown Source) > at org.glassfish.soteria.cdi.DefaultIdentityStoreHandler.validate(DefaultIdentityStoreHandler.java:97) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1905) Use of the "%" sign in the title

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1905?page=com.atlassian.jira.plugi... ] Enrique González Martínez commented on DROOLS-1905: --------------------------------------------------- {code} final String fName = URLEncoder.encode("100% test.java", "UTF-8"); final String pName = "/path/to/" + fName; final MemoryFile mFile = (MemoryFile) memoryFileSystem.getFile(pName); memoryFileSystem.setFileContents(mFile, new byte[] {}); for(String file : memoryFileSystem.getFileNames()) { System.out.println("file: " + file); } {code} problem lies that while the file name sets the file content encoded the memory file system decodes it (internally) leading to a strange situation where getFileNames come already decoded... so calling getFile causes to try to decode a file name already decoded. > Use of the "%" sign in the title > -------------------------------- > > Key: DROOLS-1905 > URL: https://issues.jboss.org/browse/DROOLS-1905 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Affects Versions: 6.5.0.Final > Reporter: Petr Farmakovsky > Assignee: Enrique González Martínez > Labels: drools-tools > Attachments: 14-12-2016 19-28-17.gif > > > When you save rules or other objects Drools Workbench allows the use of the "%" sign in the title. Opening of any rule results in an error if there is an object with title containing "%" sign in the repository. > It is impossible to build and publish the project. > Error message: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: "s." > !14-12-2016 19-28-17.gif! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2934) Use the new views on the test result panel

by Juraj Soltes (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2934?page=com.atlassian.jira.plugi... ] Juraj Soltes updated DROOLS-2934: --------------------------------- Summary: Use the new views on the test result panel (was: Use the new views on the component.) > Use the new views on the test result panel > ------------------------------------------ > > Key: DROOLS-2934 > URL: https://issues.jboss.org/browse/DROOLS-2934 > Project: Drools > Issue Type: Sub-task > Components: Scenario Simulation and Testing > Reporter: Juraj Soltes > Assignee: Juraj Soltes > > New views to be found here: https://issues.jboss.org/browse/DROOLS-2707 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2989) Avoid refire of rules with synthetic Fact Handles

by Luca Molteni (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2989?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-2989: --------------------------------- Sprint: 2018 Week 36-38 > Avoid refire of rules with synthetic Fact Handles > ------------------------------------------------- > > Key: DROOLS-2989 > URL: https://issues.jboss.org/browse/DROOLS-2989 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Luca Molteni > Assignee: Luca Molteni > > Currently the FromNode and the AccumulateNode create "synthetic" fact handles, that means they're not serialized and they're recreated in memory each time we need the access. > There's already a way to avoid the refiring of the rules but involves serializing and deserializing these synthetic Fact Handles without the objects. > We now want a better way to do it by serializing the objects without their FactHandles and at the same time keep the same behaviour as before (same number of rules should fire) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase runs into intermittent failures

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-1535. -------------------------------- Resolution: Out of Date This is out of date, test is enabled for a long time now. > SSLEJBRemoteClientTestCase runs into intermittent failures > ---------------------------------------------------------- > > Key: WFLY-1535 > URL: https://issues.jboss.org/browse/WFLY-1535 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha1 > Reporter: jaikiran pai > Assignee: Paul Ferraro > > SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsD.... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-740) Set the port_range on JGroups stacks to 1

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-740?page=com.atlassian.jira.plugin.s... ] Radoslav Husar closed WFLY-740. ------------------------------- Fix Version/s: (was: Awaiting Volunteers) Resolution: Out of Date This is out of date as of WFLY-8657. > Set the port_range on JGroups stacks to 1 > ----------------------------------------- > > Key: WFLY-740 > URL: https://issues.jboss.org/browse/WFLY-740 > Project: WildFly > Issue Type: Task > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > > Lock down the ports. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2794) [DMN Designer] Data-types: Support usage in grids

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2794?page=com.atlassian.jira.plugi... ] Michael Anstis resolved DROOLS-2794. ------------------------------------ Fix Version/s: 7.12.0.Final Resolution: Done > [DMN Designer] Data-types: Support usage in grids > ------------------------------------------------- > > Key: DROOLS-2794 > URL: https://issues.jboss.org/browse/DROOLS-2794 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Affects Versions: 7.9.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Fix For: 7.12.0.Final > > > Listing requirements here; and then possibly move this to an EPIC and add smaller tasks. > *_General_* > - (x) {{<< Back to XXX}} does not update if name changed in Properties panel > - (x) "TypeRef" on Properties panel should show "Output Data Type" > *_Literal Expression_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > - (x) Update header when Output Data Type is changed via Properties panel > *_Decision Table_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > - (x) Hide Output Data Type in header when there are multiple {{OutputClause}} columns > - (x) {{InputClause}} columns header should show Input Data Type > - (x) {{InputClause}} columns should support changing the Input Data Type > - (x) {{OutputClause}} columns header should show Output Data Type > - (x) {{OutputClause}} columns should support changing the Output Data Type > *_Context_* > - (x) Grid header _could_ show Output Data Type (for Decision/BKM) > - (/) Editing Output Data Type (for Decision/BKM) is possible via Properties panel > - (x) {{ContextEntry}} should show Output Data Type (for {{ContextEntry}}) > - (x) {{ContextEntry}} should support changing the Output Data Type (for {{ContextEntry}}) > *_Relation_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > - (x) {{InformationItem}} column should show Input Data Type > - (x) {{InformationItem}} column should support changing Input Data Type > *_Invocation_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > *_Function_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2819) [DMN Designer] [IE11] Expression type change throws an Error

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2819?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-2819: ---------------------------------------- [~jomarko] Could you please test this JIRA along with DROOLS-2820 to verify, when the PR is reviewed? > [DMN Designer] [IE11] Expression type change throws an Error > ------------------------------------------------------------ > > Key: DROOLS-2819 > URL: https://issues.jboss.org/browse/DROOLS-2819 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.10.0.Final > Environment: IE11 > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Labels: drools-tools > > When user tries to change expression type the Unexpected error appears: *Uncaught exception: Exception caught: Exception caught: (TypeError) : Object doesn't support property or method 'startsWith' Caused by: Exception caught: (TypeError) : Object doesn't support property or method 'startsWith' Caused by: (TypeError) : Object doesn't support property or method 'startsWith'* -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Jan Lieskovsky (JIRA)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Jan Lieskovsky commented on WFLY-11007: --------------------------------------- [~mchoma] Thanks, Martin! [~sebastian.laskawiec] Sebastian, could you hopefully isolate the PoC to demostrate the issue outside of OpenShift environments too? Also, try the suggested \[1\] \[2\] parameters above, if they fix the current defect? Thanks, Jan > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Stuart Douglas > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 September 2018