[Red Hat JIRA] (WFLY-13871) Re-implement correct suspend/resume behaviour for EJB client
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFLY-13871:
---------------------------
Labels: downstream_dependency (was: )
> Re-implement correct suspend/resume behaviour for EJB client
> ------------------------------------------------------------
>
> Key: WFLY-13871
> URL: https://issues.redhat.com/browse/WFLY-13871
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Fix For: 21.0.0.Final
>
>
> When a server is suspended, in order to avoid receipt of invocations which will never be correctly processed, all connected clients should be notified that all modules on that server are now unavailable; when the server is resumed, all connected clients should be notified that all modules on that server are now again available so that the server may again take part in processing invocations.
> This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to the new EJB client server-side classes which were substantially refactored.
> This issue will re-instante that behaviour. The two cases of standalone and clustered deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5722) Fix ServiceDiscoveryImpl.reset
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5722:
----------------------------------------
Summary: Fix ServiceDiscoveryImpl.reset
Key: DROOLS-5722
URL: https://issues.redhat.com/browse/DROOLS-5722
Project: Drools
Issue Type: Bug
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
In one of the last PR a
{code:java}
PriorityMap
{code}
has been implemented inside
{code:java}
org.kie.api.internal.utils.ServiceDiscoveryImpl
{code}
But this map is not updated/reset from
{code:java}
org.kie.api.internal.utils.ServiceDiscoveryImpl.reset()
{code}
and that lead to unconsistent situation: _cachedServices_ are removed but they can't be repopulated, because an exception is thrown at
https://github.com/kiegroup/droolsjbpm-knowledge/blob/3b8c6100f2544987923...
This ticket should add a "reset" method inside PriorityMap, and call it inside
{code:java}
org.kie.api.internal.utils.ServiceDiscoveryImpl
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13057) Unexpected status of WSBACoordinator when using IBM JDK and SecurityManager
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFLY-13057?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFLY-13057:
-----------------------------------------
Assignee: Bartosz Baranowski
> Unexpected status of WSBACoordinator when using IBM JDK and SecurityManager
> ---------------------------------------------------------------------------
>
> Key: WFLY-13057
> URL: https://issues.redhat.com/browse/WFLY-13057
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Affects Versions: 19.0.0.Beta1
> Reporter: Francesco Marchioni
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: surefire-reports.zip
>
>
> An unexpected status of WSBACoordinator causes failures in the following tests when using IBM JDK 1.8 and Security Manager
> {code:java}
> [ERROR] Failures:
> [ERROR] BACoordinatorCompletionTestCase.testWSBACoordinatorCannotComplete:133->assertEventLogClient1:193->BaseFunctionalTest.assertEventLog:85 Another status order expected for the bacoordinator_completition_service1 expected:<[CANCEL]> but was:<null>
> [ERROR] BACoordinatorCompletionTestCase.testWSBACoordinatorCompletionFailToComplete:184->assertEventLogClient1:193->BaseFunctionalTest.assertEventLog:85 Another status order expected for the bacoordinator_completition_service1 expected:<[COMPLETE, CONFIRM_COMPLETED, COMPENSATE]> but was:<null>
> {code}
> Affected Tests in the AS Testsuite:
> org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCannotComplete
> org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCompletionFailToComplete
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5721) Ruleflow group rule does not fire when drools-traits is on classpath
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5721?page=com.atlassian.jira.plug... ]
Luca Molteni moved RHDM-1479 to DROOLS-5721:
--------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5721 (was: RHDM-1479)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: core engine
(was: BRE)
Affects Build: (was: CR1)
Affects Version/s: 7.44.0.Final
(was: 7.9.0.GA)
QE Status: NEW
> Ruleflow group rule does not fire when drools-traits is on classpath
> --------------------------------------------------------------------
>
> Key: DROOLS-5721
> URL: https://issues.redhat.com/browse/DROOLS-5721
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.44.0.Final
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Critical
> Labels: regression, reported-by-qe
> Attachments: traits-reproducer.zip
>
>
> When drools-traits is added on the classpath, the provided tests fails on {{fireAllRules()}} returning 0 instead of expected 1. The test passes in RHDM/RHPAM 7.8.1 and earlier, the problem was reproduced on master.
> If the test describes a behaviour which is now not supported, please let us know, thanks! Otherwise, it seems to be a regression.
> I have set the priority to Critical in order to investigate what is going on (if the regression might cause more serious unexpected behaviour), it can be deprioritized if we are sure what it affects.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5710) [DMN XML] Signavio Profile - DayDiffFunction: Should work with Date and DateTime values
by Jonas Beyer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5710?page=com.atlassian.jira.plug... ]
Jonas Beyer commented on DROOLS-5710:
-------------------------------------
Thanks! :)
> [DMN XML] Signavio Profile - DayDiffFunction: Should work with Date and DateTime values
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-5710
> URL: https://issues.redhat.com/browse/DROOLS-5710
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Jonas Beyer
> Assignee: Matteo Mortari
> Priority: Minor
>
> If the DayDiff() function is called with a parameter of data type Date, an error is thrown during runtime.
> Example:
> {quote}dayDiff(myDate, today())
> {quote}
> h3. Acceptance Criteria:
> * DayDiff function can be called with datatypes Date and Datetime in any combination
> ** Date, Date
> ** Date, Datetime
> ** Datetime, Date
> ** Datetime, Datetime
> h3. Details:
> The {{DayDiffFunction}} is implemented using {{Duration#between}} . This implementation will try to calculate the duration between the given {{Temporal}} s based on their nanoseconds or seconds, which can't be extracted from values of type Date that don't have a time component.
> Suggestion: Manually convert the parameters to {{Instant}} s, using the start of the day as time component for Date values.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2430:
--------------------------------
What happens with encryption? If we have a member A sending a message M to B via the GossipRouter GR, will GR have to decrypt M from A, and encrypt M with GR's secret before passing it on to B? That would defy the purpose of this JIRA!
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-996) Default Stateless Session in Kie Server
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-996?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-996:
-------------------------------------
Story Points: 2
Sprint: 2020 Week 40-42 (from Sep 28)
> Default Stateless Session in Kie Server
> ---------------------------------------
>
> Key: DROOLS-996
> URL: https://issues.redhat.com/browse/DROOLS-996
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Justin Goldsmith
> Assignee: Toshiya Kobayashi
> Priority: Minor
>
> When executing against a container in kie server if the default session is stateful you do not have to provide a lookup, but if the default session is stateless it throws an exception stating there is no default session. While this is easy to work around its not intuitive.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13954) Class not found error in Jakarta EE 9 deployment stage
by hantsy bai (Jira)
[ https://issues.redhat.com/browse/WFLY-13954?page=com.atlassian.jira.plugi... ]
hantsy bai edited comment on WFLY-13954 at 10/12/20 11:57 PM:
--------------------------------------------------------------
I was using the official 21.0.0.Beta1 dist which declared initial Jakarta EE 9 support in some blog I have read.
was (Author: hantsy):
I was using the official ** 21.0.0.Beta1 dist which declares intiail Jakarta EE 9 support in the blog.
> Class not found error in Jakarta EE 9 deployment stage
> ------------------------------------------------------
>
> Key: WFLY-13954
> URL: https://issues.redhat.com/browse/WFLY-13954
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 21.0.0.Beta1
> Reporter: hantsy bai
> Assignee: Brian Stansberry
> Priority: Major
>
> When I deployed a Jakarata EE 9 applicaiton into 21, got the following exception in the deployment progress.
>
> ```
> 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 4) WELD-000119: Not generating any bean definitions from com.example.GreetingResource because of underlying class loa
> ding error: Type jakarta.ws.rs.core.Response from [Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader] not found. If this is unexpected, enable DEBUG lo
> gging to see the full error.
> 11:05:04,558 WARN [org.jboss.modules.define] (Weld Thread Pool -- 2) Failed to define class com.example.JaxrsActivator in Module "deployment.jakartaee9-starter-boilerplate.war" from S
> ervice Module Loader: java.lang.NoClassDefFoundError: Failed to link com/example/JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jak
> arta/ws/rs/core/Application
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.as.weld@21.0.0.Beta1//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:82)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:108)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:87)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:55)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:52)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513)
> 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from com.example.JaxrsActivator because of underlying class loadi
> ng error: Type Failed to link com.example.JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jakarta.ws.rs.core.Application not found.
> If this is unexpected, enable DEBUG logging to see the full error.
> ```
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13954) Class not found error in Jakarta EE 9 deployment stage
by hantsy bai (Jira)
[ https://issues.redhat.com/browse/WFLY-13954?page=com.atlassian.jira.plugi... ]
hantsy bai commented on WFLY-13954:
-----------------------------------
I was using the official ** 21.0.0.Beta1 dist which declares intiail Jakarta EE 9 support in the blog.
> Class not found error in Jakarta EE 9 deployment stage
> ------------------------------------------------------
>
> Key: WFLY-13954
> URL: https://issues.redhat.com/browse/WFLY-13954
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 21.0.0.Beta1
> Reporter: hantsy bai
> Assignee: Brian Stansberry
> Priority: Major
>
> When I deployed a Jakarata EE 9 applicaiton into 21, got the following exception in the deployment progress.
>
> ```
> 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 4) WELD-000119: Not generating any bean definitions from com.example.GreetingResource because of underlying class loa
> ding error: Type jakarta.ws.rs.core.Response from [Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader] not found. If this is unexpected, enable DEBUG lo
> gging to see the full error.
> 11:05:04,558 WARN [org.jboss.modules.define] (Weld Thread Pool -- 2) Failed to define class com.example.JaxrsActivator in Module "deployment.jakartaee9-starter-boilerplate.war" from S
> ervice Module Loader: java.lang.NoClassDefFoundError: Failed to link com/example/JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jak
> arta/ws/rs/core/Application
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at org.jboss.as.weld@21.0.0.Beta1//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(AnnotatedTypeLoader.java:82)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType(AnnotatedTypeLoader.java:62)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType(FastAnnotatedTypeLoader.java:108)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:87)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:55)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:52)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.core@3.1.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513)
> 11:05:04,558 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from com.example.JaxrsActivator because of underlying class loadi
> ng error: Type Failed to link com.example.JaxrsActivator (Module "deployment.jakartaee9-starter-boilerplate.war" from Service Module Loader): jakarta.ws.rs.core.Application not found.
> If this is unexpected, enable DEBUG logging to see the full error.
> ```
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-996) Default Stateless Session in Kie Server
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-996?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi reassigned DROOLS-996:
----------------------------------------
Assignee: Toshiya Kobayashi (was: Justin Goldsmith)
> Default Stateless Session in Kie Server
> ---------------------------------------
>
> Key: DROOLS-996
> URL: https://issues.redhat.com/browse/DROOLS-996
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Justin Goldsmith
> Assignee: Toshiya Kobayashi
> Priority: Minor
>
> When executing against a container in kie server if the default session is stateful you do not have to provide a lookup, but if the default session is stateless it throws an exception stating there is no default session. While this is easy to work around its not intuitive.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months