January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml

by Chris Giddings (JIRA)

[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ] Chris Giddings updated WFLY-9681: --------------------------------- Labels: JDBC JP (was: JDBC) > Deleting ExampleDS Leaves Remnants in standalone.xml > ---------------------------------------------------- > > Key: WFLY-9681 > URL: https://issues.jboss.org/browse/WFLY-9681 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.Final > Reporter: Chris Giddings > Assignee: Stefano Maestri > Priority: Minor > Labels: JDBC > > h2. SUMMARY > When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS". > When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode. > h2. WORKAROUND > Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found) > h2. BUG JUSTIFICATION > # I would expect anything labeled as "Example" to be deleted by an administrator in most environments > # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml

by Chris Giddings (JIRA)

[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ] Chris Giddings updated WFLY-9681: --------------------------------- Labels: JDBC (was: JDBC JP) > Deleting ExampleDS Leaves Remnants in standalone.xml > ---------------------------------------------------- > > Key: WFLY-9681 > URL: https://issues.jboss.org/browse/WFLY-9681 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.Final > Reporter: Chris Giddings > Assignee: Stefano Maestri > Priority: Minor > Labels: JDBC > > h2. SUMMARY > When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS". > When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode. > h2. WORKAROUND > Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found) > h2. BUG JUSTIFICATION > # I would expect anything labeled as "Example" to be deleted by an administrator in most environments > # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves Remnants in standalone.xml

by Chris Giddings (JIRA)

[ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.... ] Chris Giddings commented on WFLY-9681: -------------------------------------- [~jaikiran], The error posted (from StackOverflow) is not my own, but mine is nearly identical. For the WAR file I'm attempting to deploy myself, yes. Rather prolifically. I'm currently running a POC to transition our applications from Tomcat 8 to Wildfly (11 Final) for easier cluster and HA management. > Deleting ExampleDS Leaves Remnants in standalone.xml > ---------------------------------------------------- > > Key: WFLY-9681 > URL: https://issues.jboss.org/browse/WFLY-9681 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.Final > Reporter: Chris Giddings > Assignee: Stefano Maestri > Priority: Minor > Labels: JDBC > > h2. SUMMARY > When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS". > When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode. > h2. WORKAROUND > Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found) > h2. BUG JUSTIFICATION > # I would expect anything labeled as "Example" to be deleted by an administrator in most environments > # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage

by David Lloyd (JIRA)

David Lloyd created ELY-1490: -------------------------------- Summary: Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage Key: ELY-1490 URL: https://issues.jboss.org/browse/ELY-1490 Project: WildFly Elytron Issue Type: Bug Components: Testsuite Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.2.0.Beta12 The error is: {noformat} [ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest) Time elapsed: 0.053 s <<< ERROR! java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size at java.base/java.security.Signature$Delegate.init(Signature.java:1178) at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138) at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202) at java.base/java.security.Signature.initSign(Signature.java:545) at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426) {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1490?page=com.atlassian.jira.plugin.s... ] David Lloyd updated ELY-1490: ----------------------------- Labels: Java9 (was: ) > Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage > --------------------------------------------------------------- > > Key: ELY-1490 > URL: https://issues.jboss.org/browse/ELY-1490 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Reporter: David Lloyd > Assignee: David Lloyd > Labels: Java9 > Fix For: 1.2.0.Beta12 > > > The error is: > {noformat} > [ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest > [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest) Time elapsed: 0.053 s <<< ERROR! > java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size > at java.base/java.security.Signature$Delegate.init(Signature.java:1178) > at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138) > at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202) > at java.base/java.security.Signature.initSign(Signature.java:545) > at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-9702: -------------------------------------- Summary: SSO Integration for Programmatic Authentication Key: WFLY-9702 URL: https://issues.jboss.org/browse/WFLY-9702 Project: WildFly Issue Type: Bug Components: Clustering, Security, Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 12.0.0.Alpha1 At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. In this scenario we don't have either a wrapped mechanism or a CallbackHandler. Couple of options: - * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. * -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-9702: ----------------------------------- Priority: Critical (was: Major) > SSO Integration for Programmatic Authentication > ----------------------------------------------- > > Key: WFLY-9702 > URL: https://issues.jboss.org/browse/WFLY-9702 > Project: WildFly > Issue Type: Bug > Components: Clustering, Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. > In this scenario we don't have either a wrapped mechanism or a CallbackHandler. > Couple of options: - > * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. > * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? > * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. > * -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3487) ValueTypeCompletionTestCase test renaming

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3487?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3487: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3017 > ValueTypeCompletionTestCase test renaming > ----------------------------------------- > > Key: WFCORE-3487 > URL: https://issues.jboss.org/browse/WFCORE-3487 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 4.0.0.Alpha5 > Reporter: Miroslav Novak > Assignee: Miroslav Novak > Priority: Optional > > ValueTypeCompletionTestCase contains test names which does not imply what the test is doing. Rename those tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3515) Tests for enhanced CLI to support Aesh Commands

by Marek Kopecký (JIRA)

Marek Kopecký created WFCORE-3515: ------------------------------------- Summary: Tests for enhanced CLI to support Aesh Commands Key: WFCORE-3515 URL: https://issues.jboss.org/browse/WFCORE-3515 Project: WildFly Core Issue Type: Task Reporter: Marek Kopecký Tests for enhanced CLI to support Aesh Commands -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3515) Tests for enhanced CLI to support Aesh Commands

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3515?page=com.atlassian.jira.plugi... ] Marek Kopecký reassigned WFCORE-3515: ------------------------------------- Assignee: Marek Kopecký > Tests for enhanced CLI to support Aesh Commands > ----------------------------------------------- > > Key: WFCORE-3515 > URL: https://issues.jboss.org/browse/WFCORE-3515 > Project: WildFly Core > Issue Type: Task > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > Tests for enhanced CLI to support Aesh Commands -- 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 January 2018