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
