Yes, the conversational scope is the main reason for the upgrade. Seam-conversation has always been sort of a hack, and it is good to see this fixed. You say it is possible to deploy a CDI 1.1 provider as part of your web application, and this should indeed work. However, a CDI provider deployed in a war does not provide the same level of integration as the CDI provider that is loaded by the container. For example, it is not possible to inject classes like servlet listeners. Also, I'm not sure if extensions loaded by the container-CDI, such as the extensions provided by infinispan and resteasy, are available when you embed a CDI provider in your war. What would happen if you use the infispan extension to configure caches in your Wicket application or when you combine a REST webservice with a Wicket application in the same war? I know for sure that the weld servlet listener does not work when a CDI provider is already loaded by the container, which could make it difficult to integrate the newer version of weld in your application.
Relying on the availability of wildfly 8 and/or glassfish 4 is not an option IMHO. These projects have both shown not to stick to their deadlines. The wildfly guys even keep saying on their forum 'It's done when it's done'. This might very well be somewhere mid 2014 for all you know. I think we should be careful to provide a level of integration that is the same or better than Wicket 6 does, especially for popular containers like wildfly and glassfish. Perhaps we can split wicket-cdi into 3 components: core, cdi-1.0 and cdi-1.1. This way users can pick the version they are using, rather than changing the cdi version they are using. Best regards, Emond On Mon, May 6, 2013 at 11:18 PM, Dominik Drzewiecki < [email protected]> wrote: > I think that the rationale behind upgrading to CDI 1.1 is the support of > the conversational scope right in the spec. > Right now it is plumbed using seam-conversation-spi along with the > appropriate seam-conversation-{weld,owb,candi} container integration > module. The point is that seam-conversation is somewhat outdated and seems > abandoned (no new releases since version 3.0 in January 2012). It will not > work with openwebbeans >=1.1.4 nor will it work with tomee >=1.5.0 leaving > the user with the only option - weld 1.1.x. Don't be affraid of cdi 1.1 not > being implemented in containers, one can always settle for custom cdi > integration, deployed as part of web application - both weld and owb are > fitted with appropriate listeners that bootstrap embedded cdi container. > Besides, cdi 1.1 implementations are around the corner - Weld 2.0.0.Final > got released on 24 April, OWB guys declare that it will be pretty > straightforward to support CDI 1.1 after the refactorings that they had > done to OWB 1.2. I understand that upgrading CDI impl in containers already > supporting it is not an option, but by the time wicket 7 RCs start rolling, > both wildfly (jboss 8) and glassfish 4 reach GA (both use weld). > > regz, > /dd > > > 2013/5/6 Emond Papegaaij <[email protected]> > > > Hi all, > > > > I noticed the TODO for Wicket 7 to upgrade the CDI dependency > > to 1.1. I think it's better to pospone this upgrade to Wicket 8. > > CDI 1.1 is part of JEE 7, for which the spec only has been > > approved last week. Containers will need some time to > > implement the spec, for example wildFly (formerly JBoss) 8 is > > expected to be released in November and Glassfish somewhere > > this summer. Upgrading CDI in a container like Glassfish 3.2 or > > JBoss 7 often is not option, so I think it's probably better not to > > upgrade wicket-cdi before containers supporting CDI 1.1 are > > available. > > > > Best regards, > > Emond > > > > > > -- > /* Spelin donut mader if iz ina coment */ >
