As far as I know the latest 6.4 and 7.x On Thu, Dec 6, 2018 at 12:58 PM Gunnar Morling <gun...@hibernate.org> wrote:
> Yes, that's a good point. That's why we add the targeted WF version to > the id of the HV patch files (in general we try to only have one for > the latest WF at that point in time). A plain ZIP is more forgiving in > that regard, although I'd argue it should be tested and documented > which server versions are supported by a given ZIP (e.g. this wasn't > quite clear to me from the Infinispan docs). > Am Do., 6. Dez. 2018 um 11:05 Uhr schrieb Wolf Fink <wf...@redhat.com>: > > > > As the DG modules are for EAP6 and EAP7 there is no simple way to have > one zip for all releases. This means we have to multiply the zip if use > that approach and add more testing. > > > > On Thu, Dec 6, 2018 at 10:56 AM Gunnar Morling <gun...@hibernate.org> > wrote: > >> > >> Hi, > >> > >> So I'm using the module ZIP now and changed my app to depend on that > >> specific slot. Works nicely, thanks again. > >> > >> One quick note on the module ZIP: this adds modules to the server's > >> original "system" directory, so this can be tough to be undone, if > >> needed (not so much an issue when thinking of containerized immutable > >> infra, but the more traditional server admin might be more concerned). > >> Have you considered to provide a file using the server's patching > >> mechanism instead? It's still a ZIP essentially, but contains some > >> additional metadata. By applying this via jboss-cli.sh's patch > >> command, this can cleanly be undone (the contents are put into a > >> separate "overlays" directory instead of "system" itself). > >> > >> As an example, Hibernate Validator is providing a patch based on that > approach: > >> > >> > https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#_updating_hibernate_validator_in_wildfly > >> > >> We've also developed a Maven plug-in which helps to produce such patch > >> file. You can see it in use for HV here: > >> > >> > https://github.com/hibernate/hibernate-validator/blob/master/modules/pom.xml > >> > >> --Gunnar > >> > >> Am Mi., 5. Dez. 2018 um 17:01 Uhr schrieb Gunnar Morling < > gun...@hibernate.org>: > >> > > >> > > if all you want is to invalidate Hibernate ORM's 2LC caches, > Hibernate > >> > > exposes a specific API to do just that. > >> > > >> > Yes, I am aware of this (using the JPA method for that in the blog > post). > >> > > >> > But I only want to invalidate the caches after external transactions, > >> > i.e. not after transactions run by the app and Hibernate itself. Hence > >> > I'm keeping a cache of transaction ids run by the application, so the > >> > Debezium event handler can match incoming change events against them > >> > and only call evict() after transactions _not_ executed by the > >> > application. It's described in the blog post draft I linked, perhaps > >> > you can take a look and let me know in case I'm missing anything? > >> > Thanks! > >> > > >> > > >> > Am Mi., 5. Dez. 2018 um 16:40 Uhr schrieb Sanne Grinovero > >> > <sa...@infinispan.org>: > >> > > > >> > > Hi Gunnar, > >> > > > >> > > if all you want is to invalidate Hibernate ORM's 2LC caches, > Hibernate > >> > > exposes a specific API to do just that. > >> > > > >> > > Sanne > >> > > > >> > > On Wed, 5 Dec 2018 at 14:30, Gunnar Morling <gun...@hibernate.org> > wrote: > >> > > > > >> > > > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev