February 2021 - infinispan-issues

[Red Hat JIRA] (ISPN-12696) SerializationContextRegistryImpl should automatically register PERSISTENCE SCIs with Global context

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-12696?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-12696: -------------------------------- Description: The GlOBAL context is a superset of the PERSISTENCE context, therefore if an internal SCI is registered with the PERSISTENCE context this should also be registered with the GLOBAL conmtext. Currently it's necessary for Infinispan modules to register with both manually. For example the MultiMap LifecycleManager has todo the following: {code:java} ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.PERSISTENCE, new PersistenceContextInitializerImpl()); ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.GLOBAL, new PersistenceContextInitializerImpl()); {code} was: The GlOBAL context is a superset of the PERSISTENCE context, therefore if an internal SCI is registered with the PERSISTENCE context this should also be registered with the GLOBAL conmtext. Currently it's necessary for Infinispan modules to register with both manually. For example the Query LifecycleManager has todo the following: {code:java} ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.PERSISTENCE, new PersistenceContextInitializerImpl()); ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.GLOBAL, MarshallerRegistration.INSTANCE); {code} > SerializationContextRegistryImpl should automatically register PERSISTENCE SCIs with Global context > --------------------------------------------------------------------------------------------------- > > Key: ISPN-12696 > URL: https://issues.redhat.com/browse/ISPN-12696 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 12.0.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > > The GlOBAL context is a superset of the PERSISTENCE context, therefore if an internal SCI is registered with the PERSISTENCE context this should also be registered with the GLOBAL conmtext. > Currently it's necessary for Infinispan modules to register with both manually. For example the MultiMap LifecycleManager has todo the following: > {code:java} > ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.PERSISTENCE, new PersistenceContextInitializerImpl()); > ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.GLOBAL, new PersistenceContextInitializerImpl()); > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12696) SerializationContextRegistryImpl should automatically register PERSISTENCE SCIs with Global context

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-12696: ----------------------------------- Summary: SerializationContextRegistryImpl should automatically register PERSISTENCE SCIs with Global context Key: ISPN-12696 URL: https://issues.redhat.com/browse/ISPN-12696 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 12.0.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson The GlOBAL context is a superset of the PERSISTENCE context, therefore if an internal SCI is registered with the PERSISTENCE context this should also be registered with the GLOBAL conmtext. Currently it's necessary for Infinispan modules to register with both manually. For example the Query LifecycleManager has todo the following: {code:java} ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.PERSISTENCE, new PersistenceContextInitializerImpl()); ctxRegistry.addContextInitializer(SerializationContextRegistry.MarshallerType.GLOBAL, MarshallerRegistration.INSTANCE); {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (IPROTO-185) Annotation processor should not process classes in other modules or without annotations

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-185?page=com.atlassian.jira.plugi... ] Nistor Adrian commented on IPROTO-185: -------------------------------------- Problem number 1 is the weirdest of all. Should not happen at all. > Annotation processor should not process classes in other modules or without annotations > --------------------------------------------------------------------------------------- > > Key: IPROTO-185 > URL: https://issues.redhat.com/browse/IPROTO-185 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Affects Versions: 4.4.0.Alpha4 > Reporter: Dan Berindei > Priority: Major > > If I have a {{@ProtoField}} method returning an {{Object}}, the processor should log any error saying that {{java.lang.Object}} is not marshallable. > Instead, it generates a marshaller for {{java.lang.Object}}. > But post-Jigsaw JVMs do not load {{java.lang}} classes from application jars, leading to confusing runtime errors like this: > {noformat} > java.lang.NoClassDefFoundError: java/lang/Object$___Marshaller_7cfc5a759c8f8d76ba63b427d975ad253085d80aa05aa8e1121221ae7d5d35cd > at org.infinispan.spring.common.provider.PersistenceContextInitializerImpl.registerMarshallers(PersistenceContextInitializerImpl.java:56) > at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl$MarshallerContext.lambda$update$0(SerializationContextRegistryImpl.java:148) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) > at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl$MarshallerContext.update(SerializationContextRegistryImpl.java:146) > at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.lambda$addContextInitializer$3(SerializationContextRegistryImpl.java:85) > at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.update(SerializationContextRegistryImpl.java:105) > at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.addContextInitializer(SerializationContextRegistryImpl.java:85) > {noformat} > I see 2 different problems: > 1. {{java.lang.Object}} does not have any Protostream annotations, but the annotation processor still creates a marshaller for it. > Creating marshallers for classes without annotations means when compiling a module it's impossible to know which classes in that module will ever have marshallers. > 2. Split packages do not work with Jigsaw modules. > Creating a marshaller in the same package but in a different jar is a problem not only for {{java.lang.Object}} and {{java.util}} collection classes, but also for application classes when using modular jars. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12695) Remove unzip tomcat logic from third-party-server module

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/ISPN-12695?page=com.atlassian.jira.plugi... ] Diego Lovison updated ISPN-12695: --------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/9037 Status: Pull Request Sent (was: Open) > Remove unzip tomcat logic from third-party-server module > -------------------------------------------------------- > > Key: ISPN-12695 > URL: https://issues.redhat.com/browse/ISPN-12695 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > While running the downstream tests, I saw that it makes more sense and is easier to just set the Catalina path -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12695) Remove unzip tomcat logic from third-party-server module

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/ISPN-12695?page=com.atlassian.jira.plugi... ] Diego Lovison updated ISPN-12695: --------------------------------- Status: Open (was: New) > Remove unzip tomcat logic from third-party-server module > -------------------------------------------------------- > > Key: ISPN-12695 > URL: https://issues.redhat.com/browse/ISPN-12695 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > While running the downstream tests, I saw that it makes more sense and is easier to just set the Catalina path -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12695) Remove unzip tomcat logic from third-party-server module

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/ISPN-12695?page=com.atlassian.jira.plugi... ] Diego Lovison reassigned ISPN-12695: ------------------------------------ Assignee: Diego Lovison > Remove unzip tomcat logic from third-party-server module > -------------------------------------------------------- > > Key: ISPN-12695 > URL: https://issues.redhat.com/browse/ISPN-12695 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > While running the downstream tests, I saw that it makes more sense and is easier to just set the Catalina path -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (IPROTO-185) Annotation processor should not process classes in other modules or without annotations

by Dan Berindei (Jira)

Dan Berindei created IPROTO-185: ----------------------------------- Summary: Annotation processor should not process classes in other modules or without annotations Key: IPROTO-185 URL: https://issues.redhat.com/browse/IPROTO-185 Project: Infinispan ProtoStream Issue Type: Enhancement Affects Versions: 4.4.0.Alpha4 Reporter: Dan Berindei If I have a {{@ProtoField}} method returning an {{Object}}, the processor should log any error saying that {{java.lang.Object}} is not marshallable. Instead, it generates a marshaller for {{java.lang.Object}}. But post-Jigsaw JVMs do not load {{java.lang}} classes from application jars, leading to confusing runtime errors like this: {noformat} java.lang.NoClassDefFoundError: java/lang/Object$___Marshaller_7cfc5a759c8f8d76ba63b427d975ad253085d80aa05aa8e1121221ae7d5d35cd at org.infinispan.spring.common.provider.PersistenceContextInitializerImpl.registerMarshallers(PersistenceContextInitializerImpl.java:56) at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl$MarshallerContext.lambda$update$0(SerializationContextRegistryImpl.java:148) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl$MarshallerContext.update(SerializationContextRegistryImpl.java:146) at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.lambda$addContextInitializer$3(SerializationContextRegistryImpl.java:85) at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.update(SerializationContextRegistryImpl.java:105) at org.infinispan.marshall.protostream.impl.SerializationContextRegistryImpl.addContextInitializer(SerializationContextRegistryImpl.java:85) {noformat} I see 2 different problems: 1. {{java.lang.Object}} does not have any Protostream annotations, but the annotation processor still creates a marshaller for it. Creating marshallers for classes without annotations means when compiling a module it's impossible to know which classes in that module will ever have marshallers. 2. Split packages do not work with Jigsaw modules. Creating a marshaller in the same package but in a different jar is a problem not only for {{java.lang.Object}} and {{java.util}} collection classes, but also for application classes when using modular jars. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-12695) Remove unzip tomcat logic from third-party-server module

by Diego Lovison (Jira)

Diego Lovison created ISPN-12695: ------------------------------------ Summary: Remove unzip tomcat logic from third-party-server module Key: ISPN-12695 URL: https://issues.redhat.com/browse/ISPN-12695 Project: Infinispan Issue Type: Enhancement Components: Test Suite Affects Versions: 12.0.0.Final Reporter: Diego Lovison While running the downstream tests, I saw that it makes more sense and is easier to just set the Catalina path -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (IPROTO-184) Improve annotation processor error messages

by Dan Berindei (Jira)

Dan Berindei created IPROTO-184: ----------------------------------- Summary: Improve annotation processor error messages Key: IPROTO-184 URL: https://issues.redhat.com/browse/IPROTO-184 Project: Infinispan ProtoStream Issue Type: Enhancement Affects Versions: 4.4.0.Alpha4 Reporter: Dan Berindei Simplify the error message when a class doesn't have any protostream annotations and also doesn't have a no-argument constructor. Currently the processor says {noformat} [ERROR] /home/dan/Work/infinispan/spring/spring5/spring5-common/src/main/java/org/infinispan/spring/common/provider/PersistenceContextInitializer.java:[24,8] org.infinispan.protostream.annotations.ProtoSchemaBuilderException: The class java.time.Duration must be instantiable using an accessible no-argument constructor. [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.checkInstantiability(ProtoMessageTypeMetadata.java:305) [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.<init>(ProtoMessageTypeMetadata.java:75) [ERROR] at org.infinispan.protostream.annotations.impl.processor.CompileTimeProtoMessageTypeMetadata.<init>(CompileTimeProtoMessageTypeMetadata.java:16) [ERROR] at org.infinispan.protostream.annotations.impl.processor.CompileTimeProtoSchemaGenerator.makeMessageTypeMetadata(CompileTimeProtoSchemaGenerator.java:57) ... {noformat} Since class java.time.Duration doesn't have any Protostream annotations, I believe the processor error message should only say that the class is not marshallable with Protostream, without going into more details. After all, the user can't change JDK classes, so they would have to write {{@ProtoAdapter}} class instead of adding a no-argument constructor. ---- Hide the exception when an annotation value is unavailable Infinispan modules all allocate type ids in a commons class, {{ProtostreamTypeIds}}. When I add a new type id but I forget to recompile the commons module, Javac's compilation error is preceded by an internal protostream-processor error: {noformat} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project infinispan-spring5-common: Compilation failure: Compilation failure: [ERROR] @AutoProtoSchemaBuilder processor threw a fatal exception: java.lang.annotation.AnnotationTypeMismatchException: Incorrectly typed data found for annotation element public abstract int org.infinispan.protostream.annotations.ProtoTypeId.value() (Found data of type <any>) [ERROR] at jdk.compiler/com.sun.tools.javac.model.AnnotationProxyMaker$ValueVisitor$1AnnotationTypeMismatchExceptionProxy.generateException(AnnotationProxyMaker.java:271) [ERROR] at java.base/sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:88) [ERROR] at com.sun.proxy.$Proxy288.value(Unknown Source) [ERROR] at org.infinispan.protostream.annotations.impl.ProtoTypeMetadata.getProtoTypeId(ProtoTypeMetadata.java:67) [ERROR] at org.infinispan.protostream.annotations.impl.ProtoTypeMetadata.getDocumentation(ProtoTypeMetadata.java:46) [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.generateProto(ProtoMessageTypeMetadata.java:134) ... [ERROR] /home/dan/Work/infinispan/spring/spring5/spring5-common/src/main/java/org/infinispan/spring/common/session/MapSessionProtoAdapter.java:[17,32] cannot find symbol [ERROR] symbol: variable SPRING_SESSION [ERROR] location: interface org.infinispan.commons.marshall.ProtoStreamTypeIds {noformat} It would be great if the processor could recognize data type {{<any>}} and skip logging an error, since Javac is going to fail the compilation anyway. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-11873) Add report failure for RxJava Undelivered Errors

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11873?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11873: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/8356, https://github.com/infinispan/infinispan/pull/9036 (was: https://github.com/infinispan/infinispan/pull/8356) > Add report failure for RxJava Undelivered Errors > ------------------------------------------------ > > Key: ISPN-11873 > URL: https://issues.redhat.com/browse/ISPN-11873 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > We should install an error handler into RxJava during the test suite so that if we get any undelivered exceptions they will be reported, similar to uncaught exception handler that was added. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2021