[JBoss JIRA] (ELY-1132) Unable to load passwords from wildfly-config.xml
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/ELY-1132?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on ELY-1132:
-------------------------------------
Full trace is below. Is there any reason that this can't be hard coded to use the Elytron provider? Is there any use case for a different clear text password provider?
java.lang.ExceptionInInitializerError
at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
at org.wildfly.httpclient.common.HttpTargetContext.acquireSessionAffinity(HttpTargetContext.java:110)
at org.wildfly.httpclient.common.HttpTargetContext.acquireAffinitiy(HttpTargetContext.java:101)
at org.wildfly.httpclient.common.HttpTargetContext.init(HttpTargetContext.java:95)
at org.wildfly.httpclient.common.WildflyHttpContext.getConnectionPoolForURI(WildflyHttpContext.java:116)
at org.wildfly.httpclient.common.WildflyHttpContext.getTargetContext(WildflyHttpContext.java:93)
at org.wildfly.httpclient.ejb.SimpleInvocationTestCase.clearSessionId(SimpleInvocationTestCase.java:194)
at org.wildfly.httpclient.ejb.SimpleInvocationTestCase.testSimpleSSLInvocationViaURLAffinity(SimpleInvocationTestCase.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.wildfly.httpclient.common.HTTPTestServer.run(HTTPTestServer.java:153)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01133: Failed to create credential
at file:/Users/stuart/workspace/wildfly-http-client/ejb/target/test-classes/wildfly-config.xml:65:68
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
... 34 more
Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01133: Failed to create credential
at file:/Users/stuart/workspace/wildfly-http-client/ejb/target/test-classes/wildfly-config.xml:65:68
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$47(ElytronXmlParser.java:2012)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1321)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$45(ElytronXmlParser.java:1337)
at org.wildfly.security.auth.client.ElytronXmlParser$PrivateKeyKeyStoreEntryCredentialFactory.get(ElytronXmlParser.java:2398)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$5(ElytronXmlParser.java:459)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$6(ElytronXmlParser.java:501)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:537)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:309)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
... 36 more
Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$47(ElytronXmlParser.java:2009)
... 46 more
> Unable to load passwords from wildfly-config.xml
> ------------------------------------------------
>
> Key: ELY-1132
> URL: https://issues.jboss.org/browse/ELY-1132
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Stuart Douglas
> Assignee: Darran Lofthouse
>
> I see the following exception, adding use-service-loader-providers does not help
> Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
> at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseClearPassword$47(ElytronXmlParser.java:2009)
> ... 46 more
> Looks like this should just be hard coded to use the Elytron provider?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-983) WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-983?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek reopened ELY-983:
-----------------------------
It still needs a fix in {{ExternalSaslServerFactory}}. I'll send a new PR.
> WildFlySasl.MECHANISM_QUERY_ALL is taken into account in ExternalSasl*Factory.createSasl* methods
> -------------------------------------------------------------------------------------------------
>
> Key: ELY-983
> URL: https://issues.jboss.org/browse/ELY-983
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta37
>
>
> The description of {{MECHANISM_QUERY_ALL}} filtering property says:
> {quote}
> This flag is only effective on calls to SaslServerFactory.getMechanismNames(Map) or SaslClientFactory.getMechanismNames(Map) for Elytron-provided SASL factories.
> {quote}
> It's not true for EXTERNAL SASL mechanism factories, where it's taken into account also in {{createSaslServer/Client}} methods.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Ariel Carrera commented on WFLY-8706:
-------------------------------------
Sorry I think maybe it can be a problem in the environment with the jgroups configuration. I am checking that.
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2768) There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2768?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2768:
------------------------------------------
This means the OperationStepHandlers for this are not taking the necessary steps to prevent concurrent execution.
Most likely the OSH is doing this
context.getServiceRegistry(false)
when it should be
context.getServiceRegistry(true)
The 'modify' param must be 'true' if the thread will make any sort of modification to any object accessed via that call -- the ServiceRegistry, any ServiceController or other MSC object obtained from it, as well as the Service and the value object read from the ServiceController. In this case the value object being the CredentialStore. The meaning of that 'modify' param *is not limited to modifications to the service registry itself*.
> There is ConcurrentModificationException when we write new aliases to one credential store resource through multiple threads (management clients)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2768
> URL: https://issues.jboss.org/browse/WFCORE-2768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> There is ConcurrentModificationException when
> we write new aliases to one credential store resource through multiple threads (management clients)
> *Use case:*
> More users are connected through CLI to same application server and work parallel with same credential store resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8695) WeldPortableExtensionProcessor does not clear registered Extensions on undeploy()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8695?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-8695:
---------------------------------
Summary: WeldPortableExtensionProcessor does not clear registered Extensions on undeploy() (was: DUP leaks on undeploy causing WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default)
> WeldPortableExtensionProcessor does not clear registered Extensions on undeploy()
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8695
> URL: https://issues.jboss.org/browse/WFLY-8695
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
>
> {noformat}
> 20:11:08,590 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0003: node1 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service
> 20:11:08,594 INFO [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".installer service
> 20:11:08,603 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel server: [node1|4] (1) [node1]
> ...
> 20:11:08,794 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) WFLYCLINF0002: Started clusterbench-ee7-singleton-jbossall.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 20:11:08,837 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
> at injection point [UnbackedAnnotatedField] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> at org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator(ValidationInterceptor.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:362)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
> at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:539)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:78)
> at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:76)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Ariel Carrera updated WFLY-8706:
--------------------------------
Steps to Reproduce:
1-config a wildfly domain environment
2-config a group with the "ha profile"
3-start server group
4-add a singleton deploment and assign it to the server group
5-enable deployment and check server logs
was:
1-config a wildfly domain environment
2-config a group with the "ha profile"
3-start servers
4-add a singleton deploment and assign to the server group
5-enable deployment and check server logs
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months