On Tue, Apr 17, 2012 at 9:19 AM, Mark Struberg <[email protected]> wrote: > 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.
i meant contracts on the Conversation interface, etc. > 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. you have to define a "wicket" application first. it is very rare for a large-ish application to use purely wicket. most applications end up using servlets for things like jaxb, rmi, etc. so we have to support not only wicket, but servlets as well. >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. we use it on a very large project and love it. we have a lot of complex ui workflows which wouldve been very clunky to implement without conversational scope. see https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-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. sure. weve hit a few problems, but nothing that was insurmountable. that is true with any non-trivial tech. > 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... funny. thats exactly what we do, store EntityManager in conversations. no problems here. so i would say that, while the model can certainly be improved, i do not think it is broken. -igor > > > 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 >>>> >>
