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