users@javaee-spec.java.net

[javaee-spec users] Re: [jsr342-experts] Re: CDI in Application Client Container

From: Peter Pilgrim <peter.pilgrim_at_gmail.com>
Date: Tue, 13 Nov 2012 14:56:59 +0100

Hi Antonio

I suppose that just leaves us with Arquillian, which is designed for
integration testing and the Weld and DeltaSpike. These are not
standardised and may be constrained to the application server vendor
API.

On 13 November 2012 13:55, Antonio Goncalves
<antonio.goncalves_at_gmail.com> wrote:
> No. Pete Muir just sent an email a few days ago saying this will be in CDI
> 2.0. I also find that disapointing because it could have been a winner
> feature to use more and more CDI on Java SE (and all the Java EE specs that
> can rely on just Java SE like JPA, JMS, JAX-WS, JAX-RS, Batch...)
>
> Antonio
>
>
> On Tue, Nov 13, 2012 at 12:21 PM, Peter Pilgrim <peter.pilgrim_at_gmail.com>
> wrote:
>>
>> Hi All
>>
>> Just a quick question, about this conversation.
>>
>> Will running CdiContainer outside the container be standardise for Java EE
>> 7?
>>
>> If you have a Rich Client application running in JavaFX for example,
>> and you want to rely on @Local injection for speed, or perhaps what to
>> allow pluggable producers for remote connection @Produces, then do you
>> not think it would good to have CdiContainer working outside the
>> container as a standard? I am quite sure that developer will want to
>> way to know if there is standard way of using CDI and EE injection
>> outside of a container.
>>
>> Cheers!
>>
>> On 13 November 2012 10:43, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
>> > Right, from my perspective as CDI spec lead, this is a mistake in the
>> > Java EE spec that was introduced when CDI was added to Java EE 6. The CDI
>> > spec unambiguously says that the Application Client Container is not
>> > required to be supported by CDI, and the CDI TCK does not test it.
>> >
>> > I'll raise this with the CDI EG and see if they want to support it or
>> > not. However, I would certainly vote no at this point. As I expressed, I
>> > would prefer to defer to CDI 2.0 when we define Java SE support - this then
>> > becomes an easy problem to solve.
>> >
>>
>>
>>
>> --
>> Peter Pilgrim,
>> **Java Champion**,
>> Java EE Software Development / Design / Architect for financial
>> services, London, UK
>>
>>
>> ====================================
>> :::: D E V O X X 2 0 1 2 ::::
>> ====================================
>>
>>
>> JavaFX ++ Scala ++ Groovy ++ Android ++ Java
>>
>> :: http://www.xenonique.co.uk/blog/ ::
>> :: http://twitter.com/peter_pilgrim ::
>> :: http://audio.fm/profile/peter_pilgrim ::
>> :: Skype Call peter_pilgrim ::
>> :: http://java-champions.java.net/ ::
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France



-- 
Peter Pilgrim,
**Java Champion**,
Java EE Software Development / Design / Architect for financial
services, London, UK
====================================
::::   D E V O X X   2 0 1 2    ::::
====================================
JavaFX ++ Scala ++ Groovy ++  Android ++ Java
:: http://www.xenonique.co.uk/blog/  ::
:: http://twitter.com/peter_pilgrim ::
:: http://audio.fm/profile/peter_pilgrim  ::
:: Skype Call peter_pilgrim ::
:: http://java-champions.java.net/ ::