Hi Igor! The Conversation behaviour is not defined at all for all the cases you mentioned. It is really purely only defined in faces requests!
The behaviour in ALL other cases, including non-faces Servlet requests or Wicket requests is NOT defined at all. For a Wicket app it would just make no sense at all to use the same context control as a JSF application. Instead you should create and define your own behaviour which works best for wicket applications. The trick with the CDI Extension to redefine @ConversationScoped beans to @WicketConversationScoped beans is only for making it possible to re-use already existing @ConversationScoped beans. Though I doubt that you will find many in real world projects... The CDI Conversation concept is imo seriously flawed and most people I know tried it but dumped it pretty quickly. You can take a look at CODI Conversations for example. There you will also find a list of issues with the current CDI Conversations. Again: this stuff looks cool if you read through the paper, but with big real world projects you pretty quickly hit a few problems. That's similar to storing the EntityManager in Conversations or the Session - just broken and completely unusable in real world apps where you have multiple cluster nodes... LieGrue, strub ----- Original Message ----- > From: Igor Vaynberg <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Tuesday, April 17, 2012 5:32 PM > Subject: Re: wicket-cdi > > what about applications that share conversations between wicket pages > and servlets? having a wicket-specific conversation impl seems too > narrow a usecase. why not just rebuild the conversation scope, making > it general, and controlled via a servletcontextlistener just like weld > does it...this should be portable and still work for everything....and > we can provide the SPI to control it. > > however, rebuilding such a thing in a way that works exactly how the > spec says would be no small fit. i am only for this if it can be > removed cleanly and easily once cdi-1.1 is out. > > further, we have code that activates conversations in > non-servlet-request threads. we use this to have a conversation around > background tasks. so this usecase, too, needs to be supported. > > -igor > > On Tue, Apr 17, 2012 at 4:10 AM, Mark Struberg <[email protected]> wrote: >> Yes, this will get added to CDI-1.1. >> >> >> But I personally expect CDI-1.1 only hit the street later that year. The > main reason for this is that CDI-1.0 is pretty well written and usable > already. > Most of the changes are clarifications and wording corrections which are > perfectly possible to implement without changing the API. Most of those > changes > already got implemented in the latest OWB and Weld versions. >> >> But things like the Context Control SPI changes are binary incompatible and > can only be implemented later. >> >> By providing your very own Context you have it all under full control. I > can help with the impl if you need some help. >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Emond Papegaaij <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Tuesday, April 17, 2012 12:21 PM >>> Subject: Re: wicket-cdi >>> >>> Ok, now I understand what you mean. Will it stay this way, or are there > plans >>> to add the the conversation SPI to the spec? I think I heard somewhere > that >>> they were planning to add those parts to the CDI spec, making it > possible to >>> use the conversation scope in a portable way. In that case, I'd > rather leave >>> >>> it like it is now and move the to new SPI later on. Writing a custom >>> conversation scope for wicket seems like a lot of work for something > that >>> already works fine with Seam. >>> >>> On Tuesday 17 April 2012 10:33:12 Mark Struberg wrote: >>>> The seam-conversation stuff only works with one of the n CDI > containers: >>>> Weld. >>>> >>>> >>>> It will NOT work on Apache OpenWebBeans, Geronimo, WAS, TomEE, etc >>>> It will not even run on a few versions of GlassFish because they > use a >>>> different Weld version. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> > From: Emond Papegaaij <[email protected]> >>>> > To: [email protected] >>>> > Cc: >>>> > Sent: Tuesday, April 17, 2012 11:21 AM >>>> > Subject: Re: wicket-cdi >>>> > >>>> >T hanks for the feedback! It's good that other people take > a look >>> at this >>>> > >>>> > code >>>> > before we put it in Wicket. >>>> > >>>> > I don't understand the problem with @ConversationScoped. > What do >>> you mean >>>> > with >>>> > non-portable? Portable to what? AFAIK the conversation scope > is part >>> of >>>> > the >>>> > CDI spec and the current implementation in wicket-cdi works > just fine, >>> at >>>> > least it does so for us. From what I understand we use it the > way it >>>> > should be used. >>>> > >>>> > Best regards, >>>> > Emond >>>> > >>>> > On Tuesday 17 April 2012 08:57:37 Mark Struberg wrote: >>>> >> 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 >>> >
