September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5639) InternalKnowledgeBuilder.Empty should delegate all the methods

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5639?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5639. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/e20002ccc5dfc4291f4289e5fd8c79a... > InternalKnowledgeBuilder.Empty should delegate all the methods > -------------------------------------------------------------- > > Key: DROOLS-5639 > URL: https://issues.redhat.com/browse/DROOLS-5639 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Daniele Zonca > Assignee: Mario Fusco > Priority: Major > > InternalKnowledgeBuilder.Empty should delegate all methods to real impl because it is possible to build an empty project and then incrementally add resources (this is what BC normally does) > https://github.com/kiegroup/drools/blob/master/drools-compiler/src/main/j... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1717) ContextName creation does not honor '.' in archive name

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-1717?page=com.atlassian.jira.plugin... ] Ranabir Chakraborty closed WFLY-1717. ------------------------------------- Resolution: Out of Date I have checked it and the issue is outdated. So I'm closing this one. Thanks! > ContextName creation does not honor '.' in archive name > ------------------------------------------------------- > > Key: WFLY-1717 > URL: https://issues.redhat.com/browse/WFLY-1717 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Ranabir Chakraborty > Priority: Major > > If you deploy an archive that contains '.' (dots), Arquillian will return contextPath trimmed by removing last .dot > This goes wrong in case that archive name contains dot. .war/.ear/.jar extension might already be removed in contextName returned by WebSubsystem. > For instance, this leads to: > http://localhost:8080/pushee-0.1 instead of http://localhost:8080/pushee-0.1.0 if you deploy pushee-0.1.0.war via Maven.resolver() > Relevant code: > https://github.com/wildfly/wildfly/blob/master/arquillian/common/src/main... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1717) ContextName creation does not honor '.' in archive name

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-1717?page=com.atlassian.jira.plugin... ] Ranabir Chakraborty reassigned WFLY-1717: ----------------------------------------- Assignee: Ranabir Chakraborty > ContextName creation does not honor '.' in archive name > ------------------------------------------------------- > > Key: WFLY-1717 > URL: https://issues.redhat.com/browse/WFLY-1717 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Karel Piwko > Assignee: Ranabir Chakraborty > Priority: Major > > If you deploy an archive that contains '.' (dots), Arquillian will return contextPath trimmed by removing last .dot > This goes wrong in case that archive name contains dot. .war/.ear/.jar extension might already be removed in contextName returned by WebSubsystem. > For instance, this leads to: > http://localhost:8080/pushee-0.1 instead of http://localhost:8080/pushee-0.1.0 if you deploy pushee-0.1.0.war via Maven.resolver() > Relevant code: > https://github.com/wildfly/wildfly/blob/master/arquillian/common/src/main... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13866: ------------------------------------------ The context is 'clear', the ScopeManager used by opentracing per default relies on ThreadLocal and thus is 'lost' for the async calls. We need something to propagate it. > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Critical > Fix For: 21.0.0.Beta1 > > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13854) WildFly cannot connect to an infinispan-server cluster requiring authentication using properties

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13854?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13854: ---------------------------------- Description: We should also allow informal adhoc properties (like we already do for JGroups protocols and cache stores) - which are processed by the hotrod client before any formal properties from the model. > WildFly cannot connect to an infinispan-server cluster requiring authentication using properties > ------------------------------------------------------------------------------------------------ > > Key: WFLY-13854 > URL: https://issues.redhat.com/browse/WFLY-13854 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > Fix For: 21.0.0.Beta1 > > > We should also allow informal adhoc properties (like we already do for JGroups protocols and cache stores) - which are processed by the hotrod client before any formal properties from the model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5135) Add a test case to verify that banned modules are not provisioned with the Galleon layers

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5135?page=com.atlassian.jira.plug... ] Yeray Borges Santana updated WFCORE-5135: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4333 (was: https://github.com/wildfly/wildfly-core/pull/4332) > Add a test case to verify that banned modules are not provisioned with the Galleon layers > ------------------------------------------------------------------------------------------ > > Key: WFCORE-5135 > URL: https://issues.redhat.com/browse/WFCORE-5135 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 13.0.0.Beta6 > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > We need to verify that org.jboss.as.security is not provisioned by using the Galleon Layers. > The proposed solution is to expand the LayersTestCase to add the ability to specify banned modules and be able to detect if a banned module is provisioned. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Fabio Burzigotti updated WFLY-13866: ------------------------------------ Involved: Martin Choma > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Critical > Fix For: 21.0.0.Beta1 > > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Fabio Burzigotti updated WFLY-13866: ------------------------------------ Priority: Critical (was: Major) > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Critical > Fix For: 21.0.0.Beta1 > > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFLY-13866?page=com.atlassian.jira.plugi... ] Fabio Burzigotti commented on WFLY-13866: ----------------------------------------- Hi [~ehugonnet] and [~rhusar] - for some more information. I tried with WildFly 19.1.0 and WildFly 20.0.1.Final. The issue is present there too, so no regression, but I'd raise this to {{Critical}} at least until we don't have a full understanding of the issue context. BTW - Actually it behaves in a slightly different way with 19, meaning that there I can see 4 separate traces for the async call instead there are 3 of them with 20 (the endpoint trace has 2 spans in it, since the fallback related one is included there) CC [~brian.stansberry] > Several traces created in Jaeger for just one method call > --------------------------------------------------------- > > Key: WFLY-13866 > URL: https://issues.redhat.com/browse/WFLY-13866 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 21.0.0.Beta1 > Reporter: Fabio Burzigotti > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 21.0.0.Beta1 > > > I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject. > The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order: > - call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly > - call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger: > TT: 1 trace with 4 spans > WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback. > [1] > https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13876) Test for key-store certificate realm login (test for ELY-2023)

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFLY-13876: ---------------------------------------------- Summary: Test for key-store certificate realm login (test for ELY-2023) Key: WFLY-13876 URL: https://issues.redhat.com/browse/WFLY-13876 Project: WildFly Issue Type: Bug Components: Security, Test Suite Affects Versions: 20.0.1.Final Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero Working on ELY-2023 I realized that there is no test for a certificate login using a keystore realm. This JIRA is to follow the addition of that test (which in turn tests issue ELY-2023). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 2020