May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-18) Add constructor and factory methods to AgroalDatasource that take AgroalListener as parameter

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-18?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-18. ----------------------------- Fix Version/s: 0.2 Resolution: Done > Add constructor and factory methods to AgroalDatasource that take AgroalListener as parameter > --------------------------------------------------------------------------------------------- > > Key: AG-18 > URL: https://issues.jboss.org/browse/AG-18 > Project: Agroal > Issue Type: Task > Components: api > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (AG-17) Deprecate PrefillMode and introduce initialSize

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-17?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-17. ----------------------------- Fix Version/s: 0.2 Resolution: Done > Deprecate PrefillMode and introduce initialSize > ----------------------------------------------- > > Key: AG-17 > URL: https://issues.jboss.org/browse/AG-17 > Project: Agroal > Issue Type: Task > Components: api > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (AG-19) Implement integration with JBoss Threads for interrupt protection

by Luis Barreiro (JIRA)

Luis Barreiro created AG-19: ------------------------------- Summary: Implement integration with JBoss Threads for interrupt protection Key: AG-19 URL: https://issues.jboss.org/browse/AG-19 Project: Agroal Issue Type: Task Components: jboss-threads Reporter: Luis Barreiro Assignee: Luis Barreiro -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-988?page=com.atlassian.jira.plugin.sy... ] Chao Wang reassigned ELY-988: ----------------------------- Assignee: Chao Wang (was: Darran Lofthouse) > Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly > --------------------------------------------------------------------------------------- > > Key: ELY-988 > URL: https://issues.jboss.org/browse/ELY-988 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Chao Wang > Priority: Critical > > According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. > In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: > * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created > * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created > Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[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)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8708) Move standalone-load-balancer.xml to the config dir

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8708?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-10762 to WFLY-8708: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8708 (was: JBEAP-10762) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Move standalone-load-balancer.xml to the config dir > --------------------------------------------------- > > Key: WFLY-8708 > URL: https://issues.jboss.org/browse/WFLY-8708 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8708) Move standalone-load-balancer.xml to the config dir

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8708?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8708: ------------------------------------ Assignee: Stuart Douglas > Move standalone-load-balancer.xml to the config dir > --------------------------------------------------- > > Key: WFLY-8708 > URL: https://issues.jboss.org/browse/WFLY-8708 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8707) Add bom for legacy compatibility library, and tests to verify usage

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-8707?page=com.atlassian.jira.plugin.... ] Jason Greene moved JBEAP-10760 to WFLY-8707: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8707 (was: JBEAP-10760) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Fix Version/s: 11.0.0.Beta1 (was: 7.1.0.DR18) > Add bom for legacy compatibility library, and tests to verify usage > ------------------------------------------------------------------- > > Key: WFLY-8707 > URL: https://issues.jboss.org/browse/WFLY-8707 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Jason Greene > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[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)

9 years

1
0
0 / 0

[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)

9 years

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 May 2017