[
https://issues.redhat.com/browse/WFLY-13519?page=com.atlassian.jira.plugi...
]
Paul Ferraro updated WFLY-13519:
--------------------------------
Description:
The cache-container and remote-cache-container resources in the Infinispan subsystem have
a module attribute that is used to dynamically load externalizers used to configure
marshalling for capabilities associated with these resources.
Additionally, this attribute is also used to load Infinispan modules (e.g query, multimap,
hibernate, etc.).
Several users have had issues with configuring the marshalling of a custom cache because
the module to which their cache container is associated does not know about their module.
Users wanting to a specific Infinispan module has a similar issue.
Currently, the only way to load marshalling configuration from multiple modules is through
the use of module dependencies (using services="import"). This causes lots of
unnatural service dependencies, which complicates the ability to build fine grained
galleon layers.
In order to support the use of multiple modules for a given cache-container, and also to
support marshalling for multiple modules, we need to allow these resources to be
associated with a list of modules, instead of a single module.
Thus, the "module" will need to be replaced by "modules", where the
former becomes an alias for the latter, with some translation logic to convert multiple
values to a single value.
was:
The channel resource in the JGroups subsystem and cache-container and
remote-cache-container resources in the Infinispan subsystem have a module attribute that
is used to dynamically load externalizers used to configure marshalling for capabilities
associated with these resources.
In the case of Infinispan, this attribute is also used to load Infinispan modules (e.g
query, multimap, hibernate, etc.).
Several users have had issues with configuring the marshalling of a custom cache because
the module to which their cache container is associated does not know about their module.
Currently, the only way to load marshalling configuration from multiple modules is through
the use of module dependencies (using services="import"). This causes lots of
unnatural service dependencies, which complicates the ability to build fine grained
galleon layers.
In order to support the use of multiple modules for a given cache-container, and also to
support marshalling for multiple modules, we need to allow these resources to be
associated with a list of modules, instead of a single module.
Thus, the "module" will need to be replaced by "modules", where the
former becomes an alias for the latter, with some translation logic to convert multiple
values to a single value.
Infinispan module attribute needs to support multiple values
------------------------------------------------------------
Key: WFLY-13519
URL:
https://issues.redhat.com/browse/WFLY-13519
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 20.0.0.Beta1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Priority: Major
The cache-container and remote-cache-container resources in the Infinispan subsystem have
a module attribute that is used to dynamically load externalizers used to configure
marshalling for capabilities associated with these resources.
Additionally, this attribute is also used to load Infinispan modules (e.g query,
multimap, hibernate, etc.).
Several users have had issues with configuring the marshalling of a custom cache because
the module to which their cache container is associated does not know about their module.
Users wanting to a specific Infinispan module has a similar issue.
Currently, the only way to load marshalling configuration from multiple modules is
through the use of module dependencies (using services="import"). This causes
lots of unnatural service dependencies, which complicates the ability to build fine
grained galleon layers.
In order to support the use of multiple modules for a given cache-container, and also to
support marshalling for multiple modules, we need to allow these resources to be
associated with a list of modules, instead of a single module.
Thus, the "module" will need to be replaced by "modules", where the
former becomes an alias for the latter, with some translation logic to convert multiple
values to a single value.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)