[JBoss JIRA] (ISPN-9180) Remove compat mode from Remote Query
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9180?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9180:
------------------------------------
Description:
The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the incoming content to java object (String) on the fly, as long as the server supports conversion between the content produced by marshaller and java object.
Apart from that, there are multiple places in the code that registers/instantiates/configures objects based on the compat mode marshaller, and assume all content will be unmarshalled by this marshaller. It should instead rely on the MediaType information sent by the HR client and do the conversion on the fly, this would allow indexing and querying in multiple formats as long as the storage format is supported and the conversion between the input/storage is supported by the server.
was:
The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the protofile to java object on the fly, as long as the server support conversion between the content produced by marshaller and java object.
> Remove compat mode from Remote Query
> ------------------------------------
>
> Key: ISPN-9180
> URL: https://issues.jboss.org/browse/ISPN-9180
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Gustavo Fernandes
>
> The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
> The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the incoming content to java object (String) on the fly, as long as the server supports conversion between the content produced by marshaller and java object.
> Apart from that, there are multiple places in the code that registers/instantiates/configures objects based on the compat mode marshaller, and assume all content will be unmarshalled by this marshaller. It should instead rely on the MediaType information sent by the HR client and do the conversion on the fly, this would allow indexing and querying in multiple formats as long as the storage format is supported and the conversion between the input/storage is supported by the server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-9181) Remove compat mode from Remote Iterator
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9181?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9181:
------------------------------------
Description:
The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where each listener control the type of data should receive, either as Pojos or binary format.
was:
The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
> Remove compat mode from Remote Iterator
> ---------------------------------------
>
> Key: ISPN-9181
> URL: https://issues.jboss.org/browse/ISPN-9181
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Gustavo Fernandes
>
> The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
> There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where each listener control the type of data should receive, either as Pojos or binary format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-9181) Remove compat mode from Remote Iterator
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9181?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9181:
------------------------------------
Description:
The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
There should be a mechanism (in the event subsystem preferably) where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
> Remove compat mode from Remote Iterator
> ---------------------------------------
>
> Key: ISPN-9181
> URL: https://issues.jboss.org/browse/ISPN-9181
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Gustavo Fernandes
>
> The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
> There should be a mechanism (in the event subsystem preferably) where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-9181) Remove compat mode from Remote Iterator
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9181?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9181:
------------------------------------
Description:
The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
was:
The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
There should be a mechanism (in the event subsystem preferably) where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
> Remove compat mode from Remote Iterator
> ---------------------------------------
>
> Key: ISPN-9181
> URL: https://issues.jboss.org/browse/ISPN-9181
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Gustavo Fernandes
>
> The remote iterator checks for compat mode and if present, unmarshalls keys and values before running them to the filters (in case they're present).
> There should be a generic mechanism where the filter itself specifies in which format it wants to process the data. Something similar to {{useRawData()}} in the remote listeners, where it control it listeners should receive data as POJOS or binary format
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-9182) Remove compat mode from Tasks and Scripts
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-9182:
---------------------------------------
Summary: Remove compat mode from Tasks and Scripts
Key: ISPN-9182
URL: https://issues.jboss.org/browse/ISPN-9182
Project: Infinispan
Issue Type: Sub-task
Reporter: Gustavo Fernandes
Both script and tasks hardcode GenericJbossMarshaller in several places, and use it to unmarshall parameters and user data when executing code. If the client uses a different marshaller, it breaks.
Both should rely instead of the MediaType sent by the Hot Rod client in order to convert from and to the storage format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ISPN-9180) Remove compat mode from Remote Query
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9180?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9180:
------------------------------------
Description:
The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the protofile to java object on the fly, as long as the server support conversion between the content produced by marshaller and java object.
> Remove compat mode from Remote Query
> ------------------------------------
>
> Key: ISPN-9180
> URL: https://issues.jboss.org/browse/ISPN-9180
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Gustavo Fernandes
>
> The ProtobufMetadataManager is configured internally using compat mode plus the CompatibilityProtostreamMarshaller as a marshaller. This requires that HR clients use the protostream marshaller to register .proto files, since otheriwse the server cannot unmarshall it.
> The ProtobufMetadataManager cache should rely instead on the MediaType sent by the HR client and convert the protofile to java object on the fly, as long as the server support conversion between the content produced by marshaller and java object.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months