On Wed, 23 Apr 2025 at 23:26, Martin Terra <martin.te...@koodaripalvelut.com> wrote:
> 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". The idea is to make such an integration that it would sit along side with wicket-cdi or such. However if one was to use quarkus and wicket it would come with some price. Thinking out loud: can't you just spin a non wicket CDI handler into a > different servlet and keep it separate from wicket? I'm not sure how that would help with injection of services in Wicket components. > Martijn Become a Wicket expert, learn from the best: http://wicketinaction.com > > ** > 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 > > >
