October 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (IPROTO-75) Conversion from JSON to Protobuf fails when using required non-scalar fields

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/IPROTO-75?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated IPROTO-75: ------------------------------------ Summary: Conversion from JSON to Protobuf fails when using required non-scalar fields (was: Conversion from Protobuf to JSON fails when using required non-scalar fields) > Conversion from JSON to Protobuf fails when using required non-scalar fields > ---------------------------------------------------------------------------- > > Key: IPROTO-75 > URL: https://issues.jboss.org/browse/IPROTO-75 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Gustavo Fernandes > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-75) Conversion from Protobuf to JSON fails when using required non-scalar fields

by Gustavo Fernandes (Jira)

Gustavo Fernandes created IPROTO-75: --------------------------------------- Summary: Conversion from Protobuf to JSON fails when using required non-scalar fields Key: IPROTO-75 URL: https://issues.jboss.org/browse/IPROTO-75 Project: Infinispan ProtoStream Issue Type: Bug Reporter: Gustavo Fernandes -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-56) Dynamic entity support in MarshallerProvider

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/IPROTO-56?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned IPROTO-56: --------------------------------------- Assignee: Gustavo Fernandes > Dynamic entity support in MarshallerProvider > -------------------------------------------- > > Key: IPROTO-56 > URL: https://issues.jboss.org/browse/IPROTO-56 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > The use case is a class that describe the entity. This class contains a 'type' and a list of properties. MarshallerProvider is used to associate a type with a marshaller that uses this 'type' to understand the fields and data types to read/write the stream. > The type of the entity is contained in the entity itself, and when reading from the stream, this type is used to figure out the fields to read. During writes, though, the type is not involved so it's not possible to use the same strategy. > Attached is a unit test to illustrate the situation. This is not necessarily a bug, it may be possible to achieve the usage of Dynamic Entities under other circumstances, or maybe the API needs to be extended. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9624?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9624: ------------------------------- Description: The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. {code:java} @ThreadSafe public interface StreamAwareMarshaller extends Marshaller { /** * Marshall an object to the {@link OutputStream} * * @param o the object to write to the {@link OutputStream} * @param out the {@link OutputStream} to write the object to * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error */ void writeObject(Object o, OutputStream out) throws IOException; /** * Unmarshall an object from the {@link InputStream} * * @param in the {@link InputStream} to unmarshall an object from * @return the unmarshalled object instance * @throws IOException if unmarshalling cannot complete due to some I/O error * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found */ Object readObject(InputStream in) throws ClassNotFoundException, IOException; } {code} was:The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. > Deprecate StreamingMarshaller interface > --------------------------------------- > > Key: ISPN-9624 > URL: https://issues.jboss.org/browse/ISPN-9624 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Alpha1 > > > The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. > {code:java} > @ThreadSafe > public interface StreamAwareMarshaller extends Marshaller { > /** > * Marshall an object to the {@link OutputStream} > * > * @param o the object to write to the {@link OutputStream} > * @param out the {@link OutputStream} to write the object to > * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error > */ > void writeObject(Object o, OutputStream out) throws IOException; > /** > * Unmarshall an object from the {@link InputStream} > * > * @param in the {@link InputStream} to unmarshall an object from > * @return the unmarshalled object instance > * @throws IOException if unmarshalling cannot complete due to some I/O error > * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found > */ > Object readObject(InputStream in) throws ClassNotFoundException, IOException; > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-9624: ---------------------------------- Summary: Deprecate StreamingMarshaller interface Key: ISPN-9624 URL: https://issues.jboss.org/browse/ISPN-9624 Project: Infinispan Issue Type: Sub-task Components: Core Affects Versions: 9.4.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Alpha1 The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9623) Create Protobuf based user marshaller

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-9623: ---------------------------------- Summary: Create Protobuf based user marshaller Key: ISPN-9623 URL: https://issues.jboss.org/browse/ISPN-9623 Project: Infinispan Issue Type: Sub-task Components: Core Affects Versions: 9.4.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Alpha1 With the internal and persistence marshaller being protobuf based, we should also provide a user marshaller implementation that utilises protostream. Users should be able to configure annotated pojos or MessageMarshaller implementations for their objects. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9622) Replace GlobalMarshaller with protobuf based marshaller

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-9622: ---------------------------------- Summary: Replace GlobalMarshaller with protobuf based marshaller Key: ISPN-9622 URL: https://issues.jboss.org/browse/ISPN-9622 Project: Infinispan Issue Type: Sub-task Components: Core Affects Versions: 9.4.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Alpha1 The internal marshaller should be responsible for serializing all internal objects sent between infinispan nodes. For user objects it should delegate to the configured user marshaller (jboss-marshaller based for now) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9621) Split global marshaller into Persistence and Internal marshaller

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-9621: ---------------------------------- Summary: Split global marshaller into Persistence and Internal marshaller Key: ISPN-9621 URL: https://issues.jboss.org/browse/ISPN-9621 Project: Infinispan Issue Type: Sub-task Components: Core, Loaders and Stores Affects Versions: 9.4.0.Final Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 10.0.0.Alpha1 Currently the internal marshaller is used for marshalling key/value/metadata in store implementations. This means that it is possible for internal classes to be marshalled to a user store, which can cause compatibility issues if an internal classes serialization format changes (due to marshaller changes or addition/removal of fields). We should separate the internal and persistence marshaller, only exposing the latter to stores via the InitializationContext. The persistence marshaller should only be able to serialize user key/values and the metadata/version data. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9620: ------------------------------- Description: In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation. (was: In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. We should utilise protobuf messages to define all messages that are required for ) > Rolling Upgrade Marshaller Changes > ---------------------------------- > > Key: ISPN-9620 > URL: https://issues.jboss.org/browse/ISPN-9620 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Alpha1 > > > In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9620: ------------------------------- Description: In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. We should utilise protobuf messages to define all messages that are required for was:In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. > Rolling Upgrade Marshaller Changes > ---------------------------------- > > Key: ISPN-9620 > URL: https://issues.jboss.org/browse/ISPN-9620 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Alpha1 > > > In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. > We should utilise protobuf messages to define all messages that are required for -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 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 October 2018