[JBoss JIRA] (ISPN-9637) Cleanup dependency injection in Ickle filters and their indexing providers
by Adrian Nistor (Jira)
Adrian Nistor created ISPN-9637:
-----------------------------------
Summary: Cleanup dependency injection in Ickle filters and their indexing providers
Key: ISPN-9637
URL: https://issues.jboss.org/browse/ISPN-9637
Project: Infinispan
Issue Type: Task
Components: Listeners
Reporter: Adrian Nistor
Assignee: Adrian Nistor
These filters could have a common base class that handles the extraction of query string and params from the Object[] argument. This was done until now with the helper class IckleFilterConverterUtils but we can do it a bit more elegantly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9636) Refactor IckleFilterAndConverter into a Function so it does not need wrapping for streams
by Adrian Nistor (Jira)
[ https://issues.jboss.org/browse/ISPN-9636?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9636:
--------------------------------
Description: This filter can be used for filtering cache events and also for distributed streams. With a little refactoring we can use it directly with streams without needing the wrapper from CacheFilters.filterAndConvert( .. ).
> Refactor IckleFilterAndConverter into a Function so it does not need wrapping for streams
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-9636
> URL: https://issues.jboss.org/browse/ISPN-9636
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Listeners
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Priority: Major
>
> This filter can be used for filtering cache events and also for distributed streams. With a little refactoring we can use it directly with streams without needing the wrapper from CacheFilters.filterAndConvert( .. ).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9635) Support receiving values in the remote events API
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9635?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9635:
------------------------------------
Description:
There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently used by Near Cache, Spark connector and JCache.
Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding (clients may choose to receive keys and values in different formats) and requires less efforts in the client to consume those events.
was:
There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently used by Near Cache, Spark connector and JCache.
Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding and requires less efforts in the client to consume those events.
> Support receiving values in the remote events API
> -------------------------------------------------
>
> Key: ISPN-9635
> URL: https://issues.jboss.org/browse/ISPN-9635
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners
> Reporter: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently used by Near Cache, Spark connector and JCache.
> Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding (clients may choose to receive keys and values in different formats) and requires less efforts in the client to consume those events.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9634) Deprecate useRawData from remote listeners
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9634?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9634:
------------------------------------
Description:
Since remote listeners with converters and filters were introduced, it was assumed the user supplied implementations would receive "unmarshalled" data to operate.
A parameter on the remote listener annotation itself called "useRawData" was later introduced to provide a way for filters/converters to use data as it was stored (i.e., without unmarshalling)
Since transcoders were introduced, the choice of format for listeners and converters can be specified on the listeners/converters themselves in the format() method and should not rely on useRawData anymore.
was:
Since remote listeners with converters and filters were introduced, it was assumed the user supplied implementations would receive "unmarshalled" data to operate.
A parameter on the remote listener annotation itself called "useRawData" was later introduced to provide a way for filters/converters to use data as it was stored (i.e., without unmarshalling)
Since transcoders were introduced, the choice of format for listeners and converters can be specified on the listeners/converters themselves in the format() method method and should not rely on useRawData anymore.
> Deprecate useRawData from remote listeners
> ------------------------------------------
>
> Key: ISPN-9634
> URL: https://issues.jboss.org/browse/ISPN-9634
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Since remote listeners with converters and filters were introduced, it was assumed the user supplied implementations would receive "unmarshalled" data to operate.
> A parameter on the remote listener annotation itself called "useRawData" was later introduced to provide a way for filters/converters to use data as it was stored (i.e., without unmarshalling)
> Since transcoders were introduced, the choice of format for listeners and converters can be specified on the listeners/converters themselves in the format() method and should not rely on useRawData anymore.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9635) Support receiving values in the remote events API
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9635?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9635:
------------------------------------
Description:
There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently used by Near Cache, Spark and JCache.
Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding and requires less efforts in the client to consume those events.
was:
There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently sed by Near Cache, Spark and JCache.
Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding and requires less efforts in the client to consume those events.
> Support receiving values in the remote events API
> -------------------------------------------------
>
> Key: ISPN-9635
> URL: https://issues.jboss.org/browse/ISPN-9635
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners
> Reporter: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> There is no proper API to receive both keys and values from remote events without resorting to KeyValueConverters that produces custom events with keys and values together. Converters are currently used by Near Cache, Spark and JCache.
> Ideally there should be a way to receive the event with keys and values separated, this facilitates transcoding and requires less efforts in the client to consume those events.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months