[DISCUSSION] Continued Support for Infinispan

[Alex Porcelli <po...@apache.org>]

As part of the ongoing effort to upgrade to the latest Quarkus LTS version,
we’re currently dealing with the impact of aligning with Infinispan 15,
which introduces a new set of changes and potentially api compatibility
issues.

Given this context, I’d like to revisit the question: Do we really want to
continue supporting Infinispan?

This has been discussed in the past, and there was some resistance to
removing it. However, maintaining support goes beyond the existing
implementation—it requires us to stay on top of future upgrades, adapt to
API changes, and deal with potential security vulnerabilities stemming from
Infinispan itself and its transitive dependencies.

I believe it’s worth re-evaluating its value and whether it’s aligned with
the future direction of the project.

Looking forward to your thoughts.

-

Alex

Re: [DISCUSSION] Continued Support for Infinispan

[Alex Porcelli <po...@apache.org>]

Goal is to remove before the quarkus 3.20.0 upgrade.

And sue the upcoming 10.1.0 to announce the deprecation with the removal
for next release.


On Thu, Apr 3, 2025 at 3:11 AM Yeser Amer <ya...@apache.org> wrote:

> I agree to plan the component deprecation and then its removal in a future
> release.
>
> On 2025/04/02 22:32:25 ricardo zanini fernandes wrote:
> > Please +1 to deprecate. We can push for another tech stack in the future,
> > like Redis, if necessary. Currently, ISPN in our codebase is bringing
> more
> > harm than good. The tradeoff is not worth it IMO.
> >
> > On Wed, Apr 2, 2025 at 1:36 PM Jason Porter <li...@apache.org>
> wrote:
> >
> > > I have very little skin in this game, but I am also +1 for deprecation
> and
> > > removal. This will simplify what we need to support, examples (we'll
> have
> > > to make sure those are looked at, as well as documentation), and should
> > > also make maintenance easier.
> > >
> > > On 2025/04/01 23:05:02 Martin Weiler wrote:
> > > > +1 to deprecation and eventual removal of infinispan as persistence
> store
> > > >
> > > > Martin
> > > >
> > > > On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote:
> > > > > I'm +1 to deprecate and exclude the infinispan support from our
> > > > > deliverables, from the process engine persistence to data-index and
> > > > > jobs-service (including addons). In this case I think that keeping
> it
> > > for
> > > > > reference can be useful for users.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Pere
> > > > >
> > > > > On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com.invalid> wrote:
> > > > >
> > > > > > Yes, of course, I'm not worried about history, I'm worried about
> > > > > > visibility.
> > > > > > If Infinispan is still there with a deprecation notice,
> everybody,
> > > without
> > > > > > the need to visit the github log will know that it used to be
> there
> > > and was
> > > > > > explicitly deprecated.
> > > > > > And once it is out of the parent module, it won't be bothering
> > > anymore.
> > > > > > Anyway, I don't really care much, we can delete it.
> > > > > > It's not the first thing I will delete from Apps repo though,
> Trusty
> > > is
> > > > > > even more bothersome.
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me>
> > > wrote:
> > > > > >
> > > > > > > Thanks for the thoughtful response—I'm glad we're aligned on
> > > moving on
> > > > > > > from Infinispan.
> > > > > > >
> > > > > > > That said, I respectfully disagree with the idea of keeping the
> > > code
> > > > > > > in the repository but out of the build. One of the core
> purposes of
> > > > > > > Git is precisely to allow us to revisit and recover code from
> the
> > > past
> > > > > > > if needed. Keeping "dead code" in the codebase creates
> unnecessary
> > > > > > > maintenance overhead and potential confusion as the project
> > > evolves.
> > > > > > >
> > > > > > > If there's a need to bring it back in the future, we can always
> > > > > > > retrieve it from the commit history or a dedicated tag/branch.
> For
> > > > > > > now, I believe removing it entirely is the cleaner and more
> > > > > > > maintainable approach.
> > > > > > >
> > > > > > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > > > > > > <ft...@redhat.com.invalid> wrote:
> > > > > > > >
> > > > > > > > I agree to remove Inifinispan, although I have invested a
> > > substantial
> > > > > > > > amount of work to keep it working.
> > > > > > > > But we have better alternatives for embedded, both relational
> > > (embedded
> > > > > > > > postgresql, h2) and non relational (rocksbd)
> > > > > > > > Also, it does not have the same level of query support than
> > > Mongo and
> > > > > > > > Postgress (it is not possible to query variables or metadata)
> > > > > > > > Besides, I also find questionable the original decision to
> use
> > > it as
> > > > > > > > default data store, given the fact that the optimal use for
> > > Inifnispan
> > > > > > is
> > > > > > > > as persistent distributed cache (so, in a way, it was like
> using
> > > Kafka
> > > > > > as
> > > > > > > > datastore, possible, but not its original intent)
> > > > > > > > I think is good to deprecate it and focus on keeping JPA and
> > > mongoDB
> > > > > > > > implementation at the same level of functionality (currently
> > > Mongo is
> > > > > > > > slightly behind)
> > > > > > > > Thats said, I think that, rather than removing, we can
> exclude
> > > it (just
> > > > > > > > remove the reference from the parent POM and keep the code)
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <
> alex@porcelli.me>
> > > wrote:
> > > > > > > >
> > > > > > > > > I think those interfaces are already in place - at some
> > > extent. We
> > > > > > > have a
> > > > > > > > > few different db implementations already: mongo, Postgres,
> > > rocksdb;
> > > > > > so
> > > > > > > I’d
> > > > > > > > > suspect that it should be enough for now.
> > > > > > > > >
> > > > > > > > > I also would argue that H2 is also a reasonable solution
> for
> > > > > > in-memory
> > > > > > > with
> > > > > > > > > low cost and is now actively used in jBPM when running in
> dev
> > > mode.
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > Alex
> > > > > > > > >
> > > > > > > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > HI Alex,
> > > > > > > > > > I agree with your concern.
> > > > > > > > > > I do not know exactly where and why infinispan is used,
> but
> > > I also
> > > > > > > hit
> > > > > > > > > > issues with it during some upgrades.
> > > > > > > > > > From my POV the issue is that
> > > > > > > > > > 1. On one side, we want to provide in-memory support for
> our
> > > > > > > > > applications,
> > > > > > > > > > which is a good feature
> > > > > > > > > > 2. on the other side, we implemented specific solutions,
> with
> > > > > > > > > hard-binding
> > > > > > > > > > to that specific implementation (infinispan), that lead
> to
> > > the
> > > > > > issue
> > > > > > > you
> > > > > > > > > > mentioned
> > > > > > > > > >
> > > > > > > > > > Being everything open source, maybe a good solution
> would be
> > > to
> > > > > > > design
> > > > > > > > > and
> > > > > > > > > > provide API/interfaces for any "in-memory" database, and
> then
> > > > > > whoever
> > > > > > > > > wants
> > > > > > > > > > to create a specific implementation, outside our
> apache-kie
> > > > > > project,
> > > > > > > > > would
> > > > > > > > > > still be able to create it.
> > > > > > > > > >
> > > > > > > > > > Wdyt ?
> > > > > > > > > >
> > > > > > > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > > > > > > porcelli@apache.org
> > > > > > > > > > >
> > > > > > > > > > ha scritto:
> > > > > > > > > >
> > > > > > > > > > > As part of the ongoing effort to upgrade to the latest
> > > Quarkus
> > > > > > LTS
> > > > > > > > > > version,
> > > > > > > > > > > we’re currently dealing with the impact of aligning
> with
> > > > > > > Infinispan 15,
> > > > > > > > > > > which introduces a new set of changes and potentially
> api
> > > > > > > compatibility
> > > > > > > > > > > issues.
> > > > > > > > > > >
> > > > > > > > > > > Given this context, I’d like to revisit the question:
> Do we
> > > > > > really
> > > > > > > want
> > > > > > > > > > to
> > > > > > > > > > > continue supporting Infinispan?
> > > > > > > > > > >
> > > > > > > > > > > This has been discussed in the past, and there was some
> > > > > > resistance
> > > > > > > to
> > > > > > > > > > > removing it. However, maintaining support goes beyond
> the
> > > > > > existing
> > > > > > > > > > > implementation—it requires us to stay on top of future
> > > upgrades,
> > > > > > > adapt
> > > > > > > > > to
> > > > > > > > > > > API changes, and deal with potential security
> > > vulnerabilities
> > > > > > > stemming
> > > > > > > > > > from
> > > > > > > > > > > Infinispan itself and its transitive dependencies.
> > > > > > > > > > >
> > > > > > > > > > > I believe it’s worth re-evaluating its value and
> whether
> > > it’s
> > > > > > > aligned
> > > > > > > > > > with
> > > > > > > > > > > the future direction of the project.
> > > > > > > > > > >
> > > > > > > > > > > Looking forward to your thoughts.
> > > > > > > > > > >
> > > > > > > > > > > -
> > > > > > > > > > >
> > > > > > > > > > > Alex
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [DISCUSSION] Continued Support for Infinispan

[Yeser Amer <ya...@apache.org>]

I agree to plan the component deprecation and then its removal in a future release.

On 2025/04/02 22:32:25 ricardo zanini fernandes wrote:
> Please +1 to deprecate. We can push for another tech stack in the future,
> like Redis, if necessary. Currently, ISPN in our codebase is bringing more
> harm than good. The tradeoff is not worth it IMO.
> 
> On Wed, Apr 2, 2025 at 1:36 PM Jason Porter <li...@apache.org> wrote:
> 
> > I have very little skin in this game, but I am also +1 for deprecation and
> > removal. This will simplify what we need to support, examples (we'll have
> > to make sure those are looked at, as well as documentation), and should
> > also make maintenance easier.
> >
> > On 2025/04/01 23:05:02 Martin Weiler wrote:
> > > +1 to deprecation and eventual removal of infinispan as persistence store
> > >
> > > Martin
> > >
> > > On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote:
> > > > I'm +1 to deprecate and exclude the infinispan support from our
> > > > deliverables, from the process engine persistence to data-index and
> > > > jobs-service (including addons). In this case I think that keeping it
> > for
> > > > reference can be useful for users.
> > > >
> > > > Cheers,
> > > >
> > > > Pere
> > > >
> > > > On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com.invalid> wrote:
> > > >
> > > > > Yes, of course, I'm not worried about history, I'm worried about
> > > > > visibility.
> > > > > If Infinispan is still there with a deprecation notice, everybody,
> > without
> > > > > the need to visit the github log will know that it used to be there
> > and was
> > > > > explicitly deprecated.
> > > > > And once it is out of the parent module, it won't be bothering
> > anymore.
> > > > > Anyway, I don't really care much, we can delete it.
> > > > > It's not the first thing I will delete from Apps repo though, Trusty
> > is
> > > > > even more bothersome.
> > > > >
> > > > >
> > > > > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > > >
> > > > > > Thanks for the thoughtful response—I'm glad we're aligned on
> > moving on
> > > > > > from Infinispan.
> > > > > >
> > > > > > That said, I respectfully disagree with the idea of keeping the
> > code
> > > > > > in the repository but out of the build. One of the core purposes of
> > > > > > Git is precisely to allow us to revisit and recover code from the
> > past
> > > > > > if needed. Keeping "dead code" in the codebase creates unnecessary
> > > > > > maintenance overhead and potential confusion as the project
> > evolves.
> > > > > >
> > > > > > If there's a need to bring it back in the future, we can always
> > > > > > retrieve it from the commit history or a dedicated tag/branch. For
> > > > > > now, I believe removing it entirely is the cleaner and more
> > > > > > maintainable approach.
> > > > > >
> > > > > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > > > > > <ft...@redhat.com.invalid> wrote:
> > > > > > >
> > > > > > > I agree to remove Inifinispan, although I have invested a
> > substantial
> > > > > > > amount of work to keep it working.
> > > > > > > But we have better alternatives for embedded, both relational
> > (embedded
> > > > > > > postgresql, h2) and non relational (rocksbd)
> > > > > > > Also, it does not have the same level of query support than
> > Mongo and
> > > > > > > Postgress (it is not possible to query variables or metadata)
> > > > > > > Besides, I also find questionable the original decision to use
> > it as
> > > > > > > default data store, given the fact that the optimal use for
> > Inifnispan
> > > > > is
> > > > > > > as persistent distributed cache (so, in a way, it was like using
> > Kafka
> > > > > as
> > > > > > > datastore, possible, but not its original intent)
> > > > > > > I think is good to deprecate it and focus on keeping JPA and
> > mongoDB
> > > > > > > implementation at the same level of functionality (currently
> > Mongo is
> > > > > > > slightly behind)
> > > > > > > Thats said, I think that, rather than removing, we can exclude
> > it (just
> > > > > > > remove the reference from the parent POM and keep the code)
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me>
> > wrote:
> > > > > > >
> > > > > > > > I think those interfaces are already in place - at some
> > extent. We
> > > > > > have a
> > > > > > > > few different db implementations already: mongo, Postgres,
> > rocksdb;
> > > > > so
> > > > > > I’d
> > > > > > > > suspect that it should be enough for now.
> > > > > > > >
> > > > > > > > I also would argue that H2 is also a reasonable solution for
> > > > > in-memory
> > > > > > with
> > > > > > > > low cost and is now actively used in jBPM when running in dev
> > mode.
> > > > > > > >
> > > > > > > > -
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > HI Alex,
> > > > > > > > > I agree with your concern.
> > > > > > > > > I do not know exactly where and why infinispan is used, but
> > I also
> > > > > > hit
> > > > > > > > > issues with it during some upgrades.
> > > > > > > > > From my POV the issue is that
> > > > > > > > > 1. On one side, we want to provide in-memory support for our
> > > > > > > > applications,
> > > > > > > > > which is a good feature
> > > > > > > > > 2. on the other side, we implemented specific solutions, with
> > > > > > > > hard-binding
> > > > > > > > > to that specific implementation (infinispan), that lead to
> > the
> > > > > issue
> > > > > > you
> > > > > > > > > mentioned
> > > > > > > > >
> > > > > > > > > Being everything open source, maybe a good solution would be
> > to
> > > > > > design
> > > > > > > > and
> > > > > > > > > provide API/interfaces for any "in-memory" database, and then
> > > > > whoever
> > > > > > > > wants
> > > > > > > > > to create a specific implementation, outside our apache-kie
> > > > > project,
> > > > > > > > would
> > > > > > > > > still be able to create it.
> > > > > > > > >
> > > > > > > > > Wdyt ?
> > > > > > > > >
> > > > > > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > > > > > porcelli@apache.org
> > > > > > > > > >
> > > > > > > > > ha scritto:
> > > > > > > > >
> > > > > > > > > > As part of the ongoing effort to upgrade to the latest
> > Quarkus
> > > > > LTS
> > > > > > > > > version,
> > > > > > > > > > we’re currently dealing with the impact of aligning with
> > > > > > Infinispan 15,
> > > > > > > > > > which introduces a new set of changes and potentially api
> > > > > > compatibility
> > > > > > > > > > issues.
> > > > > > > > > >
> > > > > > > > > > Given this context, I’d like to revisit the question: Do we
> > > > > really
> > > > > > want
> > > > > > > > > to
> > > > > > > > > > continue supporting Infinispan?
> > > > > > > > > >
> > > > > > > > > > This has been discussed in the past, and there was some
> > > > > resistance
> > > > > > to
> > > > > > > > > > removing it. However, maintaining support goes beyond the
> > > > > existing
> > > > > > > > > > implementation—it requires us to stay on top of future
> > upgrades,
> > > > > > adapt
> > > > > > > > to
> > > > > > > > > > API changes, and deal with potential security
> > vulnerabilities
> > > > > > stemming
> > > > > > > > > from
> > > > > > > > > > Infinispan itself and its transitive dependencies.
> > > > > > > > > >
> > > > > > > > > > I believe it’s worth re-evaluating its value and whether
> > it’s
> > > > > > aligned
> > > > > > > > > with
> > > > > > > > > > the future direction of the project.
> > > > > > > > > >
> > > > > > > > > > Looking forward to your thoughts.
> > > > > > > > > >
> > > > > > > > > > -
> > > > > > > > > >
> > > > > > > > > > Alex
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [DISCUSSION] Continued Support for Infinispan

[ricardo zanini fernandes <ri...@gmail.com>]

Please +1 to deprecate. We can push for another tech stack in the future,
like Redis, if necessary. Currently, ISPN in our codebase is bringing more
harm than good. The tradeoff is not worth it IMO.

On Wed, Apr 2, 2025 at 1:36 PM Jason Porter <li...@apache.org> wrote:

> I have very little skin in this game, but I am also +1 for deprecation and
> removal. This will simplify what we need to support, examples (we'll have
> to make sure those are looked at, as well as documentation), and should
> also make maintenance easier.
>
> On 2025/04/01 23:05:02 Martin Weiler wrote:
> > +1 to deprecation and eventual removal of infinispan as persistence store
> >
> > Martin
> >
> > On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote:
> > > I'm +1 to deprecate and exclude the infinispan support from our
> > > deliverables, from the process engine persistence to data-index and
> > > jobs-service (including addons). In this case I think that keeping it
> for
> > > reference can be useful for users.
> > >
> > > Cheers,
> > >
> > > Pere
> > >
> > > On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
> > > <ft...@redhat.com.invalid> wrote:
> > >
> > > > Yes, of course, I'm not worried about history, I'm worried about
> > > > visibility.
> > > > If Infinispan is still there with a deprecation notice, everybody,
> without
> > > > the need to visit the github log will know that it used to be there
> and was
> > > > explicitly deprecated.
> > > > And once it is out of the parent module, it won't be bothering
> anymore.
> > > > Anyway, I don't really care much, we can delete it.
> > > > It's not the first thing I will delete from Apps repo though, Trusty
> is
> > > > even more bothersome.
> > > >
> > > >
> > > > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me>
> wrote:
> > > >
> > > > > Thanks for the thoughtful response—I'm glad we're aligned on
> moving on
> > > > > from Infinispan.
> > > > >
> > > > > That said, I respectfully disagree with the idea of keeping the
> code
> > > > > in the repository but out of the build. One of the core purposes of
> > > > > Git is precisely to allow us to revisit and recover code from the
> past
> > > > > if needed. Keeping "dead code" in the codebase creates unnecessary
> > > > > maintenance overhead and potential confusion as the project
> evolves.
> > > > >
> > > > > If there's a need to bring it back in the future, we can always
> > > > > retrieve it from the commit history or a dedicated tag/branch. For
> > > > > now, I believe removing it entirely is the cleaner and more
> > > > > maintainable approach.
> > > > >
> > > > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > > > > <ft...@redhat.com.invalid> wrote:
> > > > > >
> > > > > > I agree to remove Inifinispan, although I have invested a
> substantial
> > > > > > amount of work to keep it working.
> > > > > > But we have better alternatives for embedded, both relational
> (embedded
> > > > > > postgresql, h2) and non relational (rocksbd)
> > > > > > Also, it does not have the same level of query support than
> Mongo and
> > > > > > Postgress (it is not possible to query variables or metadata)
> > > > > > Besides, I also find questionable the original decision to use
> it as
> > > > > > default data store, given the fact that the optimal use for
> Inifnispan
> > > > is
> > > > > > as persistent distributed cache (so, in a way, it was like using
> Kafka
> > > > as
> > > > > > datastore, possible, but not its original intent)
> > > > > > I think is good to deprecate it and focus on keeping JPA and
> mongoDB
> > > > > > implementation at the same level of functionality (currently
> Mongo is
> > > > > > slightly behind)
> > > > > > Thats said, I think that, rather than removing, we can exclude
> it (just
> > > > > > remove the reference from the parent POM and keep the code)
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me>
> wrote:
> > > > > >
> > > > > > > I think those interfaces are already in place - at some
> extent. We
> > > > > have a
> > > > > > > few different db implementations already: mongo, Postgres,
> rocksdb;
> > > > so
> > > > > I’d
> > > > > > > suspect that it should be enough for now.
> > > > > > >
> > > > > > > I also would argue that H2 is also a reasonable solution for
> > > > in-memory
> > > > > with
> > > > > > > low cost and is now actively used in jBPM when running in dev
> mode.
> > > > > > >
> > > > > > > -
> > > > > > > Alex
> > > > > > >
> > > > > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > > > > gabriele.cardosi@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > HI Alex,
> > > > > > > > I agree with your concern.
> > > > > > > > I do not know exactly where and why infinispan is used, but
> I also
> > > > > hit
> > > > > > > > issues with it during some upgrades.
> > > > > > > > From my POV the issue is that
> > > > > > > > 1. On one side, we want to provide in-memory support for our
> > > > > > > applications,
> > > > > > > > which is a good feature
> > > > > > > > 2. on the other side, we implemented specific solutions, with
> > > > > > > hard-binding
> > > > > > > > to that specific implementation (infinispan), that lead to
> the
> > > > issue
> > > > > you
> > > > > > > > mentioned
> > > > > > > >
> > > > > > > > Being everything open source, maybe a good solution would be
> to
> > > > > design
> > > > > > > and
> > > > > > > > provide API/interfaces for any "in-memory" database, and then
> > > > whoever
> > > > > > > wants
> > > > > > > > to create a specific implementation, outside our apache-kie
> > > > project,
> > > > > > > would
> > > > > > > > still be able to create it.
> > > > > > > >
> > > > > > > > Wdyt ?
> > > > > > > >
> > > > > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > > > > porcelli@apache.org
> > > > > > > > >
> > > > > > > > ha scritto:
> > > > > > > >
> > > > > > > > > As part of the ongoing effort to upgrade to the latest
> Quarkus
> > > > LTS
> > > > > > > > version,
> > > > > > > > > we’re currently dealing with the impact of aligning with
> > > > > Infinispan 15,
> > > > > > > > > which introduces a new set of changes and potentially api
> > > > > compatibility
> > > > > > > > > issues.
> > > > > > > > >
> > > > > > > > > Given this context, I’d like to revisit the question: Do we
> > > > really
> > > > > want
> > > > > > > > to
> > > > > > > > > continue supporting Infinispan?
> > > > > > > > >
> > > > > > > > > This has been discussed in the past, and there was some
> > > > resistance
> > > > > to
> > > > > > > > > removing it. However, maintaining support goes beyond the
> > > > existing
> > > > > > > > > implementation—it requires us to stay on top of future
> upgrades,
> > > > > adapt
> > > > > > > to
> > > > > > > > > API changes, and deal with potential security
> vulnerabilities
> > > > > stemming
> > > > > > > > from
> > > > > > > > > Infinispan itself and its transitive dependencies.
> > > > > > > > >
> > > > > > > > > I believe it’s worth re-evaluating its value and whether
> it’s
> > > > > aligned
> > > > > > > > with
> > > > > > > > > the future direction of the project.
> > > > > > > > >
> > > > > > > > > Looking forward to your thoughts.
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > >
> > > > > > > > > Alex
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [DISCUSSION] Continued Support for Infinispan

[Jason Porter <li...@apache.org>]

I have very little skin in this game, but I am also +1 for deprecation and removal. This will simplify what we need to support, examples (we'll have to make sure those are looked at, as well as documentation), and should also make maintenance easier.

On 2025/04/01 23:05:02 Martin Weiler wrote:
> +1 to deprecation and eventual removal of infinispan as persistence store
> 
> Martin
> 
> On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote:
> > I'm +1 to deprecate and exclude the infinispan support from our
> > deliverables, from the process engine persistence to data-index and
> > jobs-service (including addons). In this case I think that keeping it for
> > reference can be useful for users.
> > 
> > Cheers,
> > 
> > Pere
> > 
> > On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
> > <ft...@redhat.com.invalid> wrote:
> > 
> > > Yes, of course, I'm not worried about history, I'm worried about
> > > visibility.
> > > If Infinispan is still there with a deprecation notice, everybody, without
> > > the need to visit the github log will know that it used to be there and was
> > > explicitly deprecated.
> > > And once it is out of the parent module, it won't be bothering anymore.
> > > Anyway, I don't really care much, we can delete it.
> > > It's not the first thing I will delete from Apps repo though, Trusty is
> > > even more bothersome.
> > >
> > >
> > > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > > Thanks for the thoughtful response—I'm glad we're aligned on moving on
> > > > from Infinispan.
> > > >
> > > > That said, I respectfully disagree with the idea of keeping the code
> > > > in the repository but out of the build. One of the core purposes of
> > > > Git is precisely to allow us to revisit and recover code from the past
> > > > if needed. Keeping "dead code" in the codebase creates unnecessary
> > > > maintenance overhead and potential confusion as the project evolves.
> > > >
> > > > If there's a need to bring it back in the future, we can always
> > > > retrieve it from the commit history or a dedicated tag/branch. For
> > > > now, I believe removing it entirely is the cleaner and more
> > > > maintainable approach.
> > > >
> > > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > > > <ft...@redhat.com.invalid> wrote:
> > > > >
> > > > > I agree to remove Inifinispan, although I have invested a substantial
> > > > > amount of work to keep it working.
> > > > > But we have better alternatives for embedded, both relational (embedded
> > > > > postgresql, h2) and non relational (rocksbd)
> > > > > Also, it does not have the same level of query support than Mongo and
> > > > > Postgress (it is not possible to query variables or metadata)
> > > > > Besides, I also find questionable the original decision to use it as
> > > > > default data store, given the fact that the optimal use for Inifnispan
> > > is
> > > > > as persistent distributed cache (so, in a way, it was like using Kafka
> > > as
> > > > > datastore, possible, but not its original intent)
> > > > > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > > > > implementation at the same level of functionality (currently Mongo is
> > > > > slightly behind)
> > > > > Thats said, I think that, rather than removing, we can exclude it (just
> > > > > remove the reference from the parent POM and keep the code)
> > > > >
> > > > >
> > > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> > > > >
> > > > > > I think those interfaces are already in place - at some extent. We
> > > > have a
> > > > > > few different db implementations already: mongo, Postgres, rocksdb;
> > > so
> > > > I’d
> > > > > > suspect that it should be enough for now.
> > > > > >
> > > > > > I also would argue that H2 is also a reasonable solution for
> > > in-memory
> > > > with
> > > > > > low cost and is now actively used in jBPM when running in dev mode.
> > > > > >
> > > > > > -
> > > > > > Alex
> > > > > >
> > > > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > > > gabriele.cardosi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > HI Alex,
> > > > > > > I agree with your concern.
> > > > > > > I do not know exactly where and why infinispan is used, but I also
> > > > hit
> > > > > > > issues with it during some upgrades.
> > > > > > > From my POV the issue is that
> > > > > > > 1. On one side, we want to provide in-memory support for our
> > > > > > applications,
> > > > > > > which is a good feature
> > > > > > > 2. on the other side, we implemented specific solutions, with
> > > > > > hard-binding
> > > > > > > to that specific implementation (infinispan), that lead to the
> > > issue
> > > > you
> > > > > > > mentioned
> > > > > > >
> > > > > > > Being everything open source, maybe a good solution would be to
> > > > design
> > > > > > and
> > > > > > > provide API/interfaces for any "in-memory" database, and then
> > > whoever
> > > > > > wants
> > > > > > > to create a specific implementation, outside our apache-kie
> > > project,
> > > > > > would
> > > > > > > still be able to create it.
> > > > > > >
> > > > > > > Wdyt ?
> > > > > > >
> > > > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > > > porcelli@apache.org
> > > > > > > >
> > > > > > > ha scritto:
> > > > > > >
> > > > > > > > As part of the ongoing effort to upgrade to the latest Quarkus
> > > LTS
> > > > > > > version,
> > > > > > > > we’re currently dealing with the impact of aligning with
> > > > Infinispan 15,
> > > > > > > > which introduces a new set of changes and potentially api
> > > > compatibility
> > > > > > > > issues.
> > > > > > > >
> > > > > > > > Given this context, I’d like to revisit the question: Do we
> > > really
> > > > want
> > > > > > > to
> > > > > > > > continue supporting Infinispan?
> > > > > > > >
> > > > > > > > This has been discussed in the past, and there was some
> > > resistance
> > > > to
> > > > > > > > removing it. However, maintaining support goes beyond the
> > > existing
> > > > > > > > implementation—it requires us to stay on top of future upgrades,
> > > > adapt
> > > > > > to
> > > > > > > > API changes, and deal with potential security vulnerabilities
> > > > stemming
> > > > > > > from
> > > > > > > > Infinispan itself and its transitive dependencies.
> > > > > > > >
> > > > > > > > I believe it’s worth re-evaluating its value and whether it’s
> > > > aligned
> > > > > > > with
> > > > > > > > the future direction of the project.
> > > > > > > >
> > > > > > > > Looking forward to your thoughts.
> > > > > > > >
> > > > > > > > -
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [DISCUSSION] Continued Support for Infinispan

[Martin Weiler <mw...@apache.org>]

+1 to deprecation and eventual removal of infinispan as persistence store

Martin

On 2025/04/01 16:34:45 "Pere Fernandez (apache)" wrote:
> I'm +1 to deprecate and exclude the infinispan support from our
> deliverables, from the process engine persistence to data-index and
> jobs-service (including addons). In this case I think that keeping it for
> reference can be useful for users.
> 
> Cheers,
> 
> Pere
> 
> On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
> <ft...@redhat.com.invalid> wrote:
> 
> > Yes, of course, I'm not worried about history, I'm worried about
> > visibility.
> > If Infinispan is still there with a deprecation notice, everybody, without
> > the need to visit the github log will know that it used to be there and was
> > explicitly deprecated.
> > And once it is out of the parent module, it won't be bothering anymore.
> > Anyway, I don't really care much, we can delete it.
> > It's not the first thing I will delete from Apps repo though, Trusty is
> > even more bothersome.
> >
> >
> > On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Thanks for the thoughtful response—I'm glad we're aligned on moving on
> > > from Infinispan.
> > >
> > > That said, I respectfully disagree with the idea of keeping the code
> > > in the repository but out of the build. One of the core purposes of
> > > Git is precisely to allow us to revisit and recover code from the past
> > > if needed. Keeping "dead code" in the codebase creates unnecessary
> > > maintenance overhead and potential confusion as the project evolves.
> > >
> > > If there's a need to bring it back in the future, we can always
> > > retrieve it from the commit history or a dedicated tag/branch. For
> > > now, I believe removing it entirely is the cleaner and more
> > > maintainable approach.
> > >
> > > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > > <ft...@redhat.com.invalid> wrote:
> > > >
> > > > I agree to remove Inifinispan, although I have invested a substantial
> > > > amount of work to keep it working.
> > > > But we have better alternatives for embedded, both relational (embedded
> > > > postgresql, h2) and non relational (rocksbd)
> > > > Also, it does not have the same level of query support than Mongo and
> > > > Postgress (it is not possible to query variables or metadata)
> > > > Besides, I also find questionable the original decision to use it as
> > > > default data store, given the fact that the optimal use for Inifnispan
> > is
> > > > as persistent distributed cache (so, in a way, it was like using Kafka
> > as
> > > > datastore, possible, but not its original intent)
> > > > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > > > implementation at the same level of functionality (currently Mongo is
> > > > slightly behind)
> > > > Thats said, I think that, rather than removing, we can exclude it (just
> > > > remove the reference from the parent POM and keep the code)
> > > >
> > > >
> > > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> > > >
> > > > > I think those interfaces are already in place - at some extent. We
> > > have a
> > > > > few different db implementations already: mongo, Postgres, rocksdb;
> > so
> > > I’d
> > > > > suspect that it should be enough for now.
> > > > >
> > > > > I also would argue that H2 is also a reasonable solution for
> > in-memory
> > > with
> > > > > low cost and is now actively used in jBPM when running in dev mode.
> > > > >
> > > > > -
> > > > > Alex
> > > > >
> > > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > > gabriele.cardosi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > HI Alex,
> > > > > > I agree with your concern.
> > > > > > I do not know exactly where and why infinispan is used, but I also
> > > hit
> > > > > > issues with it during some upgrades.
> > > > > > From my POV the issue is that
> > > > > > 1. On one side, we want to provide in-memory support for our
> > > > > applications,
> > > > > > which is a good feature
> > > > > > 2. on the other side, we implemented specific solutions, with
> > > > > hard-binding
> > > > > > to that specific implementation (infinispan), that lead to the
> > issue
> > > you
> > > > > > mentioned
> > > > > >
> > > > > > Being everything open source, maybe a good solution would be to
> > > design
> > > > > and
> > > > > > provide API/interfaces for any "in-memory" database, and then
> > whoever
> > > > > wants
> > > > > > to create a specific implementation, outside our apache-kie
> > project,
> > > > > would
> > > > > > still be able to create it.
> > > > > >
> > > > > > Wdyt ?
> > > > > >
> > > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > > porcelli@apache.org
> > > > > > >
> > > > > > ha scritto:
> > > > > >
> > > > > > > As part of the ongoing effort to upgrade to the latest Quarkus
> > LTS
> > > > > > version,
> > > > > > > we’re currently dealing with the impact of aligning with
> > > Infinispan 15,
> > > > > > > which introduces a new set of changes and potentially api
> > > compatibility
> > > > > > > issues.
> > > > > > >
> > > > > > > Given this context, I’d like to revisit the question: Do we
> > really
> > > want
> > > > > > to
> > > > > > > continue supporting Infinispan?
> > > > > > >
> > > > > > > This has been discussed in the past, and there was some
> > resistance
> > > to
> > > > > > > removing it. However, maintaining support goes beyond the
> > existing
> > > > > > > implementation—it requires us to stay on top of future upgrades,
> > > adapt
> > > > > to
> > > > > > > API changes, and deal with potential security vulnerabilities
> > > stemming
> > > > > > from
> > > > > > > Infinispan itself and its transitive dependencies.
> > > > > > >
> > > > > > > I believe it’s worth re-evaluating its value and whether it’s
> > > aligned
> > > > > > with
> > > > > > > the future direction of the project.
> > > > > > >
> > > > > > > Looking forward to your thoughts.
> > > > > > >
> > > > > > > -
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [DISCUSSION] Continued Support for Infinispan

["Pere Fernandez (apache)" <pe...@apache.org>]

I'm +1 to deprecate and exclude the infinispan support from our
deliverables, from the process engine persistence to data-index and
jobs-service (including addons). In this case I think that keeping it for
reference can be useful for users.

Cheers,

Pere

On Tue, 1 Apr 2025 at 16:08, Francisco Javier Tirado Sarti
<ft...@redhat.com.invalid> wrote:

> Yes, of course, I'm not worried about history, I'm worried about
> visibility.
> If Infinispan is still there with a deprecation notice, everybody, without
> the need to visit the github log will know that it used to be there and was
> explicitly deprecated.
> And once it is out of the parent module, it won't be bothering anymore.
> Anyway, I don't really care much, we can delete it.
> It's not the first thing I will delete from Apps repo though, Trusty is
> even more bothersome.
>
>
> On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Thanks for the thoughtful response—I'm glad we're aligned on moving on
> > from Infinispan.
> >
> > That said, I respectfully disagree with the idea of keeping the code
> > in the repository but out of the build. One of the core purposes of
> > Git is precisely to allow us to revisit and recover code from the past
> > if needed. Keeping "dead code" in the codebase creates unnecessary
> > maintenance overhead and potential confusion as the project evolves.
> >
> > If there's a need to bring it back in the future, we can always
> > retrieve it from the commit history or a dedicated tag/branch. For
> > now, I believe removing it entirely is the cleaner and more
> > maintainable approach.
> >
> > On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> > <ft...@redhat.com.invalid> wrote:
> > >
> > > I agree to remove Inifinispan, although I have invested a substantial
> > > amount of work to keep it working.
> > > But we have better alternatives for embedded, both relational (embedded
> > > postgresql, h2) and non relational (rocksbd)
> > > Also, it does not have the same level of query support than Mongo and
> > > Postgress (it is not possible to query variables or metadata)
> > > Besides, I also find questionable the original decision to use it as
> > > default data store, given the fact that the optimal use for Inifnispan
> is
> > > as persistent distributed cache (so, in a way, it was like using Kafka
> as
> > > datastore, possible, but not its original intent)
> > > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > > implementation at the same level of functionality (currently Mongo is
> > > slightly behind)
> > > Thats said, I think that, rather than removing, we can exclude it (just
> > > remove the reference from the parent POM and keep the code)
> > >
> > >
> > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > > I think those interfaces are already in place - at some extent. We
> > have a
> > > > few different db implementations already: mongo, Postgres, rocksdb;
> so
> > I’d
> > > > suspect that it should be enough for now.
> > > >
> > > > I also would argue that H2 is also a reasonable solution for
> in-memory
> > with
> > > > low cost and is now actively used in jBPM when running in dev mode.
> > > >
> > > > -
> > > > Alex
> > > >
> > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > HI Alex,
> > > > > I agree with your concern.
> > > > > I do not know exactly where and why infinispan is used, but I also
> > hit
> > > > > issues with it during some upgrades.
> > > > > From my POV the issue is that
> > > > > 1. On one side, we want to provide in-memory support for our
> > > > applications,
> > > > > which is a good feature
> > > > > 2. on the other side, we implemented specific solutions, with
> > > > hard-binding
> > > > > to that specific implementation (infinispan), that lead to the
> issue
> > you
> > > > > mentioned
> > > > >
> > > > > Being everything open source, maybe a good solution would be to
> > design
> > > > and
> > > > > provide API/interfaces for any "in-memory" database, and then
> whoever
> > > > wants
> > > > > to create a specific implementation, outside our apache-kie
> project,
> > > > would
> > > > > still be able to create it.
> > > > >
> > > > > Wdyt ?
> > > > >
> > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > porcelli@apache.org
> > > > > >
> > > > > ha scritto:
> > > > >
> > > > > > As part of the ongoing effort to upgrade to the latest Quarkus
> LTS
> > > > > version,
> > > > > > we’re currently dealing with the impact of aligning with
> > Infinispan 15,
> > > > > > which introduces a new set of changes and potentially api
> > compatibility
> > > > > > issues.
> > > > > >
> > > > > > Given this context, I’d like to revisit the question: Do we
> really
> > want
> > > > > to
> > > > > > continue supporting Infinispan?
> > > > > >
> > > > > > This has been discussed in the past, and there was some
> resistance
> > to
> > > > > > removing it. However, maintaining support goes beyond the
> existing
> > > > > > implementation—it requires us to stay on top of future upgrades,
> > adapt
> > > > to
> > > > > > API changes, and deal with potential security vulnerabilities
> > stemming
> > > > > from
> > > > > > Infinispan itself and its transitive dependencies.
> > > > > >
> > > > > > I believe it’s worth re-evaluating its value and whether it’s
> > aligned
> > > > > with
> > > > > > the future direction of the project.
> > > > > >
> > > > > > Looking forward to your thoughts.
> > > > > >
> > > > > > -
> > > > > >
> > > > > > Alex
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>

Re: [DISCUSSION] Continued Support for Infinispan

[Francisco Javier Tirado Sarti <ft...@redhat.com.INVALID>]

Yes, of course, I'm not worried about history, I'm worried about
visibility.
If Infinispan is still there with a deprecation notice, everybody, without
the need to visit the github log will know that it used to be there and was
explicitly deprecated.
And once it is out of the parent module, it won't be bothering anymore.
Anyway, I don't really care much, we can delete it.
It's not the first thing I will delete from Apps repo though, Trusty is
even more bothersome.


On Tue, Apr 1, 2025 at 4:01 PM Alex Porcelli <al...@porcelli.me> wrote:

> Thanks for the thoughtful response—I'm glad we're aligned on moving on
> from Infinispan.
>
> That said, I respectfully disagree with the idea of keeping the code
> in the repository but out of the build. One of the core purposes of
> Git is precisely to allow us to revisit and recover code from the past
> if needed. Keeping "dead code" in the codebase creates unnecessary
> maintenance overhead and potential confusion as the project evolves.
>
> If there's a need to bring it back in the future, we can always
> retrieve it from the commit history or a dedicated tag/branch. For
> now, I believe removing it entirely is the cleaner and more
> maintainable approach.
>
> On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
> <ft...@redhat.com.invalid> wrote:
> >
> > I agree to remove Inifinispan, although I have invested a substantial
> > amount of work to keep it working.
> > But we have better alternatives for embedded, both relational (embedded
> > postgresql, h2) and non relational (rocksbd)
> > Also, it does not have the same level of query support than Mongo and
> > Postgress (it is not possible to query variables or metadata)
> > Besides, I also find questionable the original decision to use it as
> > default data store, given the fact that the optimal use for Inifnispan is
> > as persistent distributed cache (so, in a way, it was like using Kafka as
> > datastore, possible, but not its original intent)
> > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > implementation at the same level of functionality (currently Mongo is
> > slightly behind)
> > Thats said, I think that, rather than removing, we can exclude it (just
> > remove the reference from the parent POM and keep the code)
> >
> >
> > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > I think those interfaces are already in place - at some extent. We
> have a
> > > few different db implementations already: mongo, Postgres, rocksdb; so
> I’d
> > > suspect that it should be enough for now.
> > >
> > > I also would argue that H2 is also a reasonable solution for in-memory
> with
> > > low cost and is now actively used in jBPM when running in dev mode.
> > >
> > > -
> > > Alex
> > >
> > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > HI Alex,
> > > > I agree with your concern.
> > > > I do not know exactly where and why infinispan is used, but I also
> hit
> > > > issues with it during some upgrades.
> > > > From my POV the issue is that
> > > > 1. On one side, we want to provide in-memory support for our
> > > applications,
> > > > which is a good feature
> > > > 2. on the other side, we implemented specific solutions, with
> > > hard-binding
> > > > to that specific implementation (infinispan), that lead to the issue
> you
> > > > mentioned
> > > >
> > > > Being everything open source, maybe a good solution would be to
> design
> > > and
> > > > provide API/interfaces for any "in-memory" database, and then whoever
> > > wants
> > > > to create a specific implementation, outside our apache-kie project,
> > > would
> > > > still be able to create it.
> > > >
> > > > Wdyt ?
> > > >
> > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > porcelli@apache.org
> > > > >
> > > > ha scritto:
> > > >
> > > > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > > > version,
> > > > > we’re currently dealing with the impact of aligning with
> Infinispan 15,
> > > > > which introduces a new set of changes and potentially api
> compatibility
> > > > > issues.
> > > > >
> > > > > Given this context, I’d like to revisit the question: Do we really
> want
> > > > to
> > > > > continue supporting Infinispan?
> > > > >
> > > > > This has been discussed in the past, and there was some resistance
> to
> > > > > removing it. However, maintaining support goes beyond the existing
> > > > > implementation—it requires us to stay on top of future upgrades,
> adapt
> > > to
> > > > > API changes, and deal with potential security vulnerabilities
> stemming
> > > > from
> > > > > Infinispan itself and its transitive dependencies.
> > > > >
> > > > > I believe it’s worth re-evaluating its value and whether it’s
> aligned
> > > > with
> > > > > the future direction of the project.
> > > > >
> > > > > Looking forward to your thoughts.
> > > > >
> > > > > -
> > > > >
> > > > > Alex
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [DISCUSSION] Continued Support for Infinispan

[Alex Porcelli <al...@porcelli.me>]

Thanks for the thoughtful response—I'm glad we're aligned on moving on
from Infinispan.

That said, I respectfully disagree with the idea of keeping the code
in the repository but out of the build. One of the core purposes of
Git is precisely to allow us to revisit and recover code from the past
if needed. Keeping "dead code" in the codebase creates unnecessary
maintenance overhead and potential confusion as the project evolves.

If there's a need to bring it back in the future, we can always
retrieve it from the commit history or a dedicated tag/branch. For
now, I believe removing it entirely is the cleaner and more
maintainable approach.

On Tue, Apr 1, 2025 at 8:36 AM Francisco Javier Tirado Sarti
<ft...@redhat.com.invalid> wrote:
>
> I agree to remove Inifinispan, although I have invested a substantial
> amount of work to keep it working.
> But we have better alternatives for embedded, both relational (embedded
> postgresql, h2) and non relational (rocksbd)
> Also, it does not have the same level of query support than Mongo and
> Postgress (it is not possible to query variables or metadata)
> Besides, I also find questionable the original decision to use it as
> default data store, given the fact that the optimal use for Inifnispan is
> as persistent distributed cache (so, in a way, it was like using Kafka as
> datastore, possible, but not its original intent)
> I think is good to deprecate it and focus on keeping JPA and mongoDB
> implementation at the same level of functionality (currently Mongo is
> slightly behind)
> Thats said, I think that, rather than removing, we can exclude it (just
> remove the reference from the parent POM and keep the code)
>
>
> On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > I think those interfaces are already in place - at some extent. We have a
> > few different db implementations already: mongo, Postgres, rocksdb; so I’d
> > suspect that it should be enough for now.
> >
> > I also would argue that H2 is also a reasonable solution for in-memory with
> > low cost and is now actively used in jBPM when running in dev mode.
> >
> > -
> > Alex
> >
> > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > HI Alex,
> > > I agree with your concern.
> > > I do not know exactly where and why infinispan is used, but I also hit
> > > issues with it during some upgrades.
> > > From my POV the issue is that
> > > 1. On one side, we want to provide in-memory support for our
> > applications,
> > > which is a good feature
> > > 2. on the other side, we implemented specific solutions, with
> > hard-binding
> > > to that specific implementation (infinispan), that lead to the issue you
> > > mentioned
> > >
> > > Being everything open source, maybe a good solution would be to design
> > and
> > > provide API/interfaces for any "in-memory" database, and then whoever
> > wants
> > > to create a specific implementation, outside our apache-kie project,
> > would
> > > still be able to create it.
> > >
> > > Wdyt ?
> > >
> > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > porcelli@apache.org
> > > >
> > > ha scritto:
> > >
> > > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > > version,
> > > > we’re currently dealing with the impact of aligning with Infinispan 15,
> > > > which introduces a new set of changes and potentially api compatibility
> > > > issues.
> > > >
> > > > Given this context, I’d like to revisit the question: Do we really want
> > > to
> > > > continue supporting Infinispan?
> > > >
> > > > This has been discussed in the past, and there was some resistance to
> > > > removing it. However, maintaining support goes beyond the existing
> > > > implementation—it requires us to stay on top of future upgrades, adapt
> > to
> > > > API changes, and deal with potential security vulnerabilities stemming
> > > from
> > > > Infinispan itself and its transitive dependencies.
> > > >
> > > > I believe it’s worth re-evaluating its value and whether it’s aligned
> > > with
> > > > the future direction of the project.
> > > >
> > > > Looking forward to your thoughts.
> > > >
> > > > -
> > > >
> > > > Alex
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [DISCUSSION] Continued Support for Infinispan

[Gabriele Cardosi <ga...@gmail.com>]

Ok, thanks!

Il giorno mar 1 apr 2025 alle ore 15:54 Alex Porcelli <al...@porcelli.me> ha
scritto:

> Gabriele,
>
> Good point, the drools codebase also has Infinispan usage for datagrid
> use cases...
>
> But as you already pointed out, the surface of those places are much
> less of a problem if compared to the current infinispan "persistence"
> modules.
>
> On Tue, Apr 1, 2025 at 9:32 AM Gabriele Cardosi
> <ga...@gmail.com> wrote:
> >
> > Please keep in mind that there are other usages of infinispan
> > scattered throughout our codebase, e.g.
> >
> > *org.kie.kogito.codegen.process.persistence.PersistenceGenerator*
> >
> > import and uses
> >
> > *import org.infinispan.protostream.FileDescriptorSource;*
> >
> > IMO, until we get rid of all of them , the problem with infinispan
> binding
> > will remain, anyway it could be that the impact is much more mitigated.
> >
> > M2C
> >
> >
> >
> >
> >
> > Il giorno mar 1 apr 2025 alle ore 14:37 Francisco Javier Tirado Sarti
> > <ft...@redhat.com.invalid> ha scritto:
> >
> > > I agree to remove Inifinispan, although I have invested a substantial
> > > amount of work to keep it working.
> > > But we have better alternatives for embedded, both relational (embedded
> > > postgresql, h2) and non relational (rocksbd)
> > > Also, it does not have the same level of query support than Mongo and
> > > Postgress (it is not possible to query variables or metadata)
> > > Besides, I also find questionable the original decision to use it as
> > > default data store, given the fact that the optimal use for Inifnispan
> is
> > > as persistent distributed cache (so, in a way, it was like using Kafka
> as
> > > datastore, possible, but not its original intent)
> > > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > > implementation at the same level of functionality (currently Mongo is
> > > slightly behind)
> > > Thats said, I think that, rather than removing, we can exclude it (just
> > > remove the reference from the parent POM and keep the code)
> > >
> > >
> > > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> > >
> > > > I think those interfaces are already in place - at some extent. We
> have a
> > > > few different db implementations already: mongo, Postgres, rocksdb;
> so
> > > I’d
> > > > suspect that it should be enough for now.
> > > >
> > > > I also would argue that H2 is also a reasonable solution for
> in-memory
> > > with
> > > > low cost and is now actively used in jBPM when running in dev mode.
> > > >
> > > > -
> > > > Alex
> > > >
> > > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > > gabriele.cardosi@gmail.com>
> > > > wrote:
> > > >
> > > > > HI Alex,
> > > > > I agree with your concern.
> > > > > I do not know exactly where and why infinispan is used, but I also
> hit
> > > > > issues with it during some upgrades.
> > > > > From my POV the issue is that
> > > > > 1. On one side, we want to provide in-memory support for our
> > > > applications,
> > > > > which is a good feature
> > > > > 2. on the other side, we implemented specific solutions, with
> > > > hard-binding
> > > > > to that specific implementation (infinispan), that lead to the
> issue
> > > you
> > > > > mentioned
> > > > >
> > > > > Being everything open source, maybe a good solution would be to
> design
> > > > and
> > > > > provide API/interfaces for any "in-memory" database, and then
> whoever
> > > > wants
> > > > > to create a specific implementation, outside our apache-kie
> project,
> > > > would
> > > > > still be able to create it.
> > > > >
> > > > > Wdyt ?
> > > > >
> > > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > > porcelli@apache.org
> > > > > >
> > > > > ha scritto:
> > > > >
> > > > > > As part of the ongoing effort to upgrade to the latest Quarkus
> LTS
> > > > > version,
> > > > > > we’re currently dealing with the impact of aligning with
> Infinispan
> > > 15,
> > > > > > which introduces a new set of changes and potentially api
> > > compatibility
> > > > > > issues.
> > > > > >
> > > > > > Given this context, I’d like to revisit the question: Do we
> really
> > > want
> > > > > to
> > > > > > continue supporting Infinispan?
> > > > > >
> > > > > > This has been discussed in the past, and there was some
> resistance to
> > > > > > removing it. However, maintaining support goes beyond the
> existing
> > > > > > implementation—it requires us to stay on top of future upgrades,
> > > adapt
> > > > to
> > > > > > API changes, and deal with potential security vulnerabilities
> > > stemming
> > > > > from
> > > > > > Infinispan itself and its transitive dependencies.
> > > > > >
> > > > > > I believe it’s worth re-evaluating its value and whether it’s
> aligned
> > > > > with
> > > > > > the future direction of the project.
> > > > > >
> > > > > > Looking forward to your thoughts.
> > > > > >
> > > > > > -
> > > > > >
> > > > > > Alex
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [DISCUSSION] Continued Support for Infinispan

[Alex Porcelli <al...@porcelli.me>]

Gabriele,

Good point, the drools codebase also has Infinispan usage for datagrid
use cases...

But as you already pointed out, the surface of those places are much
less of a problem if compared to the current infinispan "persistence"
modules.

On Tue, Apr 1, 2025 at 9:32 AM Gabriele Cardosi
<ga...@gmail.com> wrote:
>
> Please keep in mind that there are other usages of infinispan
> scattered throughout our codebase, e.g.
>
> *org.kie.kogito.codegen.process.persistence.PersistenceGenerator*
>
> import and uses
>
> *import org.infinispan.protostream.FileDescriptorSource;*
>
> IMO, until we get rid of all of them , the problem with infinispan binding
> will remain, anyway it could be that the impact is much more mitigated.
>
> M2C
>
>
>
>
>
> Il giorno mar 1 apr 2025 alle ore 14:37 Francisco Javier Tirado Sarti
> <ft...@redhat.com.invalid> ha scritto:
>
> > I agree to remove Inifinispan, although I have invested a substantial
> > amount of work to keep it working.
> > But we have better alternatives for embedded, both relational (embedded
> > postgresql, h2) and non relational (rocksbd)
> > Also, it does not have the same level of query support than Mongo and
> > Postgress (it is not possible to query variables or metadata)
> > Besides, I also find questionable the original decision to use it as
> > default data store, given the fact that the optimal use for Inifnispan is
> > as persistent distributed cache (so, in a way, it was like using Kafka as
> > datastore, possible, but not its original intent)
> > I think is good to deprecate it and focus on keeping JPA and mongoDB
> > implementation at the same level of functionality (currently Mongo is
> > slightly behind)
> > Thats said, I think that, rather than removing, we can exclude it (just
> > remove the reference from the parent POM and keep the code)
> >
> >
> > On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > I think those interfaces are already in place - at some extent. We have a
> > > few different db implementations already: mongo, Postgres, rocksdb; so
> > I’d
> > > suspect that it should be enough for now.
> > >
> > > I also would argue that H2 is also a reasonable solution for in-memory
> > with
> > > low cost and is now actively used in jBPM when running in dev mode.
> > >
> > > -
> > > Alex
> > >
> > > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > > gabriele.cardosi@gmail.com>
> > > wrote:
> > >
> > > > HI Alex,
> > > > I agree with your concern.
> > > > I do not know exactly where and why infinispan is used, but I also hit
> > > > issues with it during some upgrades.
> > > > From my POV the issue is that
> > > > 1. On one side, we want to provide in-memory support for our
> > > applications,
> > > > which is a good feature
> > > > 2. on the other side, we implemented specific solutions, with
> > > hard-binding
> > > > to that specific implementation (infinispan), that lead to the issue
> > you
> > > > mentioned
> > > >
> > > > Being everything open source, maybe a good solution would be to design
> > > and
> > > > provide API/interfaces for any "in-memory" database, and then whoever
> > > wants
> > > > to create a specific implementation, outside our apache-kie project,
> > > would
> > > > still be able to create it.
> > > >
> > > > Wdyt ?
> > > >
> > > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > > porcelli@apache.org
> > > > >
> > > > ha scritto:
> > > >
> > > > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > > > version,
> > > > > we’re currently dealing with the impact of aligning with Infinispan
> > 15,
> > > > > which introduces a new set of changes and potentially api
> > compatibility
> > > > > issues.
> > > > >
> > > > > Given this context, I’d like to revisit the question: Do we really
> > want
> > > > to
> > > > > continue supporting Infinispan?
> > > > >
> > > > > This has been discussed in the past, and there was some resistance to
> > > > > removing it. However, maintaining support goes beyond the existing
> > > > > implementation—it requires us to stay on top of future upgrades,
> > adapt
> > > to
> > > > > API changes, and deal with potential security vulnerabilities
> > stemming
> > > > from
> > > > > Infinispan itself and its transitive dependencies.
> > > > >
> > > > > I believe it’s worth re-evaluating its value and whether it’s aligned
> > > > with
> > > > > the future direction of the project.
> > > > >
> > > > > Looking forward to your thoughts.
> > > > >
> > > > > -
> > > > >
> > > > > Alex
> > > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [DISCUSSION] Continued Support for Infinispan

[Gabriele Cardosi <ga...@gmail.com>]

Please keep in mind that there are other usages of infinispan
scattered throughout our codebase, e.g.

*org.kie.kogito.codegen.process.persistence.PersistenceGenerator*

import and uses

*import org.infinispan.protostream.FileDescriptorSource;*

IMO, until we get rid of all of them , the problem with infinispan binding
will remain, anyway it could be that the impact is much more mitigated.

M2C





Il giorno mar 1 apr 2025 alle ore 14:37 Francisco Javier Tirado Sarti
<ft...@redhat.com.invalid> ha scritto:

> I agree to remove Inifinispan, although I have invested a substantial
> amount of work to keep it working.
> But we have better alternatives for embedded, both relational (embedded
> postgresql, h2) and non relational (rocksbd)
> Also, it does not have the same level of query support than Mongo and
> Postgress (it is not possible to query variables or metadata)
> Besides, I also find questionable the original decision to use it as
> default data store, given the fact that the optimal use for Inifnispan is
> as persistent distributed cache (so, in a way, it was like using Kafka as
> datastore, possible, but not its original intent)
> I think is good to deprecate it and focus on keeping JPA and mongoDB
> implementation at the same level of functionality (currently Mongo is
> slightly behind)
> Thats said, I think that, rather than removing, we can exclude it (just
> remove the reference from the parent POM and keep the code)
>
>
> On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > I think those interfaces are already in place - at some extent. We have a
> > few different db implementations already: mongo, Postgres, rocksdb; so
> I’d
> > suspect that it should be enough for now.
> >
> > I also would argue that H2 is also a reasonable solution for in-memory
> with
> > low cost and is now actively used in jBPM when running in dev mode.
> >
> > -
> > Alex
> >
> > On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> > gabriele.cardosi@gmail.com>
> > wrote:
> >
> > > HI Alex,
> > > I agree with your concern.
> > > I do not know exactly where and why infinispan is used, but I also hit
> > > issues with it during some upgrades.
> > > From my POV the issue is that
> > > 1. On one side, we want to provide in-memory support for our
> > applications,
> > > which is a good feature
> > > 2. on the other side, we implemented specific solutions, with
> > hard-binding
> > > to that specific implementation (infinispan), that lead to the issue
> you
> > > mentioned
> > >
> > > Being everything open source, maybe a good solution would be to design
> > and
> > > provide API/interfaces for any "in-memory" database, and then whoever
> > wants
> > > to create a specific implementation, outside our apache-kie project,
> > would
> > > still be able to create it.
> > >
> > > Wdyt ?
> > >
> > > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> > porcelli@apache.org
> > > >
> > > ha scritto:
> > >
> > > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > > version,
> > > > we’re currently dealing with the impact of aligning with Infinispan
> 15,
> > > > which introduces a new set of changes and potentially api
> compatibility
> > > > issues.
> > > >
> > > > Given this context, I’d like to revisit the question: Do we really
> want
> > > to
> > > > continue supporting Infinispan?
> > > >
> > > > This has been discussed in the past, and there was some resistance to
> > > > removing it. However, maintaining support goes beyond the existing
> > > > implementation—it requires us to stay on top of future upgrades,
> adapt
> > to
> > > > API changes, and deal with potential security vulnerabilities
> stemming
> > > from
> > > > Infinispan itself and its transitive dependencies.
> > > >
> > > > I believe it’s worth re-evaluating its value and whether it’s aligned
> > > with
> > > > the future direction of the project.
> > > >
> > > > Looking forward to your thoughts.
> > > >
> > > > -
> > > >
> > > > Alex
> > > >
> > >
> >
>

Re: [DISCUSSION] Continued Support for Infinispan

[Francisco Javier Tirado Sarti <ft...@redhat.com.INVALID>]

I agree to remove Inifinispan, although I have invested a substantial
amount of work to keep it working.
But we have better alternatives for embedded, both relational (embedded
postgresql, h2) and non relational (rocksbd)
Also, it does not have the same level of query support than Mongo and
Postgress (it is not possible to query variables or metadata)
Besides, I also find questionable the original decision to use it as
default data store, given the fact that the optimal use for Inifnispan is
as persistent distributed cache (so, in a way, it was like using Kafka as
datastore, possible, but not its original intent)
I think is good to deprecate it and focus on keeping JPA and mongoDB
implementation at the same level of functionality (currently Mongo is
slightly behind)
Thats said, I think that, rather than removing, we can exclude it (just
remove the reference from the parent POM and keep the code)


On Tue, Apr 1, 2025 at 2:02 PM Alex Porcelli <al...@porcelli.me> wrote:

> I think those interfaces are already in place - at some extent. We have a
> few different db implementations already: mongo, Postgres, rocksdb; so I’d
> suspect that it should be enough for now.
>
> I also would argue that H2 is also a reasonable solution for in-memory with
> low cost and is now actively used in jBPM when running in dev mode.
>
> -
> Alex
>
> On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > HI Alex,
> > I agree with your concern.
> > I do not know exactly where and why infinispan is used, but I also hit
> > issues with it during some upgrades.
> > From my POV the issue is that
> > 1. On one side, we want to provide in-memory support for our
> applications,
> > which is a good feature
> > 2. on the other side, we implemented specific solutions, with
> hard-binding
> > to that specific implementation (infinispan), that lead to the issue you
> > mentioned
> >
> > Being everything open source, maybe a good solution would be to design
> and
> > provide API/interfaces for any "in-memory" database, and then whoever
> wants
> > to create a specific implementation, outside our apache-kie project,
> would
> > still be able to create it.
> >
> > Wdyt ?
> >
> > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> porcelli@apache.org
> > >
> > ha scritto:
> >
> > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > version,
> > > we’re currently dealing with the impact of aligning with Infinispan 15,
> > > which introduces a new set of changes and potentially api compatibility
> > > issues.
> > >
> > > Given this context, I’d like to revisit the question: Do we really want
> > to
> > > continue supporting Infinispan?
> > >
> > > This has been discussed in the past, and there was some resistance to
> > > removing it. However, maintaining support goes beyond the existing
> > > implementation—it requires us to stay on top of future upgrades, adapt
> to
> > > API changes, and deal with potential security vulnerabilities stemming
> > from
> > > Infinispan itself and its transitive dependencies.
> > >
> > > I believe it’s worth re-evaluating its value and whether it’s aligned
> > with
> > > the future direction of the project.
> > >
> > > Looking forward to your thoughts.
> > >
> > > -
> > >
> > > Alex
> > >
> >
>

Re: [DISCUSSION] Continued Support for Infinispan

[Gabriele Cardosi <ga...@gmail.com>]

Ok, thanks!

Il giorno mar 1 apr 2025 alle ore 14:00 Alex Porcelli <al...@porcelli.me> ha
scritto:

> I think those interfaces are already in place - at some extent. We have a
> few different db implementations already: mongo, Postgres, rocksdb; so I’d
> suspect that it should be enough for now.
>
> I also would argue that H2 is also a reasonable solution for in-memory with
> low cost and is now actively used in jBPM when running in dev mode.
>
> -
> Alex
>
> On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <
> gabriele.cardosi@gmail.com>
> wrote:
>
> > HI Alex,
> > I agree with your concern.
> > I do not know exactly where and why infinispan is used, but I also hit
> > issues with it during some upgrades.
> > From my POV the issue is that
> > 1. On one side, we want to provide in-memory support for our
> applications,
> > which is a good feature
> > 2. on the other side, we implemented specific solutions, with
> hard-binding
> > to that specific implementation (infinispan), that lead to the issue you
> > mentioned
> >
> > Being everything open source, maybe a good solution would be to design
> and
> > provide API/interfaces for any "in-memory" database, and then whoever
> wants
> > to create a specific implementation, outside our apache-kie project,
> would
> > still be able to create it.
> >
> > Wdyt ?
> >
> > Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <
> porcelli@apache.org
> > >
> > ha scritto:
> >
> > > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> > version,
> > > we’re currently dealing with the impact of aligning with Infinispan 15,
> > > which introduces a new set of changes and potentially api compatibility
> > > issues.
> > >
> > > Given this context, I’d like to revisit the question: Do we really want
> > to
> > > continue supporting Infinispan?
> > >
> > > This has been discussed in the past, and there was some resistance to
> > > removing it. However, maintaining support goes beyond the existing
> > > implementation—it requires us to stay on top of future upgrades, adapt
> to
> > > API changes, and deal with potential security vulnerabilities stemming
> > from
> > > Infinispan itself and its transitive dependencies.
> > >
> > > I believe it’s worth re-evaluating its value and whether it’s aligned
> > with
> > > the future direction of the project.
> > >
> > > Looking forward to your thoughts.
> > >
> > > -
> > >
> > > Alex
> > >
> >
>

Re: [DISCUSSION] Continued Support for Infinispan

[Alex Porcelli <al...@porcelli.me>]

I think those interfaces are already in place - at some extent. We have a
few different db implementations already: mongo, Postgres, rocksdb; so I’d
suspect that it should be enough for now.

I also would argue that H2 is also a reasonable solution for in-memory with
low cost and is now actively used in jBPM when running in dev mode.

-
Alex

On Tue, Apr 1, 2025 at 7:54 AM Gabriele Cardosi <ga...@gmail.com>
wrote:

> HI Alex,
> I agree with your concern.
> I do not know exactly where and why infinispan is used, but I also hit
> issues with it during some upgrades.
> From my POV the issue is that
> 1. On one side, we want to provide in-memory support for our applications,
> which is a good feature
> 2. on the other side, we implemented specific solutions, with hard-binding
> to that specific implementation (infinispan), that lead to the issue you
> mentioned
>
> Being everything open source, maybe a good solution would be to design and
> provide API/interfaces for any "in-memory" database, and then whoever wants
> to create a specific implementation, outside our apache-kie project, would
> still be able to create it.
>
> Wdyt ?
>
> Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <porcelli@apache.org
> >
> ha scritto:
>
> > As part of the ongoing effort to upgrade to the latest Quarkus LTS
> version,
> > we’re currently dealing with the impact of aligning with Infinispan 15,
> > which introduces a new set of changes and potentially api compatibility
> > issues.
> >
> > Given this context, I’d like to revisit the question: Do we really want
> to
> > continue supporting Infinispan?
> >
> > This has been discussed in the past, and there was some resistance to
> > removing it. However, maintaining support goes beyond the existing
> > implementation—it requires us to stay on top of future upgrades, adapt to
> > API changes, and deal with potential security vulnerabilities stemming
> from
> > Infinispan itself and its transitive dependencies.
> >
> > I believe it’s worth re-evaluating its value and whether it’s aligned
> with
> > the future direction of the project.
> >
> > Looking forward to your thoughts.
> >
> > -
> >
> > Alex
> >
>

Re: [DISCUSSION] Continued Support for Infinispan

[Gabriele Cardosi <ga...@gmail.com>]

HI Alex,
I agree with your concern.
I do not know exactly where and why infinispan is used, but I also hit
issues with it during some upgrades.
From my POV the issue is that
1. On one side, we want to provide in-memory support for our applications,
which is a good feature
2. on the other side, we implemented specific solutions, with hard-binding
to that specific implementation (infinispan), that lead to the issue you
mentioned

Being everything open source, maybe a good solution would be to design and
provide API/interfaces for any "in-memory" database, and then whoever wants
to create a specific implementation, outside our apache-kie project, would
still be able to create it.

Wdyt ?

Il giorno mar 1 apr 2025 alle ore 13:23 Alex Porcelli <po...@apache.org>
ha scritto:

> As part of the ongoing effort to upgrade to the latest Quarkus LTS version,
> we’re currently dealing with the impact of aligning with Infinispan 15,
> which introduces a new set of changes and potentially api compatibility
> issues.
>
> Given this context, I’d like to revisit the question: Do we really want to
> continue supporting Infinispan?
>
> This has been discussed in the past, and there was some resistance to
> removing it. However, maintaining support goes beyond the existing
> implementation—it requires us to stay on top of future upgrades, adapt to
> API changes, and deal with potential security vulnerabilities stemming from
> Infinispan itself and its transitive dependencies.
>
> I believe it’s worth re-evaluating its value and whether it’s aligned with
> the future direction of the project.
>
> Looking forward to your thoughts.
>
> -
>
> Alex
>

Re: [DISCUSSION] Continued Support for Infinispan

[Mark Proctor <md...@apache.org>]

As infinispan has a complex impl to make it work, requiring all the Lucene
indexing to extract data and make it searchable and also it doesn’t work
with Kafka or have eventual consistency with debezium, I’m happy to +1 its
removal.

Mark

On Tue, 1 Apr 2025 at 12:23, Alex Porcelli <po...@apache.org> wrote:

> As part of the ongoing effort to upgrade to the latest Quarkus LTS version,
> we’re currently dealing with the impact of aligning with Infinispan 15,
> which introduces a new set of changes and potentially api compatibility
> issues.
>
> Given this context, I’d like to revisit the question: Do we really want to
> continue supporting Infinispan?
>
> This has been discussed in the past, and there was some resistance to
> removing it. However, maintaining support goes beyond the existing
> implementation—it requires us to stay on top of future upgrades, adapt to
> API changes, and deal with potential security vulnerabilities stemming from
> Infinispan itself and its transitive dependencies.
>
> I believe it’s worth re-evaluating its value and whether it’s aligned with
> the future direction of the project.
>
> Looking forward to your thoughts.
>
> -
>
> Alex
>