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.dasho...@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
>

Reply via email to