May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1162) Improve output of IPI and UPI provisioning jobs when waiting for operators

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1162: ------------------------------------ Summary: Improve output of IPI and UPI provisioning jobs when waiting for operators Key: SWSQE-1162 URL: https://issues.redhat.com/browse/SWSQE-1162 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta The jobs are sometimes stuck on waiting for operators and the output is not very clear, we need to improve that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13517) [GSS](7.3.z) WFLY-11808 - Unable to do jndi lookup when starting batch job from web console

by Joerg Baesner (Jira)

Joerg Baesner created WFLY-13517: ------------------------------------ Summary: [GSS](7.3.z) WFLY-11808 - Unable to do jndi lookup when starting batch job from web console Key: WFLY-13517 URL: https://issues.redhat.com/browse/WFLY-13517 Project: WildFly Issue Type: Bug Components: Batch Affects Versions: 16.0.0.Final Reporter: Joerg Baesner Assignee: Cheng Fang Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13516) Create integration test scenario for transaction recovery failure of ejb remoting JBEAP-19408

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created WFLY-13516: --------------------------------------- Summary: Create integration test scenario for transaction recovery failure of ejb remoting JBEAP-19408 Key: WFLY-13516 URL: https://issues.redhat.com/browse/WFLY-13516 Project: WildFly Issue Type: Task Components: Test Suite, Transactions Affects Versions: 20.0.0.Beta1 Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka There was found a transaction recovery failure scenario which caused regression being filled as https://issues.redhat.com/browse/JBEAP-19408. The issue JBEAP-19408 causes that in case of WildFly communicating over EJB remoting to other WildFly and when there is a failure then there could be left prepared resources on the other WildFly which are never rolled-back. E.g. in case of database it means locked rows which could not be manipulated with until administrator comes and manually unlock them. The scenario which was this hit with and which should be simulated in the WildFly testsuite: * server A starts the transactions * transaction at server A enlists the an XAResource related to a future interation with server B (At server A, WFTC enlists an "ejb client resource" related to a future interaction with B) * server A makes the remote EJB call to server B where transaction is propagated * server A asks server B to prepare * server A creates a "ejb client resource" XAResourceRegistry file system record * server B prepares * server A crashes before it writes a transaction log * server A restarts (transaction recovery cycle starts) * server A can see no record of the transactions in the object store * server A uses the standard orphan detection processing * server A calls XAResource.recover(TMSTARTRSCAN) on "ejb client resource". It returns prepared XAResources from server B as there is XAResourceRegistry file system record on server A (related to a future interation with server B) * server A calls XAResource.recover(TMENDRSCAN), the recovery cycle finishes * server A calls another round of recovery wwith XAResource.recover(TMSTARTRSCAN) and there is the XAResourceRegistry and orphan detection rolls-back the subtransaction resources on server B -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8420) Missing dependencies from wildfly-naming-client

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-8420?page=com.atlassian.jira.plugin... ] Parul Sharma reassigned WFLY-8420: ---------------------------------- Assignee: Parul Sharma > Missing dependencies from wildfly-naming-client > ----------------------------------------------- > > Key: WFLY-8420 > URL: https://issues.redhat.com/browse/WFLY-8420 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: Parul Sharma > Priority: Major > > This module is missing service dependencies on the EJB client and the transaction client, both of which register context handlers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5378) Alpha Node ordering

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5378: ----------------------------------------- Summary: Alpha Node ordering Key: DROOLS-5378 URL: https://issues.redhat.com/browse/DROOLS-5378 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.38.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi Re-order Alpha Node based on some strategies: - Expression usage count - Other strategies : Chapter 9 "Ordering Conditions" in http://i.stanford.edu/pub/cstr/reports/cs/tr/86/1124/CS-TR-86-1124.pdf It would contribute to maximise sharing and minimise the number of evaluations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) [GSS](7.3.z) Application does not fail when @Singleton @PostConstruct throws exception

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Cheng Fang moved JBEAP-19555 to WFLY-13515: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13515 (was: JBEAP-19555) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.6.GA) (was: 7.3.1.GA) (was: 7.2.8.GA) > [GSS](7.3.z) Application does not fail when @Singleton @PostConstruct throws exception > -------------------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Cheng Fang > Assignee: Panagiotis Sotiropoulos > Priority: Major > Labels: Regression > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) Application does not fail when @Singleton @PostConstruct throws exception

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13515: ------------------------------ Summary: Application does not fail when @Singleton @PostConstruct throws exception (was: [GSS](7.3.z) Application does not fail when @Singleton @PostConstruct throws exception) > Application does not fail when @Singleton @PostConstruct throws exception > ------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Final, 20.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Panagiotis Sotiropoulos > Priority: Major > Labels: Regression > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) Application does not fail when @Singleton @PostConstruct throws exception

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13515: ------------------------------ Affects Version/s: 20.0.0.Beta1 19.0.0.Final > Application does not fail when @Singleton @PostConstruct throws exception > ------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Final, 20.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Panagiotis Sotiropoulos > Priority: Major > Labels: Regression > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1972) Elytron server truststore configuration for root CA

by Meena Meghana Ravuri (Jira)

Meena Meghana Ravuri created ELY-1972: ----------------------------------------- Summary: Elytron server truststore configuration for root CA Key: ELY-1972 URL: https://issues.redhat.com/browse/ELY-1972 Project: WildFly Elytron Issue Type: Clarification Components: Certificate Authority, KeyStores, SSL Reporter: Meena Meghana Ravuri Hi, I configured two way SSL context in eytron (to make use of credential store). But I still face following error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target This error is gone when I add server's CA certificate to jre certificate store. Is there any way that I can add server's CA certificate to server.truststore and make do with it? Please help -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5332) [DMN Designer] Unable to open BKM editor

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5332?page=com.atlassian.jira.plug... ] Guilherme Gomes reassigned DROOLS-5332: --------------------------------------- Assignee: Valentino Pellegrino (was: Guilherme Gomes) > [DMN Designer] Unable to open BKM editor > ----------------------------------------- > > Key: DROOLS-5332 > URL: https://issues.redhat.com/browse/DROOLS-5332 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Valentino Pellegrino > Priority: Major > Labels: drools-tools > > Using the referenced file: > https://kiegroup.github.io/kogito-online/?file=https://gist.githubusercon... > The User is unable to edit the Business Knowledge Model nodes for the following nodes: > - Risk Rating for Last Transaction Amount > - Risk Rating for last 24 hours Transactions > The {{kogito-tooling}} version reports the following to the console. > {code} > Error: JavaScriptException: (TypeError) : Cannot read property 'd' of null > at Xys (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:30330) > at tes.a6r [as FW] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31966) > at Ist (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:27657) > at ntt.ptt [as yW] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31973) > at Q4r (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:29779) > at roy.soy [as J7] (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:31999) > at _Vr (/kogito-online/org.kie.workbench.common.dmn.showcase.DMNKogitoRuntimeWebapp-0.js:13043) > {code} > Sorry I have no debugged myself further. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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 May 2020