[
https://issues.jboss.org/browse/ISPN-9604?page=com.atlassian.jira.plugin....
]
Gustavo Fernandes updated ISPN-9604:
------------------------------------
Description:
As described in the
[
docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a
filter/converter can optionally specify a {{MediaType}} to process events, and let
Infinispan perform the conversion between the storage format and the chosen format. Once
converters are applied, the last step, in case it's needed, it to convert the event to
the request format, which is the format that the cache was decorated with the
{{withMediaType(...)}} method when the listener registration was performed.
Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used
in NearCache and the Spark Connecor) cannot work in this scheme since as part of its
operation, it reads the stored key and values and creates a new value which is the
aggregation of the Key and the Value in the byte[] format, thus preventing the final
transformation step to the request mediatype.
For this case it'd be interesting to have the possibility of applying the
converters's convert() operation *after* having transformed the Key and Values to the
final request format, therefore the final event value will be an aggregated byte[] but in
the user requested format.
was:
As described in the
[
docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a
filter/converter can optionally specify a {{MediaType}} to process events, and let
Infinispan perform the conversion between the storage format and the chosen format, so
that the converter/filter will be presented in the specified format. The last step, in
case it's needed, it to convert the event to the request format, which is the format
that the cache was decorated with the {{withMediaType(...)}} method when the listener
registration was performed.
Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used
in NearCache and the Spark Connecor) cannot work in this scheme since as part of its
operation, it reads the stored key and values and creates a new value which is the
aggregation of the Key and the Value in the byte[] format, thus preventing the final
transformation step to the request mediatype.
For this case it'd be interesting to have the possibility of applying the
converters's convert() operation *after* having transformed the Key and Values to the
final request format, therefore the final event value will be an aggregated byte[] but in
the user requested format.
Support to run converters in the user requested format
------------------------------------------------------
Key: ISPN-9604
URL:
https://issues.jboss.org/browse/ISPN-9604
Project: Infinispan
Issue Type: Feature Request
Components: Listeners, Remote Protocols
Affects Versions: 9.4.0.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
Priority: Major
As described in the
[
docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a
filter/converter can optionally specify a {{MediaType}} to process events, and let
Infinispan perform the conversion between the storage format and the chosen format. Once
converters are applied, the last step, in case it's needed, it to convert the event to
the request format, which is the format that the cache was decorated with the
{{withMediaType(...)}} method when the listener registration was performed.
Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used
in NearCache and the Spark Connecor) cannot work in this scheme since as part of its
operation, it reads the stored key and values and creates a new value which is the
aggregation of the Key and the Value in the byte[] format, thus preventing the final
transformation step to the request mediatype.
For this case it'd be interesting to have the possibility of applying the
converters's convert() operation *after* having transformed the Key and Values to the
final request format, therefore the final event value will be an aggregated byte[] but in
the user requested format.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)