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 >
