June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1834) Add support for missing MP-JWT requirements

by Martin Mazanek (Jira)

[ https://issues.jboss.org/browse/ELY-1834?page=com.atlassian.jira.plugin.s... ] Martin Mazanek moved WFCORE-4548 to ELY-1834: --------------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1834 (was: WFCORE-4548) Component/s: (was: Security) Fix Version/s: (was: 10.0.0.Beta1) > Add support for missing MP-JWT requirements > ------------------------------------------- > > Key: ELY-1834 > URL: https://issues.jboss.org/browse/ELY-1834 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Martin Mazanek > Assignee: Martin Mazanek > Priority: Major > Labels: EAP-CD18 > > There are two main things that are currently missing: > * Support for injection of the currently authenticated caller as a {{JsonWebToken}} > * The {{java.security.Principal}} returned from {{javax.ws.rs.core.SecurityContext.getUserPrincipal()}} must be an instance of {{org.eclipse.microprofile.jwt.JsonWebToken}} > More details can be found [here|https://www.eclipse.org/community/eclipse_newsletter/2017/september/...]. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1833) KeyStoreCredentialStore does not use Provider[] for passwords.

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1833: ------------------------------------- Summary: KeyStoreCredentialStore does not use Provider[] for passwords. Key: ELY-1833 URL: https://issues.jboss.org/browse/ELY-1833 Project: WildFly Elytron Issue Type: Bug Components: Credential Store Affects Versions: 1.10.0.CR1 Reporter: Darran Lofthouse The KeyStoreCredentialStore implementation does not use the Provider[] passed in during initialisation for PasswordFactory interaction. However it does use it for the underlying KeyStore. Any changes here will need to consider backwards compatibility as existing users may be used to this difference. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-9631: ---------------------------------- This is what I understand how DatabaseTimerPersistence works, some new timers are successfully saved to db and so they are consistent in both cache and db, and no issue for those timers. DatabaseTimerPersistence thinks db has the authoritative state and it examines each timer in cache, and if it is in cache only, then it thinks it is not good. > "Failed to reinstate timer" warning is shown when creating large number of EJB timers > ------------------------------------------------------------------------------------- > > Key: WFLY-9631 > URL: https://issues.jboss.org/browse/WFLY-9631 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: EAP 7.0.8.GA > Oracle 12 c > [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema. > Reporter: Marian Macik > Assignee: Cheng Fang > Priority: Major > Attachments: WFLY-9631-reproducer.zip > > > Hi, [~manovotn], > as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. > What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created: > {code:java} > WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507 > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance. > Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred. > So I think it has something to do with refresh interval. > Can you please have a look at it? For further configuration details, check the Environment field. > Thank you very much! > Marian Macik -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4257) DMN UX - overlay information about an entire simulation execution

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-4257: ------------------------------------- Summary: DMN UX - overlay information about an entire simulation execution Key: DROOLS-4257 URL: https://issues.jboss.org/browse/DROOLS-4257 Project: Drools Issue Type: Story Components: DMN Editor Reporter: Daniele Zonca Assignee: Tao Zhu Related to https://issues.jboss.org/browse/DROOLS-3731 This task will cover this use case: - user creates a DMN model - user creates a Test Scenario with some scenarios - user executes the Test Scenario - user open Coverage Report - user wants to analyze coverage information of the *whole* simulation - user clicks on "a link" near global coverage information - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4258) DMN UX - overlay information about a single scenario run

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-4258: ------------------------------------- Summary: DMN UX - overlay information about a single scenario run Key: DROOLS-4258 URL: https://issues.jboss.org/browse/DROOLS-4258 Project: Drools Issue Type: Story Components: DMN Editor Reporter: Daniele Zonca Assignee: Tao Zhu Related to https://issues.jboss.org/browse/DROOLS-3731 This task will cover this use case: - user creates a DMN model - user creates a Test Scenario with some scenarios - user executes the Test Scenario - user open Coverage Report - user wants to analyze the execution of a *single scenario* in the DMN model - user clicks on "a link" related to the scenario to analyze - user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value (from the scenario) and to open an executed decision table to see which row has been evaluated -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4256) Make Quarkus extension hot reload to also work with new rules

by Mario Fusco (Jira)

Mario Fusco created DROOLS-4256: ----------------------------------- Summary: Make Quarkus extension hot reload to also work with new rules Key: DROOLS-4256 URL: https://issues.jboss.org/browse/DROOLS-4256 Project: Drools Issue Type: Task Reporter: Mario Fusco Assignee: Mario Fusco At the moment hot reload of Kogito extesnsion for Quarkus only works when modifying an existing rule. It should also work when new rules (or entire drl files) are added or removed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4200) Design and implement new DataSources API

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4200?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4200: -------------------------------- Sprint: 2019 Week 26-28 > Design and implement new DataSources API > ---------------------------------------- > > Key: DROOLS-4200 > URL: https://issues.jboss.org/browse/DROOLS-4200 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > We need 2 distinct DataSources: > * DataStream with only an append operation > * DataStore with all 3 WMA operations (has to return a FH) > Each RuleUnit will have a mailbox. When a RuleUnit is executed for the first time all data in its DataSources are flushed into its mailbox (wrapped in Commands). Then, when the RuleUnit is quiescent, it remains subscribed to its DataSources so that all new operation performed on them get also automatically flushed into its mailbox. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4255) Add KIE server support for deploying custom Prometheus metrics

by Vladimir Blagojevic (Jira)

Vladimir Blagojevic created DROOLS-4255: ------------------------------------------- Summary: Add KIE server support for deploying custom Prometheus metrics Key: DROOLS-4255 URL: https://issues.jboss.org/browse/DROOLS-4255 Project: Drools Issue Type: Enhancement Components: kie server Affects Versions: 7.24.0.Final Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 7.24.0.Final The first implementation of Prometheus support in Kie provided default Prometheus metrics. We should enable our users to deploy their custom Prometheus metrics in addition to default Prometheus metrics already published. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers

by Marian Macik (Jira)

[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ] Marian Macik commented on WFLY-9631: ------------------------------------ ??As explained above, *some new timers are removed from DatabaseTimerPersistence cache*, but the block that saves them to db eventually gets to run and they are persisted into db. When it comes next timer refresh, they are deemed as timers that need to be added since they are present in db but not in cache. Hence the duplicate timer resource warning.?? Why would only some new timers be removed from the cache in that case? If refresh is interleaved with persisting and there is no sync, I would say that refresh will manage to remove the whole cache, but not necessarily all of it before timers are persisted in DB. In other words, I don't see any duplication here. Can you maybe explain a little bit more? > "Failed to reinstate timer" warning is shown when creating large number of EJB timers > ------------------------------------------------------------------------------------- > > Key: WFLY-9631 > URL: https://issues.jboss.org/browse/WFLY-9631 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: EAP 7.0.8.GA > Oracle 12 c > [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema. > Reporter: Marian Macik > Assignee: Cheng Fang > Priority: Major > Attachments: WFLY-9631-reproducer.zip > > > Hi, [~manovotn], > as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. > What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created: > {code:java} > WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507 > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance. > Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred. > So I think it has something to do with refresh interval. > Can you please have a look at it? For further configuration details, check the Environment field. > Thank you very much! > Marian Macik -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-3879?page=com.atlassian.jira.plugi... ] Daniele Zonca commented on DROOLS-3879: --------------------------------------- [~kkufova] We should probably promote subtask as task linked to the epic to have them on the board but fine for me to have it as feature request too :) > Create Kogito version of Test Scenarios designer > ------------------------------------------------ > > Key: DROOLS-3879 > URL: https://issues.jboss.org/browse/DROOLS-3879 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > Create the *Kogito* (standalone) version of scesim editor. > No Home Page, no Library, No preferences, no other editors. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 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 June 2019