November 2019 - infinispan-issues

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Work on IPROTO-120 started by Nistor Adrian. -------------------------------------------- > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.3.0.Final > > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-122) JDK version check in the annotation processor fails on Openjdk 13

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-122?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-122: --------------------------------- Status: Open (was: New) > JDK version check in the annotation processor fails on Openjdk 13 > ----------------------------------------------------------------- > > Key: IPROTO-122 > URL: https://issues.jboss.org/browse/IPROTO-122 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.0.Final > Reporter: Nistor Adrian > Priority: Major > > {code} > Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 > at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.getJavaMajorVersion (AutoProtoSchemaBuilderAnnotationProcessor.java:209) > at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.process (AutoProtoSchemaBuilderAnnotationProcessor.java:165) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor (JavacProcessingEnvironment.java:1023) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-122) JDK version check in the annotation processor fails on Openjdk 13

by Nistor Adrian (Jira)

Nistor Adrian created IPROTO-122: ------------------------------------ Summary: JDK version check in the annotation processor fails on Openjdk 13 Key: IPROTO-122 URL: https://issues.jboss.org/browse/IPROTO-122 Project: Infinispan ProtoStream Issue Type: Bug Affects Versions: 4.3.0.Final Reporter: Nistor Adrian {code} Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.getJavaMajorVersion (AutoProtoSchemaBuilderAnnotationProcessor.java:209) at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.process (AutoProtoSchemaBuilderAnnotationProcessor.java:165) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor (JavacProcessingEnvironment.java:1023) {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9964) Logging incompatibility when deploying modules on older versions of WildFly

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9964?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9964: ------------------------------- Sprint: (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > Logging incompatibility when deploying modules on older versions of WildFly > --------------------------------------------------------------------------- > > Key: ISPN-9964 > URL: https://issues.jboss.org/browse/ISPN-9964 > Project: Infinispan > Issue Type: Bug > Components: WildFly modules > Affects Versions: 9.4.6.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.7.Final > > > Older versions of Wildfly 7.1.x still utilise jboss-logging 3.1.x, whereas the 9.4.x branch uses 3.3.x. Jboss-logging 3.3.x introduced several new method signatures, which results in a {{NoSuchMethodError}} being thrown when infinispan is embedded on a older wildfly version. -To overcome this, it is necessary to make sure that only the method signatures found in both jboss-logging 3.1.x and 3.3.x are utilised.- Explicitly including the required version of jboss-logging in the wildfly-modules ensures that no discrepancy exists. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10590) PersistenceMarshallerImpl should not wrap objects when no user marshaller is configured

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10590?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10590: -------------------------------- Sprint: (was: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > PersistenceMarshallerImpl should not wrap objects when no user marshaller is configured > --------------------------------------------------------------------------------------- > > Key: ISPN-10590 > URL: https://issues.jboss.org/browse/ISPN-10590 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.CR1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.CR2 > > > Currently the PersistenceMarshallerImpl still tries to wrap values that are not in it's SerializationContext even when protostream is to be used directly for user types. This does not make sense, as it will results in a NPE due to a delegate user marshaller not existing. Instead, if protostream is to be used for delegate types the PersistenceMarshallerImpl should state that java primitive values can be marshalled and no wrapping should be attempted. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10779) RestConnectorTest.testUrlWithSSL failure

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10779?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10779: -------------------------------- Sprint: (was: DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > RestConnectorTest.testUrlWithSSL failure > ---------------------------------------- > > Key: ISPN-10779 > URL: https://issues.jboss.org/browse/ISPN-10779 > Project: Infinispan > Issue Type: Bug > Components: CLI > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > IllegalStateException thrown by SSLConfigurationBuilder::validate as no TrustManager set -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10834) Client ConfigurationBuilder contextInitializer methods should be consistent with core

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10834?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10834: -------------------------------- Sprint: (was: DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > Client ConfigurationBuilder contextInitializer methods should be consistent with core > ------------------------------------------------------------------------------------- > > Key: ISPN-10834 > URL: https://issues.jboss.org/browse/ISPN-10834 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 10.0.0.CR3 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > Currently the client ConfigurationBuilder uses ConfigurationBuilder::contextInitializer whereas core uses ConfigurationBuilder::addContextInitializer. We should make these the same for consistency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10414) Remove AtomicObjectFactory

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10414?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10414: -------------------------------- Sprint: (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > Remove AtomicObjectFactory > -------------------------- > > Key: ISPN-10414 > URL: https://issues.jboss.org/browse/ISPN-10414 > Project: Infinispan > Issue Type: Task > Components: API > Affects Versions: 10.0.0.Beta4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta5 > > > The AtomicObjectFactory has not been actively developed since it's inception in ISPN-3695 and is not documented in the user guide. We should remove this module. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9976) Query still has a hard dependency on Elasticsearch

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9976?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9976: ------------------------------- Sprint: (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > Query still has a hard dependency on Elasticsearch > -------------------------------------------------- > > Key: ISPN-9976 > URL: https://issues.jboss.org/browse/ISPN-9976 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 10.0.0.Alpha3, 9.4.6.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.7.Final, 10.0.0.Beta1 > > > ISPN-9795 Made the {{org.hibernate.search.elasticsearch}} module optional in our feature-packs, however in `infinispan-query`there is an unchecked call to {{org.hibernate.search.elasticsearch.bridge.builtin.impl.ElasticsearchDateBridge}} regardless of whether Elasticsearch is actually available on the classpath. This results in a {{NoClassDefFoundError}} whenever {{HibernateSearchPropertyHelper#convertToPropertyType}} is called and Elasticsearch is not available. For example when deploying the wfly-modules to a wfly instance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10423) RocksDB ReadOptions memory leak

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10423?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10423: -------------------------------- Sprint: (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37) > RocksDB ReadOptions memory leak > ------------------------------- > > Key: ISPN-10423 > URL: https://issues.jboss.org/browse/ISPN-10423 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 10.0.0.Beta4, 9.4.15.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > Currently our rocksdb store impl creates a new ReadOptions instance per iterator created. As per the RocksDB we should be calling {{dispose()}} on this once it goes out of scope, so that the c++ underlying impl can free the memory. Currently we're not doing this, resulting in a memory leak. > As we only ever use the same ReadOptions for all iterators, we should simply re-use a singleton for all iterators and then dispose of this on shutdown. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2019