March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: Screenshot from 2019-03-27 20-59-00.png > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png, MySpace_a.zip, Screenshot from 2019-03-27 20-59-00.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: MySpace_a.zip > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png, MySpace_a.zip, Screenshot from 2019-03-27 20-59-00.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11807) FD_SOCK socket-binding client mappings do not map to external_addr/port properly

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11807?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11807: -------------------------------- Summary: FD_SOCK socket-binding client mappings do not map to external_addr/port properly (was: Better port configuration for JGroups FD_SOCK) > FD_SOCK socket-binding client mappings do not map to external_addr/port properly > -------------------------------------------------------------------------------- > > Key: WFLY-11807 > URL: https://issues.jboss.org/browse/WFLY-11807 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Final > Reporter: Rich DiCroce > Assignee: Paul Ferraro > Priority: Major > > The JGroups FD_SOCK protocol requires 2 TCP sockets. Older versions of WildFly accepted a socket-binding for this protocol, but that was removed around version 11, apparently because the binding's port number [wasn't actually used|https://access.redhat.com/solutions/3485801]. > Now the port selection is random by default, which is a problem if you've got firewalls to deal with, as noted in the linked document. The suggested workaround is to set the client_bind_port and start_port properties of the protocol, but that has the drawback of not being affected by a socket-binding-group's port-offset. This means that if you want to run 2 WildFly instances on the same box with the same config (which I do, as a developer, to test application code related to clustering), simply changing the port offset is insufficient to get the second instance to start. > So I'd like to suggest that socket-binding for FD_SOCK be resurrected, given that it can be implemented correctly now. FD_SOCK calls the configured SocketFactory for both the server socket (with name jgroups.fd_sock.srv_sock) and the client socket (with name jgroups.fd.ping_sock), so it should be possible for WildFly to fully manage the socket bindings. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2335) Code for determining the coordinator hangs in certain conditions

by Aieksiei Illarionov (Jira)

Aieksiei Illarionov created JGRP-2335: ----------------------------------------- Summary: Code for determining the coordinator hangs in certain conditions Key: JGRP-2335 URL: https://issues.jboss.org/browse/JGRP-2335 Project: JGroups Issue Type: Bug Reporter: Aieksiei Illarionov Assignee: Bela Ban Affected version: {code:xml} <dependency> <groupId>org.jgroups</groupId> <artifactId>jgroups</artifactId> <version>4.0.0.Final</version> </dependency> {code} ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied: - using JDBC_PING for discovery protocol - JGROUPSPING table contains data from previous sessions - all of the previous sessions were killed (kill -9) - AddressGenerator is not customized The sorted set {code:java} SortedSet<Address> clients=new TreeSet<>(); {code} contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set. Suggestions: either a) somehow involve MembershipChangePolicy in ordering strategy, or b) make the new server (joiner) the first in the sorted set, or c) make UUID addresses to sort depending on their time of creation. I've used the following config: {code:xml}  <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xmlns:fork="fork" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd"> <TCP bind_port="7800" port_range="10" bind_addr="<placeholder here>" recv_buf_size="${tcp.recv_buf_size:130k}" send_buf_size="${tcp.send_buf_size:130k}" max_bundle_size="64K" sock_conn_timeout="300" thread_pool.min_threads="0" thread_pool.max_threads="20" thread_pool.keep_alive_time="30000"/> <JDBC_PING remove_all_data_on_view_change="true" connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase" connection_username="user" connection_password="password" /> <MERGE3 min_interval="10000" max_interval="30000"/> <FD_SOCK/> <FD timeout="3000" max_tries="3" /> <VERIFY_SUSPECT timeout="1500" /> <BARRIER /> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> <UNICAST3 conn_close_timeout="240000" xmit_interval="5000"/> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="4M"/> <pbcast.GMS print_local_addr="true" join_timeout="2000" view_bundling="true" membership_change_policy="ru.illar.AppMembershipChangePolicy"/> <MFC max_credits="2M" min_threshold="0.4"/> <FRAG2 frag_size="60K" />  <pbcast.STATE_TRANSFER/> </config> {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4391) Upgrade apacheds-all to 2.0.0-M24 for Elytron tests

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4391?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4391: ------------------------------- Description: This upgrade is needed to avoid a race condition in Apache Directory Server that causes a hang in {{org.wildfly.extension.elytron.LdapTestCase}} with TLS 1.3. (was: This upgrade is needed to avoid a race condition in Apache Directory Server that occurs in {{org.wildfly.extension.elytron.LdapTestCase}} with TLS 1.3.) > Upgrade apacheds-all to 2.0.0-M24 for Elytron tests > --------------------------------------------------- > > Key: WFCORE-4391 > URL: https://issues.jboss.org/browse/WFCORE-4391 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > > This upgrade is needed to avoid a race condition in Apache Directory Server that causes a hang in {{org.wildfly.extension.elytron.LdapTestCase}} with TLS 1.3. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-659) x509: certificate signed by unknown authority error: unable to locate any template files with name on Maistra Job

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-659: --------------------------------------------- Summary: x509: certificate signed by unknown authority error: unable to locate any template files with name on Maistra Job Key: SWSQE-659 URL: https://issues.jboss.org/browse/SWSQE-659 Project: Kiali QE Issue Type: Task Reporter: Guilherme Baufaker Rêgo Assignee: Guilherme Baufaker Rêgo http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Maistra/259/console It seems to be something related to the certificate -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-659) x509: certificate signed by unknown authority error: unable to locate any template files with name on Maistra Job

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-659?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-659: ------------------------------------------ Sprint: Kiali Sprint #20 > x509: certificate signed by unknown authority error: unable to locate any template files with name on Maistra Job > ----------------------------------------------------------------------------------------------------------------- > > Key: SWSQE-659 > URL: https://issues.jboss.org/browse/SWSQE-659 > Project: Kiali QE > Issue Type: Task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Labels: infrastructure > > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Maistra/259/console > It seems to be something related to the certificate -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4391) Upgrade apacheds-all to 2.0.0-M24 for Elytron tests

by Farah Juma (Jira)

Farah Juma created WFCORE-4391: ---------------------------------- Summary: Upgrade apacheds-all to 2.0.0-M24 for Elytron tests Key: WFCORE-4391 URL: https://issues.jboss.org/browse/WFCORE-4391 Project: WildFly Core Issue Type: Component Upgrade Reporter: Farah Juma Assignee: Farah Juma This upgrade is needed to avoid a race condition in Apache Directory Server that occurs in {{org.wildfly.extension.elytron.LdapTestCase}} with TLS 1.3. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3698) Remove need of reflection for property reactivity in executable model

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3698?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3698. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/submarine-runtimes/commit/36bbe554effa3bde6d0... > Remove need of reflection for property reactivity in executable model > --------------------------------------------------------------------- > > Key: DROOLS-3698 > URL: https://issues.jboss.org/browse/DROOLS-3698 > Project: Drools > Issue Type: Enhancement > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > Labels: submarine > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-158) Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs

by Justin Bertram (Jira)

[ https://issues.jboss.org/browse/WFWIP-158?page=com.atlassian.jira.plugin.... ] Justin Bertram commented on WFWIP-158: -------------------------------------- I'm not sure there's anything we can do about this from Artemis code since the logging is being done by {{org.apache.commons.beanutils.BeanUtils}}. I think this would need to be solved in configuration by setting {{org.apache.commons.beanutils}} to {{INFO}} or higher. > Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs > -------------------------------------------------------------------------- > > Key: WFWIP-158 > URL: https://issues.jboss.org/browse/WFWIP-158 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Justin Bertram > Priority: Major > > If TRACE log is enabled for {{org.apache.activemq.artemis}} then StompProtoco is logging password in clear text: > {code} > 13:48:06,488 DEBUG [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) BeanUtils.populate(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, {needClientAuth=tru > e, trustStorePassword=hornetqexample, keyStorePassword=hornetqexample, port=6445, sslEnabled=true, host=127.0.0.1, trustStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-weekly-common-ssl/eap-t > estsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.truststore, keyStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-week > ly-common-ssl/eap-testsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.keystore}) > ... > 13:48:06,488 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, trustStorePassword, horn > etqexample) > ... > 13:48:06,489 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, keyStorePassword, hornet > qexample) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 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 March 2019