June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-86) Adjust REST API Client in MgmtSystem

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-86?page=com.atlassian.jira.plu... ] Hayk Hovsepyan commented on HAWKULARQE-86: ------------------------------------------ PR https://github.com/ManageIQ/wrapanapi/pull/124 sent and merged > Adjust REST API Client in MgmtSystem > ------------------------------------ > > Key: HAWKULARQE-86 > URL: https://issues.jboss.org/browse/HAWKULARQE-86 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Move all Hawkular Inventory REST API calls into Hawkular Metrics. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-86) Adjust REST API Client in MgmtSystem

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-86?page=com.atlassian.jira.plu... ] Hayk Hovsepyan resolved HAWKULARQE-86. -------------------------------------- Resolution: Done > Adjust REST API Client in MgmtSystem > ------------------------------------ > > Key: HAWKULARQE-86 > URL: https://issues.jboss.org/browse/HAWKULARQE-86 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Move all Hawkular Inventory REST API calls into Hawkular Metrics. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-85) Inventory goes into Metrics

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-85?page=com.atlassian.jira.plu... ] Hayk Hovsepyan resolved HAWKULARQE-85. -------------------------------------- Resolution: Done PR https://github.com/ManageIQ/wrapanapi/pull/124 is merged > Inventory goes into Metrics > --------------------------- > > Key: HAWKULARQE-85 > URL: https://issues.jboss.org/browse/HAWKULARQE-85 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Hawkular Inventory will not exist anymore, it will be moved into Hawkular Metrics. > So Hawkular Services will not contain Inventory anymore. > Action items are in subtasks. > Should be done for Upstream Hawkular Services for the first. > Then it is expected that it will be included into downstream ER2 build. > It is important that our Manual Testcases and automation tests catch all bugs in upstream, before receive it in ER2, as in ER2 and any further releases we would not have much time to do full regression testing. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2929) Missing default values in ldap-key-store description in management model.

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2929?page=com.atlassian.jira.plugi... ] Yeray Borges moved WFLY-7664 to WFCORE-2929: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2929 (was: WFLY-7664) Component/s: Security (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) Fix Version/s: (was: 11.0.0.Beta1) > Missing default values in ldap-key-store description in management model. > ------------------------------------------------------------------------- > > Key: WFCORE-2929 > URL: https://issues.jboss.org/browse/WFCORE-2929 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Yeray Borges > Labels: user_experience > > Some attributes of Elytron {{ldap-key-store}} resource have defined some default value, but description of these attributes in CLI is missing default values. According to XSD following attributes of {{ldap-key-store}} have assigned some default value: > * {{search-recursive}} has default value {{true}} > * {{search-time-limit}} has default value {{10000}} > * {{filter-alias}} has default value {{(alias-attribute=\{0\})}} > * {{filter-certificate}} has default value {{(certificate-attribute=\{0\})}} > * {{filter-iterate}} has default value {{(alias-attribute=*)}} > * {{alias-attribute}} has default value {{cn}} > * {{certificate-attribute}} has default value {{usercertificate}} > * {{certificate-type}} has default value {{X.509}} > * {{certificate-chain-attribute}} has default value {{userSMIMECertificate}} > * {{certificate-chain-encoding}} has default value {{PKCS7}} > * {{key-attribute}} has default value {{userPKCS12}} > * {{key-type}} has default value {{PKCS12}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1605) Ability to run TCK tests during DMN build

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1605?page=com.atlassian.jira.plugi... ] Tibor Zimányi resolved DROOLS-1605. ----------------------------------- Resolution: Done > Ability to run TCK tests during DMN build > ----------------------------------------- > > Key: DROOLS-1605 > URL: https://issues.jboss.org/browse/DROOLS-1605 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.1.0.Beta2 > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Fix For: 7.1.0.Beta3 > > > We should be able to run DMN-TCK tests as part of our build, so we can quickly find bugs and compliance problems while developing new features. > I will provide PR for this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8906) Cache containers w/out JGroups transport should start on-demand

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8906: ---------------------------------- Summary: Cache containers w/out JGroups transport should start on-demand Key: WFLY-8906 URL: https://issues.jboss.org/browse/WFLY-8906 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 11.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Most infinispan services are configured to start passively - since Infinispan requires its cache container to start when the associated JGroups channel is started. However, local cache containers (i.e. containing only local caches and no associated JGroups transport) do not have this limitation, and should thus start as on-demand. This should help reduce WF's startup memory footprint. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1606) Error: "write size larger than buffer can fit" when running test scenario in workbench

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1606?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1606: ------------------------------------- Assignee: Toni Rikkola (was: Edson Tirelli) > Error: "write size larger than buffer can fit" when running test scenario in workbench > -------------------------------------------------------------------------------------- > > Key: DROOLS-1606 > URL: https://issues.jboss.org/browse/DROOLS-1606 > Project: Drools > Issue Type: Bug > Components: kie server, tools > Affects Versions: 6.5.0.Final > Environment: KIE Drools Workbench - Distribution Wars-Version: 6.5.0.Final > Apache Tomcat 9.0 (CLI startup), Windows 7 x64 > H2 database > Reporter: Russell Morrisey > Assignee: Toni Rikkola > Attachments: KIE WB write size error.png, KIE test scenario.png > > > When I run a test scenario in the KIE Workbench, the test scenario completes normally, but after it's completed, I get a pop-up error dialog: > _Unable to complete your request. The following exception occurred: write size larger than buffer can fit._ > This looks like it may(?) be related to: > https://issues.jboss.org/browse/RHBPMS-1475 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2926) CLI class doesn't allow to disable errorOnInteract flag

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2926?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2926: ----------------------------------------- Description: This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. CommandContextConfiguration is located in the imply package although it is exposed from public API CommandContextFactory. It is already part of the public API. was: This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. CommandContextConfiguration being located in the impl package, it should be moved to the API package. > CLI class doesn't allow to disable errorOnInteract flag > ------------------------------------------------------- > > Key: WFCORE-2926 > URL: https://issues.jboss.org/browse/WFCORE-2926 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Critical > > This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. > In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. > CommandContextConfiguration is located in the imply package although it is exposed from public API CommandContextFactory. It is already part of the public API. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2926) CLI class doesn't allow to disable errorOnInteract flag

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2926?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2926: ----------------------------------------- Description: This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. CommandContextConfiguration is located in the impl package although it is exposed from public API CommandContextFactory. It is already part of the public API. was: This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. CommandContextConfiguration is located in the imply package although it is exposed from public API CommandContextFactory. It is already part of the public API. > CLI class doesn't allow to disable errorOnInteract flag > ------------------------------------------------------- > > Key: WFCORE-2926 > URL: https://issues.jboss.org/browse/WFCORE-2926 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Critical > > This flag has been introduced in 7.0. It is enabled by default, CLI class should have been updated to disable it by default. > In addition a connect(CommandContextConfiguration config) API should be added to the CLI class to allow for full control on the CommandContext configuration. > CommandContextConfiguration is located in the impl package although it is exposed from public API CommandContextFactory. It is already part of the public API. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1233) Elytron revise why exception stacktrace is not logged in some cases

by Martin Choma (JIRA)

Martin Choma created ELY-1233: --------------------------------- Summary: Elytron revise why exception stacktrace is not logged in some cases Key: ELY-1233 URL: https://issues.jboss.org/browse/ELY-1233 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical During verification of JBEAP-9297 I have found another occurences where logging should be justified. In some cases not logging exception can hide original cause of problem. But justification is necessary if extending loggin won't introduce unnecessary logs, but it does not seems to me this should be case. {code} [mchoma@localhost wildfly-elytron]$ grep -r ".*\.debug([^\"]" --include=*.java . ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e); ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e); ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e); ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e); ./src/main/java/org/wildfly/security/http/util/SecurityProviderServerMechanismFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/http/util/SecurityProviderServerMechanismFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/http/util/ServiceLoaderServerMechanismFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/http/util/ServiceLoaderServerMechanismFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslClientFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslClientFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslServerFactory.java: log.debug(e); ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslServerFactory.java: log.debug(e); [mchoma@localhost wildfly-elytron]$ grep -r ".*\.trace([^\"]" --include=*.java . ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b); ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b); ./src/main/java/org/wildfly/security/http/impl/DigestAuthenticationMechanism.java: log.trace(e); {code} These are OK {code} ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b); ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b); {code} Setting to Critical priority, as this could reveal useful information during process of troubleshooting. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 June 2017