[JBoss JIRA] (ISPN-10574) Off Heap iteration performance improvements
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10574?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10574:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.0.0.CR3
Resolution: Done
> Off Heap iteration performance improvements
> -------------------------------------------
>
> Key: ISPN-10574
> URL: https://issues.jboss.org/browse/ISPN-10574
> Project: Infinispan
> Issue Type: Enhancement
> Components: Off Heap
> Affects Versions: 10.0.0.CR1
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.CR3, 10.0.0.Final
>
>
> When testing out some things it was found that an off heap cache with a single entry compared to an object one takes significantly longer for state transfer. Off Heap can be improved to make iteration faster and thus improve things like state transfer.
> # Off Heap entries are stored using modulus for locks. This causes iteration to not access entries sequentially as well as having to acquire the same lock many times over.
> # Off Heap should optimize code paths that can be short circuited (ie. don't create stream if size is 0)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10723) JMX registration cleanup
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/ISPN-10723?page=com.atlassian.jira.plugin... ]
Nistor Adrian updated ISPN-10723:
---------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7402
> JMX registration cleanup
> ------------------------
>
> Key: ISPN-10723
> URL: https://issues.jboss.org/browse/ISPN-10723
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.CR1
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> - all jmx registration should happen via CacheManagerJmxRegistration/CacheJmxRegistration - we should not have other classes using JmxUtil.buildJmxDomain
> - there are very few legitimate direct usages of JmxUtil.lookupMBeanServer; all else must go
> - some registrations are not currently ResourceDMBeans; these need to be converted
> - use of registerExternalMBean should be converted to registerMBean
> - avoid performing the unregistration manually. Components registered with registerMBean will be unregistered automatically
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10723) JMX registration cleanup
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/ISPN-10723?page=com.atlassian.jira.plugin... ]
Nistor Adrian updated ISPN-10723:
---------------------------------
Status: Open (was: New)
> JMX registration cleanup
> ------------------------
>
> Key: ISPN-10723
> URL: https://issues.jboss.org/browse/ISPN-10723
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.CR1
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> - all jmx registration should happen via CacheManagerJmxRegistration/CacheJmxRegistration - we should not have other classes using JmxUtil.buildJmxDomain
> - there are very few legitimate direct usages of JmxUtil.lookupMBeanServer; all else must go
> - some registrations are not currently ResourceDMBeans; these need to be converted
> - use of registerExternalMBean should be converted to registerMBean
> - avoid performing the unregistration manually. Components registered with registerMBean will be unregistered automatically
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10723) JMX registration cleanup
by Nistor Adrian (Jira)
Nistor Adrian created ISPN-10723:
------------------------------------
Summary: JMX registration cleanup
Key: ISPN-10723
URL: https://issues.jboss.org/browse/ISPN-10723
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 10.0.0.CR1
Reporter: Nistor Adrian
Assignee: Nistor Adrian
Fix For: 10.0.0.CR3
- all jmx registration should happen via CacheManagerJmxRegistration/CacheJmxRegistration - we should not have other classes using JmxUtil.buildJmxDomain
- there are very few legitimate direct usages of JmxUtil.lookupMBeanServer; all else must go
- some registrations are not currently ResourceDMBeans; these need to be converted
- use of registerExternalMBean should be converted to registerMBean
- avoid performing the unregistration manually. Components registered with registerMBean will be unregistered automatically
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10722) Mgmt console: home page load fails in case secured cache container
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10722?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10722:
--------------------------------
Status: Open (was: New)
> Mgmt console: home page load fails in case secured cache container
> ------------------------------------------------------------------
>
> Key: ISPN-10722
> URL: https://issues.jboss.org/browse/ISPN-10722
> Project: Infinispan
> Issue Type: Bug
> Components: Console, JMX, reporting and management
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Major
>
> The following exception appears in server logs and hanging screen is visible in browser when mgmt console home page is accessed, in case when the server is started with secured cache-container.
> {noformat}
> 12:53:09,199 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "local")
> ]): java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'ADMIN' permission
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:87)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:57)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.manager.DefaultCacheManager.getDefaultCacheConfiguration(DefaultCacheManager.java:847)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.collectXSiteAdminOperation(GlobalXSiteAdminOperations.java:135)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.globalStatus(GlobalXSiteAdminOperations.java:86)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.filterSitesByStatus(CacheContainerMetricsHandler.java:342)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.executeRuntimeStep(CacheContainerMetricsHandler.java:296)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10722) Mgmt console: home page load fails in case secured cache container
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10722?page=com.atlassian.jira.plugin... ]
Dan Berindei reassigned ISPN-10722:
-----------------------------------
Assignee: Dan Berindei (was: Pedro Ruivo)
> Mgmt console: home page load fails in case secured cache container
> ------------------------------------------------------------------
>
> Key: ISPN-10722
> URL: https://issues.jboss.org/browse/ISPN-10722
> Project: Infinispan
> Issue Type: Bug
> Components: Console, JMX, reporting and management
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
>
> The following exception appears in server logs and hanging screen is visible in browser when mgmt console home page is accessed, in case when the server is started with secured cache-container.
> {noformat}
> 12:53:09,199 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "local")
> ]): java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'ADMIN' permission
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:87)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:57)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.manager.DefaultCacheManager.getDefaultCacheConfiguration(DefaultCacheManager.java:847)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.collectXSiteAdminOperation(GlobalXSiteAdminOperations.java:135)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.globalStatus(GlobalXSiteAdminOperations.java:86)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.filterSitesByStatus(CacheContainerMetricsHandler.java:342)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.executeRuntimeStep(CacheContainerMetricsHandler.java:296)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10722) Mgmt console: home page load fails in case secured cache container
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10722?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10722:
--------------------------------
Security: (was: Red Hat Internal)
> Mgmt console: home page load fails in case secured cache container
> ------------------------------------------------------------------
>
> Key: ISPN-10722
> URL: https://issues.jboss.org/browse/ISPN-10722
> Project: Infinispan
> Issue Type: Bug
> Components: Console, JMX, reporting and management
> Affects Versions: 9.4.16.Final, 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Major
>
> The following exception appears in server logs and hanging screen is visible in browser when mgmt console home page is accessed, in case when the server is started with secured cache-container.
> {noformat}
> 12:53:09,199 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "local")
> ]): java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'ADMIN' permission
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:87)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:57)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.manager.DefaultCacheManager.getDefaultCacheConfiguration(DefaultCacheManager.java:847)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.collectXSiteAdminOperation(GlobalXSiteAdminOperations.java:135)
> at org.infinispan.core:ispn-9.4@9.4.16.Final//org.infinispan.xsite.GlobalXSiteAdminOperations.globalStatus(GlobalXSiteAdminOperations.java:86)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.filterSitesByStatus(CacheContainerMetricsHandler.java:342)
> at org.infinispan.extension:ispn-9.4@9.4.16.Final//org.jboss.as.clustering.infinispan.subsystem.CacheContainerMetricsHandler.executeRuntimeStep(CacheContainerMetricsHandler.java:296)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10591) Make Protostream the default user marshaller
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10591?page=com.atlassian.jira.plugin... ]
Ryan Emerson updated ISPN-10591:
--------------------------------
Description:
Protostream should be used as the default marshaller for user types unless a user explicitly provides a custom marshaller via {{SerializationConfiguration.marshaller}}.
This requires that all of our testsuite is also updated to provide protostream pojos and that the `infinispan-jboss-marshalling` dependency is removed from all possible sub-modules. Most notably:
* core
* query
* server
* client
This will require various integration tests to also be updated to reflect the new behaviour, as the APPLICATION_JBOSS_MARSHALLING media type will not be available to the client/server by default.
In order for a user to utilise jboss-marshalling on the client side, it's necessary for the `infinispan-jboss-marshalling` jar to be added to the classpath. Furthermore, if APPLICATION_OBJECT storage is desired on the server and jboss-marshalling is utilised on the client, it's also necessary for the dependency to be added to the server. In order to verify that this functionality works as expected, it's necessary for a `integrationtests/jboss-marshalling` sub-module to be created in order to test these scenarios.
was:_emphasized text_
> Make Protostream the default user marshaller
> --------------------------------------------
>
> Key: ISPN-10591
> URL: https://issues.jboss.org/browse/ISPN-10591
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 10.0.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> Protostream should be used as the default marshaller for user types unless a user explicitly provides a custom marshaller via {{SerializationConfiguration.marshaller}}.
> This requires that all of our testsuite is also updated to provide protostream pojos and that the `infinispan-jboss-marshalling` dependency is removed from all possible sub-modules. Most notably:
> * core
> * query
> * server
> * client
> This will require various integration tests to also be updated to reflect the new behaviour, as the APPLICATION_JBOSS_MARSHALLING media type will not be available to the client/server by default.
> In order for a user to utilise jboss-marshalling on the client side, it's necessary for the `infinispan-jboss-marshalling` jar to be added to the classpath. Furthermore, if APPLICATION_OBJECT storage is desired on the server and jboss-marshalling is utilised on the client, it's also necessary for the dependency to be added to the server. In order to verify that this functionality works as expected, it's necessary for a `integrationtests/jboss-marshalling` sub-module to be created in order to test these scenarios.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10721) jcache/tck-runner module should not unpack cache-tests
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10721?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10721:
--------------------------------
Description:
The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests.
This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations:
{noformat}
[2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult
[2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
[2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default],
[2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default]
[2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26)
{noformat}
Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead:
{code:xml}
<dependenciesToScan>
<dependency>javax.cache:cache-tests</dependency>
</dependenciesToScan>
{code}
was:
The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests.
This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations:
{noformat}
[2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult
[2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
[2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default],
[2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default]
[2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23)
[2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26)
{noformat}
Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead:
{noformat}
<dependenciesToScan>
<dependency>javax.cache:cache-tests</dependency>
</dependenciesToScan>
{noformat}
> jcache/tck-runner module should not unpack cache-tests
> ------------------------------------------------------
>
> Key: ISPN-10721
> URL: https://issues.jboss.org/browse/ISPN-10721
> Project: Infinispan
> Issue Type: Bug
> Components: JCache, Test Suite - Server
> Affects Versions: 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR3
>
>
> The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests.
> This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations:
> {noformat}
> [2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult
> [2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default],
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default]
> [2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26)
> {noformat}
> Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead:
> {code:xml}
> <dependenciesToScan>
> <dependency>javax.cache:cache-tests</dependency>
> </dependenciesToScan>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10721) jcache/tck-runner module should not unpack cache-tests
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10721?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10721:
--------------------------------
Status: Open (was: New)
> jcache/tck-runner module should not unpack cache-tests
> ------------------------------------------------------
>
> Key: ISPN-10721
> URL: https://issues.jboss.org/browse/ISPN-10721
> Project: Infinispan
> Issue Type: Bug
> Components: JCache, Test Suite - Server
> Affects Versions: 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR3
>
>
> The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests.
> This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations:
> {noformat}
> [2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult
> [2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between:
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default],
> [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default]
> [2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23)
> [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26)
> {noformat}
> Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead:
> {noformat}
> <dependenciesToScan>
> <dependency>javax.cache:cache-tests</dependency>
> </dependenciesToScan>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months