January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1923) NPE in AuthenticationConfiguration.toString()

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1923?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-1923. ----------------------------- Resolution: Done > NPE in AuthenticationConfiguration.toString() > --------------------------------------------- > > Key: ELY-1923 > URL: https://issues.redhat.com/browse/ELY-1923 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.11.1.CR1 > > > {noformat} > LogManager error of type FORMAT_FAILURE: Formatting error > java.lang.NullPointerException > at org.wildfly.security.auth.client.AuthenticationConfiguration.toString(AuthenticationConfiguration.java:1654) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12996) Upgrade Narayana to 5.10.3.Final

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-12996?page=com.atlassian.jira.plugi... ] Thomas Jenkinson updated WFLY-12996: ------------------------------------ Description: Transactions component upgrade https://issues.redhat.com/projects/JBTM/versions/12343377 was:Transactions component upgrade > Upgrade Narayana to 5.10.3.Final > -------------------------------- > > Key: WFLY-12996 > URL: https://issues.redhat.com/browse/WFLY-12996 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 19.0.0.Beta1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 19.0.0.Beta2 > > > Transactions component upgrade > https://issues.redhat.com/projects/JBTM/versions/12343377 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12996) Upgrade Narayana to 5.10.3.Final

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-12996?page=com.atlassian.jira.plugi... ] Thomas Jenkinson updated WFLY-12996: ------------------------------------ Summary: Upgrade Narayana to 5.10.3.Final (was: Upgrade Narayana to 5.10.2.Final) > Upgrade Narayana to 5.10.3.Final > -------------------------------- > > Key: WFLY-12996 > URL: https://issues.redhat.com/browse/WFLY-12996 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Affects Versions: 19.0.0.Beta1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 19.0.0.Beta2 > > > Transactions component upgrade -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Petr Kremensky (Jira)

[ https://issues.redhat.com/browse/WFWIP-276?page=com.atlassian.jira.plugin... ] Petr Kremensky updated WFWIP-276: --------------------------------- Description: # As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): ||17.0-6||pod time||EAP boot||config time |#1 | 8283|6128|2155 |#2 | 9446|7548|1898 |#3 | 8767|6871| 1896 |#4 | 8568|6272| 2296 |#5 | 8000 |6362|1638 ||average ||8613ms||6636ms||1977ms ||18.0-7||pod time||EAP boot||config time |#1 |13769|5716|8053 |#2 |13362|5952|7410 |#3 |14261|6093|8168 |#4 |14322|6135|8187 |#5 |13921|6326|7595 ||average||13927ms||6044ms||7883ms pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) EAP boot = time of boot EAP itself == {{started in ..}} config time = the difference of previou timess = anything before EAP boot begins Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. was: As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): ||17.0-6||pod time||EAP boot||config time |#1 | 8283|6128|2155 |#2 | 9446|7548|1898 |#3 | 8767|6871| 1896 |#4 | 8568|6272| 2296 |#5 | 8000 |6362|1638 ||average ||8613ms||6636ms||1977ms ||18.0-7||pod time||EAP boot||config time |#1 |13769|5716|8053 |#2 |13362|5952|7410 |#3 |14261|6093|8168 |#4 |14322|6135|8187 |#5 |13921|6326|7595 ||average||13927ms||6044ms||7883ms pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) EAP boot = time of boot EAP itself == {{started in ..}} config time = the difference of previou timess = anything before EAP boot begins Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.redhat.com/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > # As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-11214?page=com.atlassian.jira.plugi... ] Michael Musgrove updated WFLY-11214: ------------------------------------ Priority: Major (was: Critical) > Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-11214 > URL: https://issues.redhat.com/browse/WFLY-11214 > Project: WildFly > Issue Type: Bug > Components: Agroal, Transactions > Reporter: Ivan Straka > Assignee: Luis Barreiro > Priority: Major > Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log > > > Scenario: > Halts server at commit phase ... > # enlist TestXA resource > # enlist XA resource > # prepare TestXA resource > # prepare XA resource > # commit Test XA resource > # JVM crash > # recovery started > # commit XA resource > Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module. > Test outcome: > {code:java} > Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE! > java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418) > at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4878) Test Scenario: fix support for default stateless kieSession

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4878?page=com.atlassian.jira.plug... ] Daniele Zonca updated DROOLS-4878: ---------------------------------- Description: How to reproduce: - edit kmodule.xml and create only a default stateless session {code:java} <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <kbase name="myKieBase"> <ksession name="mySession" type="stateless" default="true"/> </kbase> </kmodule> {code} - create a Rule test scenario and specify in Setting panel {{stateless}} - run Without the fix: Test failed with this exception "Impossible to find a KieSession with name null" With the fix: The test should be able to run because that kmodule configuration is valid was: How to reproduce: - edit kmodule.xml and create only a default stateless session {code:java} <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <kbase name="myKieBase"> <ksession name="mySession" type="stateless" default="true"/> </kbase> </kmodule> {code} - create a Rule test scenario and specify in Setting panel {{stateless}} - run > Test Scenario: fix support for default stateless kieSession > ----------------------------------------------------------- > > Key: DROOLS-4878 > URL: https://issues.redhat.com/browse/DROOLS-4878 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: drools-tools > > How to reproduce: > - edit kmodule.xml and create only a default stateless session > {code:java} > <kmodule xmlns="http://www.drools.org/xsd/kmodule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <kbase name="myKieBase"> > <ksession name="mySession" type="stateless" default="true"/> > </kbase> > </kmodule> > {code} > - create a Rule test scenario and specify in Setting panel {{stateless}} > - run > Without the fix: > Test failed with this exception "Impossible to find a KieSession with name null" > With the fix: > The test should be able to run because that kmodule configuration is valid -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4959) Package name does not changes on copying of an existing package

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4959?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4959: ---------------------------------------- Our {{CopyHelper}} class and related infrastructure works OK for individual assets (and they can only be copied to the _same_ package). So it seems we're missing the bits to handle copying/renaming an entire {{package}}.... :-( > Package name does not changes on copying of an existing package > --------------------------------------------------------------- > > Key: DROOLS-4959 > URL: https://issues.redhat.com/browse/DROOLS-4959 > Project: Drools > Issue Type: Bug > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: Toni Rikkola > Priority: Major > Attachments: step1.PNG, step2.PNG, step3.PNG, step4.PNG > > > After copying a package to a new one, all copied resources will remain referencing the existing one. > This becomes a bigger issue once you use guided rules, which their source cannot be edited. > Due to that, duplication alerts will be raised. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4960) Reference a data object from one project to another one.

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4960?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-4960: ---------------------------------------- If you've _built_ a project in BRMS it should have been installed in the server's local Maven .m2 repository AFAIK the local .m2 should be used by Maven to resolve dependencies even in offline mode. > Reference a data object from one project to another one. > -------------------------------------------------------- > > Key: DROOLS-4960 > URL: https://issues.redhat.com/browse/DROOLS-4960 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > Currently, nothing can be referenced from one project to another one. > Using a common area to create the Data Objects etc. and reference them on several projects will be very helpful. > Java-wise is like we are creating two projects and we reference the first one in the second one, in order to use some classes in our code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Nikos Tsekouras commented on DROOLS-4961: ----------------------------------------- Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar) and each department will have permissions on its package. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Nikos Tsekouras (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Nikos Tsekouras edited comment on DROOLS-4961 at 1/23/20 7:39 AM: ------------------------------------------------------------------ Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar to maintain) and each department to have permissions on its package. was (Author: nicktsek): Hi [~Rikkola], Think that there is an organization consisting of 5 departments. It's easier to have 1 Project for the whole organization (= 1 jar) and each department will have permissions on its package. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 January 2020