Quarkus CDI & Wicket sitting in a tree, maybe?

[Martijn Dashorst <ma...@gmail.com>]

After some soul searching for a while I might have a workable idea for
using Quarkus CDI and Wicket, which is probably the biggest hold back for
using these technologies together.

I've put my thoughts in this JIRA ticket in the last comment:
https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818

I'll also paste my comment here:

The issue is that ARC (the cdi implementation behind quarkus) doesn't
support and isn't going to support non-contextual injections as it wants to
resolve injections at build time rather than deploy- and runtime. Wicket's
basic premise is that it is a non-managed framework where you are allowed
to new your components and behaviors and models at will, which all escape
the management of a CDI container.

I'm thinking about this a bit for a while, and I figure that it might be
possible to provide some form of integration if we limit some constructs
that are now available for Wicket developers.

First we need to make pages managed, and the restored state of pages
managed when they are retrieved from the page store. This is probably
fairly easy to build using a `@SessionScoped` CDI producer that retrieves
pages either from a factory or from the pagestore if there's state
available (i.e. there's a pageid in the request). This also means that you
are no longer allowed to instantiate pages yourself, but that they must
have a default constructor, a pageparameters constructor or a
mapper/factory that can instantiate the page based on the provided URL.
This allows CDI to perform its injections on the retrieved instance(s). I'm
sure this would work for instantiating new pages. I'm not so sure about
retrieving pages from the page store and getting those managed again (about
90% hopeful that it works). This should also work with injected services in
the page instances, but not general component instances.

Next we need a way to make Panels injectable with CDI beans. This is a
hairy one. For now the only way I can foresee this working is to have an
Instance<MyPanel> field in your page and get an instance from that to add
to the page's component hierarchy. I'm open to other suggestions.

As for scoping, I'm not 100% sure, but using the @RequestScope for the page
producers and panel instances might just work. We might need our own scope,
but I wouldn't know how that differs from the request scope for our
purposes.
Injection into behaviors and models is something that either needs to go
through the Instance<Behavior> / Instance<FooModel> route or using producer
methods. My guess is that it is probably easier to use constructor
parameters and use the page/panel injected beans as parameters to the
models/behaviors.

This is all without providing any integration libraries such as a "Wicket
Arc" that would plug into arc for our purposes. It might be possible to do
all the above automatically given the right integration, but I'm not an arc
knower, nor a CDI implementation builder.

What do y'all think?

Martijn

Re: Quarkus CDI & Wicket sitting in a tree, maybe?

[Petr Sakař <pe...@chare.eu>]

Possible solution to "Issue with that is the build time scanner of ARC that hunts for injections and will create errors" can be annotations - you would have to annotate the required classes with some new annotation (or search for existing ones)

Petr

On 4/24/25 8:16 AM, Martijn Dashorst wrote:
> Yesterday evening i was able to bootstrap the filter and an application
> through ARC CDI and render the home page (without any services to inject).
>
> Lying in bed I thought that it might be possible to create a
> ComponentInstantiationListener that gets an injected Instance of eg
> ApplicationScoped beans, from which the listener selects the required
> injectable beans and injects those into the components just as wicket-cdi
> does now.
>
> Issue with that is the build time scanner of ARC that hunts for injections
> and will create errors
>
> Martijn
>
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
> On Wed, 23 Apr 2025 at 21:09, Martijn Dashorst <ma...@gmail.com>
> wrote:
>
>> After some soul searching for a while I might have a workable idea for
>> using Quarkus CDI and Wicket, which is probably the biggest hold back for
>> using these technologies together.
>>
>> I've put my thoughts in this JIRA ticket in the last comment:
>> https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818
>>
>> I'll also paste my comment here:
>>
>> The issue is that ARC (the cdi implementation behind quarkus) doesn't
>> support and isn't going to support non-contextual injections as it wants to
>> resolve injections at build time rather than deploy- and runtime. Wicket's
>> basic premise is that it is a non-managed framework where you are allowed
>> to new your components and behaviors and models at will, which all escape
>> the management of a CDI container.
>>
>> I'm thinking about this a bit for a while, and I figure that it might be
>> possible to provide some form of integration if we limit some constructs
>> that are now available for Wicket developers.
>>
>> First we need to make pages managed, and the restored state of pages
>> managed when they are retrieved from the page store. This is probably
>> fairly easy to build using a `@SessionScoped` CDI producer that retrieves
>> pages either from a factory or from the pagestore if there's state
>> available (i.e. there's a pageid in the request). This also means that you
>> are no longer allowed to instantiate pages yourself, but that they must
>> have a default constructor, a pageparameters constructor or a
>> mapper/factory that can instantiate the page based on the provided URL.
>> This allows CDI to perform its injections on the retrieved instance(s). I'm
>> sure this would work for instantiating new pages. I'm not so sure about
>> retrieving pages from the page store and getting those managed again (about
>> 90% hopeful that it works). This should also work with injected services in
>> the page instances, but not general component instances.
>>
>> Next we need a way to make Panels injectable with CDI beans. This is a
>> hairy one. For now the only way I can foresee this working is to have an
>> Instance<MyPanel> field in your page and get an instance from that to add
>> to the page's component hierarchy. I'm open to other suggestions.
>>
>> As for scoping, I'm not 100% sure, but using the @RequestScope for the
>> page producers and panel instances might just work. We might need our own
>> scope, but I wouldn't know how that differs from the request scope for our
>> purposes.
>> Injection into behaviors and models is something that either needs to go
>> through the Instance<Behavior> / Instance<FooModel> route or using producer
>> methods. My guess is that it is probably easier to use constructor
>> parameters and use the page/panel injected beans as parameters to the
>> models/behaviors.
>>
>> This is all without providing any integration libraries such as a "Wicket
>> Arc" that would plug into arc for our purposes. It might be possible to do
>> all the above automatically given the right integration, but I'm not an arc
>> knower, nor a CDI implementation builder.
>>
>> What do y'all think?
>>
>> Martijn
>>

Re: Quarkus CDI & Wicket sitting in a tree, maybe?

[Martijn Dashorst <ma...@gmail.com>]

Yesterday evening i was able to bootstrap the filter and an application
through ARC CDI and render the home page (without any services to inject).

Lying in bed I thought that it might be possible to create a
ComponentInstantiationListener that gets an injected Instance of eg
ApplicationScoped beans, from which the listener selects the required
injectable beans and injects those into the components just as wicket-cdi
does now.

Issue with that is the build time scanner of ARC that hunts for injections
and will create errors

Martijn

Become a Wicket expert, learn from the best: http://wicketinaction.com


On Wed, 23 Apr 2025 at 21:09, Martijn Dashorst <ma...@gmail.com>
wrote:

> After some soul searching for a while I might have a workable idea for
> using Quarkus CDI and Wicket, which is probably the biggest hold back for
> using these technologies together.
>
> I've put my thoughts in this JIRA ticket in the last comment:
> https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818
>
> I'll also paste my comment here:
>
> The issue is that ARC (the cdi implementation behind quarkus) doesn't
> support and isn't going to support non-contextual injections as it wants to
> resolve injections at build time rather than deploy- and runtime. Wicket's
> basic premise is that it is a non-managed framework where you are allowed
> to new your components and behaviors and models at will, which all escape
> the management of a CDI container.
>
> I'm thinking about this a bit for a while, and I figure that it might be
> possible to provide some form of integration if we limit some constructs
> that are now available for Wicket developers.
>
> First we need to make pages managed, and the restored state of pages
> managed when they are retrieved from the page store. This is probably
> fairly easy to build using a `@SessionScoped` CDI producer that retrieves
> pages either from a factory or from the pagestore if there's state
> available (i.e. there's a pageid in the request). This also means that you
> are no longer allowed to instantiate pages yourself, but that they must
> have a default constructor, a pageparameters constructor or a
> mapper/factory that can instantiate the page based on the provided URL.
> This allows CDI to perform its injections on the retrieved instance(s). I'm
> sure this would work for instantiating new pages. I'm not so sure about
> retrieving pages from the page store and getting those managed again (about
> 90% hopeful that it works). This should also work with injected services in
> the page instances, but not general component instances.
>
> Next we need a way to make Panels injectable with CDI beans. This is a
> hairy one. For now the only way I can foresee this working is to have an
> Instance<MyPanel> field in your page and get an instance from that to add
> to the page's component hierarchy. I'm open to other suggestions.
>
> As for scoping, I'm not 100% sure, but using the @RequestScope for the
> page producers and panel instances might just work. We might need our own
> scope, but I wouldn't know how that differs from the request scope for our
> purposes.
> Injection into behaviors and models is something that either needs to go
> through the Instance<Behavior> / Instance<FooModel> route or using producer
> methods. My guess is that it is probably easier to use constructor
> parameters and use the page/panel injected beans as parameters to the
> models/behaviors.
>
> This is all without providing any integration libraries such as a "Wicket
> Arc" that would plug into arc for our purposes. It might be possible to do
> all the above automatically given the right integration, but I'm not an arc
> knower, nor a CDI implementation builder.
>
> What do y'all think?
>
> Martijn
>

Re: Quarkus CDI & Wicket sitting in a tree, maybe?

[Martin Terra <ma...@koodaripalvelut.com>]

to 24.4.2025 klo 8.26 Martijn Dashorst (martijn.dashorst@gmail.com)
kirjoitti:

> On Wed, 23 Apr 2025 at 23:26, Martin Terra <
> martin.terra@koodaripalvelut.com>
> wrote:
>
> > As long as it doesn't take over Wicket. Roughly it looks like "what do
> you
> > need wicket for if you decided to go heavy on CDI".
>
>
> The idea is to make such an integration that it would sit along side with
> wicket-cdi or such. However if one was to use quarkus and wicket it would
> come with some price.
>
> Thinking out loud: can't you just spin a non wicket CDI handler into a
> > different servlet and keep it separate from wicket?
>
>
> I'm not sure how that would help with injection of services in Wicket
> components.
>

Thanks for the perspective. I tried to google for an example with wicket
where it makes sense to have cdi within wicket.

I assume you have some experience with this. Can you refer to some example
or paste some meaningful code sample (hello world is too trivial)? Would
help to evaluate if tihs is something we should be looking into.

**
Martin


>
> >
> Martijn
>
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
>
>
>
> >
> > **
> > Martin
> >
> > ke 23.4.2025 klo 22.10 Martijn Dashorst (martijn.dashorst@gmail.com)
> > kirjoitti:
> >
> > > After some soul searching for a while I might have a workable idea for
> > > using Quarkus CDI and Wicket, which is probably the biggest hold back
> for
> > > using these technologies together.
> > >
> > > I've put my thoughts in this JIRA ticket in the last comment:
> > >
> > >
> >
> https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818
> > >
> > > I'll also paste my comment here:
> > >
> > > The issue is that ARC (the cdi implementation behind quarkus) doesn't
> > > support and isn't going to support non-contextual injections as it
> wants
> > to
> > > resolve injections at build time rather than deploy- and runtime.
> > Wicket's
> > > basic premise is that it is a non-managed framework where you are
> allowed
> > > to new your components and behaviors and models at will, which all
> escape
> > > the management of a CDI container.
> > >
> > > I'm thinking about this a bit for a while, and I figure that it might
> be
> > > possible to provide some form of integration if we limit some
> constructs
> > > that are now available for Wicket developers.
> > >
> > > First we need to make pages managed, and the restored state of pages
> > > managed when they are retrieved from the page store. This is probably
> > > fairly easy to build using a `@SessionScoped` CDI producer that
> retrieves
> > > pages either from a factory or from the pagestore if there's state
> > > available (i.e. there's a pageid in the request). This also means that
> > you
> > > are no longer allowed to instantiate pages yourself, but that they must
> > > have a default constructor, a pageparameters constructor or a
> > > mapper/factory that can instantiate the page based on the provided URL.
> > > This allows CDI to perform its injections on the retrieved instance(s).
> > I'm
> > > sure this would work for instantiating new pages. I'm not so sure about
> > > retrieving pages from the page store and getting those managed again
> > (about
> > > 90% hopeful that it works). This should also work with injected
> services
> > in
> > > the page instances, but not general component instances.
> > >
> > > Next we need a way to make Panels injectable with CDI beans. This is a
> > > hairy one. For now the only way I can foresee this working is to have
> an
> > > Instance<MyPanel> field in your page and get an instance from that to
> add
> > > to the page's component hierarchy. I'm open to other suggestions.
> > >
> > > As for scoping, I'm not 100% sure, but using the @RequestScope for the
> > page
> > > producers and panel instances might just work. We might need our own
> > scope,
> > > but I wouldn't know how that differs from the request scope for our
> > > purposes.
> > > Injection into behaviors and models is something that either needs to
> go
> > > through the Instance<Behavior> / Instance<FooModel> route or using
> > producer
> > > methods. My guess is that it is probably easier to use constructor
> > > parameters and use the page/panel injected beans as parameters to the
> > > models/behaviors.
> > >
> > > This is all without providing any integration libraries such as a
> "Wicket
> > > Arc" that would plug into arc for our purposes. It might be possible to
> > do
> > > all the above automatically given the right integration, but I'm not an
> > arc
> > > knower, nor a CDI implementation builder.
> > >
> > > What do y'all think?
> > >
> > > Martijn
> > >
> >
>

Re: Quarkus CDI & Wicket sitting in a tree, maybe?

[Martijn Dashorst <ma...@gmail.com>]

On Wed, 23 Apr 2025 at 23:26, Martin Terra <ma...@koodaripalvelut.com>
wrote:

> As long as it doesn't take over Wicket. Roughly it looks like "what do you
> need wicket for if you decided to go heavy on CDI".


The idea is to make such an integration that it would sit along side with
wicket-cdi or such. However if one was to use quarkus and wicket it would
come with some price.

Thinking out loud: can't you just spin a non wicket CDI handler into a
> different servlet and keep it separate from wicket?


I'm not sure how that would help with injection of services in Wicket
components.

>
Martijn

Become a Wicket expert, learn from the best: http://wicketinaction.com





>
> **
> Martin
>
> ke 23.4.2025 klo 22.10 Martijn Dashorst (martijn.dashorst@gmail.com)
> kirjoitti:
>
> > After some soul searching for a while I might have a workable idea for
> > using Quarkus CDI and Wicket, which is probably the biggest hold back for
> > using these technologies together.
> >
> > I've put my thoughts in this JIRA ticket in the last comment:
> >
> >
> https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818
> >
> > I'll also paste my comment here:
> >
> > The issue is that ARC (the cdi implementation behind quarkus) doesn't
> > support and isn't going to support non-contextual injections as it wants
> to
> > resolve injections at build time rather than deploy- and runtime.
> Wicket's
> > basic premise is that it is a non-managed framework where you are allowed
> > to new your components and behaviors and models at will, which all escape
> > the management of a CDI container.
> >
> > I'm thinking about this a bit for a while, and I figure that it might be
> > possible to provide some form of integration if we limit some constructs
> > that are now available for Wicket developers.
> >
> > First we need to make pages managed, and the restored state of pages
> > managed when they are retrieved from the page store. This is probably
> > fairly easy to build using a `@SessionScoped` CDI producer that retrieves
> > pages either from a factory or from the pagestore if there's state
> > available (i.e. there's a pageid in the request). This also means that
> you
> > are no longer allowed to instantiate pages yourself, but that they must
> > have a default constructor, a pageparameters constructor or a
> > mapper/factory that can instantiate the page based on the provided URL.
> > This allows CDI to perform its injections on the retrieved instance(s).
> I'm
> > sure this would work for instantiating new pages. I'm not so sure about
> > retrieving pages from the page store and getting those managed again
> (about
> > 90% hopeful that it works). This should also work with injected services
> in
> > the page instances, but not general component instances.
> >
> > Next we need a way to make Panels injectable with CDI beans. This is a
> > hairy one. For now the only way I can foresee this working is to have an
> > Instance<MyPanel> field in your page and get an instance from that to add
> > to the page's component hierarchy. I'm open to other suggestions.
> >
> > As for scoping, I'm not 100% sure, but using the @RequestScope for the
> page
> > producers and panel instances might just work. We might need our own
> scope,
> > but I wouldn't know how that differs from the request scope for our
> > purposes.
> > Injection into behaviors and models is something that either needs to go
> > through the Instance<Behavior> / Instance<FooModel> route or using
> producer
> > methods. My guess is that it is probably easier to use constructor
> > parameters and use the page/panel injected beans as parameters to the
> > models/behaviors.
> >
> > This is all without providing any integration libraries such as a "Wicket
> > Arc" that would plug into arc for our purposes. It might be possible to
> do
> > all the above automatically given the right integration, but I'm not an
> arc
> > knower, nor a CDI implementation builder.
> >
> > What do y'all think?
> >
> > Martijn
> >
>

Re: Quarkus CDI & Wicket sitting in a tree, maybe?

[Martin Terra <ma...@koodaripalvelut.com>]

As long as it doesn't take over Wicket. Roughly it looks like "what do you
need wicket for if you decided to go heavy on CDI".

Thinking out loud: can't you just spin a non wicket CDI handler into a
different servlet and keep it separate from wicket?

**
Martin

ke 23.4.2025 klo 22.10 Martijn Dashorst (martijn.dashorst@gmail.com)
kirjoitti:

> After some soul searching for a while I might have a workable idea for
> using Quarkus CDI and Wicket, which is probably the biggest hold back for
> using these technologies together.
>
> I've put my thoughts in this JIRA ticket in the last comment:
>
> https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818
>
> I'll also paste my comment here:
>
> The issue is that ARC (the cdi implementation behind quarkus) doesn't
> support and isn't going to support non-contextual injections as it wants to
> resolve injections at build time rather than deploy- and runtime. Wicket's
> basic premise is that it is a non-managed framework where you are allowed
> to new your components and behaviors and models at will, which all escape
> the management of a CDI container.
>
> I'm thinking about this a bit for a while, and I figure that it might be
> possible to provide some form of integration if we limit some constructs
> that are now available for Wicket developers.
>
> First we need to make pages managed, and the restored state of pages
> managed when they are retrieved from the page store. This is probably
> fairly easy to build using a `@SessionScoped` CDI producer that retrieves
> pages either from a factory or from the pagestore if there's state
> available (i.e. there's a pageid in the request). This also means that you
> are no longer allowed to instantiate pages yourself, but that they must
> have a default constructor, a pageparameters constructor or a
> mapper/factory that can instantiate the page based on the provided URL.
> This allows CDI to perform its injections on the retrieved instance(s). I'm
> sure this would work for instantiating new pages. I'm not so sure about
> retrieving pages from the page store and getting those managed again (about
> 90% hopeful that it works). This should also work with injected services in
> the page instances, but not general component instances.
>
> Next we need a way to make Panels injectable with CDI beans. This is a
> hairy one. For now the only way I can foresee this working is to have an
> Instance<MyPanel> field in your page and get an instance from that to add
> to the page's component hierarchy. I'm open to other suggestions.
>
> As for scoping, I'm not 100% sure, but using the @RequestScope for the page
> producers and panel instances might just work. We might need our own scope,
> but I wouldn't know how that differs from the request scope for our
> purposes.
> Injection into behaviors and models is something that either needs to go
> through the Instance<Behavior> / Instance<FooModel> route or using producer
> methods. My guess is that it is probably easier to use constructor
> parameters and use the page/panel injected beans as parameters to the
> models/behaviors.
>
> This is all without providing any integration libraries such as a "Wicket
> Arc" that would plug into arc for our purposes. It might be possible to do
> all the above automatically given the right integration, but I'm not an arc
> knower, nor a CDI implementation builder.
>
> What do y'all think?
>
> Martijn
>