[JBoss JIRA] (ISPN-5535) Infinispan subsystem not loaded in WildFly
by Majid Mostafavi (JIRA)
[ https://issues.jboss.org/browse/ISPN-5535?page=com.atlassian.jira.plugin.... ]
Majid Mostafavi commented on ISPN-5535:
---------------------------------------
09:41:03,067 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."nejat.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."nejat.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "nejat.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
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: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class ir.ac.tums.core.utils.SystemManager with ClassLoader ModuleClassLoader for Module "deployment.nejat.war:main" from Service Module Loader
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70)
at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:91)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
Caused by: java.lang.NoClassDefFoundError: Lorg/infinispan/Cache;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2575)
at java.lang.Class.getDeclaredFields(Class.java:1908)
at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:72)
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)
... 10 more
Caused by: java.lang.ClassNotFoundException: org.infinispan.Cache from [Module "deployment.nejat.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
... 15 more
09:41:03,156 INFO [org.hibernate.Version] (ServerService Thread Pool -- 8) HHH000412: Hibernate Core {5.0.10.Final}
09:41:03,159 INFO [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 8) HHH000206: hibernate.properties not found
09:41:03,161 INFO [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 8) HHH000021: Bytecode provider name : javassist
09:41:03,269 INFO [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 8) HCANN000001: Hibernate Commons Annotations {5.0.1.Final}
09:41:05,303 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "nejat")]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"nejat.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"nejat.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"nejat.war\"
Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class ir.ac.tums.core.utils.SystemManager with ClassLoader ModuleClassLoader for Module \"deployment.nejat.war:main\" from Service Module Loader
Caused by: java.lang.NoClassDefFoundError: Lorg/infinispan/Cache;
Caused by: java.lang.ClassNotFoundException: org.infinispan.Cache from [Module \"deployment.nejat.war:main\" from Service Module Loader]"},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"nejat.war\".POST_MODULE"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
09:41:05,305 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "nejat.war" was rolled back with the following failure message:
{
"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"nejat.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"nejat.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"nejat.war\"
Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class ir.ac.tums.core.utils.SystemManager with ClassLoader ModuleClassLoader for Module \"deployment.nejat.war:main\" from Service Module Loader
Caused by: java.lang.NoClassDefFoundError: Lorg/infinispan/Cache;
Caused by: java.lang.ClassNotFoundException: org.infinispan.Cache from [Module \"deployment.nejat.war:main\" from Service Module Loader]"},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"nejat.war\".POST_MODULE"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> Infinispan subsystem not loaded in WildFly
> ------------------------------------------
>
> Key: ISPN-5535
> URL: https://issues.jboss.org/browse/ISPN-5535
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.3.Final
> Environment: Linux / WildFy 8.2.0
> Reporter: Veli Cris
> Attachments: standalone.xml
>
>
> org.infinispan.Cache<Object, Object> c = new org.infinispan.manager.DefaultCacheManager().getCache();
> Triying to instantiate a simple infinispan cache in test application results in following exception:
> 2015-06-09 12:10:13,241 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./push-api: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./push-api: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/infinispan/manager/DefaultCacheManager
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.lang.ClassNotFoundException: org.infinispan.manager.DefaultCacheManager from [Module "deployment.push-api.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 11 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-5535) Infinispan subsystem not loaded in WildFly
by Majid Mostafavi (JIRA)
[ https://issues.jboss.org/browse/ISPN-5535?page=com.atlassian.jira.plugin.... ]
Majid Mostafavi commented on ISPN-5535:
---------------------------------------
<!-- cache -->
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>9.0.0.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-commons</artifactId>
<version>9.0.0.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-cachestore-jdbc</artifactId>
<version>9.0.0.Final</version>
<scope>provided</scope>
</dependency>
> Infinispan subsystem not loaded in WildFly
> ------------------------------------------
>
> Key: ISPN-5535
> URL: https://issues.jboss.org/browse/ISPN-5535
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.3.Final
> Environment: Linux / WildFy 8.2.0
> Reporter: Veli Cris
> Attachments: standalone.xml
>
>
> org.infinispan.Cache<Object, Object> c = new org.infinispan.manager.DefaultCacheManager().getCache();
> Triying to instantiate a simple infinispan cache in test application results in following exception:
> 2015-06-09 12:10:13,241 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./push-api: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./push-api: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/infinispan/manager/DefaultCacheManager
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.lang.ClassNotFoundException: org.infinispan.manager.DefaultCacheManager from [Module "deployment.push-api.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 11 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Adrian Moos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ]
Adrian Moos commented on ISPN-3128:
-----------------------------------
Spring 4.3.8 (and possibly earlier versions as well) invokes {{cache.put(Object, Object)}} for @CachePut methods, and {{cache.get(Object, Callable)}} for @Cacheable methods.
As such, the CacheDelegate could easily distinguish read and write access, and only invalidate remote caches on write access. This seems aligned with the contract of Spring's Cache.get(Object, Calleable) which states:
{quote}
Return the value to which this cache maps the specified key, obtaining that value from valueLoader if necessary. This method provides a simple substitute for the conventional "if cached, return; otherwise create, cache and return" pattern.
{quote}
> Better support for (Spring) read caching
> ----------------------------------------
>
> Key: ISPN-3128
> URL: https://issues.jboss.org/browse/ISPN-3128
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Affects Versions: 5.3.0.Beta2
> Environment: Spring 3.1+
> Reporter: Mike Noordermeer
> Assignee: Gustavo Fernandes
>
> We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
> As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
> - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
> - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
> - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
> - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
> The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
> In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
> - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
> - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
> Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-7580) Use of marsheller is not consistent in all places
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7580:
-------------------------------------
Hi [~rareddy],
is this issue still relevant. I remember this was solved in a different way in Protostream. Can we close this now?
Thanks,
Adrian
> Use of marsheller is not consistent in all places
> -------------------------------------------------
>
> Key: ISPN-7580
> URL: https://issues.jboss.org/browse/ISPN-7580
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Querying
> Reporter: Ramesh Reddy
> Assignee: Adrian Nistor
>
> Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to read/write byte streams in portable fashion for given message type, which are representions of a relational table in Teiid. This works fine, if I just use cache's get/put calls.
> However, the same fails when used with RemoteQuery or Continuous query. The reason is, these classes circumvent extended Marsheller and go directly to serialization context registered to do the wrapping/unwrapping. Not only that there are few places code will type cast the SerializationContext to SerializationContextImpl object. Thus I can not even provide my own Serializer nor I can extend this as SerializationContextImpl is declared as final. These need to be corrected such that extended marsheller is used rather than hard coding them.
> I am guessing this is first time anyone has even done this without using dedicated java classes as marshellers.
> This is extremely critical for me to be fixed to move forward, I can provide the pull request for it?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-6161) Indexes should be created only for annotated message types
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6161?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6161:
--------------------------------
Description: Modify behaviour of indexing for protobuf entities: Current behaviour is: if the message types is not annotated then we index all its fields; if some fields are annotated then index those fields only. New behaviour: index only the annotated fields. (was: Modify behaviour of indexing for protobuf entities: Current behaviour is: if nothing is annotated then we index all fields;if some fields are annotated then index those fields only. New behaviour: index only the annotated fields.)
> Indexes should be created only for annotated message types
> ----------------------------------------------------------
>
> Key: ISPN-6161
> URL: https://issues.jboss.org/browse/ISPN-6161
> Project: Infinispan
> Issue Type: Task
> Components: Remote Querying
> Reporter: Tristan Tarrant
> Assignee: Adrian Nistor
> Fix For: 9.1.0.Final
>
>
> Modify behaviour of indexing for protobuf entities: Current behaviour is: if the message types is not annotated then we index all its fields; if some fields are annotated then index those fields only. New behaviour: index only the annotated fields.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ISPN-6161) Indexes should be created only for annotated message types
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6161?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6161:
--------------------------------
Summary: Indexes should be created only for annotated message types (was: Indexes should be created only for annotated fields)
> Indexes should be created only for annotated message types
> ----------------------------------------------------------
>
> Key: ISPN-6161
> URL: https://issues.jboss.org/browse/ISPN-6161
> Project: Infinispan
> Issue Type: Task
> Components: Remote Querying
> Reporter: Tristan Tarrant
> Assignee: Adrian Nistor
> Fix For: 9.1.0.Final
>
>
> Modify behaviour of indexing for protobuf entities: Current behaviour is: if nothing is annotated then we index all fields;if some fields are annotated then index those fields only. New behaviour: index only the annotated fields.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months