Hey all,
Thanks a lot for the quick replies!
To give some background on what I was trying to do: my intention was
to use a simple cache within my app for a demo + blog post I'm
creating on invalidating the JPA 2nd-level cache after external data
changes (i.e. bypassing the app) via Debezium:
https://github.com/debezium/debezium-examples/tree/master/cache-invalidation
https://github.com/debezium/debezium.github.io/pull/230
For that I need a simple in-app cache to keep track of all
transactions run by the app itself, so to keep them apart from
transactions run by external clients (as I need to invalidate the 2L
cache items only for the latter).
So the questions around support are not too much of a concern for my
purpose. Using the modules coming with the server seemed so easy in
comparison to putting the modules in place :) I'll try and have a look
at how this could be done in my Dockerfile (this btw. could be an
interesting example for you to have, too). Regarding CDI, I gave up on
this and just obtained a cache via the API. Seemed simpler in the end.
Thanks again,
--Gunnar
Am Mi., 5. Dez. 2018 um 13:02 Uhr schrieb Wolf Fink <wf...@redhat.com>:
>
> 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 <ttarr...@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_modules_for_wildfly_eap
>>
>> > 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
