CDI upgrade to 1.1

[Emond Papegaaij <em...@topicus.nl>]

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

Re: CDI upgrade to 1.1

[Igor Vaynberg <ig...@gmail.com>]

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
<em...@gmail.com> 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 <
> dominik.drzewiecki@gmail.com> 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 <em...@topicus.nl>
>>
>> > 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 */
>>

Re: CDI upgrade to 1.1

[Emond Papegaaij <em...@gmail.com>]

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 <
dominik.drzewiecki@gmail.com> 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 <em...@topicus.nl>
>
> > 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 */
>

Re: CDI upgrade to 1.1

[Dominik Drzewiecki <do...@gmail.com>]

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 <em...@topicus.nl>

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