[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12429?page=com.atlassian.jira.plugin... ]
Richard Opalka commented on WFLY-12429:
---------------------------------------
Just FYI [~brian.stansberry] this issue is new regression on latest JDK13
> MockitoException in InfinispanBeanTestCase on latest JDK13
> ----------------------------------------------------------
>
> Key: WFLY-12429
> URL: https://issues.jboss.org/browse/WFLY-12429
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 18.0.0.Beta1
>
>
> [INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:
> Cannot call abstract real method on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by Richard Opalka (Jira)
Richard Opalka created WFLY-12429:
-------------------------------------
Summary: MockitoException in InfinispanBeanTestCase on latest JDK13
Key: WFLY-12429
URL: https://issues.jboss.org/browse/WFLY-12429
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Richard Opalka
Assignee: Paul Ferraro
Fix For: 18.0.0.Beta1
[INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
[ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
[ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
org.mockito.exceptions.base.MockitoException:
Cannot call abstract real method on java object!
Calling real methods is only possible when mocking non abstract method.
//correct example:
when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-944?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-944:
------------------------------------
Fix Version/s: 10.0.0.Beta5
(was: 10.0.0.Beta4)
> truststore path is ignored if provider is not JKS
> -------------------------------------------------
>
> Key: WFCORE-944
> URL: https://issues.jboss.org/browse/WFCORE-944
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Arto Huusko
> Priority: Major
> Fix For: 10.0.0.Beta5
>
>
> truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS.
> This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working.
> We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured.
> Even standard java supports PKCS12 truststores, where the same problem would occur.
> So I would suggest that
> - if provider is JKS, path is mandatory
> - if provider is not JKS, but path is specified, it is passed to the provider
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4227) Add the ability for the CLI SSL security commands to be able to obtain a server certificate from Let's Encrypt
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4227?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4227:
-------------------------------------
Fix Version/s: 10.0.0.Beta5
(was: 10.0.0.Beta4)
> Add the ability for the CLI SSL security commands to be able to obtain a server certificate from Let's Encrypt
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4227
> URL: https://issues.jboss.org/browse/WFCORE-4227
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Marek Marusic
> Assignee: Marek Marusic
> Priority: Major
> Fix For: 10.0.0.Beta5
>
>
> WFCORE-3447 introduced high-level security commands (ssl enable-ssl-management and ssl enable-ssl-http-server) for enabling one-way and two-way SSL easily. To generate the server certificate, these high-level security commands made use of key-store management operations to generate a self-signed certificate. Since it is now possible to obtain certificates from the Let's Encrypt certificate authority using the CLI, the high-level security commands should be updated so that in addition to being able to generate a self-signed server certificate, they can also obtain a server certificate from Let's Encrypt. Details on the new management operations for obtaining and managing certificates from Let's Encrypt can be found in the analysis document and in this blog post.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-3747) Enhance credential-store description related to location and type attributes
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-3747?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3747:
-------------------------------------
Fix Version/s: 10.0.0.Beta5
(was: 10.0.0.Beta4)
> Enhance credential-store description related to location and type attributes
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3747
> URL: https://issues.jboss.org/browse/WFCORE-3747
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 10.0.0.Beta5
>
>
> The description for "location" and "type" for credential-store resource is displayed below.
> Following discussion of WFCORE-3458, the "location" attribute is required only when the "type" is file based, but the description doesn't says that, the description may be improved to reflect this behavior and list the possible file based types.
> When the user doesn't set the "type" attribute it defaults to "JCEKS", but there is no "default" value on resource description for "type" attribute.
> {code}
> "location" => {
> "type" => STRING,
> "description" => "File name of credential store storage.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "type" => {
> "type" => STRING,
> "description" => "The credential store type, e.g. KeyStoreCredentialStore.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4447) Elytron: Ability to load the attributes of an identity from multiple sources
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4447?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4447:
-------------------------------------
Fix Version/s: 10.0.0.Beta5
(was: 10.0.0.Beta4)
> Elytron: Ability to load the attributes of an identity from multiple sources
> ----------------------------------------------------------------------------
>
> Key: WFCORE-4447
> URL: https://issues.jboss.org/browse/WFCORE-4447
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 10.0.0.Beta5
>
>
> In previous versions a {{security-domain}} was used to merge or add roles from multiple repositories. For example the roles for the users were obtained from two different ldaps and a database. All the roles were merged and the final authenticated principal belonged to all of them. The old picketbox subsystem used stacking of login modules (and password) to implement this feature. This use-case is not rare among the customers.
> This issue is avoiding migrations from the old security subsystem to elytron.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4407) Cannot configure Elytron security domain using embedded server in admin mode
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4407?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4407:
-------------------------------------
Fix Version/s: 10.0.0.Beta5
(was: 10.0.0.Beta4)
> Cannot configure Elytron security domain using embedded server in admin mode
> ----------------------------------------------------------------------------
>
> Key: WFCORE-4407
> URL: https://issues.jboss.org/browse/WFCORE-4407
> Project: WildFly Core
> Issue Type: Bug
> Components: Embedded
> Environment:
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
> Fix For: 10.0.0.Beta5
>
>
> There are some configurations that are impossible to do using the embedded server, for example, we cannot create a security domain in Elytron that references a security domain in the security subsystem:
> {noformat}
> embed-server --server-config=standalone-full-ha.xml --std-out=echo
> /subsystem=security/security-domain=my-sec-domain:add(cache-type=default)
> /subsystem=security/security-domain=my-sec-domain/authentication=classic:add(login-modules=[{code=RealmUsersRoles, flag=required, module=RealmUsersRoles, module-options=[("usersProperties"=>"usersProperties"),("rolesProperties"=>"rolesProperties")]}])
> /subsystem=security/elytron-realm=my-sec-domain:add(legacy-jaas-config=my-sec-domain)
> /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> stop-embedded-server
> {noformat}
> The execution of these operations in an embedded server running in admin-mode throws the following error:
> {noformat}
> [standalone@embedded /] /subsystem=elytron/security-domain=my-sec-domain:add(realms=[{realm=my-sec-domain}],default-realm=my-sec-domain,permission-mapper=default-permission-mapper)
> 12:30:53,429 ERROR [org.jboss.as.controller.management-operation] (pool-3-thread-1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "my-sec-domain")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> }
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.my-sec-domain"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.my-sec-domain.initial is missing [org.wildfly.security.security-realm.my-sec-domain]"]
> },
> "rolled-back" => true
> }
> {noformat}
> The problem here is Elytron security domain services cannot be up because they require the legacy installed realm services, which are not up when we are using embedded in admin-only mode.
> The SecurityDomain advertises no runtime operation, if no services are installed that would ever depend on security domain we may be able to skip installing some of these services entirely and allow their configuration in embedded / admin-only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months