November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1998) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1998?page=com.atlassian.jira.plugi... ] Osamu Nagano commented on WFCORE-1998: -------------------------------------- Changed the project to WFCORE and sent a pull request. Also added a comment to the discussion. > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFCORE-1998 > URL: https://issues.jboss.org/browse/WFCORE-1998 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 2.2.0.Final > Reporter: Osamu Nagano > Attachments: nameserviceProviderTest.zip > > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1998) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1998?page=com.atlassian.jira.plugi... ] Osamu Nagano moved WFLY-7354 to WFCORE-1998: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1998 (was: WFLY-7354) Component/s: Modules (was: Class Loading) Affects Version/s: 2.2.0.Final (was: 10.1.0.Final) > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFCORE-1998 > URL: https://issues.jboss.org/browse/WFCORE-1998 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 2.2.0.Final > Reporter: Osamu Nagano > Attachments: nameserviceProviderTest.zip > > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7608) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/WFLY-7608?page=com.atlassian.jira.plugin.... ] Osamu Nagano deleted WFLY-7608: ------------------------------- > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFLY-7608 > URL: https://issues.jboss.org/browse/WFLY-7608 > Project: WildFly > Issue Type: Bug > Reporter: Osamu Nagano > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7608) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Osamu Nagano (JIRA)

Osamu Nagano created WFLY-7608: ---------------------------------- Summary: Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly Key: WFLY-7608 URL: https://issues.jboss.org/browse/WFLY-7608 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 10.1.0.Final Reporter: Osamu Nagano System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. {code} <path name="sun/net/spi/nameservice"/> <path name="sun/net/spi/nameservice/dns"/> {code} Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2131: --------------------------- Fix Version/s: 3.6.12 4.0 > UNICAST3 drops all messages until it receives the first one > ----------------------------------------------------------- > > Key: JGRP-2131 > URL: https://issues.jboss.org/browse/JGRP-2131 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. > This causes UNICAST3.handleDataReceived to drop the message. > When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7584) Configuring more password type should be allowed for Elytron filesystem-realm identity in CLI

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7584?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7584: ------------------------------- Description: In case when two password type are part of {{set-password}} operation for identity of Elytron filesystem-realm then only first of them is used and others are discarded. Configuring multiple credentials for one identity should be supported [1]. [1] https://issues.jboss.org/browse/WFLY-7584?focusedCommentId=13322919&page=... was: It is possible to specify more types of password encryption/hash mechanism in {{set-password}} operation of filesystem-realm identity. When this happens then first password encryption/hash mechanism is correctly used, but the rest of them is discarded. However it make sense to have set only one password encryption/hash mechanism for identity. It can be confusing to allow CLI command with more types of password encryption/hash mechanism specified. Suggestion for improvement: Disallow to use set-password operation with more than one password encryption/hash mechanism. Summary: Configuring more password type should be allowed for Elytron filesystem-realm identity in CLI (was: User should be able to specify only one password type for Elytron filesystem-realm identity) > Configuring more password type should be allowed for Elytron filesystem-realm identity in CLI > --------------------------------------------------------------------------------------------- > > Key: WFLY-7584 > URL: https://issues.jboss.org/browse/WFLY-7584 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when two password type are part of {{set-password}} operation for identity of Elytron filesystem-realm then only first of them is used and others are discarded. Configuring multiple credentials for one identity should be supported [1]. > [1] https://issues.jboss.org/browse/WFLY-7584?focusedCommentId=13322919&page=... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7584) Configuring more password types should be allowed for Elytron filesystem-realm identity in CLI

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7584?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7584: ------------------------------- Summary: Configuring more password types should be allowed for Elytron filesystem-realm identity in CLI (was: Configuring more password type should be allowed for Elytron filesystem-realm identity in CLI) > Configuring more password types should be allowed for Elytron filesystem-realm identity in CLI > ---------------------------------------------------------------------------------------------- > > Key: WFLY-7584 > URL: https://issues.jboss.org/browse/WFLY-7584 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > In case when two password type are part of {{set-password}} operation for identity of Elytron filesystem-realm then only first of them is used and others are discarded. Configuring multiple credentials for one identity should be supported [1]. > [1] https://issues.jboss.org/browse/WFLY-7584?focusedCommentId=13322919&page=... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7584) User should be able to specify only one password type for Elytron filesystem-realm identity

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7584?page=com.atlassian.jira.plugin.... ] Ondrej Lukas commented on WFLY-7584: ------------------------------------ Thanks for clarification. I will update summary and description of this Jira. > User should be able to specify only one password type for Elytron filesystem-realm identity > ------------------------------------------------------------------------------------------- > > Key: WFLY-7584 > URL: https://issues.jboss.org/browse/WFLY-7584 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > > It is possible to specify more types of password encryption/hash mechanism in {{set-password}} operation of filesystem-realm identity. When this happens then first password encryption/hash mechanism is correctly used, but the rest of them is discarded. However it make sense to have set only one password encryption/hash mechanism for identity. It can be confusing to allow CLI command with more types of password encryption/hash mechanism specified. > Suggestion for improvement: > Disallow to use set-password operation with more than one password encryption/hash mechanism. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7354) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-7354?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on WFLY-7354: ------------------------------------ {quote} I suspect that you may have to use the boot classpath to make the provider work, but I'm not 100% sure. It may use TCCL in which case a module may work. {quote} A while back someone had asked a similar question on how to get this working and when I had checked the code, I did notice it was using TCCL. More details about that here https://developer.jboss.org/message/962941#962941 > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFLY-7354 > URL: https://issues.jboss.org/browse/WFLY-7354 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 10.1.0.Final > Reporter: Osamu Nagano > Attachments: nameserviceProviderTest.zip > > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7354) Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/WFLY-7354?page=com.atlassian.jira.plugin.... ] Osamu Nagano commented on WFLY-7354: ------------------------------------ I found the TCCL is ModuleClassLoader of "org.jboss.as.server:main". The name service class is loaded at boot time in an MSC thread. So jboss-deployment-structure.xml is not required but these 2 modules need to be modified. {code:title=$JBOSS_HOME/modules/**/org/jboss/as/server/main/module.xml} <module name="sun.jdk" services="export" export="true"/> {code} {code:title=$JBOSS_HOME/modules/**/sun/jdk/main/module.xml} <resource-root path="your_impl.jar"/> ... <path name="sun/net/spi/nameservice"/> <path name="sun/net/spi/nameservice/dns"/> {code} > Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly > -------------------------------------------------------------------------------- > > Key: WFLY-7354 > URL: https://issues.jboss.org/browse/WFLY-7354 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 10.1.0.Final > Reporter: Osamu Nagano > Attachments: nameserviceProviderTest.zip > > > System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies. > {code} > <path name="sun/net/spi/nameservice"/> > <path name="sun/net/spi/nameservice/dns"/> > {code} > Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 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 November 2016