As Tristan said, the infinispan bits shipped with WildFly and its
configuration will not have all ISPN features. It might change over the
time as there is no test which ensure that any feature beside those which
are used from the WF container.
The configuration for the subsystem is different and will not allow all
features.
Also if there is a plan to move to the supported products this is not
supported!
The best option is to use the infinispan modules and configure it in
server-mode, in this case the cache lifecycle is bound to the WF instance
and can be shared/injected to all deployed applications (sharing the cache
between application in embedded mode will not work)
Note that you might use the infinispan endpoints here, but if there is a
plan to use the products the use of endpoints is not supported (as it will
make WF a hybrid server for both)
Wolf
On Wed, Dec 5, 2018 at 12:17 PM Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 12/5/18 9:44 AM, Gunnar Morling wrote:
> Hey,
>
> I was trying to configure and inject an Infinispan cache through CDI,
> running on WildFly 14, using the Infinispan modules provided by the
> server.
>
> While I'm not sure whether that's something supported or recommended,
> I found this preferable over adding Infinispan another time as part of
> the deployment. I couldn't find any recent info on doing this (would
> love any pointers, though), so here's my findings, in case it's
> interesting for others:
You should not be using the Infinispan subsystem that comes with WildFly
as its configuration capabilities are a bit limited, but the modules we
supply:
http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_m...
> Btw. I also couldn't find an example for configuring a cache through
> jboss-cli.sh, perhaps that's something to consider, too?
Yes, that should be added.
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev