most likely wicket-cdi module will be cloned into wicket-cdi-1.1
module with the old one remaining...

-igor

On Mon, May 6, 2013 at 11:03 PM, Emond Papegaaij
<[email protected]> wrote:
> 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 */
>>

Reply via email to