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 >
