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 >>
