September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1213) UI Automations - Workload Details OC - Add Istio Configs

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1213: ------------------------------------- Summary: UI Automations - Workload Details OC - Add Istio Configs Key: SWSQE-1213 URL: https://issues.redhat.com/browse/SWSQE-1213 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1212) UI Automations - Service Details OC - Add Istio Configs

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1212: ------------------------------------- Summary: UI Automations - Service Details OC - Add Istio Configs Key: SWSQE-1212 URL: https://issues.redhat.com/browse/SWSQE-1212 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1211) UI Automations - Traces into Service Details

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1211: ------------------------------------- Summary: UI Automations - Traces into Service Details Key: SWSQE-1211 URL: https://issues.redhat.com/browse/SWSQE-1211 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan https://github.com/kiali/kiali-ui/pull/1905 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1424) TP: use of multiple transports

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1424: -------------------------------- The other argument in favor of multiple transports, namely bundling of different network interfaces, can be achieved at the OS level, e.g. by using IP Bonding, and probably at a much higher efficiency than doing this in user-space... > TP: use of multiple transports > ------------------------------ > > Key: JGRP-1424 > URL: https://issues.redhat.com/browse/JGRP-1424 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP. > The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination). > Or this could be overridden by a message flag on a per-message basis ! > We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1424) TP: use of multiple transports

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1424: -------------------------------- I'm questioning the usefulness of having multiple transports, against the added complexity... If we have IP multicasting available, we'd probably use UDP:PING (or TCP:MPING if we don't want to use IP multicasting for sending/receiving of messages, only for discovery). If IP multicasting is disabled, we'd have to use TCP anyway. I currently don't see a use case where both UDP *and* TCP would be enabled... > TP: use of multiple transports > ------------------------------ > > Key: JGRP-1424 > URL: https://issues.redhat.com/browse/JGRP-1424 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP. > The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination). > Or this could be overridden by a message flag on a per-message basis ! > We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1424) TP: use of multiple transports

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1424: -------------------------------- Hmm, what if we have UDP and TCP, but IP multicasting is not supported? This is hard to find out, as missed messages might be caused by firewalls/VPN policies rather than multicasting itself... Sending group messages out via UDP would then fail... > TP: use of multiple transports > ------------------------------ > > Key: JGRP-1424 > URL: https://issues.redhat.com/browse/JGRP-1424 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP. > The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination). > Or this could be overridden by a message flag on a per-message basis ! > We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package

by Magnus Larsson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5434?page=com.atlassian.jira.plug... ] Magnus Larsson commented on DROOLS-5434: ---------------------------------------- [~mfusco] Absolutely, I pushed it to a public repo here: https://github.com/Miicroo/test-drools > Incorrect warning about file declaring wrong package > ---------------------------------------------------- > > Key: DROOLS-5434 > URL: https://issues.redhat.com/browse/DROOLS-5434 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Magnus Larsson > Assignee: Mario Fusco > Priority: Major > Attachments: image-2020-09-03-09-20-10-089.png > > > I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. > I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls: > {code:java} > // packageNameForFile prints warning if package in .drl file is not same as flatted directory structure > // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning > String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); > // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded > return isPackageInKieBase( kieBase, pkgNameForFile ); > {code} > As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). > Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem

by Tommaso Borgato (Jira)

[ https://issues.redhat.com/browse/WFLY-13354?page=com.atlassian.jira.plugi... ] Tommaso Borgato edited comment on WFLY-13354 at 9/4/20 4:07 AM: ---------------------------------------------------------------- [~cfang] it's not clear which linked PR to use, one of them refers to webservices galleon layer (https://github.com/wildfly/wildfly/pull/13529) was (Author: tommaso-borgato): [~cfang] it's not clear to which linked PR to use, one of them refers to webservices galleon layer (https://github.com/wildfly/wildfly/pull/13529) > Add Galleon layers for the EJB subsystem > ---------------------------------------- > > Key: WFLY-13354 > URL: https://issues.redhat.com/browse/WFLY-13354 > Project: WildFly > Issue Type: Feature Request > Components: Build System, EJB > Reporter: Brian Stansberry > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2230) Multiple discovery protocols without MULTI_PING

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2230?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2230. ---------------------------- Release Notes Text: We can now simply add multiple discovery protocols without having to add MULTI_PING to the config. Resolution: Done > Multiple discovery protocols without MULTI_PING > ----------------------------------------------- > > Key: JGRP-2230 > URL: https://issues.redhat.com/browse/JGRP-2230 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer. > However, this is an API change, so can be done only in 5.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-346) Bootable JAR - Second bootable JAR fails to package if first uses certain layers

by Jan Kasik (Jira)

[ https://issues.redhat.com/browse/WFWIP-346?page=com.atlassian.jira.plugin... ] Jan Kasik commented on WFWIP-346: --------------------------------- [~jdenise] Thank you too for a quick fix! I tried it even with our new QE testsuite (where the problem first occurred) and your feature branch seems to be fixing the issue. > Bootable JAR - Second bootable JAR fails to package if first uses certain layers > -------------------------------------------------------------------------------- > > Key: WFWIP-346 > URL: https://issues.redhat.com/browse/WFWIP-346 > Project: WildFly WIP > Issue Type: Bug > Reporter: Jan Kasik > Assignee: Jean Francois Denise > Priority: Critical > > See the reproducer: https://github.com/honza-kasik/layer-conflict - there are two Maven modules, each configured to run WildFly Maven JAR plugin. > If I run {{mvn clean package -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3}}, bootable JAR for app-one builds but for app-two the build ends up with an error and app-two fails to package: > {noformat} > [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-jar-maven-plugin:2.0.0.Beta3:package (default) on project app-two: Provisioning failed: Failed to generate standalone.xml on { > [ERROR] "operation" => "composite", > [ERROR] "address" => [], > [ERROR] "rollback-on-runtime-failure" => true, > [ERROR] "steps" => [ > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("interface" => "public")], > [ERROR] "inet-address" => "${jboss.bind.address:127.0.0.1}" > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.wildfly.extension.bean-validation")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.jboss.as.weld")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.jboss.as.naming")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.jboss.as.ee")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.wildfly.extension.io")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.wildfly.extension.undertow")] > [ERROR] }, > [ERROR] { > [ERROR] "operation" => "add", > [ERROR] "address" => [("extension" => "org.jboss.as.jaxrs")] > [ERROR] } > [ERROR] ] > [ERROR] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-8" => "WFLYCTL0310: Extension module org.jboss.as.jaxrs not found"}} > {noformat} > Packaging when running {{mvn clean install -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3 -pl app-two}} ends with success. Same for {{app-one}} only. > If I replace layers in app-one with layer {{cloud-server}} both modules build successfully. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020