February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE TS

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-2294: ---------------------------------- Description: Improve timeouts in WF-CORE TS * SuspendResumeTestCase.java should use TimeoutUtil for timeout * Parametrize timeouts in TestRunner * CliProcessWrapper.java should use TimeoutUtil for timeout was: Use TimeoutUtil in TS * SuspendResumeTestCase.java should use TimeoutUtil for timeout * Parametrize timeouts in TestRunner * CliProcessWrapper.java should use TimeoutUtil for timeout > Improve timeouts in WF-CORE TS > ------------------------------ > > Key: WFCORE-2294 > URL: https://issues.jboss.org/browse/WFCORE-2294 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Improve timeouts in WF-CORE TS > * SuspendResumeTestCase.java should use TimeoutUtil for timeout > * Parametrize timeouts in TestRunner > * CliProcessWrapper.java should use TimeoutUtil for timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE TS

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-2294: ---------------------------------- Summary: Improve timeouts in WF-CORE TS (was: Use TimeoutUtil in TS) > Improve timeouts in WF-CORE TS > ------------------------------ > > Key: WFCORE-2294 > URL: https://issues.jboss.org/browse/WFCORE-2294 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Use TimeoutUtil in TS > * SuspendResumeTestCase.java should use TimeoutUtil for timeout > * Parametrize timeouts in TestRunner > * CliProcessWrapper.java should use TimeoutUtil for timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2294) Use TimeoutUtil in TS

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-2294: ---------------------------------- Description: Use TimeoutUtil in TS * SuspendResumeTestCase.java should use TimeoutUtil for timeout * Parametrize timeouts in TestRunner * CliProcessWrapper.java should use TimeoutUtil for timeout was: Use TimeoutUtil in TS * SuspendResumeTestCase.java should use TimeoutUtil for timeout * TestRunner should use TimeoutUtil for timeout * CliProcessWrapper.java should use TimeoutUtil for timeout > Use TimeoutUtil in TS > --------------------- > > Key: WFCORE-2294 > URL: https://issues.jboss.org/browse/WFCORE-2294 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Use TimeoutUtil in TS > * SuspendResumeTestCase.java should use TimeoutUtil for timeout > * Parametrize timeouts in TestRunner > * CliProcessWrapper.java should use TimeoutUtil for timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8107) Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)

by Martin Choma (JIRA)

Martin Choma created WFLY-8107: ---------------------------------- Summary: Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron) Key: WFLY-8107 URL: https://issues.jboss.org/browse/WFLY-8107 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered. {code:java} private X509Certificate getClientCertificate() throws SaslException { if ((clientCertChain != null) && (clientCertChain.length > 0)) { return clientCertChain[0]; } else if (clientCertUrl != null) { try { return EntityUtil.getCertificateFromUrl(clientCertUrl); } catch (IOException e) { throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException(); } } else { throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException(); } } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8106) Coverity static analysis, Dereference null return value, CredentialStoreAliasDefinition (elytron-subsystem)

by Martin Choma (JIRA)

Martin Choma created WFLY-8106: ---------------------------------- Summary: Coverity static analysis, Dereference null return value, CredentialStoreAliasDefinition (elytron-subsystem) Key: WFLY-8106 URL: https://issues.jboss.org/browse/WFLY-8106 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Coverity found 2 possible occurences of dereferencing null. Method {{propertyAliasFromOperation(final ModelNode operation)}} can return null. And return value of {{propertyAliasFromOperation(final ModelNode operation)}} is dereferenced in {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}} {code:java} private static void transformOperationAddress(final ModelNode operation) { Property alias = propertyAliasFromOperation(operation); String newAlias = alias.getValue().asString().toLowerCase(Locale.ROOT); alias.getValue().set(newAlias); } private static boolean sameAlias(final OperationContext context, final ModelNode operation) { String contextAlias = context.getCurrentAddress().getLastElement().getValue(); String operationAlias = propertyAliasFromOperation(operation).getValue().asString(); return operationAlias.equals(contextAlias); } private static Property propertyAliasFromOperation(final ModelNode operation) { ModelNode address = operation.get(ModelDescriptionConstants.OP_ADDR); List<Property> list = address.asPropertyList(); Property alias = null; for (Property p: list) { if (ElytronDescriptionConstants.ALIAS.equals(p.getName())) { alias = p; break; } } return alias; } {code} Add null check into {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2294) Use TimeoutUtil in TS

by Marek Kopecký (JIRA)

Marek Kopecký created WFCORE-2294: ------------------------------------- Summary: Use TimeoutUtil in TS Key: WFCORE-2294 URL: https://issues.jboss.org/browse/WFCORE-2294 Project: WildFly Core Issue Type: Enhancement Components: Test Suite Reporter: Marek Kopecký Assignee: Marek Kopecký Use TimeoutUtil in TS * SuspendResumeTestCase.java should use TimeoutUtil for timeout * TestRunner should use TimeoutUtil for timeout * CliProcessWrapper.java should use TimeoutUtil for timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8105) Distributed workmanager can only be removed in admin-only mode

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-8105: -------------------------------- Component/s: (was: CLI) > Distributed workmanager can only be removed in admin-only mode > -------------------------------------------------------------- > > Key: WFLY-8105 > URL: https://issues.jboss.org/browse/WFLY-8105 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Janík > Assignee: Stefano Maestri > > See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode. > It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload. > Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8105) Distributed workmanager can only be removed in admin-only mode

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.... ] Richard Janík moved JBEAP-8815 to WFLY-8105: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8105 (was: JBEAP-8815) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI JCA (was: JCA) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR11) > Distributed workmanager can only be removed in admin-only mode > -------------------------------------------------------------- > > Key: WFLY-8105 > URL: https://issues.jboss.org/browse/WFLY-8105 > Project: WildFly > Issue Type: Bug > Components: CLI, JCA > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Janík > Assignee: Stefano Maestri > > See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode. > It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8105) Distributed workmanager can only be removed in admin-only mode

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-8105: -------------------------------- Description: See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode. It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload. Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff was: See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode. It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload. > Distributed workmanager can only be removed in admin-only mode > -------------------------------------------------------------- > > Key: WFLY-8105 > URL: https://issues.jboss.org/browse/WFLY-8105 > Project: WildFly > Issue Type: Bug > Components: CLI, JCA > Affects Versions: 11.0.0.Alpha1 > Reporter: Richard Janík > Assignee: Stefano Maestri > > See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode. > It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload. > Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8104) Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem)

by Martin Choma (JIRA)

Martin Choma created WFLY-8104: ---------------------------------- Summary: Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) Key: WFLY-8104 URL: https://issues.jboss.org/browse/WFLY-8104 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Coverity found 2 possible occurences of dereferencing null. https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644... https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644... {code:java} private char[] resolvePassword() throws Exception { ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue(); CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null; if (cs != null) { return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword(); } else { throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath()); } } {code} Both {{getCredential(Class<C> credentialType)}} and {{getPassword(Class<P> type)}} have in javadoc mentioned return value can be null. Also in org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder.SimpleDirContextFactory.obtainDirContext(org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode) returned value are explicitely checked on null value. Add null check also in {{resolvePassword()}} method -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017