April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9618) Record and report stack trace of setRollbackOnly() calls

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9618?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-9618: --------------------------------- Assignee: David Lloyd > Record and report stack trace of setRollbackOnly() calls > -------------------------------------------------------- > > Key: WFLY-9618 > URL: https://issues.jboss.org/browse/WFLY-9618 > Project: WildFly > Issue Type: Enhancement > Components: EJB, Transactions > Reporter: David Lloyd > Assignee: David Lloyd > > We should track the stack trace of the first, or of each, caller of setRollbackOnly(), and if the transaction ultimately throws RollbackException or similar, we can add the stack trace as a cause. If multiple calls are done, then the latest should be the cause and the earlier should show up as suppressed exceptions. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-192) Add ability to limit number of suppressed exceptions displayed

by David Lloyd (JIRA)

David Lloyd created LOGMGR-192: ---------------------------------- Summary: Add ability to limit number of suppressed exceptions displayed Key: LOGMGR-192 URL: https://issues.jboss.org/browse/LOGMGR-192 Project: JBoss Log Manager Issue Type: Enhancement Reporter: David Lloyd Priority: Minor We probably need some way for the user to limit, or even disable, suppressed exceptions. The list could grow very very large otherwise. Maybe a formatter parameter would work. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Matt Mahoney commented on SWSQE-93: ----------------------------------- +1 on #2 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3728) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3728?page=com.atlassian.jira.plugi... ] Ilia Vassilev commented on WFCORE-3728: --------------------------------------- [~dlofthouse] Please investigate the issue from Elytron perspective. I'm assigning the issue to you based on the latest finding from Ricardo on JBEAP-14534. Thanks! > DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-3728 > URL: https://issues.jboss.org/browse/WFCORE-3728 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.10.Final > Reporter: Ilia Vassilev > > After running the enable-elytron.cli and removing the old > picketbox security subsystem, the deployment fails as > it cannot find java:jboss/DefaultJMSConnectionFactory. > java:jboss/DefaultJMSConnectionFactory is defined in the messaging > subsystem and the ee default-bindings. > Removing it from the ee default-bindings lets the app deploy, but it looks like there is some > issue as it should be bound and no errors/warnings being logged. > {code} > 2018-04-02 12:15:36,593 ERROR > [org.jboss.as.controller.management-operation] (Controller Boot Thread) > WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => > "ejb-security.jar")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => > ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => > ["jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory > is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"] > } > 2018-04-02 12:15:36,603 INFO [org.jboss.as.server] (ServerService > Thread Pool -- 42) WFLYSRV0010: Deployed "ejb-security.jar" > (runtime-name : "ejb-security.jar") > 2018-04-02 12:15:36,607 INFO [org.jboss.as.controller] (Controller Boot > Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service > jboss.naming.context.java.jboss.DefaultJMSConnectionFactory (missing) > dependents: [service > jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3728) DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3728?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFCORE-3728: ------------------------------------- Assignee: Darran Lofthouse > DefaultJMSConnectionFactory not found after switching to elytron and removing picketbox subsystem > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-3728 > URL: https://issues.jboss.org/browse/WFCORE-3728 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.10.Final > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > > After running the enable-elytron.cli and removing the old > picketbox security subsystem, the deployment fails as > it cannot find java:jboss/DefaultJMSConnectionFactory. > java:jboss/DefaultJMSConnectionFactory is defined in the messaging > subsystem and the ee default-bindings. > Removing it from the ee default-bindings lets the app deploy, but it looks like there is some > issue as it should be bound and no errors/warnings being logged. > {code} > 2018-04-02 12:15:36,593 ERROR > [org.jboss.as.controller.management-operation] (Controller Boot Thread) > WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => > "ejb-security.jar")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => > ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => > ["jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory > is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"] > } > 2018-04-02 12:15:36,603 INFO [org.jboss.as.server] (ServerService > Thread Pool -- 42) WFLYSRV0010: Deployed "ejb-security.jar" > (runtime-name : "ejb-security.jar") > 2018-04-02 12:15:36,607 INFO [org.jboss.as.controller] (Controller Boot > Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service > jboss.naming.context.java.jboss.DefaultJMSConnectionFactory (missing) > dependents: [service > jboss.naming.context.java.comp.ejb-security.ejb-security.SecuredEJB.DefaultJMSConnectionFactory] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2454) [DMN Designer] Decision content not visible after reopen

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2454?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2454: ----------------------------------- Sprint: 2018 Week 13-14 > [DMN Designer] Decision content not visible after reopen > -------------------------------------------------------- > > Key: DROOLS-2454 > URL: https://issues.jboss.org/browse/DROOLS-2454 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Fix For: 7.8.0.Final > > Attachments: Screenshot from 2018-04-05 14-35-20.png, Screenshot from 2018-04-05 14-35-52.png > > > If the decision with bigger context table is reopened, its content is not visible. > h2. Acceptance test > In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. > # Steps to reproduce fixed > # Define top level as Literal expression, reopen > # Define top level as Decision table, add columns, reopen > # Define top level as Relation, add columns, reopen > # Define top level as Invocation, specify complex parameters, reopen > # Define top level as Function, add a lot of parameters, reopen > # Define top level as Context, recursively add more Contexts, reopen -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta edited comment on SWSQE-93 at 4/5/18 9:12 AM: ------------------------------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com is approved, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 was (Author: fbrychta): There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta edited comment on SWSQE-93 at 4/5/18 9:09 AM: ------------------------------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 was (Author: fbrychta): There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta commented on SWSQE-93: ------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-123) Rresearch - Find the source to get original data from

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-123: ------------------------------------ Summary: Rresearch - Find the source to get original data from Key: SWSQE-123 URL: https://issues.jboss.org/browse/SWSQE-123 Project: Kiali QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Rest API return data for graph in Json format. Research where is the original source of data and how to read that in automation framework. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 April 2018