A possible solution scenario:
a.) write an own @WicketConversationScoped scope + Context implementation which especially fits wicket, supports your browser tab handling, conversation propagation etc. This will fully portable and you have ALL the functionality fully in your own hands! b.) write a small extension which uses the @Observes ProcessAnnotatedType. In this Extension you can easily remove all cdi @ConversationScoped annotations and replace them via your very own @WicketConversation at container startup. Just modify the AnnotatedType as you need. The result is that a user can either use @WicketConversationScoped or the CDI @ConversationScoped but both will be handled as your own wicket conversations. You might also implement your own pendant to javax.enterprise.context.Conversation which is the interface to control the conversation lifecycle from within an application. I don't think that you need to support the built-in Conversation control. The important point is imo that people can reuse components which are annotated with @ConversationScoped. For them it would make no difference if the non-working CDI conversation or your own wicket conversation Context implementation does the actual work underneath. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Tuesday, April 17, 2012 9:29 AM > Subject: Re: wicket-cdi > > Whoops, clicked send to quickly ^^ > > s/ > I try to get > / > > I try to get a push request done until the weekend. > / > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Mark Struberg <[email protected]> >> To: "[email protected]" <[email protected]> >> Cc: >> Sent: Tuesday, April 17, 2012 9:18 AM >> Subject: wicket-cdi >> >> Hi folks! >> >> I've quickly checked the wicket-cdi project on github and it looks like > a >> good start. >> >> I'd just change a few tiny bits >> >> 1.) use org.apache.geronimo.specs packages instead of javax.* packages > because >> of license reasons >> >> 2.) drop the CDI conversation support. To be honest (as a CDI EG member) > The >> built-in CDI Conversation is not that useful as it has quite a few flaws, > no >> control api, etc. >> >> It might be better to introduce an own portable WicketConversation which >> supports the wicket browser-tab handling. Having a non-portable > conversation >> support is imo a no-go. This will most probably not even run on future Weld > >> containers... >> >> >> 3.) Please add a profile for Apache OpenWebBeans as well. Just to make sure > your >> project is really portable. >> >> I try to get >> >> >> txs and LieGrue, >> strub >> >
