[
https://issues.apache.org/jira/browse/WICKET-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17946818#comment-17946818
]
Martijn Dashorst commented on WICKET-6917:
------------------------------------------
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.
> Create a module to integrate with Quarkus
> -----------------------------------------
>
> Key: WICKET-6917
> URL: https://issues.apache.org/jira/browse/WICKET-6917
> Project: Wicket
> Issue Type: New Feature
> Reporter: Amin Nasiri
> Priority: Minor
>
> As a developer, I would like to be able to integrate a
> [Quakrus|https://quarkus.io/] app with an apache Wicket app like
> Wicket-Spring.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
