June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-3450. ------------------------------------------ Resolution: Done We have colouring of required attributes. > CLI - avoid required attributes to be hard to see when using tab completion > ---------------------------------------------------------------------------- > > Key: WFCORE-3450 > URL: https://issues.jboss.org/browse/WFCORE-3450 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Miroslav Novak > Assignee: Ingo Weiss > > This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add( > ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier > allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors* > call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection > call-timeout connection-ttl max-hops notification-attempts retry-interval > {code} > it's not clear at the first look how many required attributes there are. > Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>. > Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-153) add flake8 support for Python framework

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-153?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy resolved SWSQE-153. ----------------------------------- Resolution: Done PR merged: https://github.com/Kiali-QE/kiali-qe-python/pull/45 support added via travis ci > add flake8 support for Python framework > --------------------------------------- > > Key: SWSQE-153 > URL: https://issues.jboss.org/browse/SWSQE-153 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > Right now there is no util to monitor Python automation code. If we follow flake8, will be beneficial for the long run. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-278) New test case: validate user menu

by Jeeva Kandasamy (JIRA)

Jeeva Kandasamy created SWSQE-278: ------------------------------------- Summary: New test case: validate user menu Key: SWSQE-278 URL: https://issues.jboss.org/browse/SWSQE-278 Project: Kiali QE Issue Type: QE Task Reporter: Jeeva Kandasamy Assignee: Jeeva Kandasamy Validate user menu on the navbar -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-277) New test case: invalid login test

by Jeeva Kandasamy (JIRA)

Jeeva Kandasamy created SWSQE-277: ------------------------------------- Summary: New test case: invalid login test Key: SWSQE-277 URL: https://issues.jboss.org/browse/SWSQE-277 Project: Kiali QE Issue Type: QE Task Reporter: Jeeva Kandasamy Assignee: Jeeva Kandasamy add new test case to validate invalid login -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-276) UI login code - take credentials from env.yaml

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-276?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy commented on SWSQE-276: --------------------------------------- PR sent: https://github.com/Kiali-QE/kiali-qe-python/pull/44 > UI login code - take credentials from env.yaml > ---------------------------------------------- > > Key: SWSQE-276 > URL: https://issues.jboss.org/browse/SWSQE-276 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > Currently, credentials are hardcoded on UI login code. > Take credentials from env.yaml -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-266) Update Istio Config page code

by Jeeva Kandasamy (JIRA)

[ https://issues.jboss.org/browse/SWSQE-266?page=com.atlassian.jira.plugin.... ] Jeeva Kandasamy resolved SWSQE-266. ----------------------------------- Resolution: Done PR merged > Update Istio Config page code > ----------------------------- > > Key: SWSQE-266 > URL: https://issues.jboss.org/browse/SWSQE-266 > Project: Kiali QE > Issue Type: QE Task > Reporter: Jeeva Kandasamy > Assignee: Jeeva Kandasamy > > Istio Config page has been modified. > Automation code needs to be updated -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Joni Syri (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Joni Syri commented on WFLY-9849: --------------------------------- I think the linked project is as close to a minimal as it gets :) No execution is necessary, re-deploying straight after first deployment finishes is enough to reproduce the issue. Build from the linked project can be found here: https://drive.google.com/file/d/1kOhmgTzcT4O9Kw-zYEXfXDBBuAkqFmPH/view?us... > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) > server.log https://drive.google.com/file/d/1I32OTnPWeopVEtRC3ol-pjkH2dlkLizD/view?us... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10491) Fix wildfly-capabilities repository representation on GitHub

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10491?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10491: ---------------------------------- Description: Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). The repo should have been *moved* to wildfly organization and not *forked*. This as a result has messed up all the previous forks, like https://github.com/rhusar/wildfly-capabilities which makes a poor usability from the UI, because it opens PRs against wrong repo by default. was: Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. The repo should have been *moved* to wildfly organization and not *forked*. This as a result has messed up all the previous forks, like https://github.com/rhusar/wildfly-capabilities which makes a poor usability from the UI, because it opens PRs against wrong repo by default. To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). > Fix wildfly-capabilities repository representation on GitHub > ------------------------------------------------------------ > > Key: WFLY-10491 > URL: https://issues.jboss.org/browse/WFLY-10491 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Radoslav Husar > Assignee: Brian Stansberry > Priority: Trivial > > Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. > To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). > The repo should have been *moved* to wildfly organization and not *forked*. This as a result has messed up all the previous forks, like https://github.com/rhusar/wildfly-capabilities which makes a poor usability from the UI, because it opens PRs against wrong repo by default. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10491) Fix wildfly-capabilities repository representation on GitHub

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10491?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10491: ---------------------------------- Description: Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. The repo should have been *moved* to wildfly organization and not *forked*. This as a result has messed up all the previous forks, like https://github.com/rhusar/wildfly-capabilities which makes a poor usability from the UI, because it opens PRs against wrong repo by default. To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). was: Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. The repo should have been *moved* to wildfly organization and not *forked*. To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). > Fix wildfly-capabilities repository representation on GitHub > ------------------------------------------------------------ > > Key: WFLY-10491 > URL: https://issues.jboss.org/browse/WFLY-10491 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Radoslav Husar > Assignee: Brian Stansberry > Priority: Trivial > > Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. > The repo should have been *moved* to wildfly organization and not *forked*. This as a result has messed up all the previous forks, like https://github.com/rhusar/wildfly-capabilities which makes a poor usability from the UI, because it opens PRs against wrong repo by default. > To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10491) Fix wildfly-capabilities repository representation on GitHub

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-10491: ------------------------------------- Summary: Fix wildfly-capabilities repository representation on GitHub Key: WFLY-10491 URL: https://issues.jboss.org/browse/WFLY-10491 Project: WildFly Issue Type: Task Components: Documentation Reporter: Radoslav Husar Assignee: Brian Stansberry Currently, the https://github.com/wildfly/wildfly-capabilities repository says its "forked from bstansberry/wildfly-capabilities". The common practice and understanding in community is that the upstream repository is the one that is not forked from any other repository. Thus having the upstream repository not represented as upstream is confusing. The repo should have been *moved* to wildfly organization and not *forked*. To remedy this, with a method we used in the past, is to delete the bstansberry/wildfly-capabilities repository (and then fork from wildfly of course). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2018