January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14369) Wrong documentation about remoting outbound connection on developer guide

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-14369?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka reassigned WFLY-14369: --------------------------------------- Assignee: Ondrej Chaloupka > Wrong documentation about remoting outbound connection on developer guide > ------------------------------------------------------------------------- > > Key: WFLY-14369 > URL: https://issues.redhat.com/browse/WFLY-14369 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: Adriano Teixeira de Souza > Assignee: Ondrej Chaloupka > Priority: Major > > According to https://issues.redhat.com/browse/WFLY-14284 the oficial documentation on Wildfly Developer Guide is wrong on topics about Remote Outbound Connection and remote protocol as 19.11. > It have instructions that uses deprecated way of configurations and doesn't refers to "remote+http" protocol and how each protocol works. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-4729) Change Unexpected error on Error if DMN got invalidated

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4729?page=com.atlassian.jira.plug... ] Yeser Amer closed DROOLS-4729. ------------------------------ Resolution: Cannot Reproduce No longer present. The Unexpected error is no more raised. It's correct to have the first popup, because the DMN is invalid and it's required to fix it. > Change Unexpected error on Error if DMN got invalidated > -------------------------------------------------------- > > Key: DROOLS-4729 > URL: https://issues.redhat.com/browse/DROOLS-4729 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Affects Versions: 7.29.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Minor > Labels: CustomerFocus, drools-tools > Attachments: Traffic Violation Rules.dmn, image-2019-11-05-18-30-40-011.png, image-2019-11-05-18-31-30-232.png > > > If user created DMN based scenario test and used a property from it and after some time that property disappeared - then if we reopen test scenario editor we got > *Error as expected see* > !image-2019-11-05-18-30-40-011.png|thumbnail! > But if user wants to edit any of the value we got > *Unexpected error* > !image-2019-11-05-18-31-30-232.png|thumbnail! > Steps to reproduce > # Import DMN [^Traffic Violation Rules.dmn] > # Create test scenario asset for this dmn and save > # Go back to DMN and remove Driver Should the driver... DMN objects and save > # Open test scenario -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5816) executable-model doesn't resolve kcontext with mvel dialect

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5816?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5816: -------------------------------------- Summary: executable-model doesn't resolve kcontext with mvel dialect (was: executable-model test failure in test-compiler-integration KnowledgeContextTest) > executable-model doesn't resolve kcontext with mvel dialect > ----------------------------------------------------------- > > Key: DROOLS-5816 > URL: https://issues.redhat.com/browse/DROOLS-5816 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.46.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > org.drools.mvel.integrationtests.KnowledgeContextTest in test-compiler-integration fails with some tests when executable-model is enabled. See TODO comment in the test class. Once fixed (or the test failure is justified), we can remove the TODO comment and let the test run with executable-model. > Currently, executable-model is disabled: > {code:java} > // TODO: .... > return TestParametersUtil.getKieBaseCloudConfigurations(false); > {code} > If the test failure contains multiple bugs, we may split this JIRA into multiple JIRAs. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13736) WFLYWELD0041: WeldContainer is not started when redeploying

by Stuart Douglas (Jira)

[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ] Stuart Douglas commented on WFLY-13736: --------------------------------------- I think I have managed to track down the CI failure and hopefully fixed it. > WFLYWELD0041: WeldContainer is not started when redeploying > ----------------------------------------------------------- > > Key: WFLY-13736 > URL: https://issues.redhat.com/browse/WFLY-13736 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Major > Labels: downstream_dependency > > Deploy 2 applications where: > - api is a static module containing EJB Local Interface and transfer objects > - app2.war has an EJB with a Local interface > - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything) > Start JBoss > touch app2.war to trigger redeployment and it will fail with the error below. > It seems redeploying app2 triggers app1 to restart a service based on the logs. > Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation > {code} > 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand) > 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server' > 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server' > 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ****** > 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms > 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war") > 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war > 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows: > java:global/app2/HelloEJB!api.HelloLocal > java:app/app2/HelloEJB!api.HelloLocal > java:module/HelloEJB!api.HelloLocal > ejb:/app2/HelloEJB!api.HelloLocal > java:global/app2/HelloEJB > java:app/app2/HelloEJB > java:module/HelloEJB > 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started > at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185) > at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) > ... 6 more > ... > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5969) Rule relationship analysis graph : handling special syntax or usage rules

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5969?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5969: -------------------------------------- Description: Basic parsing and generating graph is done. Now using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. was: Using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. > Rule relationship analysis graph : handling special syntax or usage rules > ------------------------------------------------------------------------- > > Key: DROOLS-5969 > URL: https://issues.redhat.com/browse/DROOLS-5969 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.49.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Basic parsing and generating graph is done. > Now using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5969) Rule relationship analysis graph : handling special syntax or usage rules

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5969?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5969: -------------------------------------- Summary: Rule relationship analysis graph : handling special syntax or usage rules (was: Rule relationship analysis graph : handling edge case rules) > Rule relationship analysis graph : handling special syntax or usage rules > ------------------------------------------------------------------------- > > Key: DROOLS-5969 > URL: https://issues.redhat.com/browse/DROOLS-5969 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.49.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5969) Rule relationship analysis graph : handling edge case rules

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5969: ----------------------------------------- Summary: Rule relationship analysis graph : handling edge case rules Key: DROOLS-5969 URL: https://issues.redhat.com/browse/DROOLS-5969 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.49.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi Using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14371) EJB timer not executed on Postgres due to timestamp comparison

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-14371?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-14371: ----------------------------- Summary: EJB timer not executed on Postgres due to timestamp comparison (was: [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison) > EJB timer not executed on Postgres due to timestamp comparison > -------------------------------------------------------------- > > Key: WFLY-14371 > URL: https://issues.redhat.com/browse/WFLY-14371 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 22.0.0.Final > Reporter: Chao Wang > Assignee: Cheng Fang > Priority: Major > Labels: support > > A single action timer fails to be executed: > {noformat} > 15:40:25,613 hz0v DEBUG [org.jboss.as.ejb3.timer] (EJB default - 5) Skipping execution of timer for ROOT.ROOT.EJBTimerScheduler as it is being run on another node or the execution is suppressed by configuration > {noformat} > *Environment*: > * RHPAM 7.7.1 > * EAP 7.2.9 > * OCP 3.11 > * single node setup > * DB: PostgreSQL 10.12, JDBC version: 42.2.3 -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14372) Multiple metrics collections

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14372?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-14372: ------------------------------------ Priority: Critical (was: Major) > Multiple metrics collections > ---------------------------- > > Key: WFLY-14372 > URL: https://issues.redhat.com/browse/WFLY-14372 > Project: WildFly > Issue Type: Task > Components: MP Metrics > Reporter: Brian Stansberry > Assignee: Jason Lee > Priority: Critical > > See discussion on https://github.com/wildfly/wildfly/pull/13871 > Do we have MetricsCollector collecting the container metrics multiple times? > I haven't thought hard about this, but doesn't the Stage.VERIFY collection in MetricsSubsystemAdd end up re-collecting all the deployment=* subtree metrics already collected in Stage.RUNTIME via DeploymentMetricProcessor/DeploymentMetricService? It walks the whole resource tree from the root. > If the MP Metrics subsystem is installed, isn't MicroProfileMetricsSubsystemAdd and that subsystem's DeploymentMetricProcessor/DeploymentMetricService also collecting the same set of metrics? > I'm filing this as a Task because maybe all that's needed is to investigate and answer those questions reporting that all is well. But if all isn't well this should converted to a Bug. > Also, as discussed on PR #13871, https://github.com/wildfly/wildfly/blob/22.0.0.Final/metrics/src/main/jav... is probably not the best idiom given the code is iterating over runtime-only resources, where the cost of hasChildren can be high. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14372) Multiple metrics collections

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14372: --------------------------------------- Summary: Multiple metrics collections Key: WFLY-14372 URL: https://issues.redhat.com/browse/WFLY-14372 Project: WildFly Issue Type: Task Components: MP Metrics Reporter: Brian Stansberry Assignee: Jason Lee See discussion on https://github.com/wildfly/wildfly/pull/13871 Do we have MetricsCollector collecting the container metrics multiple times? I haven't thought hard about this, but doesn't the Stage.VERIFY collection in MetricsSubsystemAdd end up re-collecting all the deployment=* subtree metrics already collected in Stage.RUNTIME via DeploymentMetricProcessor/DeploymentMetricService? It walks the whole resource tree from the root. If the MP Metrics subsystem is installed, isn't MicroProfileMetricsSubsystemAdd and that subsystem's DeploymentMetricProcessor/DeploymentMetricService also collecting the same set of metrics? I'm filing this as a Task because maybe all that's needed is to investigate and answer those questions reporting that all is well. But if all isn't well this should converted to a Bug. Also, as discussed on PR #13871, https://github.com/wildfly/wildfly/blob/22.0.0.Final/metrics/src/main/jav... is probably not the best idiom given the code is iterating over runtime-only resources, where the cost of hasChildren can be high. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 8 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 January 2021