Ok, thanks!

Il giorno mar 1 apr 2025 alle ore 14:00 Alex Porcelli <a...@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.card...@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 <
> porce...@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
> > >
> >
>

Reply via email to