June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1831) When manipulating a store the password should only be prompted for once.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1831?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1831: ---------------------------------- Summary: When manipulating a store the password should only be prompted for once. (was: When manipulating a store the password should only be prompted for one.) > When manipulating a store the password should only be prompted for once. > ------------------------------------------------------------------------ > > Key: ELY-1831 > URL: https://issues.jboss.org/browse/ELY-1831 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Affects Versions: 1.10.0.CR2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.0.CR3 > > > When manipulating an existing store the store password should only be prompted for once - it is either valid or it is not. It is only during the creation of the store it should be prompted for twice. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4217) Test Scenario: corrupted scenario when user accepts error suggestion for collection

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-4217?page=com.atlassian.jira.plugi... ] Daniele Zonca updated DROOLS-4217: ---------------------------------- Sprint: 2019 Week 26-28 > Test Scenario: corrupted scenario when user accepts error suggestion for collection > ----------------------------------------------------------------------------------- > > Key: DROOLS-4217 > URL: https://issues.jboss.org/browse/DROOLS-4217 > Project: Drools > Issue Type: Bug > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Blocker > Labels: ScenarioSimulation > > If a scenario fails with a wrong expect value on a collection the actual value suggested to accept is wrong and if accepted the scenario corrupts -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12238) SimpleLoadProviderResourceDefinition - identical code in different branches

by Rostislav Svoboda (Jira)

Rostislav Svoboda created WFLY-12238: ---------------------------------------- Summary: SimpleLoadProviderResourceDefinition - identical code in different branches Key: WFLY-12238 URL: https://issues.jboss.org/browse/WFLY-12238 Project: WildFly Issue Type: Bug Components: mod_cluster Reporter: Rostislav Svoboda Assignee: Radoslav Husar SimpleLoadProviderResourceDefinition - identical code in different branches https://github.com/wildfly/wildfly/blob/master/mod_cluster/extension/src/... {{parent.addChildResource(PATH)}} in both branches of {{ResourceTransformationDescriptionBuilder builder = ModClusterModel.VERSION_6_0_0.requiresTransformation(version) ? parent.addChildResource(PATH) : parent.addChildResource(PATH);}} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4246) testProxy in MavenRepositoryTest in kie-soup fails randomly

by Tibor Zimanyi (Jira)

Tibor Zimanyi created DROOLS-4246: ------------------------------------- Summary: testProxy in MavenRepositoryTest in kie-soup fails randomly Key: DROOLS-4246 URL: https://issues.jboss.org/browse/DROOLS-4246 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.23.0.Final Reporter: Tibor Zimanyi Assignee: Tibor Zimanyi Test testProxy() fails randomly. Problem is that it checks for size from all repositories, however it needs to check just the count of test repositories that needs to be proxied. [1] https://github.com/kiegroup/kie-soup/blob/master/kie-soup-maven-utils/kie... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4216) Create runtime and testing version of kogito webapp

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4216?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4216: ------------------------------------- Description: For each asset there should be two *kogito* webapp: # a **development/testing** one, that should provide **VS CODE** features, # a **runtime** one, without the above, to be used inside **VS CODE** To allow *inheritance* and avoid code-duplication, a common, parent **jar** will also be implemented was: For each asset there should be two *kogito* webapp: # a **development/testing** one, that should provide **VS CODE** funtionalities, # a **runtime** one, without the above, to be used inside **VS CODE** > Create runtime and testing version of kogito webapp > --------------------------------------------------- > > Key: DROOLS-4216 > URL: https://issues.jboss.org/browse/DROOLS-4216 > Project: Drools > Issue Type: Sub-task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: ScenarioSimulation > > For each asset there should be two *kogito* webapp: > # a **development/testing** one, that should provide **VS CODE** features, > # a **runtime** one, without the above, to be used inside **VS CODE** > To allow *inheritance* and avoid code-duplication, a common, parent **jar** will also be implemented -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4216) Create runtime and testing version of kogito webapp

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4216?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4216: ------------------------------------- Description: For each asset there should be two *kogito* webapp: # a **development/testing** one, that should provide **VS CODE** features, # a **runtime** one, without the above, to be used inside **VS CODE** To allow *inheritance* and avoid code-duplication, a common, parent *jar* will also be implemented was: For each asset there should be two *kogito* webapp: # a **development/testing** one, that should provide **VS CODE** features, # a **runtime** one, without the above, to be used inside **VS CODE** To allow *inheritance* and avoid code-duplication, a common, parent **jar** will also be implemented > Create runtime and testing version of kogito webapp > --------------------------------------------------- > > Key: DROOLS-4216 > URL: https://issues.jboss.org/browse/DROOLS-4216 > Project: Drools > Issue Type: Sub-task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: ScenarioSimulation > > For each asset there should be two *kogito* webapp: > # a **development/testing** one, that should provide **VS CODE** features, > # a **runtime** one, without the above, to be used inside **VS CODE** > To allow *inheritance* and avoid code-duplication, a common, parent *jar* will also be implemented -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3935) [DMN Designer] Data Types tab - Improve action buttons

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3935?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3935: -------------------------------- Description: In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. h2. Acceptance test On Firefox(/) and Chrome(/) - Buttons in Data Types tab has changed (/) - Buttons in toolbar has not changed (/) - Buttons in project settings has not changed (/) - Buttons in roles has not changed (/) was: In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. h2. Acceptance test On Firefox and Chrome - Buttons in Data Types tab has changed - Buttons in toolbar has not changed - Buttons in project settings has not changed - Buttons in roles has not changed > [DMN Designer] Data Types tab - Improve action buttons > ------------------------------------------------------ > > Key: DROOLS-3935 > URL: https://issues.jboss.org/browse/DROOLS-3935 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-24 at 2.06.47 PM.png > > > In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. > h2. Acceptance test > On Firefox(/) and Chrome(/) > - Buttons in Data Types tab has changed (/) > - Buttons in toolbar has not changed (/) > - Buttons in project settings has not changed (/) > - Buttons in roles has not changed (/) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3935) [DMN Designer] Data Types tab - Improve action buttons

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3935?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3935: -------------------------------- Description: In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. h2. Acceptance test On Firefox and Chrome - Buttons in Data Types tab has changed - Buttons in toolbar has not changed - Buttons in project settings has not changed - Buttons in roles has not changed was:In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. > [DMN Designer] Data Types tab - Improve action buttons > ------------------------------------------------------ > > Key: DROOLS-3935 > URL: https://issues.jboss.org/browse/DROOLS-3935 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Daniel José dos Santos > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screen Shot 2019-04-24 at 2.06.47 PM.png > > > In the Data Types list, the "Save" button must be changed to a PatternFly primary button (https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/button...), and the "X" must be changed to PatternFly default button with the "Cancel" text. > h2. Acceptance test > On Firefox and Chrome > - Buttons in Data Types tab has changed > - Buttons in toolbar has not changed > - Buttons in project settings has not changed > - Buttons in roles has not changed -- 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: ---------------------------------- wrt timers.remove(..) call in DatabaseTimerPersistence, this is to remove any timers that are in the cache, but not in the timer data store. For example, this can happen when a timer is cancelled from another server instance, and thus removed from timer db, and so the residual timer object needs to be cleared. I think this could be a thread synchronization issue, e.g., DatabaseTimerPersistence.addTimer(...) method adds timer object to cache, and then save to db. The 2 parts are not guarded as one single unit, and therefore some valid timers may be in cache, but not in db yet. If in the middle the refresher task gets to run, it will try to remove the newly-added timers in cache, since they are not present in db. This removal may explain why certain timers never take effect. Why the warning of duplicate timer ids? My guess is that during new timer creation and start, the timer resource is already added to management model. 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. If we set refresh interval to sufficiently long, the state of the cache and db are already consistent by the time the first refresh kicks in, and so there is no extra removal, or the additional adding. > "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] (WFLY-12232) socket-binding "jgroups-tcp-fd" for FD_SOCK is used for UDP stack

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12232?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-12232: ---------------------------------- Summary: socket-binding "jgroups-tcp-fd" for FD_SOCK is used for UDP stack (was: socket-binding "jgroups-tcp-fd" for FD_SOCK is used for UPD stack) > socket-binding "jgroups-tcp-fd" for FD_SOCK is used for UDP stack > ----------------------------------------------------------------- > > Key: WFLY-12232 > URL: https://issues.jboss.org/browse/WFLY-12232 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Vlasta Ramik > Assignee: Paul Ferraro > Priority: Major > > There are switched names of socket bindings in jgroups.xml > * https://github.com/wildfly/wildfly/commit/5ee199b7ecd3166a5afdc97425af412... > * https://github.com/wildfly/wildfly/commit/5ee199b7ecd3166a5afdc97425af412... > when legacy build system is used, e.g. like [here|https://github.com/keycloak/keycloak/blob/master/distribution/featur...] it ends with switched values than in standalone-ha.xml from wildfly17 dist -- 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