[infinispan-dev] Obtaining cache via CDI on WildFly

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Obtaining cache via CDI on WildFly

Gunnar Morling
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:

* A jboss-deployment-structure.xml file is needed for adding the
dependencies to the modules org.infinispan and org.infinispan.commons
* Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
part of WF, so it must be added to the deployment
* The transitive dependency from infinispan-cdi-embedded to
org.infinispan:infinispan-commons must be excluded, otherwise linking
errors will occur

Perhaps a small example of this could be added to the Infinispan docs?

Btw. I also couldn't find an example for configuring a cache through
jboss-cli.sh, perhaps that's something to consider, too?

Cheers,

--Gunnar
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Tristan Tarrant-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Sanne Grinovero-3
On Wed, 5 Dec 2018 at 11:16, Tristan Tarrant <[hidden email]> 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

Hi Gunnar,
to automate such things during integration testing, have a look at the
provisioning plugins for Maven.

 - https://github.com/infinispan/infinispan/tree/master/integrationtests/wildfly-modules
 - https://github.com/infinispan/infinispan/blob/master/integrationtests/wildfly-modules/pom.xml#L222-L249
 - https://github.com/infinispan/infinispan/blob/master/integrationtests/wildfly-modules/server-provisioning.xml

One the custom WildFly is built, you can use it "as usual" via Arquillian.

Don't use the Infinispan jars included within Wildfly as those are
"implementation detail": don't have all the bits necessary (e.g. CDI
integration) and are not tested nor supportable for such use case.

Hibernate OGM does something similar:
 - https://github.com/hibernate/hibernate-ogm/blob/master/integrationtest/server-provisioning.xml
It's not listing the Infinispan modules explicitly as some specific
OGM modules depend on them transitively, but you get the idea ;)

-- Sanne

>
> > 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Wolf Fink
In reply to this post by Tristan Tarrant-2
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Paul Ferraro
In reply to this post by Gunnar Morling
Gunnar,

While WF doesn't include infinispan-cdi integration, you can inject
Infinispan caches defined within the Infinispan subsystem as standard
EE resources via the their JNDI bindings.  This approach has the
advantage of container-managed lifecycle of the cache, even when
referenced by multiple deployments.

e.g.
@Resource(lookup = "java:jboss/infinispan/cache/foo/bar")
private Cache<?, ?> cache; // References the "bar" cache of the "foo"
cache container

or

@Resource(lookup = "java:jboss/infinispan/cache/foo/default")
private Cache<?, ?> cache; // References the default cache of the
"foo" cache container

Unfortunately, a long standing weld integration bug prevents @Resource
lookups from working correctly when the containing class is
instrumented by CDI.  To workaround this, move the JNDI lookup to a
<resource-ref/> or <resource-env-ref/> in your deployment descriptor
and reference your cache resource via its reference name.

e.g.
<resource-env-ref>
    <resource-env-ref-name>my-cache<resource-env-ref-name>
    <resource-env-ref-type>org.infinispan.Cache<resource-env-ref-type>
    <lookup-name>java:jboss/infinispan/cache/foo/bar</lookup-name>
</resource-env-ref>

@Resource(name = "my-cache")
private Cache<?, ?> cache;

Paul
On Wed, Dec 5, 2018 at 3:47 AM Gunnar Morling <[hidden email]> 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:
>
> * A jboss-deployment-structure.xml file is needed for adding the
> dependencies to the modules org.infinispan and org.infinispan.commons
> * Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
> part of WF, so it must be added to the deployment
> * The transitive dependency from infinispan-cdi-embedded to
> org.infinispan:infinispan-commons must be excluded, otherwise linking
> errors will occur
>
> Perhaps a small example of this could be added to the Infinispan docs?
>
> Btw. I also couldn't find an example for configuring a cache through
> jboss-cli.sh, perhaps that's something to consider, too?
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Gunnar Morling
In reply to this post by Wolf Fink
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 <[hidden email]>:

>
> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Sanne Grinovero-3
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 <[hidden email]> 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 <[hidden email]>:
> >
> > 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 <[hidden email]> 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
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Gunnar Morling
> 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
<[hidden email]>:

>
> 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 <[hidden email]> 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 <[hidden email]>:
> > >
> > > 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 <[hidden email]> 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
> > >> [hidden email]
> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Gunnar Morling
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 <[hidden email]>:

>
> > 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
> <[hidden email]>:
> >
> > 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 <[hidden email]> 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 <[hidden email]>:
> > > >
> > > > 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 <[hidden email]> 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
> > > >> [hidden email]
> > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Wolf Fink
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 <[hidden email]> 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 <[hidden email]>:
>
> > 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
> <[hidden email]>:
> >
> > 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 <[hidden email]> 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 <[hidden email]>:
> > > >
> > > > 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 <[hidden email]> 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
> > > >> [hidden email]
> > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Gunnar Morling
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 <[hidden email]>:

>
> 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 <[hidden email]> 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 <[hidden email]>:
>> >
>> > > 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
>> > <[hidden email]>:
>> > >
>> > > 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 <[hidden email]> 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 <[hidden email]>:
>> > > > >
>> > > > > 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 <[hidden email]> 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
>> > > > >> [hidden email]
>> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> > > >
>> > > > _______________________________________________
>> > > > infinispan-dev mailing list
>> > > > [hidden email]
>> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Wolf Fink
As far as I know the latest 6.4 and 7.x

On Thu, Dec 6, 2018 at 12:58 PM Gunnar Morling <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>> >
>> > > 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
>> > <[hidden email]>:
>> > >
>> > > 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 <[hidden email]> 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 <[hidden email]>:
>> > > > >
>> > > > > 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 <[hidden email]> 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
>> > > > >> [hidden email]
>> > > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> > > >
>> > > > _______________________________________________
>> > > > infinispan-dev mailing list
>> > > > [hidden email]
>> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev