Any CDI context state persisters/passivation?

[William Burke]

I have a need to persist/passivate a CDI scope.  Do we have an implementation of this for something like SessionScoped?  Just asking before I implement something.

Thanks.

--

Bill Burke

IBM

[Martin Kouba]

No, ArC deliberately does not support passivation [1] (included in CDI
Full), and not even passivation capable dependencies. And I can assure
you that it's not a trivial task.

Martin

[1]
https://jakarta.ee/specifications/cdi/5.0/jakarta-cdi-spec-5.0#passivating_scope

On 9/14/26 16:15, 'William Burke' via Quarkus Development mailing list
wrote:

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/CAL%3DE%3DjSBNtFc8UkoEeg-
> ZVBtyg_kguMeAN_7mFHqaK5v87Zt0Q%40mail.gmail.com <https://
> groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSBNtFc8UkoEeg-
> ZVBtyg_kguMeAN_7mFHqaK5v87Zt0Q%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[William Burke]

Quarkus AI (chat and agent workflow) is gonna need persistable conversation scopes.   Without persistable scopes, CDI will be a lot less useful.  Unfortunately, we're not in a stateless world anymore if LLM conversations are going to be managed by the server.

I believe you it is not trivial, which is why I asked, but I still need it.  (I remember Infinispan AOP cache being a nightmare).  Maybe adding some constraints would make it less complex. 

My first thought is to have it jackson-based and to ignore properties annotated with @Inject and @ConfigProperty.    On activate deserialize from json then let Arc fill in injection points, then call @PostActviation.  Provide a override interface for complex cases so users can take over passivation/activation.  Provide config switches/annotations for when passivation happens (per request, tx commit, on shutdown, when state changes, etc...)

Arc probably doesn't support @PostActivation and I'll need to figure out a way not to call @PostConstruct.

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/c9ff20be-34d1-4442-93e3-3b7be35bed2f%40redhat.com.

--

Bill Burke

IBM

[Martin Kouba]

On 9/14/26 16:50, 'William Burke' via Quarkus Development mailing list
wrote:

> Quarkus AI (chat and agent workflow) is gonna need persistable
> conversation scopes.  Without persistable scopes, CDI will be a lot less
> useful.  Unfortunately, we're not in a stateless world anymore if LLM
> conversations are going to be managed by the server.
>
> I believe you it is not trivial, which is why I asked, but I still need
> it.  (I remember Infinispan AOP cache being a nightmare).  Maybe adding
> some constraints would make it less complex.
>
> My first thought is to have it jackson-based and to ignore properties
> annotated with @Inject and @ConfigProperty.

You'll need to handle CDI initializers (~ setter injection) and
constructor injection as well. Moreover, it's not only @ConfigProperty -
in ArC any qualifier can be used for _qualified injected fields_ -
https://quarkus.io/guides/cdi-reference/#qualified-injected-fields.

Also if a serialized bean has a @Dependent bean injected then
deserialization would mean a new injected bean instance, which is
probably unexpected. Because normally beans with scope @Dependent must
be serialized along with their client.

Anyway, this is just the tip of the iceberg. For example, interceptors
and decorators of a passivation capable bean must be passivation capable
as well. And you'll need to validate this, otherwise an unexpected error
may occur at runtime.

> On activate deserialize
> from json then let Arc fill in injection points, then call
> @PostActviation.

ArC currently does not provide an API for this. So you'd have to
implement this manually.

> Provide a override interface for complex cases so
> users can take over passivation/activation.  Provide config switches/
> annotations for when passivation happens (per request, tx commit, on
> shutdown, when state changes, etc...)
>
> Arc probably doesn't support @PostActivation and I'll need to figure out
> a way not to call @PostConstruct.

No, it doesn't.

>
> On Mon, Sep 14, 2026 at 10:22 AM 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com>> wrote:
>
> No, ArC deliberately does not support passivation [1] (included in CDI
> Full), and not even passivation capable dependencies. And I can assure
> you that it's not a trivial task.
>
> Martin
>
> [1]
> https://jakarta.ee/specifications/cdi/5.0/jakarta-cdi-

> spec-5.0#passivating_scope <https://jakarta.ee/specifications/
> cdi/5.0/jakarta-cdi-spec-5.0#passivating_scope>

>
> On 9/14/26 16:15, 'William Burke' via Quarkus Development mailing list
> wrote:
> > I have a need to persist/passivate a CDI scope.  Do we have an
> > implementation of this for something like SessionScoped?  Just
> asking
> > before I implement something.
> >
> > Thanks.
> >
> > --
> > Bill Burke
> > IBM
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Quarkus Development mailing list" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev%2Bunsu...@googlegroups.com> <mailto:quarkus-
> <mailto:quarkus->
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.

> > To view this discussion visit https://groups.google.com/d/msgid/

> quarkus- <https://groups.google.com/d/msgid/quarkus->
> > dev/CAL%3DE%3DjSBNtFc8UkoEeg-
> > ZVBtyg_kguMeAN_7mFHqaK5v87Zt0Q%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSBNtFc8UkoEeg-
> <http://groups.google.com/d/msgid/quarkus-dev/
> CAL%3DE%3DjSBNtFc8UkoEeg->
> > ZVBtyg_kguMeAN_7mFHqaK5v87Zt0Q%40mail.gmail.com
> <http://40mail.gmail.com>?

> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> quarkus-dev/c9ff20be-34d1-4442-93e3-3b7be35bed2f%40redhat.com
> <https://groups.google.com/d/msgid/quarkus-dev/
> c9ff20be-34d1-4442-93e3-3b7be35bed2f%40redhat.com>.

>
>
>
> --
> Bill Burke
> IBM
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-

> dev/CAL%3DE%3DjT%2Bn%2BKLTTwv6Yi_RxVQ_O-
> VgPcVL3HrkYjBVJ5YZB3P%2BQ%40mail.gmail.com <https://groups.google.com/d/
> msgid/quarkus-dev/CAL%3DE%3DjT%2Bn%2BKLTTwv6Yi_RxVQ_O-
> VgPcVL3HrkYjBVJ5YZB3P%2BQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[William Burke]

For @Dependent beans do they use the same InjectableContext as their parent?  What about interceptors and decorators?  Are they beans within the parent InjectableContext?

Jackson allows you to deserialize on a provided object instance.  Also has hooks for deciding whether to ignore a property or not.  Since I have my own custom scope/InjectableContext I can intercept instantiation and destruction.  So, let the container create the bean instance, then run Jackson deserialization on it, then call @PostActivate

 

Require app-developer intervention as needed for special cases i.e. adding @JsonIgnore where appropriate and custom code in @PrePassivate, @PostActivate.

[Martin Kouba]

On 9/15/26 17:43, 'William Burke' via Quarkus Development mailing list
wrote:
>
>

> On Tue, Sep 15, 2026 at 3:43 AM 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com>> wrote:
>
> On 9/14/26 16:50, 'William Burke' via Quarkus Development mailing list
> wrote:
> > Quarkus AI (chat and agent workflow) is gonna need persistable
> > conversation scopes.  Without persistable scopes, CDI will be a
> lot less
> > useful.  Unfortunately, we're not in a stateless world anymore if
> LLM
> > conversations are going to be managed by the server.
> >
> > I believe you it is not trivial, which is why I asked, but I
> still need
> > it.  (I remember Infinispan AOP cache being a nightmare).  Maybe
> adding
> > some constraints would make it less complex.
> >
> > My first thought is to have it jackson-based and to ignore
> properties
> > annotated with @Inject and @ConfigProperty.
>
> You'll need to handle CDI initializers (~ setter injection) and
> constructor injection as well. Moreover, it's not only
> @ConfigProperty -
> in ArC any qualifier can be used for _qualified injected fields_ -
> https://quarkus.io/guides/cdi-reference/#qualified-injected-fields

> <https://quarkus.io/guides/cdi-reference/#qualified-injected-fields>.

>
> Also if a serialized bean has a @Dependent bean injected then
> deserialization would mean a new injected bean instance, which is
> probably unexpected. Because normally beans with scope @Dependent must
> be serialized along with their client.
>
> Anyway, this is just the tip of the iceberg. For example, interceptors
> and decorators of a passivation capable bean must be passivation
> capable
> as well. And you'll need to validate this, otherwise an unexpected
> error
> may occur at runtime.
>
> > On activate deserialize
> > from json then let Arc fill in injection points, then call
> > @PostActviation.
>
> ArC currently does not provide an API for this. So you'd have to
> implement this manually.
>
>
> For @Dependent beans do they use the same InjectableContext as their
> parent?  What about interceptors and decorators?  Are they beans within
> the parent InjectableContext?

Dependent beans do not live in any Context. They need to be Serializable
if injected in a passivation capable bean. However, the
CreationalContext [1] of a specific bean instance is responsible for
proper destruction of these beans when necessary.

Interceptors and decorators are dependent objects of the object they
intercept/decorate. They need to be serialized along the
intercepted/decorated bean instance.

[1]
https://github.com/jakartaee/cdi/blob/main/api/src/main/java/jakarta/enterprise/context/spi/CreationalContext.java

>
>
> Jackson allows you to deserialize on a provided object instance.  Also
> has hooks for deciding whether to ignore a property or not.  Since I
> have my own custom scope/InjectableContext I can intercept instantiation
> and destruction.  So, let the container create the bean instance, then
> run Jackson deserialization on it, then call @PostActivate
> Require app-developer intervention as needed for special cases i.e.
> adding @JsonIgnore where appropriate and custom code in @PrePassivate,
> @PostActivate.
>
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/

> CAL%3DE%3DjQQWP%3Du4DAO%3D8fPfJU26cqoM%3DOt5TqgqLcFvERdWqvkhA%40mail.gmail.com <https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjQQWP%3Du4DAO%3D8fPfJU26cqoM%3DOt5TqgqLcFvERdWqvkhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[William Burke]

Looks like dependent references are not stored in the CreationalContext if there is no predestroy logic.  Makes sense for optimization. I would need a 

way to force this so that I could obtain dependents at runtime.  Maybe forcing it breaks other things too. 

I guess my only option right now is to seriously constrain the implementation

* not serialize @Depedent

* not serialize interceptors/decorators

* not allow constructor injection

* PostConstruct is called before PostActivation

If user doesn't like those constraints, they need to implement their own logic.

--

Bill Burke

IBM

[Martin Kouba]

On 9/17/26 07:56, 'William Burke' via Quarkus Development mailing list
wrote:
>
>

> On Tue, Sep 15, 2026 at 1:37 PM 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-
> d...@googlegroups.com>> wrote:
>
> On 9/15/26 17:43, 'William Burke' via Quarkus Development mailing list
> wrote:
> >
> >
> > On Tue, Sep 15, 2026 at 3:43 AM 'Martin Kouba' via Quarkus
> Development
> > mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->

> >     <https://quarkus.io/guides/cdi-reference/#qualified-injected-
> fields <https://quarkus.io/guides/cdi-reference/#qualified-injected-

Yes, this an optimization we have in ArC/Weld. If there's no destruction
logic then the only thing that needs to be serialized is the injected
dependent instance.

> I would
> need a
> way to force this so that I could obtain dependents at runtime.  Maybe
> forcing it breaks other things too.
>
> I guess my only option right now is to seriously constrain the
> implementation
> * not serialize @Depedent

CDI itself does not consider transient fields, and injected params
annotated with @TransientReference as passivation capable injection
points. So you can say @Depedent IPs must be transient or something like
that.

> * not serialize interceptors/decorators

This would be a huge limitation IMO.

> * not allow constructor injection

Constructor injection is also used very often.

> * PostConstruct is called before PostActivation
>
> If user doesn't like those constraints, they need to implement their own
> logic.
>

Out of curiosity, where and when exactly do you plan to
serialize/deserialize the context?

I would recommend you to inspect the Weld's machinery around
conversation/session context, which is bound to
jakarta.servlet.http.HttpSession/jakarta.servlet.http.HttpServletRequest.
Just to give you an idea what kind of complexity to expect.

>
> --
> Bill Burke
> IBM

>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-

> dev/CAL%3DE%3DjSzMYLk1%3DpqjYXG-
> G%3Dfi2s1hXvNvXGhK%2BZrEfhKqotWBA%40mail.gmail.com <https://
> groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSzMYLk1%3DpqjYXG-
> G%3Dfi2s1hXvNvXGhK%2BZrEfhKqotWBA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Matej Novotny]

FTR, here is what spec says as to what needs to serializable and when/how - https://jakarta.ee/specifications/cdi/5.0/jakarta-cdi-spec-5.0#passivating_scope

Martin is right that this will become complex very fast; I'd also recommend looking into Weld for some inspiration regarding the necessary machinery and validation.

I did browse that code on a few occasions but, unfortunately, I remember next to nothing at this point :-(

As for the restrictions you mentioned, I think that you'd quickly find that people unknowingly rely on many of those. And not just from code they directly own.

For instance, you can have interceptors attached to your components without really knowing it (extension can add a binding programatically) and it would suddenly stop working.

Another thing coming to mind is that some built-in beans provided by CDI impl should normally be passivation capable (`Instance`/`Event`/`BeanManager`) but I doubt we meet those requirements with Arc as that is CDI Full only.

This would also be an issue.

Matej

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/8e1b4d46-884c-4992-ba95-60d4e7424f25%40redhat.com.

[William Burke]

I don't think it would be a big deal to lose @Dependent as the user can just use the conversation scope (@ChatScoped) for nested beans.

I think this is a fair workaround.

 

> * not serialize interceptors/decorators

This would be a huge limitation IMO.

> * not allow constructor injection

Constructor injection is also used very often.

Not such a big deal either, IMO.  This is a new scope type, so it will be new code.  

 

> * PostConstruct is called before PostActivation
>
> If user doesn't like those constraints, they need to implement their own
> logic.
>

Out of curiosity, where and when exactly do you plan to
serialize/deserialize the context?

Probably a few policies as time goes on:

* on deactivation  (work on this first)

* remote request boundaries.

* per touch

* per transaction

[William Burke]

For Arc, is there a way to get bean metadata information within a @BuildStep?  Like to know if a bean will be intercepted or decorated (or if a Subclass is created)?

--

Bill Burke

IBM

[Martin Kouba]

On 9/17/26 17:01, 'William Burke' via Quarkus Development mailing list
wrote:

>
>
> On Thu, Sep 17, 2026 at 9:17 AM William Burke <bbu...@redhat.com
> <mailto:bbu...@redhat.com>> wrote:
>
>
>
> On Thu, Sep 17, 2026 at 2:41 AM 'Martin Kouba' via Quarkus
> Development mailing list <quark...@googlegroups.com

> <mailto:quark...@googlegroups.com>> wrote:
>
> On 9/17/26 07:56, 'William Burke' via Quarkus Development
> mailing list
> wrote:
> >
> >
> > On Tue, Sep 15, 2026 at 1:37 PM 'Martin Kouba' via Quarkus
> Development
> > mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->
> > d...@googlegroups.com <mailto:d...@googlegroups.com>>> wrote:
> >
> >     On 9/15/26 17:43, 'William Burke' via Quarkus Development
> mailing list
> >     wrote:
> >      >
> >      >
> >      > On Tue, Sep 15, 2026 at 3:43 AM 'Martin Kouba' via Quarkus
> >     Development
> >      > mailing list <quark...@googlegroups.com

> <mailto:quark...@googlegroups.com> <mailto:quarkus-

> <mailto:quarkus->
> > d...@googlegroups.com <mailto:d...@googlegroups.com>>

> <mailto:quarkus- <mailto:quarkus-> <mailto:quarkus-

> <mailto:quarkus->>
> >      > d...@googlegroups.com <mailto:d...@googlegroups.com>

> injected- <https://quarkus.io/guides/cdi-reference/#qualified-
> injected->
> >     fields <https://quarkus.io/guides/cdi-reference/
> #qualified-injected- <https://quarkus.io/guides/cdi-reference/
> #qualified-injected->
> >     fields>
> >      >     <https://quarkus.io/guides/cdi-reference/
> #qualified-injected- <https://quarkus.io/guides/cdi-reference/
> #qualified-injected->
> >     fields <https://quarkus.io/guides/cdi-reference/
> #qualified-injected- <https://quarkus.io/guides/cdi-reference/
> #qualified-injected->

https://quarkus.io/guides/cdi-integration/#inspect_beans

>
> --
> Bill Burke
> IBM
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/

> CAL%3DE%3DjQV1gpM2M8aVur40H88EHg%2ByvOM_p_14k27Az4tYRpbCg%40mail.gmail.com <https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjQV1gpM2M8aVur40H88EHg%2ByvOM_p_14k27Az4tYRpbCg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Martin Kouba]

On 9/17/26 15:17, 'William Burke' via Quarkus Development mailing list
wrote:
>
>

> On Thu, Sep 17, 2026 at 2:41 AM 'Martin Kouba' via Quarkus Development

> mailing list <quark...@googlegroups.com <mailto:quarkus-
> d...@googlegroups.com>> wrote:
>
> On 9/17/26 07:56, 'William Burke' via Quarkus Development mailing list
> wrote:
> >
> >
> > On Tue, Sep 15, 2026 at 1:37 PM 'Martin Kouba' via Quarkus
> Development
> > mailing list <quark...@googlegroups.com <mailto:quarkus-

> d...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->
> > d...@googlegroups.com <mailto:d...@googlegroups.com>>> wrote:
> >
> >     On 9/15/26 17:43, 'William Burke' via Quarkus Development
> mailing list
> >     wrote:
> >      >
> >      >
> >      > On Tue, Sep 15, 2026 at 3:43 AM 'Martin Kouba' via Quarkus
> >     Development
> >      > mailing list <quark...@googlegroups.com

> <mailto:quark...@googlegroups.com> <mailto:quarkus- <mailto:quarkus->
> > d...@googlegroups.com <mailto:d...@googlegroups.com>>
> <mailto:quarkus- <mailto:quarkus-> <mailto:quarkus- <mailto:quarkus->>
> >      > d...@googlegroups.com <mailto:d...@googlegroups.com>

> injected- <https://quarkus.io/guides/cdi-reference/#qualified-injected->

> >     fields <https://quarkus.io/guides/cdi-reference/#qualified-
> injected- <https://quarkus.io/guides/cdi-reference/#qualified-injected->
> >     fields>
> >      >     <https://quarkus.io/guides/cdi-reference/#qualified-
> injected- <https://quarkus.io/guides/cdi-reference/#qualified-injected->
> >     fields <https://quarkus.io/guides/cdi-reference/#qualified-

> injected- <https://quarkus.io/guides/cdi-reference/#qualified-injected->

I have no idea how @ChatScoped works, but the thing is many users
consume beans which have a scope (e.g. @Dependent) and it cannot be
changed arbitrarily, e.g. because it's also used by some other bean
which is used outside the @ChatScoped.

>
> > * not serialize interceptors/decorators
>
> This would be a huge limitation IMO.
>
> > * not allow constructor injection
>
> Constructor injection is also used very often.
>
>
> Not such a big deal either, IMO.  This is a new scope type, so it will
> be new code.
>
>
> > * PostConstruct is called before PostActivation
> >
> > If user doesn't like those constraints, they need to implement
> their own
> > logic.
> >
>
> Out of curiosity, where and when exactly do you plan to
> serialize/deserialize the context?
>
>
> Probably a few policies as time goes on:
> * on deactivation  (work on this first)
> * remote request boundaries.
> * per touch
> * per transaction
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com <mailto:quarkus-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-
> dev/

> CAL%3DE%3DjQ245yw6MgTt18F1pumE8nwNaAC7ZMtdMzBGYX1Ya47mQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/quarkus-dev/
> CAL%3DE%3DjQ245yw6MgTt18F1pumE8nwNaAC7ZMtdMzBGYX1Ya47mQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.