[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
[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
[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
[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
[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
[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
[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
[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