From tremes at redhat.com  Fri Jan  2 02:15:20 2015
From: tremes at redhat.com (Tomas Remes)
Date: Fri, 2 Jan 2015 02:15:20 -0500 (EST)
Subject: [cdi-dev] where
	is	defined	javax.enterprise.context.conversation.id?
In-Reply-To: <1331379549.2620478.1419933448581.JavaMail.yahoo@jws11105.mail.ir2.yahoo.com>
References: <CA+ZZq9-8YEi9xe119O-Lxwk4Jz-bVFuiEZntooNSQh4J+KZM1w@mail.gmail.com>
	<1331379549.2620478.1419933448581.JavaMail.yahoo@jws11105.mail.ir2.yahoo.com>
Message-ID: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>



Hi,

I've checked the related TCK test and it seems to me valid. In CDI spec there is:

"6.7.5. The Conversation interface
The container provides a built-in bean with bean type Conversation , scope @RequestScoped ,
and qualifier @Default , named javax.enterprise.context.conversation ." 

Tom

----- Original Message -----
From: "Mark Struberg" <struberg at yahoo.de>
To: "Antonio Goncalves" <antonio.goncalves at gmail.com>, "Romain Manni-Bucau" <rmannibucau at gmail.com>
Cc: cdi-dev at lists.jboss.org
Sent: Tuesday, December 30, 2014 10:57:28 AM
Subject: Re: [cdi-dev] where is	defined	javax.enterprise.context.conversation.id?

cid is a different thing. But I did nowhere (spec and api) find the one mentioned by Romain.
So I think it's not specified and we need to exclude this test.

LieGrue,
strub



On Monday, 29 December 2014, 21:41, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:


>
>
>Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>
>
>6.7.4. Conversation context lifecycle
>(...)
>The long-running conversation associated with a
>request may be propagated to any Servlet request via use of a request parameter named cid
>containing the unique identifier of the conversation. In this case, the application must manage this
>request parameter.
>(...)
>
>This is accomplished via use of a request parameter named cid containing the unique
>identifier of the conversation.
>(...)
>
>
>
>On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>
>Hi guys
>>
>>didnt find in CDI and JSF PDFs where is defined
>>"javax.enterprise.context.conversation.id". Seems it should be
>>available in ELs.
>>
>>Do you have any pointer please?
>>
>>
>>Romain Manni-Bucau
>>@rmannibucau
>>http://www.tomitribe.com
>>http://rmannibucau.wordpress.com
>>https://github.com/rmannibucau
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>
>
>
>-- 
>
>Antonio Goncalves 
>Software architect, Java Champion and Pluralsight author
>
>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From jharting at redhat.com  Fri Jan  2 02:27:23 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 02 Jan 2015 08:27:23 +0100
Subject: [cdi-dev] Ordering of AfterTypeDiscovery#getAlternatives() et al
In-Reply-To: <101161120.171272.1419251804611.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com>
References: <5497D9D3.7080303@redhat.com>
	<101161120.171272.1419251804611.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com>
Message-ID: <54A6485B.4060502@redhat.com>

Ordering in the list defines the ordering of the invocation. The 
ordering of invocation for interceptors and decorators is explicitly 
defined as ascending. That implies that the ordering of 
interceptors/decorator list should be ascending as well.

Analogously, the list of alternatives is expected to be ascending.

On 12/22/2014 01:36 PM, Mark Struberg wrote:
>> Why did you change that for interceptors and decorators?
> Oh that's totally fine. Remember that the ordering in the list defines the ordering of the invocation. An if someone would re-sort that list then he must know if it is ascending or descending.
>
> LieGrue,
> strub
>
>
>
>
>
>> On Monday, 22 December 2014, 10:42, Jozef Hartinger <jharting at redhat.com> wrote:
>> On 12/22/2014 09:24 AM, Romain Manni-Bucau wrote:
>>>   hi
>>>
>>>   2014-12-22 9:23 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>   On 12/20/2014 11:26 AM, Mark Struberg wrote:
>>>>>   Hi!
>>>>>
>>>>>   If I have a
>>>>>
>>>>>
>>>>>   @Priority(100)
>>>>>   public class MyAlternative implements Foo ..
>>>>>
>>>>>   and
>>>>>
>>>>>
>>>>>   @Priority(101)
>>>>>   public class ABetterAlternative implements Foo ..
>>>>>
>>>>>
>>>>>   Then ABetterAlternative will finally be chosen.
>>>>>
>>>>>   This ordering can be changed via
>> AfterTypeDiscovery#getAlternatives().
>>>>>   But the spec only says "returns the ordered list of enabled
>> alternatives for the application.."
>>>>>   But it does NOT define in which sorting this list is ordered ;)
>>>>>
>>>>>   In OWB we hat the 'most important' alternative come first.
>> It seems in Weld it is the other way around.
>>>>   What sorting do you use for interceptors and decorators?
>>>   until yesterday the same as for runtime
>> Why did you change that for interceptors and decorators?
>>
>>>>>   I have no problem with changing this in OWB, but I would like to
>> get this clarified in our JavaDocs and spec.
>>>>   Agreed. Go ahead and file an issue.
>>>>>   LieGrue,
>>>>>   strub
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>>>   _______________________________________________
>>>>   cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>


From jharting at redhat.com  Fri Jan  2 02:40:45 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 02 Jan 2015 08:40:45 +0100
Subject: [cdi-dev] Possible cycle with ProcessBeanAttributes only for
 enabled beans
In-Reply-To: <1814799008.327138.1419271127269.JavaMail.yahoo@jws11175.mail.ir2.yahoo.com>
References: <1814799008.327138.1419271127269.JavaMail.yahoo@jws11175.mail.ir2.yahoo.com>
Message-ID: <54A64B7D.5030401@redhat.com>

You cannot just fire ProcessBeanAttributes the moment you run across 
Bravo. You need to figure out whether it is specialized or not first 
(which means processing Charlie). This is not new at all - this was the 
case since CDI 1.0 with ProcessBean.

As for the extension case the moment an extension vetoes BeanAttributes, 
you should check whether that action makes any previously disabled beans 
enabled. If so, fire ProcessBeanAttributes for them. Repeat untill all 
beans are processed.

On 12/22/2014 06:58 PM, Mark Struberg wrote:
>
> The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes must only get fired for ENABLED beans:
>
> "The container fires an event of this type for each enabled bean, interceptor or decorator deployed in a bean archive before registering the Bean object."
>
>
> The test
>
> org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
> has a nice example
>
>
> @Specializes class Charly extends
>    -> @Specializes class Bravo extends
>      -> class Alpha
>
> Which ProcessBeanAttributes events would you except to get fired?
>   *) Alpha? No, because it's specialized away (5.1.2. Enabled and disabled beans).
>   *) Bravo? No, because it's specialized away as well, right?
>   *) Charly? Yes, because that's the only _enabled_ bean!
>
>
> So far, so clear. But now comes the tricky part!
>
> This test also has an Extension which observes ProcessBeanAttributes and disables Charly.
> This means that finally Bravo is enabled, Charly disabled (is there actually a difference btw disabled and vetoed spec wording wise?)
>
> The problem is now that we only know this AFTER the ProcessBeanAttributes for Charly got fired. And this introduces an ordering issue:
> If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, then we do not know YET that Charly will get disabled. Thus we fire the ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
>
> Otoh if Charly gets scanned first, then Bravo will not get processed.
>
>
> Can you follow me?
>
>
> LieGrue,
> strub
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From tremes at redhat.com  Fri Jan  2 02:54:57 2015
From: tremes at redhat.com (Tomas Remes)
Date: Fri, 2 Jan 2015 02:54:57 -0500 (EST)
Subject: [cdi-dev] session destroyed event
In-Reply-To: <CACLE=7Pvaz_uhxZo8fGCBhM=jS2Bu97dmLQpWxsVB-d61JWVOg@mail.gmail.com>
References: <CACLE=7PEORMaKsUZsBZDJ63JexuBevMLhO9d=cTFNMMH=ZWQgg@mail.gmail.com>
	<477289819.3566690.1419847351578.JavaMail.zimbra@redhat.com>
	<CACLE=7Pvaz_uhxZo8fGCBhM=jS2Bu97dmLQpWxsVB-d61JWVOg@mail.gmail.com>
Message-ID: <1049969966.4518447.1420185297184.JavaMail.zimbra@redhat.com>



Ok so let's move back to cdi-dev list too.:) Can you please elaborate bit more why do you think it's not consistent?

Thank's
Tom

----- Original Message -----
From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
To: "Tomas Remes" <tremes at redhat.com>
Cc: cdi-tck at lists.jboss.org
Sent: Monday, December 29, 2014 11:08:49 AM
Subject: Re: [cdi-dev] session destroyed event

Hi

sorry to have used the wrong list.

Issue is then scope is not consistent (think to login/logout mecanism
for instance).


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-12-29 11:02 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
> Hi,
>
> I think the destroy event is triggered at the end of the request and not immediately if I understand correctly. The spec states:
>
> "The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListener s have been called, and at the very end of any request in which
> invalidate() was called, after all filters and ServletRequestListener s have been called."
>
> Please let's move TCK related topics to cdi-tck mailing list.
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> To: cdi-dev at lists.jboss.org
> Sent: Tuesday, December 23, 2014 8:58:16 PM
> Subject: [cdi-dev] session destroyed event
>
> Hi
>
> why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures
>
> destroyed == observer.getDestroyedSessionCount().get()
>
> For me invalidate call should trigger the destroy event: you can
> create N session in a single requests
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>

-- 
Tomas Remes



From jharting at redhat.com  Fri Jan  2 03:11:11 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 02 Jan 2015 09:11:11 +0100
Subject: [cdi-dev] unproxyable constraint for ejbs
In-Reply-To: <CACLE=7PMi=2azDo8R+xArHNOXjVwQZTkuMHRko2RGiR67vvs0A@mail.gmail.com>
References: <CACLE=7PMi=2azDo8R+xArHNOXjVwQZTkuMHRko2RGiR67vvs0A@mail.gmail.com>
Message-ID: <54A6529F.5080906@redhat.com>

Agreed. The test looks incorrect.

On 12/23/2014 09:07 PM, Romain Manni-Bucau wrote:
> Hi
>
> org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelMissile
> will make the container throw a DeploymentException cause of public
> final void finalManeuver() which is final...but it is not in the EJB
> API so CDI shouldn't even know it.
>
> Is the test buggy -
> org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelInterceptorTest?
>
> IMO this has not to be tested since the EJB container already does it.
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From jharting at redhat.com  Fri Jan  2 03:15:35 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 02 Jan 2015 09:15:35 +0100
Subject: [cdi-dev]
 org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown
 and exception handling
In-Reply-To: <CACLE=7O77ydsUnOh2rf08=6SjzvWxP8F5roNtvA-i1BPiVL6+A@mail.gmail.com>
References: <CACLE=7PQEq9+z643CGkYsmgvmWj79YR0Fj0QG0Pv9Ydzz8Z7qw@mail.gmail.com>	<CAOqetn9QEADvQ+MrVcb-7s1AhMhsvMdbwtrCM11tzV+hzHZf+Q@mail.gmail.com>
	<CACLE=7O77ydsUnOh2rf08=6SjzvWxP8F5roNtvA-i1BPiVL6+A@mail.gmail.com>
Message-ID: <54A653A7.9060408@redhat.com>

If the exception is handled why is then status set to 500?

On 12/24/2014 06:57 PM, Romain Manni-Bucau wrote:
> there is a NonexistentConversationException (sorry dont have the exact
> name right now). It is what is expected then the outermostfilter write
> few things in the response but it is "too late" status is 500. All
> other tests relying on the same thing do the set to avoid the
> exception but not this one.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-24 18:39 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
>> Why is the http client throwing an exception? AFAIK http client is just
>> making requests and generating the responding response as string or
>> otherwise.  html unit is trying to then convert it to a page to process the
>> content.
>>
>> On Wed Dec 24 2014 at 12:14:15 PM Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>> Hi
>>>
>>> isnt "client.setThrowExceptionOnFailingStatusCode(false);" missing in
>>>
>>> org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown?
>>>
>>> Cause it expects an exception but by default httpclient will throw an
>>> exception before any validation is done
>>>
>>> what do I miss?
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From rmannibucau at gmail.com  Fri Jan  2 03:37:25 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 2 Jan 2015 09:37:25 +0100
Subject: [cdi-dev]
 org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown
 and exception handling
In-Reply-To: <54A653A7.9060408@redhat.com>
References: <CACLE=7PQEq9+z643CGkYsmgvmWj79YR0Fj0QG0Pv9Ydzz8Z7qw@mail.gmail.com>
	<CAOqetn9QEADvQ+MrVcb-7s1AhMhsvMdbwtrCM11tzV+hzHZf+Q@mail.gmail.com>
	<CACLE=7O77ydsUnOh2rf08=6SjzvWxP8F5roNtvA-i1BPiVL6+A@mail.gmail.com>
	<54A653A7.9060408@redhat.com>
Message-ID: <CACLE=7N9=heN3cnHAKNoxfMPAj0XCfA84eiHOD8AC-4huV4O1w@mail.gmail.com>

Cause JSF layer set response code to 500


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 9:15 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
> If the exception is handled why is then status set to 500?
>
>
> On 12/24/2014 06:57 PM, Romain Manni-Bucau wrote:
>>
>> there is a NonexistentConversationException (sorry dont have the exact
>> name right now). It is what is expected then the outermostfilter write
>> few things in the response but it is "too late" status is 500. All
>> other tests relying on the same thing do the set to avoid the
>> exception but not this one.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-24 18:39 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:
>>>
>>> Why is the http client throwing an exception? AFAIK http client is just
>>> making requests and generating the responding response as string or
>>> otherwise.  html unit is trying to then convert it to a page to process
>>> the
>>> content.
>>>
>>> On Wed Dec 24 2014 at 12:14:15 PM Romain Manni-Bucau
>>> <rmannibucau at gmail.com>
>>> wrote:
>>>>
>>>> Hi
>>>>
>>>> isnt "client.setThrowExceptionOnFailingStatusCode(false);" missing in
>>>>
>>>>
>>>> org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testNonexistentConversationExceptionThrown?
>>>>
>>>> Cause it expects an exception but by default httpclient will throw an
>>>> exception before any validation is done
>>>>
>>>> what do I miss?
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>
>

From rmannibucau at gmail.com  Fri Jan  2 03:46:05 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 2 Jan 2015 09:46:05 +0100
Subject: [cdi-dev] session destroyed event
In-Reply-To: <1049969966.4518447.1420185297184.JavaMail.zimbra@redhat.com>
References: <CACLE=7PEORMaKsUZsBZDJ63JexuBevMLhO9d=cTFNMMH=ZWQgg@mail.gmail.com>
	<477289819.3566690.1419847351578.JavaMail.zimbra@redhat.com>
	<CACLE=7Pvaz_uhxZo8fGCBhM=jS2Bu97dmLQpWxsVB-d61JWVOg@mail.gmail.com>
	<1049969966.4518447.1420185297184.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7M5xmWSvsMfjbah=8Jv1teVprwQ4UdnRD682GHbnoNCDQ@mail.gmail.com>

If the spec mandates the session scope to be >= request scope then if
you logout during a request you would keep incorrect session.

If you do:

request {
  filter {
     playWithSession();
     logout();
  }
  auditSession();
}

Then your audit will still be bound to the user before the logout but
actually it is no more accurate. Can be ok in some cases but can be an
issue in some others. Also in this case destroy event will have a
session which can have been garbaged/destoyed by the container and
potentially (if pooled) reaffected to another request.

If you take the login case it is the opposite and here if you use
sessionId in your logic you can have troubles as well since it is very
recommanded (sometimes forced by the container) to change the
sessionId when a user is logged.




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 8:54 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
>
> Ok so let's move back to cdi-dev list too.:) Can you please elaborate bit more why do you think it's not consistent?
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> To: "Tomas Remes" <tremes at redhat.com>
> Cc: cdi-tck at lists.jboss.org
> Sent: Monday, December 29, 2014 11:08:49 AM
> Subject: Re: [cdi-dev] session destroyed event
>
> Hi
>
> sorry to have used the wrong list.
>
> Issue is then scope is not consistent (think to login/logout mecanism
> for instance).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-29 11:02 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>
>> Hi,
>>
>> I think the destroy event is triggered at the end of the request and not immediately if I understand correctly. The spec states:
>>
>> "The session context is destroyed when the HTTPSession times out, after all
>> HttpSessionListener s have been called, and at the very end of any request in which
>> invalidate() was called, after all filters and ServletRequestListener s have been called."
>>
>> Please let's move TCK related topics to cdi-tck mailing list.
>>
>> Thank's
>> Tom
>>
>> ----- Original Message -----
>> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
>> To: cdi-dev at lists.jboss.org
>> Sent: Tuesday, December 23, 2014 8:58:16 PM
>> Subject: [cdi-dev] session destroyed event
>>
>> Hi
>>
>> why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures
>>
>> destroyed == observer.getDestroyedSessionCount().get()
>>
>> For me invalidate call should trigger the destroy event: you can
>> create N session in a single requests
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
>
> --
> Tomas Remes
>
>


From rmannibucau at gmail.com  Fri Jan  2 03:51:44 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 2 Jan 2015 09:51:44 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
References: <CA+ZZq9-8YEi9xe119O-Lxwk4Jz-bVFuiEZntooNSQh4J+KZM1w@mail.gmail.com>
	<1331379549.2620478.1419933448581.JavaMail.yahoo@jws11105.mail.ir2.yahoo.com>
	<1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7MCcagQ1c47Bjiv1cNNJGj1TSFJmKUyzZh3xxv+dz643w@mail.gmail.com>

Wow it was not trivial to find, thank you Tomas!

BTW (and mainly for future): is it a right idea to use '.' in names cause of EL?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 8:15 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
>
> Hi,
>
> I've checked the related TCK test and it seems to me valid. In CDI spec there is:
>
> "6.7.5. The Conversation interface
> The container provides a built-in bean with bean type Conversation , scope @RequestScoped ,
> and qualifier @Default , named javax.enterprise.context.conversation ."
>
> Tom
>
> ----- Original Message -----
> From: "Mark Struberg" <struberg at yahoo.de>
> To: "Antonio Goncalves" <antonio.goncalves at gmail.com>, "Romain Manni-Bucau" <rmannibucau at gmail.com>
> Cc: cdi-dev at lists.jboss.org
> Sent: Tuesday, December 30, 2014 10:57:28 AM
> Subject: Re: [cdi-dev] where is defined javax.enterprise.context.conversation.id?
>
> cid is a different thing. But I did nowhere (spec and api) find the one mentioned by Romain.
> So I think it's not specified and we need to exclude this test.
>
> LieGrue,
> strub
>
>
>
> On Monday, 29 December 2014, 21:41, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
>
>
>>
>>
>>Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>>
>>
>>6.7.4. Conversation context lifecycle
>>(...)
>>The long-running conversation associated with a
>>request may be propagated to any Servlet request via use of a request parameter named cid
>>containing the unique identifier of the conversation. In this case, the application must manage this
>>request parameter.
>>(...)
>>
>>This is accomplished via use of a request parameter named cid containing the unique
>>identifier of the conversation.
>>(...)
>>
>>
>>
>>On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>>Hi guys
>>>
>>>didnt find in CDI and JSF PDFs where is defined
>>>"javax.enterprise.context.conversation.id". Seems it should be
>>>available in ELs.
>>>
>>>Do you have any pointer please?
>>>
>>>
>>>Romain Manni-Bucau
>>>@rmannibucau
>>>http://www.tomitribe.com
>>>http://rmannibucau.wordpress.com
>>>https://github.com/rmannibucau
>>>_______________________________________________
>>>cdi-dev mailing list
>>>cdi-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>
>>
>>
>>--
>>
>>Antonio Goncalves
>>Software architect, Java Champion and Pluralsight author
>>
>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>


From tremes at redhat.com  Fri Jan  2 05:04:28 2015
From: tremes at redhat.com (Tomas Remes)
Date: Fri, 2 Jan 2015 05:04:28 -0500 (EST)
Subject: [cdi-dev] unproxyable constraint for ejbs
In-Reply-To: <54A6529F.5080906@redhat.com>
References: <CACLE=7PMi=2azDo8R+xArHNOXjVwQZTkuMHRko2RGiR67vvs0A@mail.gmail.com>
	<54A6529F.5080906@redhat.com>
Message-ID: <1827673475.4547823.1420193068261.JavaMail.zimbra@redhat.com>



Yes. I created https://issues.jboss.org/browse/CDITCK-461 and need to check CDI spec if it is worth of clarification issue. 

Thank's
Tom

----- Original Message -----
From: "Jozef Hartinger" <jharting at redhat.com>
To: "Romain Manni-Bucau" <rmannibucau at gmail.com>, cdi-dev at lists.jboss.org
Sent: Friday, January 2, 2015 9:11:11 AM
Subject: Re: [cdi-dev] unproxyable constraint for ejbs

Agreed. The test looks incorrect.

On 12/23/2014 09:07 PM, Romain Manni-Bucau wrote:
> Hi
>
> org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelMissile
> will make the container throw a DeploymentException cause of public
> final void finalManeuver() which is final...but it is not in the EJB
> API so CDI shouldn't even know it.
>
> Is the test buggy -
> org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelInterceptorTest?
>
> IMO this has not to be tested since the EJB container already does it.
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-- 
Tomas Remes


From struberg at yahoo.de  Fri Jan  2 05:59:47 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 2 Jan 2015 10:59:47 +0000 (UTC)
Subject: [cdi-dev] where
	is	defined	javax.enterprise.context.conversation.id?
In-Reply-To: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
References: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
Message-ID: <1008727728.3543772.1420196387949.JavaMail.yahoo@jws11154.mail.ir2.yahoo.com>

I've grepped all the cdi spec project and this string doesn't appear. When did this got added?

LieGrue,
strub





> On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com> wrote:
> > 
> 
> Hi,
> 
> I've checked the related TCK test and it seems to me valid. In CDI spec 
> there is:
> 
> "6.7.5. The Conversation interface
> The container provides a built-in bean with bean type Conversation , scope 
> @RequestScoped ,
> and qualifier @Default , named javax.enterprise.context.conversation ." 
> 
> Tom
> 
> 
> ----- Original Message -----
> From: "Mark Struberg" <struberg at yahoo.de>
> To: "Antonio Goncalves" <antonio.goncalves at gmail.com>, 
> "Romain Manni-Bucau" <rmannibucau at gmail.com>
> Cc: cdi-dev at lists.jboss.org
> Sent: Tuesday, December 30, 2014 10:57:28 AM
> Subject: Re: [cdi-dev] where is    defined    
> javax.enterprise.context.conversation.id?
> 
> cid is a different thing. But I did nowhere (spec and api) find the one 
> mentioned by Romain.
> So I think it's not specified and we need to exclude this test.
> 
> LieGrue,
> strub
> 
> 
> 
> On Monday, 29 December 2014, 21:41, Antonio Goncalves 
> <antonio.goncalves at gmail.com> wrote:
> 
> 
>> 
>> 
>> Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>> 
>> 
>> 6.7.4. Conversation context lifecycle
>> (...)
>> The long-running conversation associated with a
>> request may be propagated to any Servlet request via use of a request 
> parameter named cid
>> containing the unique identifier of the conversation. In this case, the 
> application must manage this
>> request parameter.
>> (...)
>> 
>> This is accomplished via use of a request parameter named cid containing the 
> unique
>> identifier of the conversation.
>> (...)
>> 
>> 
>> 
>> On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>> 
>> Hi guys
>>> 
>>> didnt find in CDI and JSF PDFs where is defined
>>> "javax.enterprise.context.conversation.id". Seems it should be
>>> available in ELs.
>>> 
>>> Do you have any pointer please?
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> Antonio Goncalves 
>> Software architect, Java Champion and Pluralsight author
>> 
>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>> 
>> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From rmannibucau at gmail.com  Fri Jan  2 06:01:15 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 2 Jan 2015 12:01:15 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <1008727728.3543772.1420196387949.JavaMail.yahoo@jws11154.mail.ir2.yahoo.com>
References: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
	<1008727728.3543772.1420196387949.JavaMail.yahoo@jws11154.mail.ir2.yahoo.com>
Message-ID: <CACLE=7PKD0O=QozuC3OJo===eW6Yvkbg8jtM4sVgRvKeHZ1GqQ@mail.gmail.com>

@Mark: "6.7.5. The Conversation interface" has it in CDI 1.2 at least


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 11:59 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> I've grepped all the cdi spec project and this string doesn't appear. When did this got added?
>
> LieGrue,
> strub
>
>
>
>
>
>> On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com> wrote:
>> >
>>
>> Hi,
>>
>> I've checked the related TCK test and it seems to me valid. In CDI spec
>> there is:
>>
>> "6.7.5. The Conversation interface
>> The container provides a built-in bean with bean type Conversation , scope
>> @RequestScoped ,
>> and qualifier @Default , named javax.enterprise.context.conversation ."
>>
>> Tom
>>
>>
>> ----- Original Message -----
>> From: "Mark Struberg" <struberg at yahoo.de>
>> To: "Antonio Goncalves" <antonio.goncalves at gmail.com>,
>> "Romain Manni-Bucau" <rmannibucau at gmail.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Tuesday, December 30, 2014 10:57:28 AM
>> Subject: Re: [cdi-dev] where is    defined
>> javax.enterprise.context.conversation.id?
>>
>> cid is a different thing. But I did nowhere (spec and api) find the one
>> mentioned by Romain.
>> So I think it's not specified and we need to exclude this test.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 29 December 2014, 21:41, Antonio Goncalves
>> <antonio.goncalves at gmail.com> wrote:
>>
>>
>>>
>>>
>>> Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>>>
>>>
>>> 6.7.4. Conversation context lifecycle
>>> (...)
>>> The long-running conversation associated with a
>>> request may be propagated to any Servlet request via use of a request
>> parameter named cid
>>> containing the unique identifier of the conversation. In this case, the
>> application must manage this
>>> request parameter.
>>> (...)
>>>
>>> This is accomplished via use of a request parameter named cid containing the
>> unique
>>> identifier of the conversation.
>>> (...)
>>>
>>>
>>>
>>> On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
>> <rmannibucau at gmail.com> wrote:
>>>
>>> Hi guys
>>>>
>>>> didnt find in CDI and JSF PDFs where is defined
>>>> "javax.enterprise.context.conversation.id". Seems it should be
>>>> available in ELs.
>>>>
>>>> Do you have any pointer please?
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>>
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>

From struberg at yahoo.de  Fri Jan  2 06:49:13 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 2 Jan 2015 11:49:13 +0000 (UTC)
Subject: [cdi-dev] where
	is	defined	javax.enterprise.context.conversation.id?
In-Reply-To: <1008727728.3543772.1420196387949.JavaMail.yahoo@jws11154.mail.ir2.yahoo.com>
References: <1455666291.4513465.1420182920496.JavaMail.zimbra@redhat.com>
	<1008727728.3543772.1420196387949.JavaMail.yahoo@jws11154.mail.ir2.yahoo.com>
Message-ID: <223705296.3575589.1420199353686.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com>

Forget it, I found it. Maybe I had some typo in my grep...




LieGrue,
strub



> On Friday, 2 January 2015, 11:59, Mark Struberg <struberg at yahoo.de> wrote:
> > I've grepped all the cdi spec project and this string doesn't appear. 
> When did this got added?
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
> 
>>  On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com> 
> wrote:
>>  > 
>> 
>>  Hi,
>> 
>>  I've checked the related TCK test and it seems to me valid. In CDI spec 
> 
>>  there is:
>> 
>>  "6.7.5. The Conversation interface
>>  The container provides a built-in bean with bean type Conversation , scope 
>>  @RequestScoped ,
>>  and qualifier @Default , named javax.enterprise.context.conversation 
> ." 
>> 
>>  Tom
>> 
>> 
>>  ----- Original Message -----
>>  From: "Mark Struberg" <struberg at yahoo.de>
>>  To: "Antonio Goncalves" <antonio.goncalves at gmail.com>, 
>>  "Romain Manni-Bucau" <rmannibucau at gmail.com>
>>  Cc: cdi-dev at lists.jboss.org
>>  Sent: Tuesday, December 30, 2014 10:57:28 AM
>>  Subject: Re: [cdi-dev] where is    defined    
>>  javax.enterprise.context.conversation.id?
>> 
>>  cid is a different thing. But I did nowhere (spec and api) find the one 
>>  mentioned by Romain.
>>  So I think it's not specified and we need to exclude this test.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>>  On Monday, 29 December 2014, 21:41, Antonio Goncalves 
>>  <antonio.goncalves at gmail.com> wrote:
>> 
>> 
>>> 
>>> 
>>>  Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>>> 
>>> 
>>>  6.7.4. Conversation context lifecycle
>>>  (...)
>>>  The long-running conversation associated with a
>>>  request may be propagated to any Servlet request via use of a request 
>>  parameter named cid
>>>  containing the unique identifier of the conversation. In this case, the 
> 
>>  application must manage this
>>>  request parameter.
>>>  (...)
>>> 
>>>  This is accomplished via use of a request parameter named cid 
> containing the 
>>  unique
>>>  identifier of the conversation.
>>>  (...)
>>> 
>>> 
>>> 
>>>  On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau 
>>  <rmannibucau at gmail.com> wrote:
>>> 
>>>  Hi guys
>>>> 
>>>>  didnt find in CDI and JSF PDFs where is defined
>>>>  "javax.enterprise.context.conversation.id". Seems it 
> should be
>>>>  available in ELs.
>>>> 
>>>>  Do you have any pointer please?
>>>> 
>>>> 
>>>>  Romain Manni-Bucau
>>>>  @rmannibucau
>>>>  http://www.tomitribe.com
>>>>  http://rmannibucau.wordpress.com
>>>>  https://github.com/rmannibucau
>>>>  _______________________________________________
>>>>  cdi-dev mailing list
>>>>  cdi-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>  Note that for all code provided on this list, the provider licenses 
> the 
>>  code under the Apache License, Version 2 
>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>  on this list, the provider waives all patent and other intellectual 
> property 
>>  rights inherent in such information.
>>>> 
>>> 
>>> 
>>> 
>>>  -- 
>>> 
>>>  Antonio Goncalves 
>>>  Software architect, Java Champion and Pluralsight author
>>> 
>>>  Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>> 
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>  Note that for all code provided on this list, the provider licenses the 
> code 
>>  under the Apache License, Version 2 
>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>  on this list, the provider waives all patent and other intellectual 
> property 
>>  rights inherent in such information.
>>> 
>>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code 
>>  under the Apache License, Version 2 
>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>  on this list, the provider waives all patent and other intellectual 
> property 
>>  rights inherent in such information.
>> 
> 

From issues at jboss.org  Fri Jan  2 07:01:29 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 2 Jan 2015 07:01:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086454@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.17627.1420200089503@Atlassian.JIRA>

Tomas Remes created CDI-496:
-------------------------------

             Summary: Clarification (or completion) for interceptor binding to session bean
                 Key: CDI-496
                 URL: https://issues.jboss.org/browse/CDI-496
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:

{quote}Managed beans and EJB session and message-driven beans support interception.{quote}

But at the end of "9.3. Binding an interceptor to a bean" There is only:

{quote}
If a managed bean has a class-level or method-level interceptor binding, the managed bean must
be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From struberg at yahoo.de  Fri Jan  2 09:17:21 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 2 Jan 2015 14:17:21 +0000 (UTC)
Subject: [cdi-dev]
	where	is	defined	javax.enterprise.context.conversation.id?
In-Reply-To: <223705296.3575589.1420199353686.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com>
References: <223705296.3575589.1420199353686.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com>
Message-ID: <142757097.3601121.1420208241250.JavaMail.yahoo@jws11172.mail.ir2.yahoo.com>

Folks, I fear there is another issue:


Are dots in EL names even allowed? I think not.

Please read up EL-3.0

1.6 Operators [] and .
The EL follows ECMAScript in unifying the treatment of the . and [] operators.

And in ECMAScript dots are afaik _not_ allowed in names!


If it works in some implementations then that is fine, but it is not required by the spec -> non portable. We must not require this in CDI!

Gonna ping the servlet EG to get this confirmed.



LieGrue,
strub



> On Friday, 2 January 2015, 12:50, Mark Struberg <struberg at yahoo.de> wrote:
> > Forget it, I found it. Maybe I had some typo in my grep...
> 
> 
> 
> 
> LieGrue,
> strub
> 
> 
> 
> 
>>  On Friday, 2 January 2015, 11:59, Mark Struberg <struberg at yahoo.de> 
> wrote:
>>  > I've grepped all the cdi spec project and this string doesn't 
> appear. 
>>  When did this got added?
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>> 
>> 
>>>   On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com> 
> 
>>  wrote:
>>>   > 
>>> 
>>>   Hi,
>>> 
>>>   I've checked the related TCK test and it seems to me valid. In CDI 
> spec 
>> 
>>>   there is:
>>> 
>>>   "6.7.5. The Conversation interface
>>>   The container provides a built-in bean with bean type Conversation , 
> scope 
>>>   @RequestScoped ,
>>>   and qualifier @Default , named javax.enterprise.context.conversation 
>>  ." 
>>> 
>>>   Tom
>>> 
>>> 
>>>   ----- Original Message -----
>>>   From: "Mark Struberg" <struberg at yahoo.de>
>>>   To: "Antonio Goncalves" <antonio.goncalves at gmail.com>, 
> 
>>>   "Romain Manni-Bucau" <rmannibucau at gmail.com>
>>>   Cc: cdi-dev at lists.jboss.org
>>>   Sent: Tuesday, December 30, 2014 10:57:28 AM
>>>   Subject: Re: [cdi-dev] where is    defined    
>>>   javax.enterprise.context.conversation.id?
>>> 
>>>   cid is a different thing. But I did nowhere (spec and api) find the 
> one 
>>>   mentioned by Romain.
>>>   So I think it's not specified and we need to exclude this test.
>>> 
>>>   LieGrue,
>>>   strub
>>> 
>>> 
>>> 
>>>   On Monday, 29 December 2014, 21:41, Antonio Goncalves 
>>>   <antonio.goncalves at gmail.com> wrote:
>>> 
>>> 
>>>> 
>>>> 
>>>>   Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>>>> 
>>>> 
>>>>   6.7.4. Conversation context lifecycle
>>>>   (...)
>>>>   The long-running conversation associated with a
>>>>   request may be propagated to any Servlet request via use of a 
> request 
>>>   parameter named cid
>>>>   containing the unique identifier of the conversation. In this 
> case, the 
>> 
>>>   application must manage this
>>>>   request parameter.
>>>>   (...)
>>>> 
>>>>   This is accomplished via use of a request parameter named cid 
>>  containing the 
>>>   unique
>>>>   identifier of the conversation.
>>>>   (...)
>>>> 
>>>> 
>>>> 
>>>>   On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau 
>>>   <rmannibucau at gmail.com> wrote:
>>>> 
>>>>   Hi guys
>>>>> 
>>>>>   didnt find in CDI and JSF PDFs where is defined
>>>>>   "javax.enterprise.context.conversation.id". Seems it 
> 
>>  should be
>>>>>   available in ELs.
>>>>> 
>>>>>   Do you have any pointer please?
>>>>> 
>>>>> 
>>>>>   Romain Manni-Bucau
>>>>>   @rmannibucau
>>>>>   http://www.tomitribe.com
>>>>>   http://rmannibucau.wordpress.com
>>>>>   https://github.com/rmannibucau
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>   Note that for all code provided on this list, the provider 
> licenses 
>>  the 
>>>   code under the Apache License, Version 2 
>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> 
>>  provided 
>>>   on this list, the provider waives all patent and other intellectual 
>>  property 
>>>   rights inherent in such information.
>>>>> 
>>>> 
>>>> 
>>>> 
>>>>   -- 
>>>> 
>>>>   Antonio Goncalves 
>>>>   Software architect, Java Champion and Pluralsight author
>>>> 
>>>>   Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx 
> France
>>>> 
>>>>   _______________________________________________
>>>>   cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>   Note that for all code provided on this list, the provider 
> licenses the 
>>  code 
>>>   under the Apache License, Version 2 
>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> 
>>  provided 
>>>   on this list, the provider waives all patent and other intellectual 
>>  property 
>>>   rights inherent in such information.
>>>> 
>>>> 
>>>   _______________________________________________
>>>   cdi-dev mailing list
>>>   cdi-dev at lists.jboss.org
>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>   Note that for all code provided on this list, the provider licenses 
> the 
>>  code 
>>>   under the Apache License, Version 2 
>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> 
>>  provided 
>>>   on this list, the provider waives all patent and other intellectual 
>>  property 
>>>   rights inherent in such information.
>>> 
>> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From john.d.ament at gmail.com  Fri Jan  2 09:30:24 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 02 Jan 2015 14:30:24 +0000
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
References: <223705296.3575589.1420199353686.JavaMail.yahoo@jws11107.mail.ir2.yahoo.com>
	<142757097.3601121.1420208241250.JavaMail.yahoo@jws11172.mail.ir2.yahoo.com>
Message-ID: <CAOqetn9c2BX6XoAKHbQbzFt3rA97d2NgoHyVF6vm=kWSzr1csQ@mail.gmail.com>

As far as I know, dots are allowed in ECMAScript, under dot notation.

On Fri Jan 02 2015 at 9:17:38 AM Mark Struberg <struberg at yahoo.de> wrote:

> Folks, I fear there is another issue:
>
>
> Are dots in EL names even allowed? I think not.
>
> Please read up EL-3.0
>
> 1.6 Operators [] and .
> The EL follows ECMAScript in unifying the treatment of the . and []
> operators.
>
> And in ECMAScript dots are afaik _not_ allowed in names!
>
>
> If it works in some implementations then that is fine, but it is not
> required by the spec -> non portable. We must not require this in CDI!
>
> Gonna ping the servlet EG to get this confirmed.
>
>
>
> LieGrue,
> strub
>
>
>
> > On Friday, 2 January 2015, 12:50, Mark Struberg <struberg at yahoo.de>
> wrote:
> > > Forget it, I found it. Maybe I had some typo in my grep...
> >
> >
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >>  On Friday, 2 January 2015, 11:59, Mark Struberg <struberg at yahoo.de>
> > wrote:
> >>  > I've grepped all the cdi spec project and this string doesn't
> > appear.
> >>  When did this got added?
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>>   On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com>
> >
> >>  wrote:
> >>>   >
> >>>
> >>>   Hi,
> >>>
> >>>   I've checked the related TCK test and it seems to me valid. In CDI
> > spec
> >>
> >>>   there is:
> >>>
> >>>   "6.7.5. The Conversation interface
> >>>   The container provides a built-in bean with bean type Conversation ,
> > scope
> >>>   @RequestScoped ,
> >>>   and qualifier @Default , named javax.enterprise.context.conversation
> >>  ."
> >>>
> >>>   Tom
> >>>
> >>>
> >>>   ----- Original Message -----
> >>>   From: "Mark Struberg" <struberg at yahoo.de>
> >>>   To: "Antonio Goncalves" <antonio.goncalves at gmail.com>,
> >
> >>>   "Romain Manni-Bucau" <rmannibucau at gmail.com>
> >>>   Cc: cdi-dev at lists.jboss.org
> >>>   Sent: Tuesday, December 30, 2014 10:57:28 AM
> >>>   Subject: Re: [cdi-dev] where is    defined
> >>>   javax.enterprise.context.conversation.id?
> >>>
> >>>   cid is a different thing. But I did nowhere (spec and api) find the
> > one
> >>>   mentioned by Romain.
> >>>   So I think it's not specified and we need to exclude this test.
> >>>
> >>>   LieGrue,
> >>>   strub
> >>>
> >>>
> >>>
> >>>   On Monday, 29 December 2014, 21:41, Antonio Goncalves
> >>>   <antonio.goncalves at gmail.com> wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>>   Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
> >>>>
> >>>>
> >>>>   6.7.4. Conversation context lifecycle
> >>>>   (...)
> >>>>   The long-running conversation associated with a
> >>>>   request may be propagated to any Servlet request via use of a
> > request
> >>>   parameter named cid
> >>>>   containing the unique identifier of the conversation. In this
> > case, the
> >>
> >>>   application must manage this
> >>>>   request parameter.
> >>>>   (...)
> >>>>
> >>>>   This is accomplished via use of a request parameter named cid
> >>  containing the
> >>>   unique
> >>>>   identifier of the conversation.
> >>>>   (...)
> >>>>
> >>>>
> >>>>
> >>>>   On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
> >>>   <rmannibucau at gmail.com> wrote:
> >>>>
> >>>>   Hi guys
> >>>>>
> >>>>>   didnt find in CDI and JSF PDFs where is defined
> >>>>>   "javax.enterprise.context.conversation.id". Seems it
> >
> >>  should be
> >>>>>   available in ELs.
> >>>>>
> >>>>>   Do you have any pointer please?
> >>>>>
> >>>>>
> >>>>>   Romain Manni-Bucau
> >>>>>   @rmannibucau
> >>>>>   http://www.tomitribe.com
> >>>>>   http://rmannibucau.wordpress.com
> >>>>>   https://github.com/rmannibucau
> >>>>>   _______________________________________________
> >>>>>   cdi-dev mailing list
> >>>>>   cdi-dev at lists.jboss.org
> >>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>>
> >>>>>   Note that for all code provided on this list, the provider
> > licenses
> >>  the
> >>>   code under the Apache License, Version 2
> >>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas
> >
> >>  provided
> >>>   on this list, the provider waives all patent and other intellectual
> >>  property
> >>>   rights inherent in such information.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>   --
> >>>>
> >>>>   Antonio Goncalves
> >>>>   Software architect, Java Champion and Pluralsight author
> >>>>
> >>>>   Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> > France
> >>>>
> >>>>   _______________________________________________
> >>>>   cdi-dev mailing list
> >>>>   cdi-dev at lists.jboss.org
> >>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>>   Note that for all code provided on this list, the provider
> > licenses the
> >>  code
> >>>   under the Apache License, Version 2
> >>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas
> >
> >>  provided
> >>>   on this list, the provider waives all patent and other intellectual
> >>  property
> >>>   rights inherent in such information.
> >>>>
> >>>>
> >>>   _______________________________________________
> >>>   cdi-dev mailing list
> >>>   cdi-dev at lists.jboss.org
> >>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>>   Note that for all code provided on this list, the provider licenses
> > the
> >>  code
> >>>   under the Apache License, Version 2
> >>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas
> >
> >>  provided
> >>>   on this list, the provider waives all patent and other intellectual
> >>  property
> >>>   rights inherent in such information.
> >>>
> >>
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided
> > on this list, the provider waives all patent and other intellectual
> property
> > rights inherent in such information.
> >
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150102/18b5fe4a/attachment-0001.html 

From struberg at yahoo.de  Fri Jan  2 10:10:00 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 2 Jan 2015 15:10:00 +0000 (UTC)
Subject: [cdi-dev] where is defined
 javax.enterprise.context.conversation.id?
In-Reply-To: <CAOqetn9c2BX6XoAKHbQbzFt3rA97d2NgoHyVF6vm=kWSzr1csQ@mail.gmail.com>
References: <CAOqetn9c2BX6XoAKHbQbzFt3rA97d2NgoHyVF6vm=kWSzr1csQ@mail.gmail.com>
Message-ID: <1090297593.3655627.1420211400276.JavaMail.yahoo@jws11146.mail.ir2.yahoo.com>

but 'dot notation' in ECMAScript means that the dot is used to access properties of a variable:


myvar.x is just another way to access 

myvar["x"]
And of course variables inside a variable [1].


Otoh I've found no explicit statement that dots are disallowed neither.

LieGrue,
strub


[1] http://www.ecma-international.org/ecma-262/5.1/#sec-11.2.1


On Friday, 2 January 2015, 15:30, John D. Ament <john.d.ament at gmail.com> wrote:


>
>
>As far as I know, dots are allowed in ECMAScript, under dot notation.
>
>
>On Fri Jan 02 2015 at 9:17:38 AM Mark Struberg <struberg at yahoo.de> wrote:
>
>Folks, I fear there is another issue:
>>
>>
>>Are dots in EL names even allowed? I think not.
>>
>>Please read up EL-3.0
>>
>>1.6 Operators [] and .
>>The EL follows ECMAScript in unifying the treatment of the . and [] operators.
>>
>>And in ECMAScript dots are afaik _not_ allowed in names!
>>
>>
>>If it works in some implementations then that is fine, but it is not required by the spec -> non portable. We must not require this in CDI!
>>
>>Gonna ping the servlet EG to get this confirmed.
>>
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>> On Friday, 2 January 2015, 12:50, Mark Struberg <struberg at yahoo.de> wrote:
>>> > Forget it, I found it. Maybe I had some typo in my grep...
>>>
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>>  On Friday, 2 January 2015, 11:59, Mark Struberg <struberg at yahoo.de>
>>> wrote:
>>>>  > I've grepped all the cdi spec project and this string doesn't
>>> appear.
>>>>  When did this got added?
>>>>
>>>>  LieGrue,
>>>>  strub
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>   On Friday, 2 January 2015, 8:15, Tomas Remes <tremes at redhat.com>
>>>
>>>>  wrote:
>>>>>   >
>>>>>
>>>>>   Hi,
>>>>>
>>>>>   I've checked the related TCK test and it seems to me valid. In CDI
>>> spec
>>>>
>>>>>   there is:
>>>>>
>>>>>   "6.7.5. The Conversation interface
>>>>>   The container provides a built-in bean with bean type Conversation ,
>>> scope
>>>>>   @RequestScoped ,
>>>>>   and qualifier @Default , named javax.enterprise.context.conversation
>>>>  ."
>>>>>
>>>>>   Tom
>>>>>
>>>>>
>>>>>   ----- Original Message -----
>>>>>   From: "Mark Struberg" <struberg at yahoo.de>
>>>>>   To: "Antonio Goncalves" <antonio.goncalves at gmail.com>,
>>>
>>>>>   "Romain Manni-Bucau" <rmannibucau at gmail.com>
>>>>>   Cc: cdi-dev at lists.jboss.org
>>>>>   Sent: Tuesday, December 30, 2014 10:57:28 AM
>>>>>   Subject: Re: [cdi-dev] where is    defined
>>>>>   javax.enterprise.context.conversation.id?
>>>>>
>>>>>   cid is a different thing. But I did nowhere (spec and api) find the
>>> one
>>>>>   mentioned by Romain.
>>>>>   So I think it's not specified and we need to exclude this test.
>>>>>
>>>>>   LieGrue,
>>>>>   strub
>>>>>
>>>>>
>>>>>
>>>>>   On Monday, 29 December 2014, 21:41, Antonio Goncalves
>>>>>   <antonio.goncalves at gmail.com> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>   Nothing in JSF nor in Servlet, but in CDI 1.2 Specification :
>>>>>>
>>>>>>
>>>>>>   6.7.4. Conversation context lifecycle
>>>>>>   (...)
>>>>>>   The long-running conversation associated with a
>>>>>>   request may be propagated to any Servlet request via use of a
>>> request
>>>>>   parameter named cid
>>>>>>   containing the unique identifier of the conversation. In this
>>> case, the
>>>>
>>>>>   application must manage this
>>>>>>   request parameter.
>>>>>>   (...)
>>>>>>
>>>>>>   This is accomplished via use of a request parameter named cid
>>>>  containing the
>>>>>   unique
>>>>>>   identifier of the conversation.
>>>>>>   (...)
>>>>>>
>>>>>>
>>>>>>
>>>>>>   On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
>>>>>   <rmannibucau at gmail.com> wrote:
>>>>>>
>>>>>>   Hi guys
>>>>>>>
>>>>>>>   didnt find in CDI and JSF PDFs where is defined
>>>>>>>   "javax.enterprise.context.conversation.id". Seems it
>>>
>>>>  should be
>>>>>>>   available in ELs.
>>>>>>>
>>>>>>>   Do you have any pointer please?
>>>>>>>
>>>>>>>
>>>>>>>   Romain Manni-Bucau
>>>>>>>   @rmannibucau
>>>>>>>   http://www.tomitribe.com
>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>   https://github.com/rmannibucau
>>>>>>>   _______________________________________________
>>>>>>>   cdi-dev mailing list
>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>   Note that for all code provided on this list, the provider
>>> licenses
>>>>  the
>>>>>   code under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>
>>>>  provided
>>>>>   on this list, the provider waives all patent and other intellectual
>>>>  property
>>>>>   rights inherent in such information.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   --
>>>>>>
>>>>>>   Antonio Goncalves
>>>>>>   Software architect, Java Champion and Pluralsight author
>>>>>>
>>>>>>   Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>>> France
>>>>>>
>>>>>>   _______________________________________________
>>>>>>   cdi-dev mailing list
>>>>>>   cdi-dev at lists.jboss.org
>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>   Note that for all code provided on this list, the provider
>>> licenses the
>>>>  code
>>>>>   under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>
>>>>  provided
>>>>>   on this list, the provider waives all patent and other intellectual
>>>>  property
>>>>>   rights inherent in such information.
>>>>>>
>>>>>>
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>>> the
>>>>  code
>>>>>   under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>
>>>>  provided
>>>>>   on this list, the provider waives all patent and other intellectual
>>>>  property
>>>>>   rights inherent in such information.
>>>>>
>>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>>> on this list, the provider waives all patent and other intellectual property
>>> rights inherent in such information.
>>>
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>
>

From mjremijan at yahoo.com  Fri Jan  2 11:02:09 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Fri, 2 Jan 2015 16:02:09 +0000 (UTC)
Subject: [cdi-dev] Question regarding producer methods and default no-arg
	constructor
Message-ID: <908394098.3704324.1420214529726.JavaMail.yahoo@jws10618.mail.bf1.yahoo.com>

Greetings,
I recently ran into a situation where I had created a producer method for an object but when Weld was starting up I got errors about something being ambiguous.? I finally tracked the issue to the fact that the bean my producer method was responsible for producing only had a default no-arg constructor.? I was able to "work around" this problem by annotating the bean as an @Alternative.? So I have a few questions.
(1)Is this expected behavior from CDI? If a bean only has the default no-arg constructor should you get an ambiguous error if you also have a producer method for the bean?
(2)Is annotating the bean as an @Alternative an acceptable "work around"?? Seems hackish to me. If not, what is the appropriate solution.
Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150102/a3a52093/attachment.html 

From rmannibucau at gmail.com  Fri Jan  2 12:17:26 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 2 Jan 2015 18:17:26 +0100
Subject: [cdi-dev] Question regarding producer methods and default
	no-arg constructor
In-Reply-To: <908394098.3704324.1420214529726.JavaMail.yahoo@jws10618.mail.bf1.yahoo.com>
References: <908394098.3704324.1420214529726.JavaMail.yahoo@jws10618.mail.bf1.yahoo.com>
Message-ID: <CACLE=7ORRf5GOwnuocasX-spHQC=PDg5POiE4XVHyjEgAtnx+A@mail.gmail.com>

Hi Michael,

1) yes if the bean is scanned as well
2) you can use @Alternative but using <scan />, @Vetoed, or @Typed()
for CDI 1.0 should work as well and are maybe less hacky since you'll
never activate this alternative right?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 17:02 GMT+01:00 Michael Remijan <mjremijan at yahoo.com>:
> Greetings,
>
> I recently ran into a situation where I had created a producer method for an
> object but when Weld was starting up I got errors about something being
> ambiguous.  I finally tracked the issue to the fact that the bean my
> producer method was responsible for producing only had a default no-arg
> constructor.  I was able to "work around" this problem by annotating the
> bean as an @Alternative.  So I have a few questions.
>
> (1)
> Is this expected behavior from CDI? If a bean only has the default no-arg
> constructor should you get an ambiguous error if you also have a producer
> method for the bean?
>
> (2)
> Is annotating the bean as an @Alternative an acceptable "work around"?
> Seems hackish to me. If not, what is the appropriate solution.
>
> Thanks!
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

From mjremijan at yahoo.com  Fri Jan  2 15:03:08 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Fri, 2 Jan 2015 20:03:08 +0000 (UTC)
Subject: [cdi-dev] Question regarding producer methods and default
 no-arg constructor
In-Reply-To: <CACLE=7ORRf5GOwnuocasX-spHQC=PDg5POiE4XVHyjEgAtnx+A@mail.gmail.com>
References: <CACLE=7ORRf5GOwnuocasX-spHQC=PDg5POiE4XVHyjEgAtnx+A@mail.gmail.com>
Message-ID: <1400452043.3755611.1420228988259.JavaMail.yahoo@jws106140.mail.bf1.yahoo.com>

Yes that's right.? I don't want the bean activated directly because the producer method does some additional logic before activation.
 

     On Friday, January 2, 2015 11:17 AM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
   

 Hi Michael,

1) yes if the bean is scanned as well
2) you can use @Alternative but using <scan />, @Vetoed, or @Typed()
for CDI 1.0 should work as well and are maybe less hacky since you'll
never activate this alternative right?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 17:02 GMT+01:00 Michael Remijan <mjremijan at yahoo.com>:
> Greetings,
>
> I recently ran into a situation where I had created a producer method for an
> object but when Weld was starting up I got errors about something being
> ambiguous.? I finally tracked the issue to the fact that the bean my
> producer method was responsible for producing only had a default no-arg
> constructor.? I was able to "work around" this problem by annotating the
> bean as an @Alternative.? So I have a few questions.
>
> (1)
> Is this expected behavior from CDI? If a bean only has the default no-arg
> constructor should you get an ambiguous error if you also have a producer
> method for the bean?
>
> (2)
> Is annotating the bean as an @Alternative an acceptable "work around"?
> Seems hackish to me. If not, what is the appropriate solution.
>
> Thanks!
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150102/dab37b48/attachment.html 

From struberg at yahoo.de  Fri Jan  2 16:10:53 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 2 Jan 2015 21:10:53 +0000 (UTC)
Subject: [cdi-dev] where is defined
 javax.enterprise.context.conversation.id?
In-Reply-To: <1090297593.3655627.1420211400276.JavaMail.yahoo@jws11146.mail.ir2.yahoo.com>
References: <1090297593.3655627.1420211400276.JavaMail.yahoo@jws11146.mail.ir2.yahoo.com>
Message-ID: <302946057.3754184.1420233053665.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>

As far as I've understood after reading 7.6 [1] dots are only allowed if either the dot or the whole variable name is quoted

a\.b = 42

or 

'a.b' = 42

but 

a.b = 42 is illegal.


The spec also only says that the BEAN must have this very name and not that the bean must be accessible by EL. If we would really require this and the EL specification doesn't support it, then the CDI spec would contradict the EL spec, right?


LieGrue,
strub




[1] http://www.ecma-international.org/ecma-262/5.1/#sec-7.6



> On Friday, 2 January 2015, 16:11, Mark Struberg <struberg at yahoo.de> wrote:
> > but 'dot notation' in ECMAScript means that the dot is used to access 
> properties of a variable:
> 
> 
> myvar.x is just another way to access 
> 
> myvar["x"]
> And of course variables inside a variable [1].
> 
> 
> Otoh I've found no explicit statement that dots are disallowed neither.
> 
> LieGrue,
> strub
> 
> 
> [1] http://www.ecma-international.org/ecma-262/5.1/#sec-11.2.1
> 
> 
> On Friday, 2 January 2015, 15:30, John D. Ament <john.d.ament at gmail.com> 
> wrote:
> 
> 
>> 
>> 
>> As far as I know, dots are allowed in ECMAScript, under dot notation.
>> 
>> 
>> On Fri Jan 02 2015 at 9:17:38 AM Mark Struberg <struberg at yahoo.de> 
> wrote:
>> 
>> Folks, I fear there is another issue:
>>> 
>>> 
>>> Are dots in EL names even allowed? I think not.
>>> 
>>> Please read up EL-3.0
>>> 
>>> 1.6 Operators [] and .
>>> The EL follows ECMAScript in unifying the treatment of the . and [] 
> operators.
>>> 
>>> And in ECMAScript dots are afaik _not_ allowed in names!
>>> 
>>> 
>>> If it works in some implementations then that is fine, but it is not 
> required by the spec -> non portable. We must not require this in CDI!
>>> 
>>> Gonna ping the servlet EG to get this confirmed.
>>> 
>>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>>>  On Friday, 2 January 2015, 12:50, Mark Struberg 
> <struberg at yahoo.de> wrote:
>>>>  > Forget it, I found it. Maybe I had some typo in my grep...
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>   On Friday, 2 January 2015, 11:59, Mark Struberg 
> <struberg at yahoo.de>
>>>>  wrote:
>>>>>   > I've grepped all the cdi spec project and this string 
> doesn't
>>>>  appear.
>>>>>   When did this got added?
>>>>> 
>>>>>   LieGrue,
>>>>>   strub
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>>    On Friday, 2 January 2015, 8:15, Tomas Remes 
> <tremes at redhat.com>
>>>> 
>>>>>   wrote:
>>>>>>    >
>>>>>> 
>>>>>>    Hi,
>>>>>> 
>>>>>>    I've checked the related TCK test and it seems to me 
> valid. In CDI
>>>>  spec
>>>>> 
>>>>>>    there is:
>>>>>> 
>>>>>>    "6.7.5. The Conversation interface
>>>>>>    The container provides a built-in bean with bean type 
> Conversation ,
>>>>  scope
>>>>>>    @RequestScoped ,
>>>>>>    and qualifier @Default , named 
> javax.enterprise.context.conversation
>>>>>   ."
>>>>>> 
>>>>>>    Tom
>>>>>> 
>>>>>> 
>>>>>>    ----- Original Message -----
>>>>>>    From: "Mark Struberg" <struberg at yahoo.de>
>>>>>>    To: "Antonio Goncalves" 
> <antonio.goncalves at gmail.com>,
>>>> 
>>>>>>    "Romain Manni-Bucau" 
> <rmannibucau at gmail.com>
>>>>>>    Cc: cdi-dev at lists.jboss.org
>>>>>>    Sent: Tuesday, December 30, 2014 10:57:28 AM
>>>>>>    Subject: Re: [cdi-dev] where is    defined
>>>>>>    javax.enterprise.context.conversation.id?
>>>>>> 
>>>>>>    cid is a different thing. But I did nowhere (spec and 
> api) find the
>>>>  one
>>>>>>    mentioned by Romain.
>>>>>>    So I think it's not specified and we need to exclude 
> this test.
>>>>>> 
>>>>>>    LieGrue,
>>>>>>    strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>    On Monday, 29 December 2014, 21:41, Antonio Goncalves
>>>>>>    <antonio.goncalves at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>    Nothing in JSF nor in Servlet, but in CDI 1.2 
> Specification :
>>>>>>> 
>>>>>>> 
>>>>>>>    6.7.4. Conversation context lifecycle
>>>>>>>    (...)
>>>>>>>    The long-running conversation associated with a
>>>>>>>    request may be propagated to any Servlet request via 
> use of a
>>>>  request
>>>>>>    parameter named cid
>>>>>>>    containing the unique identifier of the conversation. 
> In this
>>>>  case, the
>>>>> 
>>>>>>    application must manage this
>>>>>>>    request parameter.
>>>>>>>    (...)
>>>>>>> 
>>>>>>>    This is accomplished via use of a request parameter 
> named cid
>>>>>   containing the
>>>>>>    unique
>>>>>>>    identifier of the conversation.
>>>>>>>    (...)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>    On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
>>>>>>    <rmannibucau at gmail.com> wrote:
>>>>>>> 
>>>>>>>    Hi guys
>>>>>>>> 
>>>>>>>>    didnt find in CDI and JSF PDFs where is defined
>>>>>>>>   
> "javax.enterprise.context.conversation.id". Seems it
>>>> 
>>>>>   should be
>>>>>>>>    available in ELs.
>>>>>>>> 
>>>>>>>>    Do you have any pointer please?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>    Romain Manni-Bucau
>>>>>>>>    @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>    _______________________________________________
>>>>>>>>    cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>>    Note that for all code provided on this list, the 
> provider
>>>>  licenses
>>>>>   the
>>>>>>    code under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>> 
>>>>>   provided
>>>>>>    on this list, the provider waives all patent and other 
> intellectual
>>>>>   property
>>>>>>    rights inherent in such information.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>    --
>>>>>>> 
>>>>>>>    Antonio Goncalves
>>>>>>>    Software architect, Java Champion and Pluralsight 
> author
>>>>>>> 
>>>>>>>    Web site | Twitter | LinkedIn | Pluralsight | Paris 
> JUG | Devoxx
>>>>  France
> 
>>>>>>> 
>>>>>>>    _______________________________________________
>>>>>>>    cdi-dev mailing list
>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>    Note that for all code provided on this list, the 
> provider
>>>>  licenses the
>>>>>   code
>>>>>>    under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>> 
>>>>>   provided
>>>>>>    on this list, the provider waives all patent and other 
> intellectual
>>>>>   property
>>>>>>    rights inherent in such information.
>>>>>>> 
>>>>>>> 
>>>>>>    _______________________________________________
>>>>>>    cdi-dev mailing list
>>>>>>   cdi-dev at lists.jboss.org
>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>>    Note that for all code provided on this list, the 
> provider licenses
>>>>  the
>>>>>   code
>>>>>>    under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>> 
>>>>>   provided
>>>>>>    on this list, the provider waives all patent and other 
> intellectual
>>>>>   property
>>>>>>    rights inherent in such information.
>>>>>> 
>>>>> 
>>>>  _______________________________________________
>>>>  cdi-dev mailing list
>>>>  cdi-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>  Note that for all code provided on this list, the provider licenses 
> the code
>>>>  under the Apache License, Version 2
>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other 
> ideas provided
>>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>>  rights inherent in such information.
>>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>> 
>> 
>> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From radim.hanus at gmail.com  Fri Jan  2 16:58:34 2015
From: radim.hanus at gmail.com (=?UTF-8?B?UmFkaW0gSGFudcWh?=)
Date: Fri, 2 Jan 2015 22:58:34 +0100
Subject: [cdi-dev] Question regarding producer methods and default
	no-arg constructor
In-Reply-To: <908394098.3704324.1420214529726.JavaMail.yahoo@jws10618.mail.bf1.yahoo.com>
References: <908394098.3704324.1420214529726.JavaMail.yahoo@jws10618.mail.bf1.yahoo.com>
Message-ID: <CAFrbYmMyduojGhCUtMVKb8taRg=R=zWYO1yLRp39C0r=Vuxqmg@mail.gmail.com>

Hi Michael,

you may also consider the following possibilities:

1) the class defining producer method is not a bean itself (in CDI 1.2 use
beans.xml with both version 1.1 and bean-discovery-mode of annotated and
don't apply any bean defining annotation)

2) define a qualifier and use it either on bean or producer method in
conjunction with inject

Radim


2015-01-02 17:02 GMT+01:00 Michael Remijan <mjremijan at yahoo.com>:

> Greetings,
>
> I recently ran into a situation where I had created a producer method for
> an object but when Weld was starting up I got errors about something being
> ambiguous.  I finally tracked the issue to the fact that the bean my
> producer method was responsible for producing only had a default no-arg
> constructor.  I was able to "work around" this problem by annotating the
> bean as an @Alternative.  So I have a few questions.
>
> (1)
> Is this expected behavior from CDI? If a bean only has the default no-arg
> constructor should you get an ambiguous error if you also have a producer
> method for the bean?
>
> (2)
> Is annotating the bean as an @Alternative an acceptable "work around"?
> Seems hackish to me. If not, what is the appropriate solution.
>
> Thanks!
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150102/27c80cb6/attachment.html 

From struberg at yahoo.de  Sat Jan  3 16:39:57 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 3 Jan 2015 21:39:57 +0000 (UTC)
Subject: [cdi-dev] Possible cycle with ProcessBeanAttributes only for
 enabled beans
In-Reply-To: <54A64B7D.5030401@redhat.com>
References: <54A64B7D.5030401@redhat.com>
Message-ID: <753697505.4091909.1420321197122.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com>

But I CANNOT know if it is enabled before I fire ProcessBeanAttributes! Because this PBA#veto() has a huge impact on which class is enabled or not.


And no, in CDI-1.0 there was only ProcessBean which did imo _not_ have a veto() method. This only got added with ProcessBeanAttributes, right?


I think in practice this will rarely be an issue, but there are cases where it is not really deterministic but depending on the order in which the classes get processed.


LieGrue,
strub





> On Friday, 2 January 2015, 8:40, Jozef Hartinger <jharting at redhat.com> wrote:
> > You cannot just fire ProcessBeanAttributes the moment you run across 
> Bravo. You need to figure out whether it is specialized or not first 
> (which means processing Charlie). This is not new at all - this was the 
> case since CDI 1.0 with ProcessBean.
> 
> As for the extension case the moment an extension vetoes BeanAttributes, 
> you should check whether that action makes any previously disabled beans 
> enabled. If so, fire ProcessBeanAttributes for them. Repeat untill all 
> beans are processed.
> 
> 
> On 12/22/2014 06:58 PM, Mark Struberg wrote:
>> 
>>  The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes 
> must only get fired for ENABLED beans:
>> 
>>  "The container fires an event of this type for each enabled bean, 
> interceptor or decorator deployed in a bean archive before registering the Bean 
> object."
>> 
>> 
>>  The test
>> 
>> 
> org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
>>  has a nice example
>> 
>> 
>>  @Specializes class Charly extends
>>     -> @Specializes class Bravo extends
>>       -> class Alpha
>> 
>>  Which ProcessBeanAttributes events would you except to get fired?
>>    *) Alpha? No, because it's specialized away (5.1.2. Enabled and 
> disabled beans).
>>    *) Bravo? No, because it's specialized away as well, right?
>>    *) Charly? Yes, because that's the only _enabled_ bean!
>> 
>> 
>>  So far, so clear. But now comes the tricky part!
>> 
>>  This test also has an Extension which observes ProcessBeanAttributes and 
> disables Charly.
>>  This means that finally Bravo is enabled, Charly disabled (is there 
> actually a difference btw disabled and vetoed spec wording wise?)
>> 
>>  The problem is now that we only know this AFTER the ProcessBeanAttributes 
> for Charly got fired. And this introduces an ordering issue:
>>  If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly, 
> then we do not know YET that Charly will get disabled. Thus we fire the 
> ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
>> 
>>  Otoh if Charly gets scanned first, then Bravo will not get processed.
>> 
>> 
>>  Can you follow me?
>> 
>> 
>>  LieGrue,
>>  strub
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From jharting at redhat.com  Mon Jan  5 03:28:23 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 05 Jan 2015 09:28:23 +0100
Subject: [cdi-dev] Possible cycle with ProcessBeanAttributes only for
 enabled beans
In-Reply-To: <753697505.4091909.1420321197122.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com>
References: <54A64B7D.5030401@redhat.com>
	<753697505.4091909.1420321197122.JavaMail.yahoo@jws11120.mail.ir2.yahoo.com>
Message-ID: <54AA4B27.3020501@redhat.com>

Let me clarify:

1) Determine what beans are enabled / disabled based on the deployment 
information (ignore ProcessBeanAttributes.veto() for now) - this is the 
same as what is done for ProcessBean in CDI 1.0
2) For each of these enabled beans fire ProcessBeanAttributes
3) If a veto action makes any previously disabled bean enabled, fire 
ProcessBeanAttributes for it once this round of PBA firing finishes
4) Repeat 2-4 until all beans are processed

On 01/03/2015 10:39 PM, Mark Struberg wrote:
> But I CANNOT know if it is enabled before I fire ProcessBeanAttributes! Because this PBA#veto() has a huge impact on which class is enabled or not.
>
>
> And no, in CDI-1.0 there was only ProcessBean which did imo _not_ have a veto() method. This only got added with ProcessBeanAttributes, right?
>
>
> I think in practice this will rarely be an issue, but there are cases where it is not really deterministic but depending on the order in which the classes get processed.
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Friday, 2 January 2015, 8:40, Jozef Hartinger <jharting at redhat.com> wrote:
>>> You cannot just fire ProcessBeanAttributes the moment you run across
>> Bravo. You need to figure out whether it is specialized or not first
>> (which means processing Charlie). This is not new at all - this was the
>> case since CDI 1.0 with ProcessBean.
>>
>> As for the extension case the moment an extension vetoes BeanAttributes,
>> you should check whether that action makes any previously disabled beans
>> enabled. If so, fire ProcessBeanAttributes for them. Repeat untill all
>> beans are processed.
>>
>>
>> On 12/22/2014 06:58 PM, Mark Struberg wrote:
>>>   The JavaDoc of ProcessBeanAttributes defines that ProcessBeanAttributes
>> must only get fired for ENABLED beans:
>>>   "The container fires an event of this type for each enabled bean,
>> interceptor or decorator deployed in a bean archive before registering the Bean
>> object."
>>>
>>>   The test
>>>
>>>
>> org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.SpecializationTest
>>>   has a nice example
>>>
>>>
>>>   @Specializes class Charly extends
>>>      -> @Specializes class Bravo extends
>>>        -> class Alpha
>>>
>>>   Which ProcessBeanAttributes events would you except to get fired?
>>>     *) Alpha? No, because it's specialized away (5.1.2. Enabled and
>> disabled beans).
>>>     *) Bravo? No, because it's specialized away as well, right?
>>>     *) Charly? Yes, because that's the only _enabled_ bean!
>>>
>>>
>>>   So far, so clear. But now comes the tricky part!
>>>
>>>   This test also has an Extension which observes ProcessBeanAttributes and
>> disables Charly.
>>>   This means that finally Bravo is enabled, Charly disabled (is there
>> actually a difference btw disabled and vetoed spec wording wise?)
>>>   The problem is now that we only know this AFTER the ProcessBeanAttributes
>> for Charly got fired. And this introduces an ordering issue:
>>>   If the BeanAttributes for Bravo gets scanned BEFORE the ones of Charly,
>> then we do not know YET that Charly will get disabled. Thus we fire the
>> ProcessBeanAttributes for Bravo as well. But as we know that should not happen!
>>>   Otoh if Charly gets scanned first, then Bravo will not get processed.
>>>
>>>
>>>   Can you follow me?
>>>
>>>
>>>   LieGrue,
>>>   strub
>>>   _______________________________________________
>>>   cdi-dev mailing list
>>>   cdi-dev at lists.jboss.org
>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>


From jharting at redhat.com  Mon Jan  5 03:33:47 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 05 Jan 2015 09:33:47 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <302946057.3754184.1420233053665.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
References: <1090297593.3655627.1420211400276.JavaMail.yahoo@jws11146.mail.ir2.yahoo.com>
	<302946057.3754184.1420233053665.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
Message-ID: <54AA4C6B.2050302@redhat.com>


On 01/02/2015 10:10 PM, Mark Struberg wrote:
> As far as I've understood after reading 7.6 [1] dots are only allowed if either the dot or the whole variable name is quoted
>
> a\.b = 42
>
> or
>
> 'a.b' = 42
>
> but
>
> a.b = 42 is illegal.
>
>
> The spec also only says that the BEAN must have this very name and not that the bean must be accessible by EL.
Given what the name is for in CDI this can be implied.
> If we would really require this and the EL specification doesn't support it, then the CDI spec would contradict the EL spec, right?
No, it would mean that the name should be placed within quotes when 
accessing the conversation bean from EL.
>
>
> LieGrue,
> strub
>
>
>
>
> [1] http://www.ecma-international.org/ecma-262/5.1/#sec-7.6
>
>
>
>> On Friday, 2 January 2015, 16:11, Mark Struberg <struberg at yahoo.de> wrote:
>>> but 'dot notation' in ECMAScript means that the dot is used to access
>> properties of a variable:
>>
>>
>> myvar.x is just another way to access
>>
>> myvar["x"]
>> And of course variables inside a variable [1].
>>
>>
>> Otoh I've found no explicit statement that dots are disallowed neither.
>>
>> LieGrue,
>> strub
>>
>>
>> [1] http://www.ecma-international.org/ecma-262/5.1/#sec-11.2.1
>>
>>
>> On Friday, 2 January 2015, 15:30, John D. Ament <john.d.ament at gmail.com>
>> wrote:
>>
>>
>>>
>>> As far as I know, dots are allowed in ECMAScript, under dot notation.
>>>
>>>
>>> On Fri Jan 02 2015 at 9:17:38 AM Mark Struberg <struberg at yahoo.de>
>> wrote:
>>> Folks, I fear there is another issue:
>>>>
>>>> Are dots in EL names even allowed? I think not.
>>>>
>>>> Please read up EL-3.0
>>>>
>>>> 1.6 Operators [] and .
>>>> The EL follows ECMAScript in unifying the treatment of the . and []
>> operators.
>>>> And in ECMAScript dots are afaik _not_ allowed in names!
>>>>
>>>>
>>>> If it works in some implementations then that is fine, but it is not
>> required by the spec -> non portable. We must not require this in CDI!
>>>> Gonna ping the servlet EG to get this confirmed.
>>>>
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>>   On Friday, 2 January 2015, 12:50, Mark Struberg
>> <struberg at yahoo.de> wrote:
>>>>>   > Forget it, I found it. Maybe I had some typo in my grep...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   LieGrue,
>>>>>   strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>    On Friday, 2 January 2015, 11:59, Mark Struberg
>> <struberg at yahoo.de>
>>>>>   wrote:
>>>>>>    > I've grepped all the cdi spec project and this string
>> doesn't
>>>>>   appear.
>>>>>>    When did this got added?
>>>>>>
>>>>>>    LieGrue,
>>>>>>    strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>     On Friday, 2 January 2015, 8:15, Tomas Remes
>> <tremes at redhat.com>
>>>>>>    wrote:
>>>>>>>     >
>>>>>>>
>>>>>>>     Hi,
>>>>>>>
>>>>>>>     I've checked the related TCK test and it seems to me
>> valid. In CDI
>>>>>   spec
>>>>>>>     there is:
>>>>>>>
>>>>>>>     "6.7.5. The Conversation interface
>>>>>>>     The container provides a built-in bean with bean type
>> Conversation ,
>>>>>   scope
>>>>>>>     @RequestScoped ,
>>>>>>>     and qualifier @Default , named
>> javax.enterprise.context.conversation
>>>>>>    ."
>>>>>>>     Tom
>>>>>>>
>>>>>>>
>>>>>>>     ----- Original Message -----
>>>>>>>     From: "Mark Struberg" <struberg at yahoo.de>
>>>>>>>     To: "Antonio Goncalves"
>> <antonio.goncalves at gmail.com>,
>>>>>>>     "Romain Manni-Bucau"
>> <rmannibucau at gmail.com>
>>>>>>>     Cc: cdi-dev at lists.jboss.org
>>>>>>>     Sent: Tuesday, December 30, 2014 10:57:28 AM
>>>>>>>     Subject: Re: [cdi-dev] where is    defined
>>>>>>>     javax.enterprise.context.conversation.id?
>>>>>>>
>>>>>>>     cid is a different thing. But I did nowhere (spec and
>> api) find the
>>>>>   one
>>>>>>>     mentioned by Romain.
>>>>>>>     So I think it's not specified and we need to exclude
>> this test.
>>>>>>>     LieGrue,
>>>>>>>     strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Monday, 29 December 2014, 21:41, Antonio Goncalves
>>>>>>>     <antonio.goncalves at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>     Nothing in JSF nor in Servlet, but in CDI 1.2
>> Specification :
>>>>>>>>
>>>>>>>>     6.7.4. Conversation context lifecycle
>>>>>>>>     (...)
>>>>>>>>     The long-running conversation associated with a
>>>>>>>>     request may be propagated to any Servlet request via
>> use of a
>>>>>   request
>>>>>>>     parameter named cid
>>>>>>>>     containing the unique identifier of the conversation.
>> In this
>>>>>   case, the
>>>>>>>     application must manage this
>>>>>>>>     request parameter.
>>>>>>>>     (...)
>>>>>>>>
>>>>>>>>     This is accomplished via use of a request parameter
>> named cid
>>>>>>    containing the
>>>>>>>     unique
>>>>>>>>     identifier of the conversation.
>>>>>>>>     (...)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
>>>>>>>     <rmannibucau at gmail.com> wrote:
>>>>>>>>     Hi guys
>>>>>>>>>     didnt find in CDI and JSF PDFs where is defined
>>>>>>>>>    
>> "javax.enterprise.context.conversation.id". Seems it
>>>>>>    should be
>>>>>>>>>     available in ELs.
>>>>>>>>>
>>>>>>>>>     Do you have any pointer please?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>     @rmannibucau
>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>     _______________________________________________
>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>     Note that for all code provided on this list, the
>> provider
>>>>>   licenses
>>>>>>    the
>>>>>>>     code under the Apache License, Version 2
>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>    provided
>>>>>>>     on this list, the provider waives all patent and other
>> intellectual
>>>>>>    property
>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>>
>>>>>>>>     --
>>>>>>>>
>>>>>>>>     Antonio Goncalves
>>>>>>>>     Software architect, Java Champion and Pluralsight
>> author
>>>>>>>>     Web site | Twitter | LinkedIn | Pluralsight | Paris
>> JUG | Devoxx
>>>>>   France
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the
>> provider
>>>>>   licenses the
>>>>>>    code
>>>>>>>     under the Apache License, Version 2
>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>    provided
>>>>>>>     on this list, the provider waives all patent and other
>> intellectual
>>>>>>    property
>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cdi-dev mailing list
>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>     Note that for all code provided on this list, the
>> provider licenses
>>>>>   the
>>>>>>    code
>>>>>>>     under the Apache License, Version 2
>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>    provided
>>>>>>>     on this list, the provider waives all patent and other
>> intellectual
>>>>>>    property
>>>>>>>     rights inherent in such information.
>>>>>>>
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>> the code
>>>>>   under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>> ideas provided
>>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>>   rights inherent in such information.
>>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From rmannibucau at gmail.com  Mon Jan  5 03:36:17 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Mon, 5 Jan 2015 09:36:17 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <54AA4C6B.2050302@redhat.com>
References: <1090297593.3655627.1420211400276.JavaMail.yahoo@jws11146.mail.ir2.yahoo.com>
	<302946057.3754184.1420233053665.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
	<54AA4C6B.2050302@redhat.com>
Message-ID: <CACLE=7P3dCiOe+2eVXYVLDWt8DGZLKBp_NoaE-Vg7LzL0zNs9g@mail.gmail.com>

@Jozef: "implied" = determine by segment (segment = a string between 2
dots)? If yes it is broken since it would set as resolved property
which are not resolved - this is a hack only - or worse this can lead
to conflicts with other namespaces.

I agree that escaped the dot in the EL should be working (ugly but compliant)


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-05 9:33 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
> On 01/02/2015 10:10 PM, Mark Struberg wrote:
>> As far as I've understood after reading 7.6 [1] dots are only allowed if either the dot or the whole variable name is quoted
>>
>> a\.b = 42
>>
>> or
>>
>> 'a.b' = 42
>>
>> but
>>
>> a.b = 42 is illegal.
>>
>>
>> The spec also only says that the BEAN must have this very name and not that the bean must be accessible by EL.
> Given what the name is for in CDI this can be implied.
>> If we would really require this and the EL specification doesn't support it, then the CDI spec would contradict the EL spec, right?
> No, it would mean that the name should be placed within quotes when
> accessing the conversation bean from EL.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> [1] http://www.ecma-international.org/ecma-262/5.1/#sec-7.6
>>
>>
>>
>>> On Friday, 2 January 2015, 16:11, Mark Struberg <struberg at yahoo.de> wrote:
>>>> but 'dot notation' in ECMAScript means that the dot is used to access
>>> properties of a variable:
>>>
>>>
>>> myvar.x is just another way to access
>>>
>>> myvar["x"]
>>> And of course variables inside a variable [1].
>>>
>>>
>>> Otoh I've found no explicit statement that dots are disallowed neither.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> [1] http://www.ecma-international.org/ecma-262/5.1/#sec-11.2.1
>>>
>>>
>>> On Friday, 2 January 2015, 15:30, John D. Ament <john.d.ament at gmail.com>
>>> wrote:
>>>
>>>
>>>>
>>>> As far as I know, dots are allowed in ECMAScript, under dot notation.
>>>>
>>>>
>>>> On Fri Jan 02 2015 at 9:17:38 AM Mark Struberg <struberg at yahoo.de>
>>> wrote:
>>>> Folks, I fear there is another issue:
>>>>>
>>>>> Are dots in EL names even allowed? I think not.
>>>>>
>>>>> Please read up EL-3.0
>>>>>
>>>>> 1.6 Operators [] and .
>>>>> The EL follows ECMAScript in unifying the treatment of the . and []
>>> operators.
>>>>> And in ECMAScript dots are afaik _not_ allowed in names!
>>>>>
>>>>>
>>>>> If it works in some implementations then that is fine, but it is not
>>> required by the spec -> non portable. We must not require this in CDI!
>>>>> Gonna ping the servlet EG to get this confirmed.
>>>>>
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>>   On Friday, 2 January 2015, 12:50, Mark Struberg
>>> <struberg at yahoo.de> wrote:
>>>>>>   > Forget it, I found it. Maybe I had some typo in my grep...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   LieGrue,
>>>>>>   strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>    On Friday, 2 January 2015, 11:59, Mark Struberg
>>> <struberg at yahoo.de>
>>>>>>   wrote:
>>>>>>>    > I've grepped all the cdi spec project and this string
>>> doesn't
>>>>>>   appear.
>>>>>>>    When did this got added?
>>>>>>>
>>>>>>>    LieGrue,
>>>>>>>    strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     On Friday, 2 January 2015, 8:15, Tomas Remes
>>> <tremes at redhat.com>
>>>>>>>    wrote:
>>>>>>>>     >
>>>>>>>>
>>>>>>>>     Hi,
>>>>>>>>
>>>>>>>>     I've checked the related TCK test and it seems to me
>>> valid. In CDI
>>>>>>   spec
>>>>>>>>     there is:
>>>>>>>>
>>>>>>>>     "6.7.5. The Conversation interface
>>>>>>>>     The container provides a built-in bean with bean type
>>> Conversation ,
>>>>>>   scope
>>>>>>>>     @RequestScoped ,
>>>>>>>>     and qualifier @Default , named
>>> javax.enterprise.context.conversation
>>>>>>>    ."
>>>>>>>>     Tom
>>>>>>>>
>>>>>>>>
>>>>>>>>     ----- Original Message -----
>>>>>>>>     From: "Mark Struberg" <struberg at yahoo.de>
>>>>>>>>     To: "Antonio Goncalves"
>>> <antonio.goncalves at gmail.com>,
>>>>>>>>     "Romain Manni-Bucau"
>>> <rmannibucau at gmail.com>
>>>>>>>>     Cc: cdi-dev at lists.jboss.org
>>>>>>>>     Sent: Tuesday, December 30, 2014 10:57:28 AM
>>>>>>>>     Subject: Re: [cdi-dev] where is    defined
>>>>>>>>     javax.enterprise.context.conversation.id?
>>>>>>>>
>>>>>>>>     cid is a different thing. But I did nowhere (spec and
>>> api) find the
>>>>>>   one
>>>>>>>>     mentioned by Romain.
>>>>>>>>     So I think it's not specified and we need to exclude
>>> this test.
>>>>>>>>     LieGrue,
>>>>>>>>     strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     On Monday, 29 December 2014, 21:41, Antonio Goncalves
>>>>>>>>     <antonio.goncalves at gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Nothing in JSF nor in Servlet, but in CDI 1.2
>>> Specification :
>>>>>>>>>
>>>>>>>>>     6.7.4. Conversation context lifecycle
>>>>>>>>>     (...)
>>>>>>>>>     The long-running conversation associated with a
>>>>>>>>>     request may be propagated to any Servlet request via
>>> use of a
>>>>>>   request
>>>>>>>>     parameter named cid
>>>>>>>>>     containing the unique identifier of the conversation.
>>> In this
>>>>>>   case, the
>>>>>>>>     application must manage this
>>>>>>>>>     request parameter.
>>>>>>>>>     (...)
>>>>>>>>>
>>>>>>>>>     This is accomplished via use of a request parameter
>>> named cid
>>>>>>>    containing the
>>>>>>>>     unique
>>>>>>>>>     identifier of the conversation.
>>>>>>>>>     (...)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     On Mon, Dec 29, 2014 at 7:54 PM, Romain Manni-Bucau
>>>>>>>>     <rmannibucau at gmail.com> wrote:
>>>>>>>>>     Hi guys
>>>>>>>>>>     didnt find in CDI and JSF PDFs where is defined
>>>>>>>>>>
>>> "javax.enterprise.context.conversation.id". Seems it
>>>>>>>    should be
>>>>>>>>>>     available in ELs.
>>>>>>>>>>
>>>>>>>>>>     Do you have any pointer please?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>     @rmannibucau
>>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>>     _______________________________________________
>>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>     Note that for all code provided on this list, the
>>> provider
>>>>>>   licenses
>>>>>>>    the
>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>> all other ideas
>>>>>>>    provided
>>>>>>>>     on this list, the provider waives all patent and other
>>> intellectual
>>>>>>>    property
>>>>>>>>     rights inherent in such information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     --
>>>>>>>>>
>>>>>>>>>     Antonio Goncalves
>>>>>>>>>     Software architect, Java Champion and Pluralsight
>>> author
>>>>>>>>>     Web site | Twitter | LinkedIn | Pluralsight | Paris
>>> JUG | Devoxx
>>>>>>   France
>>>>>>>>>     _______________________________________________
>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>     Note that for all code provided on this list, the
>>> provider
>>>>>>   licenses the
>>>>>>>    code
>>>>>>>>     under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>> all other ideas
>>>>>>>    provided
>>>>>>>>     on this list, the provider waives all patent and other
>>> intellectual
>>>>>>>    property
>>>>>>>>     rights inherent in such information.
>>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the
>>> provider licenses
>>>>>>   the
>>>>>>>    code
>>>>>>>>     under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>> all other ideas
>>>>>>>    provided
>>>>>>>>     on this list, the provider waives all patent and other
>>> intellectual
>>>>>>>    property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>   _______________________________________________
>>>>>>   cdi-dev mailing list
>>>>>>   cdi-dev at lists.jboss.org
>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>   Note that for all code provided on this list, the provider licenses
>>> the code
>>>>>>   under the Apache License, Version 2
>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>> ideas provided
>>>>>>   on this list, the provider waives all patent and other intellectual
>>> property
>>>>>>   rights inherent in such information.
>>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>>> on this list, the provider waives all patent and other intellectual property
>>> rights inherent in such information.
>>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>>> on this list, the provider waives all patent and other intellectual property
>>> rights inherent in such information.
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From issues at jboss.org  Mon Jan  5 03:44:29 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Jan 2015 03:44:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.18047.1420447469671@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029758#comment-13029758 ] 

Martin Kouba commented on CDI-496:
----------------------------------

I think we cannot simply leave out the word *managed* in the following sentences:
{quote}
Interceptor bindings may be used to associate interceptors with any _managed_ bean that is not a decorator.
If a _managed_ bean has a class-level or method-level interceptor binding, the _managed_ bean must be a proxyable bean type, as defined in Unproxyable bean types.
{quote}
Because the part *the managed bean must be a proxyable bean type* is not accurate.

Also note that the Interceptors spec, Chapter 3, "Associating Interceptors using Interceptor Bindings" is clear that bindings may be used to associate interceptors with any
*component* that is not itself an interceptor (incl. session beans).

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 03:47:30 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 5 Jan 2015 03:47:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.18055.1420447650037@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029760#comment-13029760 ] 

Romain Manni-Bucau commented on CDI-496:
----------------------------------------

Isnt the issue just the fact "contract" of Beans is not exlpicit? contract of an EJB is its API (Local, Local Bean or Remote), for a ManagedBean it is its explicit or implicit @Typed, etc...In summary it is bean.getTypes() no?

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 03:57:30 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Jan 2015 03:57:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.18070.1420448250520@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029764#comment-13029764 ] 

Martin Kouba commented on CDI-496:
----------------------------------

[~rmannibucau] I believe the contract of a CDI bean of any kind (managed, session bean, producer method, etc.) is explicitly defined (2. Concepts):
{quote}
A bean comprises the following attributes:
* A (nonempty) set of bean types
* A (nonempty) set of qualifiers
* A scope
* Optionally, a bean name
* A set of interceptor bindings
* A bean implementation
{quote}

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 03:58:30 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 5 Jan 2015 03:58:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.18087.1420448310870@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029765#comment-13029765 ] 

Romain Manni-Bucau commented on CDI-496:
----------------------------------------

@Martin: sorry was not clear, was speaking about "interception contract"

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From tremes at redhat.com  Mon Jan  5 04:00:32 2015
From: tremes at redhat.com (Tomas Remes)
Date: Mon, 5 Jan 2015 04:00:32 -0500 (EST)
Subject: [cdi-dev] session destroyed event
In-Reply-To: <CACLE=7M5xmWSvsMfjbah=8Jv1teVprwQ4UdnRD682GHbnoNCDQ@mail.gmail.com>
References: <CACLE=7PEORMaKsUZsBZDJ63JexuBevMLhO9d=cTFNMMH=ZWQgg@mail.gmail.com>
	<477289819.3566690.1419847351578.JavaMail.zimbra@redhat.com>
	<CACLE=7Pvaz_uhxZo8fGCBhM=jS2Bu97dmLQpWxsVB-d61JWVOg@mail.gmail.com>
	<1049969966.4518447.1420185297184.JavaMail.zimbra@redhat.com>
	<CACLE=7M5xmWSvsMfjbah=8Jv1teVprwQ4UdnRD682GHbnoNCDQ@mail.gmail.com>
Message-ID: <254770947.5031622.1420448432892.JavaMail.zimbra@redhat.com>


I would say it really depends on the given case. If you want to do the stuff (you described) in one request, then you'll really have some potential troubles. You can file an CDI spec issue to start broader discussion. 

Thank's 
Tom

----- Original Message -----
From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
To: "Tomas Remes" <tremes at redhat.com>
Cc: cdi-tck at lists.jboss.org, cdi-dev at lists.jboss.org
Sent: Friday, January 2, 2015 9:46:05 AM
Subject: Re: [cdi-dev] session destroyed event

If the spec mandates the session scope to be >= request scope then if
you logout during a request you would keep incorrect session.

If you do:

request {
  filter {
     playWithSession();
     logout();
  }
  auditSession();
}

Then your audit will still be bound to the user before the logout but
actually it is no more accurate. Can be ok in some cases but can be an
issue in some others. Also in this case destroy event will have a
session which can have been garbaged/destoyed by the container and
potentially (if pooled) reaffected to another request.

If you take the login case it is the opposite and here if you use
sessionId in your logic you can have troubles as well since it is very
recommanded (sometimes forced by the container) to change the
sessionId when a user is logged.




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-02 8:54 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
>
> Ok so let's move back to cdi-dev list too.:) Can you please elaborate bit more why do you think it's not consistent?
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> To: "Tomas Remes" <tremes at redhat.com>
> Cc: cdi-tck at lists.jboss.org
> Sent: Monday, December 29, 2014 11:08:49 AM
> Subject: Re: [cdi-dev] session destroyed event
>
> Hi
>
> sorry to have used the wrong list.
>
> Issue is then scope is not consistent (think to login/logout mecanism
> for instance).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-29 11:02 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>
>> Hi,
>>
>> I think the destroy event is triggered at the end of the request and not immediately if I understand correctly. The spec states:
>>
>> "The session context is destroyed when the HTTPSession times out, after all
>> HttpSessionListener s have been called, and at the very end of any request in which
>> invalidate() was called, after all filters and ServletRequestListener s have been called."
>>
>> Please let's move TCK related topics to cdi-tck mailing list.
>>
>> Thank's
>> Tom
>>
>> ----- Original Message -----
>> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
>> To: cdi-dev at lists.jboss.org
>> Sent: Tuesday, December 23, 2014 8:58:16 PM
>> Subject: [cdi-dev] session destroyed event
>>
>> Hi
>>
>> why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures
>>
>> destroyed == observer.getDestroyedSessionCount().get()
>>
>> For me invalidate call should trigger the destroy event: you can
>> create N session in a single requests
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
>
> --
> Tomas Remes
>
>

-- 
Tomas Remes



From rmannibucau at gmail.com  Mon Jan  5 04:08:00 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Mon, 5 Jan 2015 10:08:00 +0100
Subject: [cdi-dev] session destroyed event
In-Reply-To: <254770947.5031622.1420448432892.JavaMail.zimbra@redhat.com>
References: <CACLE=7PEORMaKsUZsBZDJ63JexuBevMLhO9d=cTFNMMH=ZWQgg@mail.gmail.com>
	<477289819.3566690.1419847351578.JavaMail.zimbra@redhat.com>
	<CACLE=7Pvaz_uhxZo8fGCBhM=jS2Bu97dmLQpWxsVB-d61JWVOg@mail.gmail.com>
	<1049969966.4518447.1420185297184.JavaMail.zimbra@redhat.com>
	<CACLE=7M5xmWSvsMfjbah=8Jv1teVprwQ4UdnRD682GHbnoNCDQ@mail.gmail.com>
	<254770947.5031622.1420448432892.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7Ndjf8jhpm_s=RfBPmHRBPqj4dAWqb2hz_MVJ0XMTMadg@mail.gmail.com>

https://issues.jboss.org/browse/CDI-497


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-05 10:00 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
> I would say it really depends on the given case. If you want to do the stuff (you described) in one request, then you'll really have some potential troubles. You can file an CDI spec issue to start broader discussion.
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> To: "Tomas Remes" <tremes at redhat.com>
> Cc: cdi-tck at lists.jboss.org, cdi-dev at lists.jboss.org
> Sent: Friday, January 2, 2015 9:46:05 AM
> Subject: Re: [cdi-dev] session destroyed event
>
> If the spec mandates the session scope to be >= request scope then if
> you logout during a request you would keep incorrect session.
>
> If you do:
>
> request {
>   filter {
>      playWithSession();
>      logout();
>   }
>   auditSession();
> }
>
> Then your audit will still be bound to the user before the logout but
> actually it is no more accurate. Can be ok in some cases but can be an
> issue in some others. Also in this case destroy event will have a
> session which can have been garbaged/destoyed by the container and
> potentially (if pooled) reaffected to another request.
>
> If you take the login case it is the opposite and here if you use
> sessionId in your logic you can have troubles as well since it is very
> recommanded (sometimes forced by the container) to change the
> sessionId when a user is logged.
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-02 8:54 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>
>>
>> Ok so let's move back to cdi-dev list too.:) Can you please elaborate bit more why do you think it's not consistent?
>>
>> Thank's
>> Tom
>>
>> ----- Original Message -----
>> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
>> To: "Tomas Remes" <tremes at redhat.com>
>> Cc: cdi-tck at lists.jboss.org
>> Sent: Monday, December 29, 2014 11:08:49 AM
>> Subject: Re: [cdi-dev] session destroyed event
>>
>> Hi
>>
>> sorry to have used the wrong list.
>>
>> Issue is then scope is not consistent (think to login/logout mecanism
>> for instance).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-29 11:02 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>>
>>> Hi,
>>>
>>> I think the destroy event is triggered at the end of the request and not immediately if I understand correctly. The spec states:
>>>
>>> "The session context is destroyed when the HTTPSession times out, after all
>>> HttpSessionListener s have been called, and at the very end of any request in which
>>> invalidate() was called, after all filters and ServletRequestListener s have been called."
>>>
>>> Please let's move TCK related topics to cdi-tck mailing list.
>>>
>>> Thank's
>>> Tom
>>>
>>> ----- Original Message -----
>>> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
>>> To: cdi-dev at lists.jboss.org
>>> Sent: Tuesday, December 23, 2014 8:58:16 PM
>>> Subject: [cdi-dev] session destroyed event
>>>
>>> Hi
>>>
>>> why org.jboss.cdi.tck.tests.context.session.event.Servlet#doGet ensures
>>>
>>> destroyed == observer.getDestroyedSessionCount().get()
>>>
>>> For me invalidate call should trigger the destroy event: you can
>>> create N session in a single requests
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>>
>>
>> --
>> Tomas Remes
>>
>>
>
> --
> Tomas Remes
>
>


From issues at jboss.org  Mon Jan  5 04:08:29 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 5 Jan 2015 04:08:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865734@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.18112.1420448909737@Atlassian.JIRA>

Romain Manni-Bucau created CDI-497:
--------------------------------------

             Summary: session scope doesn't follow session lifecycle
                 Key: CDI-497
                 URL: https://issues.jboss.org/browse/CDI-497
             Project: CDI Specification Issues
          Issue Type: Epic
            Reporter: Romain Manni-Bucau


ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).

Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From struberg at yahoo.de  Mon Jan  5 04:09:16 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 5 Jan 2015 09:09:16 +0000 (UTC)
Subject: [cdi-dev] where is defined
 javax.enterprise.context.conversation.id?
In-Reply-To: <54AA4C6B.2050302@redhat.com>
References: <54AA4C6B.2050302@redhat.com>
Message-ID: <1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>

>> The spec also only says that the BEAN must have this very name and not that
>> the bean must be accessible by EL.

> Given what the name is for in CDI this can be implied.


well, but it's not up to the CDI impl to do this correctly. 


>> If we would really require this and the EL specification doesn't
>> support it, then the CDI spec would contradict the EL spec, right?

> No, it would mean that the name should be placed within quotes when
> accessing the conversation bean from EL.


The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.


Why didn't we simply use underscores instead of dots? :)


LieGrue,
strub

From issues at jboss.org  Mon Jan  5 05:00:30 2015
From: issues at jboss.org (Sven Linstaedt (JIRA))
Date: Mon, 5 Jan 2015 05:00:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of generic events
 from BeanManager
In-Reply-To: <JIRA.12558063.1416843782000@Atlassian.JIRA>
References: <JIRA.12558063.1416843782000@Atlassian.JIRA>
	<JIRA.12558063.1416843782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558063.1416843782000.18208.1420452030127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Linstaedt updated CDI-493:
-------------------------------
    Component/s: Events


> Allow firing of generic events from BeanManager
> -----------------------------------------------
>
>                 Key: CDI-493
>                 URL: https://issues.jboss.org/browse/CDI-493
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable. 
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. 
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like 
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
>     if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
>         // register interceptor type
>     } else {
>         // register intercepted type
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 05:00:30 2015
From: issues at jboss.org (Sven Linstaedt (JIRA))
Date: Mon, 5 Jan 2015 05:00:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of generic events
 from BeanManager
In-Reply-To: <JIRA.12558063.1416843782000@Atlassian.JIRA>
References: <JIRA.12558063.1416843782000@Atlassian.JIRA>
	<JIRA.12558063.1416843782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558063.1416843782000.18209.1420452030168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Linstaedt updated CDI-493:
-------------------------------
    Affects Version/s: 1.2.Final


> Allow firing of generic events from BeanManager
> -----------------------------------------------
>
>                 Key: CDI-493
>                 URL: https://issues.jboss.org/browse/CDI-493
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable. 
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. 
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like 
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
>     if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
>         // register interceptor type
>     } else {
>         // register intercepted type
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 05:10:30 2015
From: issues at jboss.org (Sven Linstaedt (JIRA))
Date: Mon, 5 Jan 2015 05:10:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of parameterized
 event types from BeanManager
In-Reply-To: <JIRA.12558063.1416843782000@Atlassian.JIRA>
References: <JIRA.12558063.1416843782000@Atlassian.JIRA>
	<JIRA.12558063.1416843782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558063.1416843782000.18216.1420452630267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sven Linstaedt updated CDI-493:
-------------------------------
    Summary: Allow firing of parameterized event types from BeanManager  (was: Allow firing of generic events from BeanManager)


> Allow firing of parameterized event types from BeanManager
> ----------------------------------------------------------
>
>                 Key: CDI-493
>                 URL: https://issues.jboss.org/browse/CDI-493
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Sven Linstaedt
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable. 
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. 
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like 
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
>     if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
>         // register interceptor type
>     } else {
>         // register intercepted type
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 08:36:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 08:36:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-110) Provide support for binding an
 invocation handler to an interface or abstract class
In-Reply-To: <JIRA.12433465.1300770175000@Atlassian.JIRA>
References: <JIRA.12433465.1300770175000@Atlassian.JIRA>
	<JIRA.12433465.1300770175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433465.1300770175000.18942.1420464990449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-110:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Provide support for binding an invocation handler to an interface or abstract class
> -----------------------------------------------------------------------------------
>
>                 Key: CDI-110
>                 URL: https://issues.jboss.org/browse/CDI-110
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Inheritance and Specialization
>    Affects Versions: 1.0
>            Reporter: George Gastaldi
>              Labels: cdi
>             Fix For: 2.0 (discussion)
>
>
> The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding.
> Binding type:
> {code:java}
> @Target({ METHOD, TYPE })
> @Retention(RetentionPolicy.RUNTIME)
> @ServiceHandlerBindingType
> public @interface EchoService {}
> {code}
> Invocation handler:
> {code:java}
> @ServiceHandler
> @EchoService
> public class EchoServiceHandler {
>     @AroundInvoke
>     public Object invoke(InvocationContext ctx) {
>         return ctx.getMethod().getName().toString();
>     }
> }
> {code}
> Usage:
> {code:java}
> @EchoService
> public interface HelloWorld {
>    String helloWorld();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 08:37:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 08:37:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-110) Provide support for binding an
 invocation handler to an interface or abstract class
In-Reply-To: <JIRA.12433465.1300770175000@Atlassian.JIRA>
References: <JIRA.12433465.1300770175000@Atlassian.JIRA>
	<JIRA.12433465.1300770175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433465.1300770175000.18951.1420465050393@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029871#comment-13029871 ] 

Antoine Sabot-Durand commented on CDI-110:
------------------------------------------

Looks similar to Deltaspike Partial Bean

> Provide support for binding an invocation handler to an interface or abstract class
> -----------------------------------------------------------------------------------
>
>                 Key: CDI-110
>                 URL: https://issues.jboss.org/browse/CDI-110
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Inheritance and Specialization
>    Affects Versions: 1.0
>            Reporter: George Gastaldi
>              Labels: cdi
>             Fix For: 2.0 (discussion)
>
>
> The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding.
> Binding type:
> {code:java}
> @Target({ METHOD, TYPE })
> @Retention(RetentionPolicy.RUNTIME)
> @ServiceHandlerBindingType
> public @interface EchoService {}
> {code}
> Invocation handler:
> {code:java}
> @ServiceHandler
> @EchoService
> public class EchoServiceHandler {
>     @AroundInvoke
>     public Object invoke(InvocationContext ctx) {
>         return ctx.getMethod().getName().toString();
>     }
> }
> {code}
> Usage:
> {code:java}
> @EchoService
> public interface HelloWorld {
>    String helloWorld();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 08:42:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 08:42:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-128) Ability to access CDI enhanced
 metadata from the InvocationContext.getMethod()
In-Reply-To: <JIRA.12437277.1305149299000@Atlassian.JIRA>
References: <JIRA.12437277.1305149299000@Atlassian.JIRA>
	<JIRA.12437277.1305149299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437277.1305149299000.18961.1420465349847@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-128:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Ability to access CDI enhanced metadata from the InvocationContext.getMethod()
> ------------------------------------------------------------------------------
>
>                 Key: CDI-128
>                 URL: https://issues.jboss.org/browse/CDI-128
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Interceptors
>    Affects Versions: 1.0
>            Reporter: Richard Hightower
>             Fix For: 2.0 (discussion)
>
>
> The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). 
> For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). 
> I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 08:42:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 08:42:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-128) Ability to access CDI enhanced
 metadata from the InvocationContext.getMethod()
In-Reply-To: <JIRA.12437277.1305149299000@Atlassian.JIRA>
References: <JIRA.12437277.1305149299000@Atlassian.JIRA>
	<JIRA.12437277.1305149299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437277.1305149299000.18964.1420465350013@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029873#comment-13029873 ] 

Antoine Sabot-Durand commented on CDI-128:
------------------------------------------

Could also be useful for metadata added from an extension.

> Ability to access CDI enhanced metadata from the InvocationContext.getMethod()
> ------------------------------------------------------------------------------
>
>                 Key: CDI-128
>                 URL: https://issues.jboss.org/browse/CDI-128
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Interceptors
>    Affects Versions: 1.0
>            Reporter: Richard Hightower
>             Fix For: 2.0 (discussion)
>
>
> The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). 
> For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). 
> I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 08:57:31 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 08:57:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-137) Changing ProcessManagedBean
 getBean Method Signature
In-Reply-To: <JIRA.12440385.1308808834000@Atlassian.JIRA>
References: <JIRA.12440385.1308808834000@Atlassian.JIRA>
	<JIRA.12440385.1308808834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12440385.1308808834000.18994.1420466251036@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-137:
-------------------------------------
    Description: 
Currently ProcessSessionBean class signature is
public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}

Therefore, observers work as

Example: 
{code:java}
@Stateless
public class Elephant{}

public void observe(ProcessBean<Elephant>)  // --> Not allowed
public void observe(ProcessSessionBean<Elephant>) // --> Allowed
{code}

Pete said that main reason of using ProcessManagedBean<Object> is that
{quote}
{{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is.
{quote}

Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.

Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class.

Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean.

And change the {{ProcessSessionBean}} signature as

{code:java}
public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}
{code}

Also See https://issues.jboss.org/browse/CDITCK-215

  was:
Currently ProcessSessionBean class signature is
public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}

Therefore, observers work as

Example: 
@Stateless
public class Elephant{}

public void observe(ProcessBean<Elephant>) --> Not allowed
public void observe(ProcessSessionBean<Elephant>) --> Allowed

Pete said that main reason of using ProcessManagedBean<Object> is that 
"ProcessBean<X> offers a method getBean() which returns Bean<X>. Bean<X> has a method of type create() which returns an X. If we were to have ProcessSessionBean<X> extend ProcessManagedBean<X> then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is."

Main reason of using the ProcessSessionBean event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.

Moreover, other methods in the interface hierarchy of "ProcessSessionBean" gets <X> into the account, for example

AnnotatedType<X> getAnnotatedBeanClass()
          Returns the AnnotatedType representing the bean class.

Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  decleration as

public <T> Bean<T> getBean(); where T is the local/local view interface of the session bean.

And change the ProcessSessionBean signature as

public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}


Also See https://issues.jboss.org/browse/CDITCK-215



> Changing ProcessManagedBean getBean Method Signature
> ----------------------------------------------------
>
>                 Key: CDI-137
>                 URL: https://issues.jboss.org/browse/CDI-137
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Portable Extensions
>    Affects Versions: 1.0
>            Reporter: Gurkan Erdogdu
>             Fix For: TBD
>
>
> Currently ProcessSessionBean class signature is
> public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}
> Therefore, observers work as
> Example: 
> {code:java}
> @Stateless
> public class Elephant{}
> public void observe(ProcessBean<Elephant>)  // --> Not allowed
> public void observe(ProcessSessionBean<Elephant>) // --> Allowed
> {code}
> Pete said that main reason of using ProcessManagedBean<Object> is that
> {quote}
> {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is.
> {quote}
> Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.
> Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class.
> Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean.
> And change the {{ProcessSessionBean}} signature as
> {code:java}
> public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}
> {code}
> Also See https://issues.jboss.org/browse/CDITCK-215



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:00:32 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:00:32 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-137) Changing ProcessManagedBean
 getBean Method Signature
In-Reply-To: <JIRA.12440385.1308808834000@Atlassian.JIRA>
References: <JIRA.12440385.1308808834000@Atlassian.JIRA>
	<JIRA.12440385.1308808834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12440385.1308808834000.19016.1420466432804@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-137:
-------------------------------------
    Description: 
Currently ProcessSessionBean class signature is
{code:java}
public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}
{code}
Therefore, observers work as

Example: 
{code:java}
@Stateless
public class Elephant{}

public void observe(@Observes ProcessBean<Elephant>)  // --> Not allowed
public void observe(@Observes ProcessSessionBean<Elephant>) // --> Allowed
{code}

Pete said that main reason of using ProcessManagedBean<Object> is that
{quote}
{{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is.
{quote}

Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.

Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class.

Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean.

And change the {{ProcessSessionBean}} signature as

{code:java}
public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}
{code}

Also See https://issues.jboss.org/browse/CDITCK-215

  was:
Currently ProcessSessionBean class signature is
public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}

Therefore, observers work as

Example: 
{code:java}
@Stateless
public class Elephant{}

public void observe(ProcessBean<Elephant>)  // --> Not allowed
public void observe(ProcessSessionBean<Elephant>) // --> Allowed
{code}

Pete said that main reason of using ProcessManagedBean<Object> is that
{quote}
{{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is.
{quote}

Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.

Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class.

Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean.

And change the {{ProcessSessionBean}} signature as

{code:java}
public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}
{code}

Also See https://issues.jboss.org/browse/CDITCK-215



> Changing ProcessManagedBean getBean Method Signature
> ----------------------------------------------------
>
>                 Key: CDI-137
>                 URL: https://issues.jboss.org/browse/CDI-137
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Portable Extensions
>    Affects Versions: 1.0
>            Reporter: Gurkan Erdogdu
>             Fix For: TBD
>
>
> Currently ProcessSessionBean class signature is
> {code:java}
> public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{}
> {code}
> Therefore, observers work as
> Example: 
> {code:java}
> @Stateless
> public class Elephant{}
> public void observe(@Observes ProcessBean<Elephant>)  // --> Not allowed
> public void observe(@Observes ProcessSessionBean<Elephant>) // --> Allowed
> {code}
> Pete said that main reason of using ProcessManagedBean<Object> is that
> {quote}
> {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is.
> {quote}
> Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s.
> Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class.
> Therefore, it is more convenient to change "ProcessManagedBean getBean"  method  declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean.
> And change the {{ProcessSessionBean}} signature as
> {code:java}
> public class ProcessSessionBean<X> extends ProcessManagedBean<X>{}
> {code}
> Also See https://issues.jboss.org/browse/CDITCK-215



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:07:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:07:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-160) Split specification into "core"
 and "Java EE integration"
In-Reply-To: <JIRA.12447250.1316346512000@Atlassian.JIRA>
References: <JIRA.12447250.1316346512000@Atlassian.JIRA>
	<JIRA.12447250.1316346512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447250.1316346512000.19038.1420466850792@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reassigned CDI-160:
----------------------------------------

    Assignee: Antoine Sabot-Durand  (was: Pete Muir)


> Split specification into "core" and "Java EE integration"
> ---------------------------------------------------------
>
>                 Key: CDI-160
>                 URL: https://issues.jboss.org/browse/CDI-160
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Antoine Sabot-Durand
>            Priority: Critical
>             Fix For: 2.0 (proposed)
>
>
> In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:07:31 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:07:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-160) Split specification into "core"
 and "Java EE integration"
In-Reply-To: <JIRA.12447250.1316346512000@Atlassian.JIRA>
References: <JIRA.12447250.1316346512000@Atlassian.JIRA>
	<JIRA.12447250.1316346512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447250.1316346512000.19044.1420466851130@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-160:
-------------------------------------
    Fix Version/s: 2.0 (proposed)
                       (was: TBD)


> Split specification into "core" and "Java EE integration"
> ---------------------------------------------------------
>
>                 Key: CDI-160
>                 URL: https://issues.jboss.org/browse/CDI-160
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Antoine Sabot-Durand
>            Priority: Critical
>             Fix For: 2.0 (proposed)
>
>
> In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:16:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:16:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-157) Enabling/Disabling Extensions
In-Reply-To: <JIRA.12446748.1315843013000@Atlassian.JIRA>
References: <JIRA.12446748.1315843013000@Atlassian.JIRA>
	<JIRA.12446748.1315843013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446748.1315843013000.19087.1420467390740@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-157:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Enabling/Disabling Extensions
> -----------------------------
>
>                 Key: CDI-157
>                 URL: https://issues.jboss.org/browse/CDI-157
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion)
>
>
> Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:18:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:18:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-161) Java DSL to define beans to create
 and deploy
In-Reply-To: <JIRA.12447251.1316346729000@Atlassian.JIRA>
References: <JIRA.12447251.1316346729000@Atlassian.JIRA>
	<JIRA.12447251.1316346729000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447251.1316346729000.19093.1420467510032@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-161:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Java DSL to define beans to create and deploy
> ---------------------------------------------
>
>                 Key: CDI-161
>                 URL: https://issues.jboss.org/browse/CDI-161
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion)
>
>
> This would be especially useful in Java SE mode



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 09:19:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 09:19:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-174) Define contexts and context
 lifecycle for Java SE
In-Reply-To: <JIRA.12449484.1318609757000@Atlassian.JIRA>
References: <JIRA.12449484.1318609757000@Atlassian.JIRA>
	<JIRA.12449484.1318609757000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449484.1318609757000.19095.1420467569846@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-174:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Define contexts and context lifecycle for Java SE
> -------------------------------------------------
>
>                 Key: CDI-174
>                 URL: https://issues.jboss.org/browse/CDI-174
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion)
>
>




--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 10:02:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 10:02:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@Atlassian.JIRA>
References: <JIRA.12462205.1332363812000@Atlassian.JIRA>
	<JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.19237.1420470149623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-220:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
>                 Key: CDI-220
>                 URL: https://issues.jboss.org/browse/CDI-220
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.0, 1.1.EDR
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 2.0 (discussion)
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From jharting at redhat.com  Mon Jan  5 10:19:16 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 05 Jan 2015 16:19:16 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
References: <54AA4C6B.2050302@redhat.com>
	<1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
Message-ID: <54AAAB74.5010508@redhat.com>


On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>> The spec also only says that the BEAN must have this very name and not that
>>> the bean must be accessible by EL.
>> Given what the name is for in CDI this can be implied.
>
> well, but it's not up to the CDI impl to do this correctly.
No, my point was that if a bean is given a name it implies that this 
bean should be accessible via EL.
>
>
>>> If we would really require this and the EL specification doesn't
>>> support it, then the CDI spec would contradict the EL spec, right?
>> No, it would mean that the name should be placed within quotes when
>> accessing the conversation bean from EL.
>
> The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.
Right, the TCK test should be fixed to escape the name properly.

>
>
> Why didn't we simply use underscores instead of dots? :)
>
>
> LieGrue,
> strub


From issues at jboss.org  Mon Jan  5 11:05:31 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 11:05:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour
In-Reply-To: <JIRA.12465573.1336029589000@Atlassian.JIRA>
References: <JIRA.12465573.1336029589000@Atlassian.JIRA>
	<JIRA.12465573.1336029589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465573.1336029589000.19705.1420473931977@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-226:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Clarify the @Singleton behaviour
> --------------------------------
>
>                 Key: CDI-226
>                 URL: https://issues.jboss.org/browse/CDI-226
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.EDR
>            Reporter: Daniel Sachse
>              Labels: application-scoped, singleton
>             Fix For: 2.0 (discussion)
>
>
> The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation.
> ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ).



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 11:06:31 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 11:06:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-229) introduce @OverridesAttribute for
 @StereoType
In-Reply-To: <JIRA.12465776.1336306109000@Atlassian.JIRA>
References: <JIRA.12465776.1336306109000@Atlassian.JIRA>
	<JIRA.12465776.1336306109000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465776.1336306109000.19743.1420473991027@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-229:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> introduce @OverridesAttribute for @StereoType
> ---------------------------------------------
>
>                 Key: CDI-229
>                 URL: https://issues.jboss.org/browse/CDI-229
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.1.EDR
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> We recently had a thread on the DeltaSpike list about using StereoTypes in real world applications: http://markmail.org/thread/ntqwnsyukjvdwspm
> ------
> Imagine the following Stereotype for my Services (I spare out the standard
> stuff)
> @StereoType @Secured @Transactional @ApplicationScoped 
> public @interface @Service {}
> The problem here is that there is no way to 'propagate' any rolesAllowed from
> @Service to @Secured, etc.
> What I'd like to have is something like ... 
> public @interface @Service {
>     String[] rolesAllowed();     
>     TransactionAttributeType transactionType();
> }
> where the rolesAllowed() would get propagated to the @Secured meta-annotation
> and transactionType() to the @Transactional 
> -----------
> Gerhard Petracek now pointed me to a cool feature which is used in JSR-303 BVAL: @OverridesAttribute
> http://docs.oracle.com/javaee/6/api/javax/validation/OverridesAttribute.html
> We should ping the BVAL EG for the details. There are quite a few little tricks and side effects to consider.
> On the implementation side, we could e.g. pick the @StereoType annotation and automatically propagate those values to the AnnotatedType which get's passed to the Extensions



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 11:31:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 11:31:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.19887.1420475489824@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029961#comment-13029961 ] 

Antoine Sabot-Durand commented on CDI-232:
------------------------------------------

[~mkouba]Could give a use case where the current strict rules regarding Instance could bring limitation?

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: TBD
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:13:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:13:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-234) behavior of arrays without
	@Nonbinding
In-Reply-To: <JIRA.12467721.1338464780000@Atlassian.JIRA>
References: <JIRA.12467721.1338464780000@Atlassian.JIRA>
	<JIRA.12467721.1338464780000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467721.1338464780000.19960.1420478010061@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-234:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> behavior of arrays without @Nonbinding
> --------------------------------------
>
>                 Key: CDI-234
>                 URL: https://issues.jboss.org/browse/CDI-234
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 1.0
>            Reporter: Romain Manni-Bucau
>            Assignee: Pete Muir
>            Priority: Minor
>             Fix For: 2.0 (discussion)
>
>
> The spec says:
> "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application.
> If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior
> results."
> The case of arrays without this annotation should be managed to get a better portability. The equality of arrays is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotation.html) so i don't think there is any technical issue to consider arrays as a field.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:32:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:32:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.20023.1420479149731@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-497:
-------------------------------------
    Issue Type: Feature Request  (was: Epic)


> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:34:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:34:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.20025.1420479269694@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029988#comment-13029988 ] 

Antoine Sabot-Durand commented on CDI-497:
------------------------------------------

I'm not sure to understand your issue. Can you give a use case?

> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:37:29 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 5 Jan 2015 12:37:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.20029.1420479449702@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029990#comment-13029990 ] 

Romain Manni-Bucau commented on CDI-497:
----------------------------------------

Sure,

if invalidate is called during a request, session scope needs to be destroyed as well otherwise all usage of session scope beans later in the request is wrong and with corrupted data.



> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:38:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:38:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.20033.1420479510093@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-496:
-------------------------------------
    Affects Version/s: 1.2.Final


> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 12:38:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:38:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.20037.1420479510287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-496:
-------------------------------------
    Component/s: Interceptors


> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 12:39:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:39:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.20045.1420479570186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-496:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Mon Jan  5 12:40:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:40:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-495) What happens if an illegal bean
 type is found in the set of bean types
In-Reply-To: <JIRA.12559968.1419243129000@Atlassian.JIRA>
References: <JIRA.12559968.1419243129000@Atlassian.JIRA>
	<JIRA.12559968.1419243129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559968.1419243129000.20050.1420479630014@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-495:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
>                 Key: CDI-495
>                 URL: https://issues.jboss.org/browse/CDI-495
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Mon Jan  5 12:41:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Jan 2015 12:41:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-494) Clarify that a type variable that
 resolves to a wildcard is not resolvable
In-Reply-To: <JIRA.12558534.1417506996000@Atlassian.JIRA>
References: <JIRA.12558534.1417506996000@Atlassian.JIRA>
	<JIRA.12558534.1417506996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558534.1417506996000.20052.1420479689839@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-494:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Clarify that a type variable that resolves to a wildcard is not resolvable
> --------------------------------------------------------------------------
>
>                 Key: CDI-494
>                 URL: https://issues.jboss.org/browse/CDI-494
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Jozef Hartinger
>             Fix For: 2.0 (discussion)
>
>
> This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 03:07:30 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 6 Jan 2015 03:07:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.20585.1420531650215@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030082#comment-13030082 ] 

Martin Kouba commented on CDI-232:
----------------------------------

It's not about limitiations. As Jozef pointed out it's hardly possible to implement {{Instance}} built-in bean according to requirements. So this is mainly about the correct wording.

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: TBD
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 03:58:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 03:58:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.20676.1420534709864@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030095#comment-13030095 ] 

Antoine Sabot-Durand commented on CDI-232:
------------------------------------------

Ok got it. I read it in the wrong way. So 5.6.2 should become something like:

{quote}
The container must provide a built-in bean with:
* Instance<?> and Provider<?> in its set of bean types,
* scope @Dependent,
* no bean name, and
* an implementation provided automatically by the container.

*For all injection point of type Instance<T> or Provider<T> the container must validate that at least one bean with T in its set of bean types exists. If such a bean doesn't exist, the container automatically detects the problem and treats it as a deployment problem*

The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies.
{quote}

We probably should also mention qualifiers in the validation sentence.

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: TBD
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 04:01:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 04:01:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.20684.1420534890113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-232:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 04:21:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 04:21:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-493) Allow firing of parameterized
 event types from BeanManager
In-Reply-To: <JIRA.12558063.1416843782000@Atlassian.JIRA>
References: <JIRA.12558063.1416843782000@Atlassian.JIRA>
	<JIRA.12558063.1416843782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558063.1416843782000.20730.1420536089708@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-493:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Allow firing of parameterized event types from BeanManager
> ----------------------------------------------------------
>
>                 Key: CDI-493
>                 URL: https://issues.jboss.org/browse/CDI-493
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Sven Linstaedt
>             Fix For: 2.0 (discussion)
>
>
> Currently we are allowed firing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable. 
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type. 
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like 
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
>     if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
>         // register interceptor type
>     } else {
>         // register intercepted type
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 04:22:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 04:22:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific
 part to servlet specification
In-Reply-To: <JIRA.12557716.1416420606000@Atlassian.JIRA>
References: <JIRA.12557716.1416420606000@Atlassian.JIRA>
	<JIRA.12557716.1416420606000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557716.1416420606000.20734.1420536149857@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-492:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Give ownership of servlet specific part to servlet specification
> ----------------------------------------------------------------
>
>                 Key: CDI-492
>                 URL: https://issues.jboss.org/browse/CDI-492
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 (discussion)
>
>
> [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically,
> {quote}
> A servlet container must provide the following built-in beans, all of which have qualifier @Default:
> * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest
> * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession,
> * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext,
> These beans are passivation capable dependencies, as defined in Passivation capable dependencies.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 05:01:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 05:01:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.20818.1420538490103@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030112#comment-13030112 ] 

Antoine Sabot-Durand commented on CDI-497:
------------------------------------------

Form what I understand your concern is with [6.7.2. Session context lifecycle|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#session_context] 

{quote}
The session context is destroyed when the {{HTTPSession}} times out, after all {{HttpSessionListener}} s have been called, and at the very end of any request in which {{invalidate()}} was called, after all filters and ServletRequestListener s have been called.
{quote}

You'd like to see the session scope destroyed when {{invalidate}} is called not at the end of the request as it's specified now? 

> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 05:06:29 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 6 Jan 2015 05:06:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.20825.1420538789855@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030113#comment-13030113 ] 

Romain Manni-Bucau commented on CDI-497:
----------------------------------------

Yes Antoine.

{code}
/**
     * Invalidates this session then unbinds any objects bound
     * to it.
     *
     * @throws IllegalStateException if this method is called on an
     *                               already invalidated session
     */
    void invalidate();
{code}

This unbind bound objects so basically the scope doesn't have any sense later, id is also changed and session is often recycled (pooling implementation are quite common), it can just introduce inconsistencies IMO - ie make the same session used in 2 requests which are not linked at all, create leaks if the app relies on session id etc...

> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From sven.linstaedt at gmail.com  Tue Jan  6 05:12:10 2015
From: sven.linstaedt at gmail.com (Sven Linstaedt)
Date: Tue, 6 Jan 2015 11:12:10 +0100
Subject: [cdi-dev] generalized bean binding mechanism
Message-ID: <CADDZ-cfnAgKqyR_COZrPzRvsje05ptvZyvZQbtLjnPBuLQ_VDw@mail.gmail.com>

Hi,

while reading the discussions about upcoming cdi 2.0 features, I recognized
that more and more features (interceptors, CDI-110
<https://issues.jboss.org/browse/CDI-110>) are based on some defined
"binding" mechanism.

I am asking myself whether the currently bean binding mechanism is going to
be generalized and published as part of some API (e.g. lifecycle events) in
the near future? Doing so would

1. benefit extension providers have a solid and standardized base for their
binding based extensions
2. allow application developers to modify the binding during application
startup e.g. by interacting with the thrown lifecycle events.


br, Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150106/56ad2197/attachment-0001.html 

From tremes at redhat.com  Tue Jan  6 06:46:25 2015
From: tremes at redhat.com (Tomas Remes)
Date: Tue, 6 Jan 2015 06:46:25 -0500 (EST)
Subject: [cdi-dev] where is defined
 javax.enterprise.context.conversation.id?
In-Reply-To: <54AAAB74.5010508@redhat.com>
References: <54AA4C6B.2050302@redhat.com>
	<1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
	<54AAAB74.5010508@redhat.com>
Message-ID: <951877974.5792019.1420544785308.JavaMail.zimbra@redhat.com>


Well I am not sure. Reading EL spec and ECMA script I can't see any wording which will imply a must to escape or quote the variable in this case. I think the current usage is not forbidden anywhere. I tried to escape or quote the part of variable but it didn't work. The result was considered as String instance or I got ParserException. 

Tom

----- Original Message -----
From: "Jozef Hartinger" <jharting at redhat.com>
To: "Mark Struberg" <struberg at yahoo.de>, "John D. Ament" <john.d.ament at gmail.com>, "Tomas Remes" <tremes at redhat.com>
Cc: cdi-dev at lists.jboss.org
Sent: Monday, January 5, 2015 4:19:16 PM
Subject: Re: [cdi-dev] where is defined javax.enterprise.context.conversation.id?


On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>> The spec also only says that the BEAN must have this very name and not that
>>> the bean must be accessible by EL.
>> Given what the name is for in CDI this can be implied.
>
> well, but it's not up to the CDI impl to do this correctly.
No, my point was that if a bean is given a name it implies that this 
bean should be accessible via EL.
>
>
>>> If we would really require this and the EL specification doesn't
>>> support it, then the CDI spec would contradict the EL spec, right?
>> No, it would mean that the name should be placed within quotes when
>> accessing the conversation bean from EL.
>
> The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.
Right, the TCK test should be fixed to escape the name properly.

>
>
> Why didn't we simply use underscores instead of dots? :)
>
>
> LieGrue,
> strub




From issues at jboss.org  Tue Jan  6 06:49:30 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 6 Jan 2015 06:49:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.20980.1420544970128@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030139#comment-13030139 ] 

Jozef Hartinger commented on CDI-232:
-------------------------------------

No, the behavior is correct. It's the way the behavior is defined that is problematic.

The expected behavior is that no matter what legal type X and qualifiers you choose, you'll always get instance injected for Instance<X> and given qualifiers. The way this is specified is by saying that the built-in bean has
{quote} 
? Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
? every qualifier type in its set of qualifier types
{quote}

Combined with how CDI resolution rules work this gets the job done (since the built-in bean has all the types and qualifiers, it will always be resolved). In theory this approach is correct. However, it is difficult to materialize since it uses infinite sets (e.g. Bean<Instance>.getTypes() should strictly speaking return and infinite set of all possible bean types) which is inconvenient at best



> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From rmannibucau at gmail.com  Tue Jan  6 06:53:45 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 6 Jan 2015 12:53:45 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <951877974.5792019.1420544785308.JavaMail.zimbra@redhat.com>
References: <54AA4C6B.2050302@redhat.com>
	<1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
	<54AAAB74.5010508@redhat.com>
	<951877974.5792019.1420544785308.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7OoGHzsG4CMyYOp8iCzUcN7YXe-V_k3P4vqEYsmfq9pjQ@mail.gmail.com>

Well it is quite explicit:

1.6 Operators [] and .
The EL follows ECMAScript in unifying the treatment of the . and [] operators.
expr-a.identifier-b is equivalent to expr-a[?identifier-b?]; that is, the
identifier identifier-b is used to construct a literal whose value is
the identifier,
and then the [] operator is used with that value.

so javax.enterprise.context.conversation.id =
javax["enterprise"]["context"]["conversation"]["id"].

If then you follow the EL resolution agorithm there is no way which
can match our name case - and EL is only inspired from ECMA and doesnt
follow all its rules.

The best would be to add a "cdi" object (whatever name it is while it
is compliant) and to allow:

${cdi['javax.enterprise.context.conversation']} syntax, exactly like
requestScope can be used to get javax.servlet.* properties.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-06 12:46 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>
> Well I am not sure. Reading EL spec and ECMA script I can't see any wording which will imply a must to escape or quote the variable in this case. I think the current usage is not forbidden anywhere. I tried to escape or quote the part of variable but it didn't work. The result was considered as String instance or I got ParserException.
>
> Tom
>
> ----- Original Message -----
> From: "Jozef Hartinger" <jharting at redhat.com>
> To: "Mark Struberg" <struberg at yahoo.de>, "John D. Ament" <john.d.ament at gmail.com>, "Tomas Remes" <tremes at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Sent: Monday, January 5, 2015 4:19:16 PM
> Subject: Re: [cdi-dev] where is defined javax.enterprise.context.conversation.id?
>
>
> On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>>> The spec also only says that the BEAN must have this very name and not that
>>>> the bean must be accessible by EL.
>>> Given what the name is for in CDI this can be implied.
>>
>> well, but it's not up to the CDI impl to do this correctly.
> No, my point was that if a bean is given a name it implies that this
> bean should be accessible via EL.
>>
>>
>>>> If we would really require this and the EL specification doesn't
>>>> support it, then the CDI spec would contradict the EL spec, right?
>>> No, it would mean that the name should be placed within quotes when
>>> accessing the conversation bean from EL.
>>
>> The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.
> Right, the TCK test should be fixed to escape the name properly.
>
>>
>>
>> Why didn't we simply use underscores instead of dots? :)
>>
>>
>> LieGrue,
>> strub
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From mkouba at redhat.com  Tue Jan  6 09:08:32 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 06 Jan 2015 15:08:32 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <CACLE=7OoGHzsG4CMyYOp8iCzUcN7YXe-V_k3P4vqEYsmfq9pjQ@mail.gmail.com>
References: <54AA4C6B.2050302@redhat.com>	<1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>	<54AAAB74.5010508@redhat.com>	<951877974.5792019.1420544785308.JavaMail.zimbra@redhat.com>
	<CACLE=7OoGHzsG4CMyYOp8iCzUcN7YXe-V_k3P4vqEYsmfq9pjQ@mail.gmail.com>
Message-ID: <54ABEC60.9000308@redhat.com>

Dne 6.1.2015 v 12:53 Romain Manni-Bucau napsal(a):
> Well it is quite explicit:
>
> 1.6 Operators [] and .
> The EL follows ECMAScript in unifying the treatment of the . and [] operators.
> expr-a.identifier-b is equivalent to expr-a[?identifier-b?]; that is, the
> identifier identifier-b is used to construct a literal whose value is
> the identifier,
> and then the [] operator is used with that value.
>
> so javax.enterprise.context.conversation.id =
> javax["enterprise"]["context"]["conversation"]["id"].
>
> If then you follow the EL resolution agorithm there is no way which
> can match our name case -

It's possible although not very convenient. A custom ELResolver can 
handle these "virtual" properties. Weld builds a special namespace 
hierarchy, so that for instance javax["enterprise"] returns a Namespace 
object which has a virtual property "context" of type Namespace, etc. 
Again it's not nice and certainly not efficient. But it's not forbidden 
imho.

and EL is only inspired from ECMA and doesnt
> follow all its rules.
>
> The best would be to add a "cdi" object (whatever name it is while it
> is compliant) and to allow:
>
> ${cdi['javax.enterprise.context.conversation']} syntax, exactly like
> requestScope can be used to get javax.servlet.* properties.

Yep, this might be a better approach.

>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-06 12:46 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>
>> Well I am not sure. Reading EL spec and ECMA script I can't see any wording which will imply a must to escape or quote the variable in this case. I think the current usage is not forbidden anywhere. I tried to escape or quote the part of variable but it didn't work. The result was considered as String instance or I got ParserException.
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "Jozef Hartinger" <jharting at redhat.com>
>> To: "Mark Struberg" <struberg at yahoo.de>, "John D. Ament" <john.d.ament at gmail.com>, "Tomas Remes" <tremes at redhat.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Monday, January 5, 2015 4:19:16 PM
>> Subject: Re: [cdi-dev] where is defined javax.enterprise.context.conversation.id?
>>
>>
>> On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>>>> The spec also only says that the BEAN must have this very name and not that
>>>>> the bean must be accessible by EL.
>>>> Given what the name is for in CDI this can be implied.
>>>
>>> well, but it's not up to the CDI impl to do this correctly.
>> No, my point was that if a bean is given a name it implies that this
>> bean should be accessible via EL.
>>>
>>>
>>>>> If we would really require this and the EL specification doesn't
>>>>> support it, then the CDI spec would contradict the EL spec, right?
>>>> No, it would mean that the name should be placed within quotes when
>>>> accessing the conversation bean from EL.
>>>
>>> The question is whether it really is defined in the EL spec that way. And further if the EL TCK does test this or if this is non-portable. The TCK test doesn't use escaping for what I saw. So this test is not ok.
>> Right, the TCK test should be fixed to escape the name properly.
>>
>>>
>>>
>>> Why didn't we simply use underscores instead of dots? :)
>>>
>>>
>>> LieGrue,
>>> strub
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From rmannibucau at gmail.com  Tue Jan  6 09:10:36 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 6 Jan 2015 15:10:36 +0100
Subject: [cdi-dev] where is defined
	javax.enterprise.context.conversation.id?
In-Reply-To: <54ABEC60.9000308@redhat.com>
References: <54AA4C6B.2050302@redhat.com>
	<1686109711.4497773.1420448956529.JavaMail.yahoo@jws11134.mail.ir2.yahoo.com>
	<54AAAB74.5010508@redhat.com>
	<951877974.5792019.1420544785308.JavaMail.zimbra@redhat.com>
	<CACLE=7OoGHzsG4CMyYOp8iCzUcN7YXe-V_k3P4vqEYsmfq9pjQ@mail.gmail.com>
	<54ABEC60.9000308@redhat.com>
Message-ID: <CACLE=7NrXm2_rPH-btW01=Tndsb7u87BOxJKDcduKWJVECQm_g@mail.gmail.com>

not forbidden but then you break other specs if they use javax as well
so not sure we can rely on it anyway


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-06 15:08 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
> Dne 6.1.2015 v 12:53 Romain Manni-Bucau napsal(a):
>>
>> Well it is quite explicit:
>>
>> 1.6 Operators [] and .
>> The EL follows ECMAScript in unifying the treatment of the . and []
>> operators.
>> expr-a.identifier-b is equivalent to expr-a[?identifier-b?]; that is, the
>> identifier identifier-b is used to construct a literal whose value is
>> the identifier,
>> and then the [] operator is used with that value.
>>
>> so javax.enterprise.context.conversation.id =
>> javax["enterprise"]["context"]["conversation"]["id"].
>>
>> If then you follow the EL resolution agorithm there is no way which
>> can match our name case -
>
>
> It's possible although not very convenient. A custom ELResolver can handle
> these "virtual" properties. Weld builds a special namespace hierarchy, so
> that for instance javax["enterprise"] returns a Namespace object which has a
> virtual property "context" of type Namespace, etc. Again it's not nice and
> certainly not efficient. But it's not forbidden imho.
>
> and EL is only inspired from ECMA and doesnt
>>
>> follow all its rules.
>>
>> The best would be to add a "cdi" object (whatever name it is while it
>> is compliant) and to allow:
>>
>> ${cdi['javax.enterprise.context.conversation']} syntax, exactly like
>> requestScope can be used to get javax.servlet.* properties.
>
>
> Yep, this might be a better approach.
>
>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-06 12:46 GMT+01:00 Tomas Remes <tremes at redhat.com>:
>>>
>>>
>>> Well I am not sure. Reading EL spec and ECMA script I can't see any
>>> wording which will imply a must to escape or quote the variable in this
>>> case. I think the current usage is not forbidden anywhere. I tried to escape
>>> or quote the part of variable but it didn't work. The result was considered
>>> as String instance or I got ParserException.
>>>
>>> Tom
>>>
>>> ----- Original Message -----
>>> From: "Jozef Hartinger" <jharting at redhat.com>
>>> To: "Mark Struberg" <struberg at yahoo.de>, "John D. Ament"
>>> <john.d.ament at gmail.com>, "Tomas Remes" <tremes at redhat.com>
>>> Cc: cdi-dev at lists.jboss.org
>>> Sent: Monday, January 5, 2015 4:19:16 PM
>>> Subject: Re: [cdi-dev] where is defined
>>> javax.enterprise.context.conversation.id?
>>>
>>>
>>> On 01/05/2015 10:09 AM, Mark Struberg wrote:
>>>>>>
>>>>>> The spec also only says that the BEAN must have this very name and not
>>>>>> that
>>>>>> the bean must be accessible by EL.
>>>>>
>>>>> Given what the name is for in CDI this can be implied.
>>>>
>>>>
>>>> well, but it's not up to the CDI impl to do this correctly.
>>>
>>> No, my point was that if a bean is given a name it implies that this
>>> bean should be accessible via EL.
>>>>
>>>>
>>>>
>>>>>> If we would really require this and the EL specification doesn't
>>>>>> support it, then the CDI spec would contradict the EL spec, right?
>>>>>
>>>>> No, it would mean that the name should be placed within quotes when
>>>>> accessing the conversation bean from EL.
>>>>
>>>>
>>>> The question is whether it really is defined in the EL spec that way.
>>>> And further if the EL TCK does test this or if this is non-portable. The TCK
>>>> test doesn't use escaping for what I saw. So this test is not ok.
>>>
>>> Right, the TCK test should be fixed to escape the name properly.
>>>
>>>>
>>>>
>>>> Why didn't we simply use underscores instead of dots? :)
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic


From issues at jboss.org  Tue Jan  6 09:50:31 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 09:50:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21457.1420555831488@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030240#comment-13030240 ] 

Antoine Sabot-Durand commented on CDI-232:
------------------------------------------

yes [~jharting], that's why I was starting to propose a new way to define the behaviour. Saying that the container doesn't provide all the Instance for all bean type but only check that the Instance you injected is related to a valid bean type. Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ?

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 10:02:30 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 6 Jan 2015 10:02:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21531.1420556550843@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030255#comment-13030255 ] 

Jozef Hartinger commented on CDI-232:
-------------------------------------

{quote}Do you mean that the current behaviour allow me to put a non valid bean type (inject Instance<Foo> where no beans exist with Foo type) ?{quote}
Yes. We should not really change the behavior. Even if we were allowed to do so, this is still a valid usecase. You can have a code such as:

{code}
@Inject Instance<Foo> instance

if (!instance.isUnsatisfied()) {
    // use foo
    instance.get();
} else {
    // use something other than foo
}
{code}

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 11:08:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 11:08:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21734.1420560509845@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030291#comment-13030291 ] 

Antoine Sabot-Durand commented on CDI-232:
------------------------------------------

So we could reword the paragraph like this

{quote}
The container must provide a built-in bean:
* eligible for all injection point of type Instance<T> and Provider<T>, for any T type and having any set of qualifiers,
* with scope @Dependent,
* with no bean name, and
* an implementation provided automatically by the container.

The built-in implementation must be a passivation capable dependency, as defined in Passivation capable dependencies.
{quote}


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 11:55:29 2015
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 6 Jan 2015 11:55:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21841.1420563329862@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030305#comment-13030305 ] 

Pete Muir commented on CDI-232:
-------------------------------

So now what doe getBeanTypes return?

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 12:01:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 12:01:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21862.1420563690126@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030308#comment-13030308 ] 

Antoine Sabot-Durand commented on CDI-232:
------------------------------------------

{{Instance}}, {{Provider}} (raw types) and {{Object}}.

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 12:01:30 2015
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 6 Jan 2015 12:01:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.21864.1420563690265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030309#comment-13030309 ] 

Pete Muir commented on CDI-497:
-------------------------------

I think it would be reasonable to review this, but as with everything we should be careful about backwards compatibility.

> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 12:04:29 2015
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 6 Jan 2015 12:04:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.21870.1420563869716@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030311#comment-13030311 ] 

Pete Muir commented on CDI-232:
-------------------------------

I think that needs including in the spec.

> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 13:06:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 13:06:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.22000.1420567589754@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-232:
-------------------------------------
    Fix Version/s: 2.0 (proposed)
                       (was: 2.0 (discussion))


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>             Fix For: 2.0 (proposed)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 13:08:30 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 13:08:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-497) session scope doesn't follow
 session lifecycle
In-Reply-To: <JIRA.12560194.1420448865000@Atlassian.JIRA>
References: <JIRA.12560194.1420448865000@Atlassian.JIRA>
	<JIRA.12560194.1420448865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560194.1420448865000.22011.1420567710382@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-497:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
>                 Key: CDI-497
>                 URL: https://issues.jboss.org/browse/CDI-497
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>             Fix For: 2.0 (discussion)
>
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Tue Jan  6 13:09:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Jan 2015 13:09:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-489) NonexistentConversationException
 thrown at restore view or not?
In-Reply-To: <JIRA.12555658.1413894528000@Atlassian.JIRA>
References: <JIRA.12555658.1413894528000@Atlassian.JIRA>
	<JIRA.12555658.1413894528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555658.1413894528000.22014.1420567769814@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-489:
-------------------------------------
    Fix Version/s: 2.0 (proposed)


> NonexistentConversationException thrown at restore view or not?
> ---------------------------------------------------------------
>
>                 Key: CDI-489
>                 URL: https://issues.jboss.org/browse/CDI-489
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Vsevolod Golovanov
>             Fix For: 2.0 (proposed)
>
>
> The 1.0 spec says in 6.7.4:
> {quote}If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore
> view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.{quote}
> 1.1 and 1.2 just say:
> {quote}
> If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and
> throw an exception of type javax.enterprise.context.NonexistentConversationException.
> {quote}
> Yet the javadoc of NonexistentConversationException for both 1.1 and 1.2 says:
> {quote}
> If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type NonexistentConversationException from the restore view phase of the JSF lifecycle.
> {quote}
> So is it supposed to be thrown from restore view or not? I assume not. Probably javadoc should be amended.
> I'm curious about reasoning behind the change. I tried searching for an explanation but didn't find anything.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan  7 07:44:30 2015
From: issues at jboss.org (Pete Muir (JIRA))
Date: Wed, 7 Jan 2015 07:44:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.23335.1420634670288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030493#comment-13030493 ] 

Pete Muir commented on CDI-496:
-------------------------------

The second statement (about proxability) does not affect what beans can be intercepted. The reason session beans are not mentioned here is because the EJB specification defines that the bean must be proxiable.

I don't really understand this issue.

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From pmuir at redhat.com  Wed Jan  7 07:59:15 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 7 Jan 2015 12:59:15 +0000
Subject: [cdi-dev] Would @PostActivate,
	@PrePassivate and @Remove make sense in JSR 250 ?
In-Reply-To: <CA+ZZq9_fFgcG0B=8+5bT13sGMz+zvsHyn-SGRKsNaXZW4FwwiA@mail.gmail.com>
References: <CA+ZZq9_fFgcG0B=8+5bT13sGMz+zvsHyn-SGRKsNaXZW4FwwiA@mail.gmail.com>
Message-ID: <BFFFBBEA-A804-4D6A-860D-51B4F592A4B9@redhat.com>


> On 28 Dec 2014, at 12:38, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
> 
> Hi all,
> 
> I was playing with @SessionScoped beans... and wondered if @PostActivate, @PrePassivate and @Remove would make sense in JSR 250 ?
> 
> At the moment these annotations belong to the javax.ejb package and are only used in @Stateful EJBs. With CDI scopes, we end up with a few "stateful" scopes (@SessionScoped, but also @ConversationScoped, @ViewScoped...) so why not having the same functionality in CDI ? @PreDestroy and @PostConstruct are already part of JSR 250. So why not having @PostActivate and @PrePassivate as well so they could be used in every bean ? 
> 
> BTW, while I was playing with @SessionScoped beans, I asked Antoine to show me how to remove a bean from the session. It's only a few lines of code, but again, why not having a @Remove annotation that does that (the exact same one of javax.ejb.Remove) ?

I always found @Remove extremely weird, I think removing a bean instance should be an explicit action, not an side effect of calling some other method.

> 
> To summarize, why not taking some of those stateful EJB concerns back to JSR 250 so they could be used anywhere ?
> 
> Any thoughts ?
> 
> -- 
> Antonio Goncalves 
> Software architect, Java Champion and Pluralsight author
> 
> Web site <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>_______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150107/25796684/attachment.html 

From issues at jboss.org  Wed Jan  7 08:01:30 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 7 Jan 2015 08:01:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.23397.1420635690572@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030511#comment-13030511 ] 

Romain Manni-Bucau commented on CDI-496:
----------------------------------------

there are TCKs - sorry dont have the test name anymore - validing EJB impl class for proxying and expects it to fail with a CDI exception where CDI shouldn't see it.

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Wed Jan  7 08:03:30 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 7 Jan 2015 08:03:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.23410.1420635810142@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030513#comment-13030513 ] 

Martin Kouba commented on CDI-496:
----------------------------------

First of all I'm not sure EJB requirements exactly match CDI requirements (e.g. EJB 3.2 does not forbid non-static final methods, see "4.9.2 Session Bean Class").

Also sentences like:
{quote}
Interceptor bindings may be used to associate interceptors with any managed bean that is not a decorator.
{quote} are just confusing (9.3. Binding an interceptor to a bean).

Lastly the wording:
bq. ...the managed bean must be a proxyable bean type
is not accurate and would deserve a minor revision.

However, I would lower the priority of this issue as it's obvious that bindings can be used for session beans.

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Wed Jan  7 08:10:30 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 7 Jan 2015 08:10:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.23430.1420636230091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030518#comment-13030518 ] 

Jozef Hartinger commented on CDI-496:
-------------------------------------

The problem with the TCK test is that it verifies that the container throws a deployment exception if an intercepted session bean is not proxyable. This is an implication of

{quote}
A bean type must be proxyable if an injection point resolves to a bean:
? that requires a client proxy, or
? that has an associated decorator, or
? that has a bound interceptor.
Otherwise, the container automatically detects the problem, and treats it as a deployment problem
{quote}

The issue here is whether CDI's DeploymentException should really be thrown for a session bean or whether we should let the EJB container fail in whathever way it prefers (and therefore the aforementioned part of the spec should be changed to affect managed beans only).

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Wed Jan  7 08:16:29 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 7 Jan 2015 08:16:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-491) Clarify what happens when an
 interceptor doesn't have any @AroundInvoke or lifecycle annotation
In-Reply-To: <JIRA.12556689.1415179863000@Atlassian.JIRA>
References: <JIRA.12556689.1415179863000@Atlassian.JIRA>
	<JIRA.12556689.1415179863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556689.1415179863000.23445.1420636589937@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030524#comment-13030524 ] 

Antoine Sabot-Durand commented on CDI-491:
------------------------------------------

I agree with [~mkouba]. Currently interceptor spec states in 2.1

{quote}
An around-invoke interceptor method, an around-timeout interceptor method, and lifecycle callback interceptor methods for different lifecycle events may be defined on the same interceptor class. An interceptor class may have superclasses.
{quote}

The interceptor spec doesn't forbid to have an interceptor class without lifecycle callback or {{@AroundInvoke}}. Clarification should be made in it.  

> Clarify what happens when an interceptor doesn't have any @AroundInvoke or lifecycle annotation
> -----------------------------------------------------------------------------------------------
>
>                 Key: CDI-491
>                 URL: https://issues.jboss.org/browse/CDI-491
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Antonio Goncalves
>
> At the moment, if you enable an interceptor in {{beans.xml}} and the class is not annotated with {{@Inteceptor}}, WELD throws an exception. But if the interceptor has no {{@AroundInvoke}}, {{@AroundConstrcut}}, {{@PostConstruct}} or {{@PreDestroy}}, then WELD stays silent and the interceptor doesn't work.
> The spec should clarify that, at least, one of these four annotation has to be used otherwise it's not considered a valid interceptor.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan  7 08:16:30 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 7 Jan 2015 08:16:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-496) Clarification (or completion) for
 interceptor binding to session bean
In-Reply-To: <JIRA.12560167.1420200086000@Atlassian.JIRA>
References: <JIRA.12560167.1420200086000@Atlassian.JIRA>
	<JIRA.12560167.1420200086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560167.1420200086000.23450.1420636590209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030525#comment-13030525 ] 

Romain Manni-Bucau commented on CDI-496:
----------------------------------------

excepted the CDI container doesnt have to know the EJB actual impl type so how can it validate it? I think it should be done in EJB container - anyway it should be done in EJB container anyway and lifecycle between EJB and CDI container doesnt say today which one would fail first

> Clarification (or completion) for interceptor binding to session bean
> ---------------------------------------------------------------------
>
>                 Key: CDI-496
>                 URL: https://issues.jboss.org/browse/CDI-496
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.2.Final
>            Reporter: Tomas Remes
>             Fix For: 2.0 (discussion)
>
>
> It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
> {quote}Managed beans and EJB session and message-driven beans support interception.{quote}
> But at the end of "9.3. Binding an interceptor to a bean" There is only:
> {quote}
> If a managed bean has a class-level or method-level interceptor binding, the managed bean must
> be a proxyable bean type, as defined in Section 3.15, ?Unproxyable bean types?.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From struberg at yahoo.de  Thu Jan  8 03:27:37 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 8 Jan 2015 08:27:37 +0000 (UTC)
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <21676.24106.508156.967850@gargle.gargle.HOWL>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
Message-ID: <262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>

Dear CDI fellows!

I've received an answer regarding our EL question from the EL Spec Lead.

Ed, thanks for helping us!


LieGrue,
strub




> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
> > Hello Mark,
> 
> To close this out, no, "." is not valid in an EL name.  An EL name 
> must
> be a java identifier.  I'm told this was discussed by Pete a long time
> ago in the EL 3.0 EG.
> 
> Ed
> 
> -- 
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 42 days til DevNexus 2015
> | 52 days til JavaLand 2015
> | 62 days til CONFESS 2015
> 

From issues at jboss.org  Thu Jan  8 04:22:29 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 8 Jan 2015 04:22:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation
 interface" - dots are not valid in EL name
In-Reply-To: <JIRA.12560483.1420708910000@Atlassian.JIRA>
References: <JIRA.12560483.1420708910000@Atlassian.JIRA>
	<JIRA.12560483.1420708910178@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560483.1420708910000.25313.1420708949501@Atlassian.JIRA>

Tomas Remes created CDI-498:
-------------------------------

             Summary: Revise "6.7.5. The Conversation interface" - dots are not valid in EL name
                 Key: CDI-498
                 URL: https://issues.jboss.org/browse/CDI-498
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 1.2.Final
            Reporter: Tomas Remes


Seems that following part contradicts the EL spec:

{quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped ,
and qualifier @Default , named javax.enterprise.context.conversation .{quote}

The EL name "javax.enterprise.context.conversation" is not valid.
Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-01-06.log.html

and

http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?"



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From edward.burns at oracle.com  Fri Jan  9 09:07:26 2015
From: edward.burns at oracle.com (Edward Burns)
Date: Fri, 9 Jan 2015 06:07:26 -0800
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
Message-ID: <21679.57502.550468.694335@gargle.gargle.HOWL>

>>>>> On Thu, 8 Jan 2015 08:27:37 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:

MS> I've received an answer regarding our EL question from the EL Spec Lead.

MS> Ed, thanks for helping us!

For the record, I'm not the EL spec lead, but I asked them on Mark's
behalf for the supplied answer.

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| 39 days til DevNexus 2015
| 49 days til JavaLand 2015
| 59 days til CONFESS 2015

From struberg at yahoo.de  Fri Jan  9 18:41:14 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 9 Jan 2015 23:41:14 +0000 (UTC)
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <21679.57502.550468.694335@gargle.gargle.HOWL>
References: <21679.57502.550468.694335@gargle.gargle.HOWL>
Message-ID: <2144953826.4022.1420846874617.JavaMail.yahoo@jws11158.mail.ir2.yahoo.com>

Ah oh sorry, but you are Servlet spec lead, right? Somehow I get confused by which parts are now an own JSR and EL was originally maintained under the Servlet EG umbrella, right?

LieGrue,
strub





> On Friday, 9 January 2015, 15:07, Edward Burns <edward.burns at oracle.com> wrote:
> >>>>>>  On Thu, 8 Jan 2015 08:27:37 +0000 (UTC), Mark Struberg 
> <struberg at yahoo.de> said:
> 
> MS> I've received an answer regarding our EL question from the EL Spec 
> Lead.
> 
> MS> Ed, thanks for helping us!
> 
> For the record, I'm not the EL spec lead, but I asked them on Mark's
> behalf for the supplied answer.
> 
> 
> Ed
> 
> -- 
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 39 days til DevNexus 2015
> | 49 days til JavaLand 2015
> | 59 days til CONFESS 2015
> 

From jharting at redhat.com  Wed Jan 14 04:54:20 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 14 Jan 2015 10:54:20 +0100
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
Message-ID: <54B63CCC.3080208@redhat.com>

I think further action is needed on this. Now that it has been confirmed 
that "javax.enterprise.context.conversation" itself is not a valid EL 
name we should either:

A) Require all CDI implementations to adapt the property-based approach 
which allows this to be implemented portably (as Weld does)
B) Declare publicly that although the CDI spec declares the given name, 
it is a bug and applications should not use the name. (What about 
compatibility with existing applications?)

Jozef

On 01/08/2015 09:27 AM, Mark Struberg wrote:
> Dear CDI fellows!
>
> I've received an answer regarding our EL question from the EL Spec Lead.
>
> Ed, thanks for helping us!
>
>
> LieGrue,
> strub
>
>
>
>
>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>> Hello Mark,
>> To close this out, no, "." is not valid in an EL name.  An EL name
>> must
>> be a java identifier.  I'm told this was discussed by Pete a long time
>> ago in the EL 3.0 EG.
>>
>> Ed
>>
>> -- 
>> | edward.burns at oracle.com | office: +1 407 458 0017
>> | 42 days til DevNexus 2015
>> | 52 days til JavaLand 2015
>> | 62 days til CONFESS 2015
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From rmannibucau at gmail.com  Wed Jan 14 05:09:21 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 11:09:21 +0100
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <54B63CCC.3080208@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
Message-ID: <CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>

+1 for B (IMO it is not used that much)




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
> I think further action is needed on this. Now that it has been confirmed
> that "javax.enterprise.context.conversation" itself is not a valid EL
> name we should either:
>
> A) Require all CDI implementations to adapt the property-based approach
> which allows this to be implemented portably (as Weld does)
> B) Declare publicly that although the CDI spec declares the given name,
> it is a bug and applications should not use the name. (What about
> compatibility with existing applications?)
>
> Jozef
>
> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>> Dear CDI fellows!
>>
>> I've received an answer regarding our EL question from the EL Spec Lead.
>>
>> Ed, thanks for helping us!
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>> Hello Mark,
>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>> must
>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>> ago in the EL 3.0 EG.
>>>
>>> Ed
>>>
>>> --
>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>> | 42 days til DevNexus 2015
>>> | 52 days til JavaLand 2015
>>> | 62 days til CONFESS 2015
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From pmuir at redhat.com  Wed Jan 14 05:56:37 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 10:56:37 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
Message-ID: <231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>

We need to go for both (A) and (B).

We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.

> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> +1 for B (IMO it is not used that much)
> 
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> I think further action is needed on this. Now that it has been confirmed
>> that "javax.enterprise.context.conversation" itself is not a valid EL
>> name we should either:
>> 
>> A) Require all CDI implementations to adapt the property-based approach
>> which allows this to be implemented portably (as Weld does)
>> B) Declare publicly that although the CDI spec declares the given name,
>> it is a bug and applications should not use the name. (What about
>> compatibility with existing applications?)
>> 
>> Jozef
>> 
>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>> Dear CDI fellows!
>>> 
>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>> 
>>> Ed, thanks for helping us!
>>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>> Hello Mark,
>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>> must
>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>> ago in the EL 3.0 EG.
>>>> 
>>>> Ed
>>>> 
>>>> --
>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>> | 42 days til DevNexus 2015
>>>> | 52 days til JavaLand 2015
>>>> | 62 days til CONFESS 2015
>>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From jharting at redhat.com  Wed Jan 14 06:13:29 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 14 Jan 2015 12:13:29 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
Message-ID: <54B64F59.4030905@redhat.com>

So for CDI 1.2 the test that tests this should not be excluded after 
all, correct?

On 01/14/2015 11:56 AM, Pete Muir wrote:
> We need to go for both (A) and (B).
>
> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>
>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> +1 for B (IMO it is not used that much)
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>> I think further action is needed on this. Now that it has been confirmed
>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>> name we should either:
>>>
>>> A) Require all CDI implementations to adapt the property-based approach
>>> which allows this to be implemented portably (as Weld does)
>>> B) Declare publicly that although the CDI spec declares the given name,
>>> it is a bug and applications should not use the name. (What about
>>> compatibility with existing applications?)
>>>
>>> Jozef
>>>
>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>> Dear CDI fellows!
>>>>
>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>
>>>> Ed, thanks for helping us!
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>> Hello Mark,
>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>> must
>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>> ago in the EL 3.0 EG.
>>>>>
>>>>> Ed
>>>>>
>>>>> --
>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>> | 42 days til DevNexus 2015
>>>>> | 52 days til JavaLand 2015
>>>>> | 62 days til CONFESS 2015
>>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From pmuir at redhat.com  Wed Jan 14 06:20:52 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 11:20:52 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B64F59.4030905@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
Message-ID: <84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>

I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.

> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
> 
> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
> 
> On 01/14/2015 11:56 AM, Pete Muir wrote:
>> We need to go for both (A) and (B).
>> 
>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>> 
>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>> 
>>> +1 for B (IMO it is not used that much)
>>> 
>>> 
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> 
>>> 
>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>> I think further action is needed on this. Now that it has been confirmed
>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>> name we should either:
>>>> 
>>>> A) Require all CDI implementations to adapt the property-based approach
>>>> which allows this to be implemented portably (as Weld does)
>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>> it is a bug and applications should not use the name. (What about
>>>> compatibility with existing applications?)
>>>> 
>>>> Jozef
>>>> 
>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>> Dear CDI fellows!
>>>>> 
>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>> 
>>>>> Ed, thanks for helping us!
>>>>> 
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>> Hello Mark,
>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>> must
>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>> ago in the EL 3.0 EG.
>>>>>> 
>>>>>> Ed
>>>>>> 
>>>>>> --
>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>> | 42 days til DevNexus 2015
>>>>>> | 52 days til JavaLand 2015
>>>>>> | 62 days til CONFESS 2015
>>>>>> 
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 



From rmannibucau at gmail.com  Wed Jan 14 06:21:37 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 12:21:37 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
Message-ID: <CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>

so it means a JavaEE container will not pass this test but it is not an issue?


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>
>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>
>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>
>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>> We need to go for both (A) and (B).
>>>
>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>
>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>
>>>> +1 for B (IMO it is not used that much)
>>>>
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>> name we should either:
>>>>>
>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>> which allows this to be implemented portably (as Weld does)
>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>> it is a bug and applications should not use the name. (What about
>>>>> compatibility with existing applications?)
>>>>>
>>>>> Jozef
>>>>>
>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>> Dear CDI fellows!
>>>>>>
>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>
>>>>>> Ed, thanks for helping us!
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>> Hello Mark,
>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>> must
>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>> ago in the EL 3.0 EG.
>>>>>>>
>>>>>>> Ed
>>>>>>>
>>>>>>> --
>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>> | 42 days til DevNexus 2015
>>>>>>> | 52 days til JavaLand 2015
>>>>>>> | 62 days til CONFESS 2015
>>>>>>>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>


From pmuir at redhat.com  Wed Jan 14 06:27:00 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 11:27:00 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
Message-ID: <BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>

No, a Java EE container needs to pass this test.

> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> so it means a JavaEE container will not pass this test but it is not an issue?
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>> 
>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>> 
>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>> 
>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>> We need to go for both (A) and (B).
>>>> 
>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>> 
>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>> 
>>>>> +1 for B (IMO it is not used that much)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>> 
>>>>> 
>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>> name we should either:
>>>>>> 
>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>> it is a bug and applications should not use the name. (What about
>>>>>> compatibility with existing applications?)
>>>>>> 
>>>>>> Jozef
>>>>>> 
>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>> Dear CDI fellows!
>>>>>>> 
>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>> 
>>>>>>> Ed, thanks for helping us!
>>>>>>> 
>>>>>>> 
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>> Hello Mark,
>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>> must
>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>> 
>>>>>>>> Ed
>>>>>>>> 
>>>>>>>> --
>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>> 
>> 



From rmannibucau at gmail.com  Wed Jan 14 06:30:52 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 12:30:52 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
Message-ID: <CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>

then it will not pass EL one


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
> No, a Java EE container needs to pass this test.
>
>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> so it means a JavaEE container will not pass this test but it is not an issue?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>
>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>
>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>
>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>> We need to go for both (A) and (B).
>>>>>
>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>
>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>
>>>>>> +1 for B (IMO it is not used that much)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>> name we should either:
>>>>>>>
>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>> compatibility with existing applications?)
>>>>>>>
>>>>>>> Jozef
>>>>>>>
>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>> Dear CDI fellows!
>>>>>>>>
>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>
>>>>>>>> Ed, thanks for helping us!
>>>>>>>>
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>> Hello Mark,
>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>> must
>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>
>>>>>>>>> Ed
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>
>


From pmuir at redhat.com  Wed Jan 14 06:35:59 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 11:35:59 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
Message-ID: <6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>

Which EL test?

> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> then it will not pass EL one
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> No, a Java EE container needs to pass this test.
>> 
>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>> 
>>> so it means a JavaEE container will not pass this test but it is not an issue?
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> 
>>> 
>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>> 
>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>> 
>>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>> 
>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>> We need to go for both (A) and (B).
>>>>>> 
>>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>> 
>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>> 
>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>> name we should either:
>>>>>>>> 
>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>> compatibility with existing applications?)
>>>>>>>> 
>>>>>>>> Jozef
>>>>>>>> 
>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>> Dear CDI fellows!
>>>>>>>>> 
>>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>> 
>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>> Hello Mark,
>>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>> must
>>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>> 
>>>>>>>>>> Ed
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> cdi-dev mailing list
>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>> 
>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>> 
>>>> 
>> 



From rmannibucau at gmail.com  Wed Jan 14 06:43:35 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 12:43:35 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
Message-ID: <CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>

well there are 2 points:
1) a test should be added for it
2) test or not being certified means respecting the spec (pdf, javadoc
+ tests themselve)

So if there is this test a container can't be certified for EL + CDI
at the same time


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
> Which EL test?
>
>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> then it will not pass EL one
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>> No, a Java EE container needs to pass this test.
>>>
>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>
>>>> so it means a JavaEE container will not pass this test but it is not an issue?
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>>>
>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>
>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>>>
>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>> We need to go for both (A) and (B).
>>>>>>>
>>>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>>>
>>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>
>>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>> name we should either:
>>>>>>>>>
>>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>>> compatibility with existing applications?)
>>>>>>>>>
>>>>>>>>> Jozef
>>>>>>>>>
>>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>
>>>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>
>>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>> must
>>>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>>>
>>>>>>>>>>> Ed
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>> _______________________________________________
>>>>>>>>> cdi-dev mailing list
>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>
>>>>>
>>>
>


From mkouba at redhat.com  Wed Jan 14 07:10:14 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 14 Jan 2015 13:10:14 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>	<54B63CCC.3080208@redhat.com>	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>	<54B64F59.4030905@redhat.com>	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
Message-ID: <54B65CA6.4000009@redhat.com>

Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
> well there are 2 points:
> 1) a test should be added for it

There was a CDI TCK test since 1.1 
(org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). 
It has been modified a week ago (see also CDITCK-462) not to use 
"javax.enterprise.context.conversation.id".

> 2) test or not being certified means respecting the spec (pdf, javadoc
> + tests themselve)
>
> So if there is this test a container can't be certified for EL + CDI
> at the same time

I don't think it's a problem. An EL TCK test can't evaluate 
"#{javax.enterprise.context.conversation.id}" as an illegal expression - 
it's obviously legal. The problem is 
"javax.enterprise.context.conversation.id" can't be simply used as a 
bean name. If it is, a workaround is needed (see also 
http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).

>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> Which EL test?
>>
>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>
>>> then it will not pass EL one
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> No, a Java EE container needs to pass this test.
>>>>
>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>
>>>>> so it means a JavaEE container will not pass this test but it is not an issue?
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>>>>
>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>
>>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>>>>
>>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>> We need to go for both (A) and (B).
>>>>>>>>
>>>>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>>>>
>>>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> @rmannibucau
>>>>>>>>> http://www.tomitribe.com
>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>> name we should either:
>>>>>>>>>>
>>>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>>>> compatibility with existing applications?)
>>>>>>>>>>
>>>>>>>>>> Jozef
>>>>>>>>>>
>>>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>>
>>>>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>
>>>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>> must
>>>>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>>>>
>>>>>>>>>>>> Ed
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>> _______________________________________________
>>>>>>>>> cdi-dev mailing list
>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>
>>>>>>
>>>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

From pmuir at redhat.com  Wed Jan 14 07:12:57 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 12:12:57 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B65CA6.4000009@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
Message-ID: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>

I agree with Martin. We *should* fix this situation in the long term, which is what I proposed. However in the short term there is no problem with not passing a particular test from the EL spec. Additionally this is provably implementable as Weld implements this, and many Java EE containers pass. As there are no other spec defined beans javax, then we do not conflict with any other spec by implementing it this way.

> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
> 
> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>> well there are 2 points:
>> 1) a test should be added for it
> 
> There was a CDI TCK test since 1.1 (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). It has been modified a week ago (see also CDITCK-462) not to use "javax.enterprise.context.conversation.id".
> 
>> 2) test or not being certified means respecting the spec (pdf, javadoc
>> + tests themselve)
>> 
>> So if there is this test a container can't be certified for EL + CDI
>> at the same time
> 
> I don't think it's a problem. An EL TCK test can't evaluate "#{javax.enterprise.context.conversation.id}" as an illegal expression - it's obviously legal. The problem is "javax.enterprise.context.conversation.id" can't be simply used as a bean name. If it is, a workaround is needed (see also http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html <http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html>).
> 
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>> 
>> 
>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>> Which EL test?
>>> 
>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>> 
>>>> then it will not pass EL one
>>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>> No, a Java EE container needs to pass this test.
>>>>> 
>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>> 
>>>>>> so it means a JavaEE container will not pass this test but it is not an issue?
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>> 
>>>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>>>>> 
>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>> We need to go for both (A) and (B).
>>>>>>>>> 
>>>>>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>>>>> 
>>>>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> @rmannibucau
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>>> name we should either:
>>>>>>>>>>> 
>>>>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>>>>> compatibility with existing applications?)
>>>>>>>>>>> 
>>>>>>>>>>> Jozef
>>>>>>>>>>> 
>>>>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>>> 
>>>>>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>> 
>>>>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>> must
>>>>>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Ed
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>> 
>>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>> 
>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev>
>> 
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html <http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150114/e9c70b5e/attachment-0001.html 

From rmannibucau at gmail.com  Wed Jan 14 07:42:56 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 13:42:56 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
Message-ID: <CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>

If "there is no problem with not passing a particular test from the EL
spec" then there is no problem with not passing a particular test from
the CDI spec at EE level which seems wrong to me.

Globally I'd just remove this test and keep it in Weld vendor specific features.

@martin: my 1) was for EL spec not CDI.

About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
is a property of conversation which is a property of context which is
a property of enterprise which is a property of javax which is clearly
not what is desired and opposed to what is in the CDI spec.



Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
> I agree with Martin. We *should* fix this situation in the long term, which
> is what I proposed. However in the short term there is no problem with not
> passing a particular test from the EL spec. Additionally this is provably
> implementable as Weld implements this, and many Java EE containers pass. As
> there are no other spec defined beans javax, then we do not conflict with
> any other spec by implementing it this way.
>
> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>
> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>
> well there are 2 points:
> 1) a test should be added for it
>
>
> There was a CDI TCK test since 1.1
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
> It has been modified a week ago (see also CDITCK-462) not to use
> "javax.enterprise.context.conversation.id".
>
> 2) test or not being certified means respecting the spec (pdf, javadoc
> + tests themselve)
>
> So if there is this test a container can't be certified for EL + CDI
> at the same time
>
>
> I don't think it's a problem. An EL TCK test can't evaluate
> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
> it's obviously legal. The problem is
> "javax.enterprise.context.conversation.id" can't be simply used as a bean
> name. If it is, a workaround is needed (see also
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>
> Which EL test?
>
> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>
> then it will not pass EL one
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>
> No, a Java EE container needs to pass this test.
>
> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>
> so it means a JavaEE container will not pass this test but it is not an
> issue?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>
> I don?t think they should be excluded. The spec isn?t ambiguous about this,
> and it is supportable.
>
> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>
> So for CDI 1.2 the test that tests this should not be excluded after all,
> correct?
>
> On 01/14/2015 11:56 AM, Pete Muir wrote:
>
> We need to go for both (A) and (B).
>
> We would need to deprecate the existing name before we can allow it to not
> be supported. This means CDI 3. So I would suggest we deprecate it in 2, add
> an alternative that can be used, and then consider removing it in CDI 3. In
> the meantime for CDI 2, we will need to improve the TCK to check this more
> carefully.
>
> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>
> +1 for B (IMO it is not used that much)
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
> I think further action is needed on this. Now that it has been confirmed
> that "javax.enterprise.context.conversation" itself is not a valid EL
> name we should either:
>
> A) Require all CDI implementations to adapt the property-based approach
> which allows this to be implemented portably (as Weld does)
> B) Declare publicly that although the CDI spec declares the given name,
> it is a bug and applications should not use the name. (What about
> compatibility with existing applications?)
>
> Jozef
>
> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>
> Dear CDI fellows!
>
> I've received an answer regarding our EL question from the EL Spec Lead.
>
> Ed, thanks for helping us!
>
>
> LieGrue,
> strub
>
>
>
>
> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
> wrote:
>
> Hello Mark,
>
> To close this out, no, "." is not valid in an EL name.  An EL name
> must
> be a java identifier.  I'm told this was discussed by Pete a long time
> ago in the EL 3.0 EG.
>
> Ed
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 42 days til DevNexus 2015
> | 52 days til JavaLand 2015
> | 62 days til CONFESS 2015
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
>
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
>
>


From mkouba at redhat.com  Wed Jan 14 08:09:28 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 14 Jan 2015 14:09:28 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
Message-ID: <54B66A88.4050701@redhat.com>

Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
> If "there is no problem with not passing a particular test from the EL
> spec" then there is no problem with not passing a particular test from
> the CDI spec at EE level which seems wrong to me.
>
> Globally I'd just remove this test and keep it in Weld vendor specific features.
>
> @martin: my 1) was for EL spec not CDI.
>
> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
> is a property of conversation which is a property of context which is
> a property of enterprise which is a property of javax which is clearly
> not what is desired and opposed to what is in the CDI spec.

Sure. But EL cannot test this. From it's point of view the 
"#{javax.enterprise.context.conversation.id}" expression is ok. From CDI 
point of view the name is wrong and cannot be used as it is...

>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> I agree with Martin. We *should* fix this situation in the long term, which
>> is what I proposed. However in the short term there is no problem with not
>> passing a particular test from the EL spec. Additionally this is provably
>> implementable as Weld implements this, and many Java EE containers pass. As
>> there are no other spec defined beans javax, then we do not conflict with
>> any other spec by implementing it this way.
>>
>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>
>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>
>> well there are 2 points:
>> 1) a test should be added for it
>>
>>
>> There was a CDI TCK test since 1.1
>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>> It has been modified a week ago (see also CDITCK-462) not to use
>> "javax.enterprise.context.conversation.id".
>>
>> 2) test or not being certified means respecting the spec (pdf, javadoc
>> + tests themselve)
>>
>> So if there is this test a container can't be certified for EL + CDI
>> at the same time
>>
>>
>> I don't think it's a problem. An EL TCK test can't evaluate
>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>> it's obviously legal. The problem is
>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>> name. If it is, a workaround is needed (see also
>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>
>> Which EL test?
>>
>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> then it will not pass EL one
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>
>> No, a Java EE container needs to pass this test.
>>
>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> so it means a JavaEE container will not pass this test but it is not an
>> issue?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>
>> I don?t think they should be excluded. The spec isn?t ambiguous about this,
>> and it is supportable.
>>
>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>
>> So for CDI 1.2 the test that tests this should not be excluded after all,
>> correct?
>>
>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>
>> We need to go for both (A) and (B).
>>
>> We would need to deprecate the existing name before we can allow it to not
>> be supported. This means CDI 3. So I would suggest we deprecate it in 2, add
>> an alternative that can be used, and then consider removing it in CDI 3. In
>> the meantime for CDI 2, we will need to improve the TCK to check this more
>> carefully.
>>
>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> +1 for B (IMO it is not used that much)
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>
>> I think further action is needed on this. Now that it has been confirmed
>> that "javax.enterprise.context.conversation" itself is not a valid EL
>> name we should either:
>>
>> A) Require all CDI implementations to adapt the property-based approach
>> which allows this to be implemented portably (as Weld does)
>> B) Declare publicly that although the CDI spec declares the given name,
>> it is a bug and applications should not use the name. (What about
>> compatibility with existing applications?)
>>
>> Jozef
>>
>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>
>> Dear CDI fellows!
>>
>> I've received an answer regarding our EL question from the EL Spec Lead.
>>
>> Ed, thanks for helping us!
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>> wrote:
>>
>> Hello Mark,
>>
>> To close this out, no, "." is not valid in an EL name.  An EL name
>> must
>> be a java identifier.  I'm told this was discussed by Pete a long time
>> ago in the EL 3.0 EG.
>>
>> Ed
>>
>> --
>> | edward.burns at oracle.com | office: +1 407 458 0017
>> | 42 days til DevNexus 2015
>> | 52 days til JavaLand 2015
>> | 62 days til CONFESS 2015
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>>

From rmannibucau at gmail.com  Wed Jan 14 08:13:35 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 14:13:35 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B66A88.4050701@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
Message-ID: <CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>

well issue is when you activate EL + CDI, if you respect both specs
#{javax.enterprise.context.conversation.id} should fail - agree we can
always use the *workaround* of Weld but this is actually not mandated
by any spec excepted this test which was IMO an interpolation. That's
why i think this test shouldnt be kept even for 1.x versions.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>
>> If "there is no problem with not passing a particular test from the EL
>> spec" then there is no problem with not passing a particular test from
>> the CDI spec at EE level which seems wrong to me.
>>
>> Globally I'd just remove this test and keep it in Weld vendor specific
>> features.
>>
>> @martin: my 1) was for EL spec not CDI.
>>
>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>> is a property of conversation which is a property of context which is
>> a property of enterprise which is a property of javax which is clearly
>> not what is desired and opposed to what is in the CDI spec.
>
>
> Sure. But EL cannot test this. From it's point of view the
> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
> point of view the name is wrong and cannot be used as it is...
>
>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>
>>> I agree with Martin. We *should* fix this situation in the long term,
>>> which
>>> is what I proposed. However in the short term there is no problem with
>>> not
>>> passing a particular test from the EL spec. Additionally this is provably
>>> implementable as Weld implements this, and many Java EE containers pass.
>>> As
>>> there are no other spec defined beans javax, then we do not conflict with
>>> any other spec by implementing it this way.
>>>
>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>
>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>
>>> well there are 2 points:
>>> 1) a test should be added for it
>>>
>>>
>>> There was a CDI TCK test since 1.1
>>>
>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>> It has been modified a week ago (see also CDITCK-462) not to use
>>> "javax.enterprise.context.conversation.id".
>>>
>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>> + tests themselve)
>>>
>>> So if there is this test a container can't be certified for EL + CDI
>>> at the same time
>>>
>>>
>>> I don't think it's a problem. An EL TCK test can't evaluate
>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>> it's obviously legal. The problem is
>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>> name. If it is, a workaround is needed (see also
>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>
>>> Which EL test?
>>>
>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>> wrote:
>>>
>>> then it will not pass EL one
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>
>>> No, a Java EE container needs to pass this test.
>>>
>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>> wrote:
>>>
>>> so it means a JavaEE container will not pass this test but it is not an
>>> issue?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>
>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>> this,
>>> and it is supportable.
>>>
>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>
>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>> correct?
>>>
>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>
>>> We need to go for both (A) and (B).
>>>
>>> We would need to deprecate the existing name before we can allow it to
>>> not
>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>> add
>>> an alternative that can be used, and then consider removing it in CDI 3.
>>> In
>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>> more
>>> carefully.
>>>
>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>> wrote:
>>>
>>> +1 for B (IMO it is not used that much)
>>>
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>
>>> I think further action is needed on this. Now that it has been confirmed
>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>> name we should either:
>>>
>>> A) Require all CDI implementations to adapt the property-based approach
>>> which allows this to be implemented portably (as Weld does)
>>> B) Declare publicly that although the CDI spec declares the given name,
>>> it is a bug and applications should not use the name. (What about
>>> compatibility with existing applications?)
>>>
>>> Jozef
>>>
>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>
>>> Dear CDI fellows!
>>>
>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>
>>> Ed, thanks for helping us!
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>> wrote:
>>>
>>> Hello Mark,
>>>
>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>> must
>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>> ago in the EL 3.0 EG.
>>>
>>> Ed
>>>
>>> --
>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>> | 42 days til DevNexus 2015
>>> | 52 days til JavaLand 2015
>>> | 62 days til CONFESS 2015
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual
>>> property rights inherent in such information.
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual
>>> property rights inherent in such information.
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual
>>> property rights inherent in such information.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual
>>> property rights inherent in such information.
>>>
>>>
>


From pmuir at redhat.com  Wed Jan 14 08:28:58 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 13:28:58 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
	<CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
Message-ID: <4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>

I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it.

> On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> well issue is when you activate EL + CDI, if you respect both specs
> #{javax.enterprise.context.conversation.id} should fail - agree we can
> always use the *workaround* of Weld but this is actually not mandated
> by any spec excepted this test which was IMO an interpolation. That's
> why i think this test shouldnt be kept even for 1.x versions.
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>> 
>>> If "there is no problem with not passing a particular test from the EL
>>> spec" then there is no problem with not passing a particular test from
>>> the CDI spec at EE level which seems wrong to me.
>>> 
>>> Globally I'd just remove this test and keep it in Weld vendor specific
>>> features.
>>> 
>>> @martin: my 1) was for EL spec not CDI.
>>> 
>>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>>> is a property of conversation which is a property of context which is
>>> a property of enterprise which is a property of javax which is clearly
>>> not what is desired and opposed to what is in the CDI spec.
>> 
>> 
>> Sure. But EL cannot test this. From it's point of view the
>> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
>> point of view the name is wrong and cannot be used as it is...
>> 
>> 
>>> 
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> 
>>> 
>>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> 
>>>> I agree with Martin. We *should* fix this situation in the long term,
>>>> which
>>>> is what I proposed. However in the short term there is no problem with
>>>> not
>>>> passing a particular test from the EL spec. Additionally this is provably
>>>> implementable as Weld implements this, and many Java EE containers pass.
>>>> As
>>>> there are no other spec defined beans javax, then we do not conflict with
>>>> any other spec by implementing it this way.
>>>> 
>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>> 
>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>> 
>>>> well there are 2 points:
>>>> 1) a test should be added for it
>>>> 
>>>> 
>>>> There was a CDI TCK test since 1.1
>>>> 
>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>> It has been modified a week ago (see also CDITCK-462) not to use
>>>> "javax.enterprise.context.conversation.id".
>>>> 
>>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>> + tests themselve)
>>>> 
>>>> So if there is this test a container can't be certified for EL + CDI
>>>> at the same time
>>>> 
>>>> 
>>>> I don't think it's a problem. An EL TCK test can't evaluate
>>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>>> it's obviously legal. The problem is
>>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>>> name. If it is, a workaround is needed (see also
>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>> 
>>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> 
>>>> Which EL test?
>>>> 
>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> wrote:
>>>> 
>>>> then it will not pass EL one
>>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> 
>>>> No, a Java EE container needs to pass this test.
>>>> 
>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> wrote:
>>>> 
>>>> so it means a JavaEE container will not pass this test but it is not an
>>>> issue?
>>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> 
>>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>>> this,
>>>> and it is supportable.
>>>> 
>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>> 
>>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>>> correct?
>>>> 
>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>> 
>>>> We need to go for both (A) and (B).
>>>> 
>>>> We would need to deprecate the existing name before we can allow it to
>>>> not
>>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>> add
>>>> an alternative that can be used, and then consider removing it in CDI 3.
>>>> In
>>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>>> more
>>>> carefully.
>>>> 
>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> wrote:
>>>> 
>>>> +1 for B (IMO it is not used that much)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>> 
>>>> I think further action is needed on this. Now that it has been confirmed
>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>> name we should either:
>>>> 
>>>> A) Require all CDI implementations to adapt the property-based approach
>>>> which allows this to be implemented portably (as Weld does)
>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>> it is a bug and applications should not use the name. (What about
>>>> compatibility with existing applications?)
>>>> 
>>>> Jozef
>>>> 
>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>> 
>>>> Dear CDI fellows!
>>>> 
>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>> 
>>>> Ed, thanks for helping us!
>>>> 
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>>> wrote:
>>>> 
>>>> Hello Mark,
>>>> 
>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>> must
>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>> ago in the EL 3.0 EG.
>>>> 
>>>> Ed
>>>> 
>>>> --
>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>> | 42 days til DevNexus 2015
>>>> | 52 days til JavaLand 2015
>>>> | 62 days til CONFESS 2015
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided on this list, the provider waives all patent and other
>>>> intellectual
>>>> property rights inherent in such information.
>>>> 
>>>> 
>> 



From rmannibucau at gmail.com  Wed Jan 14 08:31:27 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 14:31:27 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
	<CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
	<4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>
Message-ID: <CACLE=7M2nEWw6+WvW-M=Yd=FVz2Q2v7WmFb7wKaxTJZESmWJpw@mail.gmail.com>

Well ATM there is no requirement it works and I'm convinced another
(better) solution will be found for coming versions so I would really
avoid to introduce a workaround on which users will not be able to
rely. Also Weld implementation breaks some valid usages of EL (since
it is not done for javax only, right?).


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
> I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it.
>
>> On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> well issue is when you activate EL + CDI, if you respect both specs
>> #{javax.enterprise.context.conversation.id} should fail - agree we can
>> always use the *workaround* of Weld but this is actually not mandated
>> by any spec excepted this test which was IMO an interpolation. That's
>> why i think this test shouldnt be kept even for 1.x versions.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>
>>>> If "there is no problem with not passing a particular test from the EL
>>>> spec" then there is no problem with not passing a particular test from
>>>> the CDI spec at EE level which seems wrong to me.
>>>>
>>>> Globally I'd just remove this test and keep it in Weld vendor specific
>>>> features.
>>>>
>>>> @martin: my 1) was for EL spec not CDI.
>>>>
>>>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>>>> is a property of conversation which is a property of context which is
>>>> a property of enterprise which is a property of javax which is clearly
>>>> not what is desired and opposed to what is in the CDI spec.
>>>
>>>
>>> Sure. But EL cannot test this. From it's point of view the
>>> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
>>> point of view the name is wrong and cannot be used as it is...
>>>
>>>
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>> I agree with Martin. We *should* fix this situation in the long term,
>>>>> which
>>>>> is what I proposed. However in the short term there is no problem with
>>>>> not
>>>>> passing a particular test from the EL spec. Additionally this is provably
>>>>> implementable as Weld implements this, and many Java EE containers pass.
>>>>> As
>>>>> there are no other spec defined beans javax, then we do not conflict with
>>>>> any other spec by implementing it this way.
>>>>>
>>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>>>
>>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>
>>>>> well there are 2 points:
>>>>> 1) a test should be added for it
>>>>>
>>>>>
>>>>> There was a CDI TCK test since 1.1
>>>>>
>>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>> It has been modified a week ago (see also CDITCK-462) not to use
>>>>> "javax.enterprise.context.conversation.id".
>>>>>
>>>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>>> + tests themselve)
>>>>>
>>>>> So if there is this test a container can't be certified for EL + CDI
>>>>> at the same time
>>>>>
>>>>>
>>>>> I don't think it's a problem. An EL TCK test can't evaluate
>>>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>>>> it's obviously legal. The problem is
>>>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>>>> name. If it is, a workaround is needed (see also
>>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>> Which EL test?
>>>>>
>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>> wrote:
>>>>>
>>>>> then it will not pass EL one
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>> No, a Java EE container needs to pass this test.
>>>>>
>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>> wrote:
>>>>>
>>>>> so it means a JavaEE container will not pass this test but it is not an
>>>>> issue?
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>>>> this,
>>>>> and it is supportable.
>>>>>
>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>
>>>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>>>> correct?
>>>>>
>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>
>>>>> We need to go for both (A) and (B).
>>>>>
>>>>> We would need to deprecate the existing name before we can allow it to
>>>>> not
>>>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>>> add
>>>>> an alternative that can be used, and then consider removing it in CDI 3.
>>>>> In
>>>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>>>> more
>>>>> carefully.
>>>>>
>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>> wrote:
>>>>>
>>>>> +1 for B (IMO it is not used that much)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>
>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>> name we should either:
>>>>>
>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>> which allows this to be implemented portably (as Weld does)
>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>> it is a bug and applications should not use the name. (What about
>>>>> compatibility with existing applications?)
>>>>>
>>>>> Jozef
>>>>>
>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>
>>>>> Dear CDI fellows!
>>>>>
>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>
>>>>> Ed, thanks for helping us!
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hello Mark,
>>>>>
>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>> must
>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>> ago in the EL 3.0 EG.
>>>>>
>>>>> Ed
>>>>>
>>>>> --
>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>> | 42 days til DevNexus 2015
>>>>> | 52 days til JavaLand 2015
>>>>> | 62 days til CONFESS 2015
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code
>>>>> under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code
>>>>> under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code
>>>>> under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>>>> code
>>>>> under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided on this list, the provider waives all patent and other
>>>>> intellectual
>>>>> property rights inherent in such information.
>>>>>
>>>>>
>>>
>


From pmuir at redhat.com  Wed Jan 14 08:35:29 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 13:35:29 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7M2nEWw6+WvW-M=Yd=FVz2Q2v7WmFb7wKaxTJZESmWJpw@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
	<CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
	<4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>
	<CACLE=7M2nEWw6+WvW!
	-M=Yd=FVz2Q2v7WmFb7wKaxTJZESmWJpw@mail.gmail.com>
Message-ID: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>


> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> Well ATM there is no requirement it works

There is a requirement that everything in the spec should work, yes.

> and I'm convinced another
> (better) solution will be found for coming versions

Yes, but we still have to implement the existing spec as it stands.

> so I would really
> avoid to introduce a workaround on which users will not be able to
> rely.

This has been a requirement since version 1.0, a number of years. How has OWB managed to not be compliant with this to date?

> Also Weld implementation breaks some valid usages of EL (since
> it is not done for javax only, right?).

For example?

> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it.
>> 
>>> On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>> 
>>> well issue is when you activate EL + CDI, if you respect both specs
>>> #{javax.enterprise.context.conversation.id} should fail - agree we can
>>> always use the *workaround* of Weld but this is actually not mandated
>>> by any spec excepted this test which was IMO an interpolation. That's
>>> why i think this test shouldnt be kept even for 1.x versions.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> 
>>> 
>>> 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>> 
>>>>> If "there is no problem with not passing a particular test from the EL
>>>>> spec" then there is no problem with not passing a particular test from
>>>>> the CDI spec at EE level which seems wrong to me.
>>>>> 
>>>>> Globally I'd just remove this test and keep it in Weld vendor specific
>>>>> features.
>>>>> 
>>>>> @martin: my 1) was for EL spec not CDI.
>>>>> 
>>>>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>> is a property of conversation which is a property of context which is
>>>>> a property of enterprise which is a property of javax which is clearly
>>>>> not what is desired and opposed to what is in the CDI spec.
>>>> 
>>>> 
>>>> Sure. But EL cannot test this. From it's point of view the
>>>> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
>>>> point of view the name is wrong and cannot be used as it is...
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>> 
>>>>> 
>>>>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> I agree with Martin. We *should* fix this situation in the long term,
>>>>>> which
>>>>>> is what I proposed. However in the short term there is no problem with
>>>>>> not
>>>>>> passing a particular test from the EL spec. Additionally this is provably
>>>>>> implementable as Weld implements this, and many Java EE containers pass.
>>>>>> As
>>>>>> there are no other spec defined beans javax, then we do not conflict with
>>>>>> any other spec by implementing it this way.
>>>>>> 
>>>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>>>> 
>>>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>> 
>>>>>> well there are 2 points:
>>>>>> 1) a test should be added for it
>>>>>> 
>>>>>> 
>>>>>> There was a CDI TCK test since 1.1
>>>>>> 
>>>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>> It has been modified a week ago (see also CDITCK-462) not to use
>>>>>> "javax.enterprise.context.conversation.id".
>>>>>> 
>>>>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>>>> + tests themselve)
>>>>>> 
>>>>>> So if there is this test a container can't be certified for EL + CDI
>>>>>> at the same time
>>>>>> 
>>>>>> 
>>>>>> I don't think it's a problem. An EL TCK test can't evaluate
>>>>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>>>>> it's obviously legal. The problem is
>>>>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>>>>> name. If it is, a workaround is needed (see also
>>>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> Which EL test?
>>>>>> 
>>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> then it will not pass EL one
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> No, a Java EE container needs to pass this test.
>>>>>> 
>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> so it means a JavaEE container will not pass this test but it is not an
>>>>>> issue?
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>>>>> this,
>>>>>> and it is supportable.
>>>>>> 
>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>> 
>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>>>>> correct?
>>>>>> 
>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>> 
>>>>>> We need to go for both (A) and (B).
>>>>>> 
>>>>>> We would need to deprecate the existing name before we can allow it to
>>>>>> not
>>>>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>>>> add
>>>>>> an alternative that can be used, and then consider removing it in CDI 3.
>>>>>> In
>>>>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>>>>> more
>>>>>> carefully.
>>>>>> 
>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> +1 for B (IMO it is not used that much)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>> 
>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>> name we should either:
>>>>>> 
>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>> it is a bug and applications should not use the name. (What about
>>>>>> compatibility with existing applications?)
>>>>>> 
>>>>>> Jozef
>>>>>> 
>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>> 
>>>>>> Dear CDI fellows!
>>>>>> 
>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>> 
>>>>>> Ed, thanks for helping us!
>>>>>> 
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>>>>> wrote:
>>>>>> 
>>>>>> Hello Mark,
>>>>>> 
>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>> must
>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>> ago in the EL 3.0 EG.
>>>>>> 
>>>>>> Ed
>>>>>> 
>>>>>> --
>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>> | 42 days til DevNexus 2015
>>>>>> | 52 days til JavaLand 2015
>>>>>> | 62 days til CONFESS 2015
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>> code
>>>>>> under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided on this list, the provider waives all patent and other
>>>>>> intellectual
>>>>>> property rights inherent in such information.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>> code
>>>>>> under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided on this list, the provider waives all patent and other
>>>>>> intellectual
>>>>>> property rights inherent in such information.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>> code
>>>>>> under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided on this list, the provider waives all patent and other
>>>>>> intellectual
>>>>>> property rights inherent in such information.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>> code
>>>>>> under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided on this list, the provider waives all patent and other
>>>>>> intellectual
>>>>>> property rights inherent in such information.
>>>>>> 
>>>>>> 
>>>> 
>> 



From rmannibucau at gmail.com  Wed Jan 14 08:48:06 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 14:48:06 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
	<CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
	<4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>
	<CACLE=7M2nEWw6+WvW-M=Yd=FVz2Q2v7WmFb7wKaxTJZESmWJpw@mail.gmail.com>
	<961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
Message-ID: <CACLE=7Og22VWVPuy7pUL=qPHDrYo5QpNLAHN_rSjc5R=Oxrj0w@mail.gmail.com>

2015-01-14 14:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>
>> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>
>> Well ATM there is no requirement it works
>
> There is a requirement that everything in the spec should work, yes.
>

Well requirement is only due to the test and we can say as much it is
a requirement as it is a bug so 0-0 IMO.

>> and I'm convinced another
>> (better) solution will be found for coming versions
>
> Yes, but we still have to implement the existing spec as it stands.
>
>> so I would really
>> avoid to introduce a workaround on which users will not be able to
>> rely.
>
> This has been a requirement since version 1.0, a number of years. How has OWB managed to not be compliant with this to date?
>

That's an open point, I guess it can be linked to the categories used
in TCKs - some normal tests are in full profile - but I didnt dig into
it to be honest, it can also be it is a new test.

>> Also Weld implementation breaks some valid usages of EL (since
>> it is not done for javax only, right?).
>
> For example?
>

1) If you already have a custom ELResolver doing it (a spring one randomly ;))
2) depending the registration ordering of your resolver you can
conflict with default BeanResolver

>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>> I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it.
>>>
>>>> On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>
>>>> well issue is when you activate EL + CDI, if you respect both specs
>>>> #{javax.enterprise.context.conversation.id} should fail - agree we can
>>>> always use the *workaround* of Weld but this is actually not mandated
>>>> by any spec excepted this test which was IMO an interpolation. That's
>>>> why i think this test shouldnt be kept even for 1.x versions.
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>>
>>>>>> If "there is no problem with not passing a particular test from the EL
>>>>>> spec" then there is no problem with not passing a particular test from
>>>>>> the CDI spec at EE level which seems wrong to me.
>>>>>>
>>>>>> Globally I'd just remove this test and keep it in Weld vendor specific
>>>>>> features.
>>>>>>
>>>>>> @martin: my 1) was for EL spec not CDI.
>>>>>>
>>>>>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>> is a property of conversation which is a property of context which is
>>>>>> a property of enterprise which is a property of javax which is clearly
>>>>>> not what is desired and opposed to what is in the CDI spec.
>>>>>
>>>>>
>>>>> Sure. But EL cannot test this. From it's point of view the
>>>>> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
>>>>> point of view the name is wrong and cannot be used as it is...
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>
>>>>>>> I agree with Martin. We *should* fix this situation in the long term,
>>>>>>> which
>>>>>>> is what I proposed. However in the short term there is no problem with
>>>>>>> not
>>>>>>> passing a particular test from the EL spec. Additionally this is provably
>>>>>>> implementable as Weld implements this, and many Java EE containers pass.
>>>>>>> As
>>>>>>> there are no other spec defined beans javax, then we do not conflict with
>>>>>>> any other spec by implementing it this way.
>>>>>>>
>>>>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>>>>>
>>>>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>>
>>>>>>> well there are 2 points:
>>>>>>> 1) a test should be added for it
>>>>>>>
>>>>>>>
>>>>>>> There was a CDI TCK test since 1.1
>>>>>>>
>>>>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>> It has been modified a week ago (see also CDITCK-462) not to use
>>>>>>> "javax.enterprise.context.conversation.id".
>>>>>>>
>>>>>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>>>>> + tests themselve)
>>>>>>>
>>>>>>> So if there is this test a container can't be certified for EL + CDI
>>>>>>> at the same time
>>>>>>>
>>>>>>>
>>>>>>> I don't think it's a problem. An EL TCK test can't evaluate
>>>>>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>>>>>> it's obviously legal. The problem is
>>>>>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>>>>>> name. If it is, a workaround is needed (see also
>>>>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>
>>>>>>> Which EL test?
>>>>>>>
>>>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> then it will not pass EL one
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>
>>>>>>> No, a Java EE container needs to pass this test.
>>>>>>>
>>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> so it means a JavaEE container will not pass this test but it is not an
>>>>>>> issue?
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>
>>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>>>>>> this,
>>>>>>> and it is supportable.
>>>>>>>
>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>
>>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>>>>>> correct?
>>>>>>>
>>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>
>>>>>>> We need to go for both (A) and (B).
>>>>>>>
>>>>>>> We would need to deprecate the existing name before we can allow it to
>>>>>>> not
>>>>>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>>>>> add
>>>>>>> an alternative that can be used, and then consider removing it in CDI 3.
>>>>>>> In
>>>>>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>>>>>> more
>>>>>>> carefully.
>>>>>>>
>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>
>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>> name we should either:
>>>>>>>
>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>> compatibility with existing applications?)
>>>>>>>
>>>>>>> Jozef
>>>>>>>
>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>
>>>>>>> Dear CDI fellows!
>>>>>>>
>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>
>>>>>>> Ed, thanks for helping us!
>>>>>>>
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello Mark,
>>>>>>>
>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>> must
>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>> ago in the EL 3.0 EG.
>>>>>>>
>>>>>>> Ed
>>>>>>>
>>>>>>> --
>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>> | 42 days til DevNexus 2015
>>>>>>> | 52 days til JavaLand 2015
>>>>>>> | 62 days til CONFESS 2015
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>> code
>>>>>>> under the Apache License, Version 2
>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>>> property rights inherent in such information.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>> code
>>>>>>> under the Apache License, Version 2
>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>>> property rights inherent in such information.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>> code
>>>>>>> under the Apache License, Version 2
>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>>> property rights inherent in such information.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>> code
>>>>>>> under the Apache License, Version 2
>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>>> property rights inherent in such information.
>>>>>>>
>>>>>>>
>>>>>
>>>
>


From pmuir at redhat.com  Wed Jan 14 09:36:42 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 14:36:42 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7Og22VWVPuy7pUL=qPHDrYo5QpNLAHN_rSjc5R=Oxrj0w@mail.gmail.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<CACLE=7OvDghdJcbXCVgZZ8u2rgQ3FxQaV7gnstGie=N1Awsrfw@mail.gmail.com>
	<54B66A88.4050701@redhat.com>
	<CACLE=7PbM=3JS3YdxWO32ZrnB3s7Fu3jbg82Q8wv_-1tBDEbag@mail.gmail.com>
	<4961EBE2-F3D9-4E27-B7D7-B1F82F3C6597@redhat.com>
	<CACLE=7M2nEWw6+WvW!
	-M=Yd=FVz2Q2v7WmFb7wKaxTJZESmWJpw@mail.gmail.com>
	<961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
	<CACLE=7Og22VWVPuy7pUL=qPHDrYo5QpNLAHN_rSjc5R=Oxrj0w@mail.gmail.com>
Message-ID: <BA22E835-F433-4E8F-8AE1-9DD2A4F87DFC@redhat.com>

Yeah, it?s arguable both ways. However my view is that given there is no test in EL which is failing, there is a test in CDI that is failing, and it is implementable, that we shouldn?t accept this TCK challenge.

That said, I agree the situation isn?t good, so we should fix it in a way that doesn?t cause existing users disruption, by deprecating it, and then considering removing it. I don?t feel that just dumping it is a good solution for users.

> On 14 Jan 2015, at 13:48, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> 2015-01-14 14:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>> 
>>> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>> 
>>> Well ATM there is no requirement it works
>> 
>> There is a requirement that everything in the spec should work, yes.
>> 
> 
> Well requirement is only due to the test and we can say as much it is
> a requirement as it is a bug so 0-0 IMO.
> 
>>> and I'm convinced another
>>> (better) solution will be found for coming versions
>> 
>> Yes, but we still have to implement the existing spec as it stands.
>> 
>>> so I would really
>>> avoid to introduce a workaround on which users will not be able to
>>> rely.
>> 
>> This has been a requirement since version 1.0, a number of years. How has OWB managed to not be compliant with this to date?
>> 
> 
> That's an open point, I guess it can be linked to the categories used
> in TCKs - some normal tests are in full profile - but I didnt dig into
> it to be honest, it can also be it is a new test.
> 
>>> Also Weld implementation breaks some valid usages of EL (since
>>> it is not done for javax only, right?).
>> 
>> For example?
>> 
> 
> 1) If you already have a custom ELResolver doing it (a spring one randomly ;))
> 2) depending the registration ordering of your resolver you can
> conflict with default BeanResolver
> 
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>> 
>>> 
>>> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it.
>>>> 
>>>>> On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>> 
>>>>> well issue is when you activate EL + CDI, if you respect both specs
>>>>> #{javax.enterprise.context.conversation.id} should fail - agree we can
>>>>> always use the *workaround* of Weld but this is actually not mandated
>>>>> by any spec excepted this test which was IMO an interpolation. That's
>>>>> why i think this test shouldnt be kept even for 1.x versions.
>>>>> 
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>> 
>>>>> 
>>>>> 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>> Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>>> 
>>>>>>> If "there is no problem with not passing a particular test from the EL
>>>>>>> spec" then there is no problem with not passing a particular test from
>>>>>>> the CDI spec at EE level which seems wrong to me.
>>>>>>> 
>>>>>>> Globally I'd just remove this test and keep it in Weld vendor specific
>>>>>>> features.
>>>>>>> 
>>>>>>> @martin: my 1) was for EL spec not CDI.
>>>>>>> 
>>>>>>> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>> is a property of conversation which is a property of context which is
>>>>>>> a property of enterprise which is a property of javax which is clearly
>>>>>>> not what is desired and opposed to what is in the CDI spec.
>>>>>> 
>>>>>> 
>>>>>> Sure. But EL cannot test this. From it's point of view the
>>>>>> "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI
>>>>>> point of view the name is wrong and cannot be used as it is...
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau
>>>>>>> http://www.tomitribe.com
>>>>>>> http://rmannibucau.wordpress.com
>>>>>>> https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> I agree with Martin. We *should* fix this situation in the long term,
>>>>>>>> which
>>>>>>>> is what I proposed. However in the short term there is no problem with
>>>>>>>> not
>>>>>>>> passing a particular test from the EL spec. Additionally this is provably
>>>>>>>> implementable as Weld implements this, and many Java EE containers pass.
>>>>>>>> As
>>>>>>>> there are no other spec defined beans javax, then we do not conflict with
>>>>>>>> any other spec by implementing it this way.
>>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>>>>>>> 
>>>>>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>>> 
>>>>>>>> well there are 2 points:
>>>>>>>> 1) a test should be added for it
>>>>>>>> 
>>>>>>>> 
>>>>>>>> There was a CDI TCK test since 1.1
>>>>>>>> 
>>>>>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>> It has been modified a week ago (see also CDITCK-462) not to use
>>>>>>>> "javax.enterprise.context.conversation.id".
>>>>>>>> 
>>>>>>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>>>>>> + tests themselve)
>>>>>>>> 
>>>>>>>> So if there is this test a container can't be certified for EL + CDI
>>>>>>>> at the same time
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I don't think it's a problem. An EL TCK test can't evaluate
>>>>>>>> "#{javax.enterprise.context.conversation.id}" as an illegal expression -
>>>>>>>> it's obviously legal. The problem is
>>>>>>>> "javax.enterprise.context.conversation.id" can't be simply used as a bean
>>>>>>>> name. If it is, a workaround is needed (see also
>>>>>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> Which EL test?
>>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> then it will not pass EL one
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> No, a Java EE container needs to pass this test.
>>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> so it means a JavaEE container will not pass this test but it is not an
>>>>>>>> issue?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about
>>>>>>>> this,
>>>>>>>> and it is supportable.
>>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>> 
>>>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all,
>>>>>>>> correct?
>>>>>>>> 
>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>> 
>>>>>>>> We need to go for both (A) and (B).
>>>>>>>> 
>>>>>>>> We would need to deprecate the existing name before we can allow it to
>>>>>>>> not
>>>>>>>> be supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>>>>>> add
>>>>>>>> an alternative that can be used, and then consider removing it in CDI 3.
>>>>>>>> In
>>>>>>>> the meantime for CDI 2, we will need to improve the TCK to check this
>>>>>>>> more
>>>>>>>> carefully.
>>>>>>>> 
>>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>> 
>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>> name we should either:
>>>>>>>> 
>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>> compatibility with existing applications?)
>>>>>>>> 
>>>>>>>> Jozef
>>>>>>>> 
>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>> 
>>>>>>>> Dear CDI fellows!
>>>>>>>> 
>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>> 
>>>>>>>> Ed, thanks for helping us!
>>>>>>>> 
>>>>>>>> 
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hello Mark,
>>>>>>>> 
>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>> must
>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>> 
>>>>>>>> Ed
>>>>>>>> 
>>>>>>>> --
>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>>> code
>>>>>>>> under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>>>> property rights inherent in such information.
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>>> code
>>>>>>>> under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>>>> property rights inherent in such information.
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>>> code
>>>>>>>> under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>>>> property rights inherent in such information.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> Note that for all code provided on this list, the provider licenses the
>>>>>>>> code
>>>>>>>> under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>>> provided on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>>>> property rights inherent in such information.
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 



From struberg at yahoo.de  Wed Jan 14 10:43:57 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:43:57 +0000 (UTC)
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <54B63CCC.3080208@redhat.com>
References: <54B63CCC.3080208@redhat.com>
Message-ID: <2030236645.1125720.1421250237191.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>

C'mon Jozef, your approach is NOT portable. This will trash all other javax ELResolvers. You fix a broken CDI paragraph by utterly and finally breaking another framework. That's just no solution.

LieGrue,
strub




----- Original Message -----
> From: Jozef Hartinger <jharting at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>; Cdi-dev <cdi-dev at lists.jboss.org>
> Cc: Edward Burns <edward.burns at oracle.com>
> Sent: Wednesday, 14 January 2015, 10:54
> Subject: Re: [cdi-dev] Fw: Answer from EL spec lead: no, "." is not valid in an EL name.
> 
> I think further action is needed on this. Now that it has been confirmed 
> that "javax.enterprise.context.conversation" itself is not a valid EL 
> name we should either:
> 
> A) Require all CDI implementations to adapt the property-based approach 
> which allows this to be implemented portably (as Weld does)
> B) Declare publicly that although the CDI spec declares the given name, 
> it is a bug and applications should not use the name. (What about 
> compatibility with existing applications?)
> 
> Jozef
> 
> 
> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>  Dear CDI fellows!
>> 
>>  I've received an answer regarding our EL question from the EL Spec 
> Lead.
>> 
>>  Ed, thanks for helping us!
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> <edward.burns at oracle.com> wrote:
>>>>  Hello Mark,
>>>  To close this out, no, "." is not valid in an EL name.  An EL 
> name
>>>  must
>>>  be a java identifier.  I'm told this was discussed by Pete a long 
> time
>>>  ago in the EL 3.0 EG.
>>> 
>>>  Ed
>>> 
>>>  -- 
>>>  | edward.burns at oracle.com | office: +1 407 458 0017
>>>  | 42 days til DevNexus 2015
>>>  | 52 days til JavaLand 2015
>>>  | 62 days til CONFESS 2015
>>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From struberg at yahoo.de  Wed Jan 14 10:45:17 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:45:17 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
References: <231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
Message-ID: <647471825.1124217.1421250317312.JavaMail.yahoo@jws11129.mail.ir2.yahoo.com>

And then break all applications which have a @Named("javax") public class MyBean?
It's simply not an option imo. It breaks lots of other specs and features. This is an XOR situation. 


LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns <edward.burns at oracle.com>
> Sent: Wednesday, 14 January 2015, 11:56
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> We need to go for both (A) and (B).
> 
> We would need to deprecate the existing name before we can allow it to not be 
> supported. This means CDI 3. So I would suggest we deprecate it in 2, add an 
> alternative that can be used, and then consider removing it in CDI 3. In the 
> meantime for CDI 2, we will need to improve the TCK to check this more 
> carefully.
> 
>>  On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> 
> wrote:
>> 
>>  +1 for B (IMO it is not used that much)
>> 
>> 
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>  I think further action is needed on this. Now that it has been 
> confirmed
>>>  that "javax.enterprise.context.conversation" itself is not a 
> valid EL
>>>  name we should either:
>>> 
>>>  A) Require all CDI implementations to adapt the property-based approach
>>>  which allows this to be implemented portably (as Weld does)
>>>  B) Declare publicly that although the CDI spec declares the given name,
>>>  it is a bug and applications should not use the name. (What about
>>>  compatibility with existing applications?)
>>> 
>>>  Jozef
>>> 
>>>  On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>  Dear CDI fellows!
>>>> 
>>>>  I've received an answer regarding our EL question from the EL 
> Spec Lead.
>>>> 
>>>>  Ed, thanks for helping us!
>>>> 
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> <edward.burns at oracle.com> wrote:
>>>>>>  Hello Mark,
>>>>>  To close this out, no, "." is not valid in an EL 
> name.  An EL name
>>>>>  must
>>>>>  be a java identifier.  I'm told this was discussed by Pete 
> a long time
>>>>>  ago in the EL 3.0 EG.
>>>>> 
>>>>>  Ed
>>>>> 
>>>>>  --
>>>>>  | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>  | 42 days til DevNexus 2015
>>>>>  | 52 days til JavaLand 2015
>>>>>  | 62 days til CONFESS 2015
>>>>> 
>>>>  _______________________________________________
>>>>  cdi-dev mailing list
>>>>  cdi-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>  Note that for all code provided on this list, the provider licenses 
> the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>> 
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 
>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From struberg at yahoo.de  Wed Jan 14 10:46:51 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:46:51 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
References: <84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
Message-ID: <1286498444.1123082.1421250411752.JavaMail.yahoo@jws11130.mail.ir2.yahoo.com>

The spec only says that the Bean must have this name. All the rest is some 3-rd level 'implicit' arguing. The spec does NOT say that the EL "javax...." must give you a Conversation...

LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Jozef Hartinger <jharting at redhat.com>
> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 12:20
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> I don?t think they should be excluded. The spec isn?t ambiguous about this, and 
> it is supportable.
> 
> 
>>  On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> 
> wrote:
>> 
>>  So for CDI 1.2 the test that tests this should not be excluded after all, 
> correct?
>> 
>>  On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>  We need to go for both (A) and (B).
>>> 
>>>  We would need to deprecate the existing name before we can allow it to 
> not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add 
> an alternative that can be used, and then consider removing it in CDI 3. In the 
> meantime for CDI 2, we will need to improve the TCK to check this more 
> carefully.
>>> 
>>>>  On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>>>> 
>>>>  +1 for B (IMO it is not used that much)
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  Romain Manni-Bucau
>>>>  @rmannibucau
>>>>  http://www.tomitribe.com
>>>>  http://rmannibucau.wordpress.com
>>>>  https://github.com/rmannibucau
>>>> 
>>>> 
>>>>  2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
> <jharting at redhat.com>:
>>>>>  I think further action is needed on this. Now that it has been 
> confirmed
>>>>>  that "javax.enterprise.context.conversation" itself 
> is not a valid EL
>>>>>  name we should either:
>>>>> 
>>>>>  A) Require all CDI implementations to adapt the property-based 
> approach
>>>>>  which allows this to be implemented portably (as Weld does)
>>>>>  B) Declare publicly that although the CDI spec declares the 
> given name,
>>>>>  it is a bug and applications should not use the name. (What 
> about
>>>>>  compatibility with existing applications?)
>>>>> 
>>>>>  Jozef
>>>>> 
>>>>>  On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>  Dear CDI fellows!
>>>>>> 
>>>>>>  I've received an answer regarding our EL question from 
> the EL Spec Lead.
>>>>>> 
>>>>>>  Ed, thanks for helping us!
>>>>>> 
>>>>>> 
>>>>>>  LieGrue,
>>>>>>  strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> <edward.burns at oracle.com> wrote:
>>>>>>>>  Hello Mark,
>>>>>>>  To close this out, no, "." is not valid in an 
> EL name.  An EL name
>>>>>>>  must
>>>>>>>  be a java identifier.  I'm told this was discussed 
> by Pete a long time
>>>>>>>  ago in the EL 3.0 EG.
>>>>>>> 
>>>>>>>  Ed
>>>>>>> 
>>>>>>>  --
>>>>>>>  | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>  | 42 days til DevNexus 2015
>>>>>>>  | 52 days til JavaLand 2015
>>>>>>>  | 62 days til CONFESS 2015
>>>>>>> 
>>>>>>  _______________________________________________
>>>>>>  cdi-dev mailing list
>>>>>>  cdi-dev at lists.jboss.org
>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>>  Note that for all code provided on this list, the provider 
> licenses the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  cdi-dev at lists.jboss.org
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>  Note that for all code provided on this list, the provider 
> licenses the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>>>  _______________________________________________
>>>>  cdi-dev mailing list
>>>>  cdi-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>  Note that for all code provided on this list, the provider licenses 
> the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>


From struberg at yahoo.de  Wed Jan 14 10:49:19 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:49:19 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
References: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
Message-ID: <2068903319.1089178.1421250559745.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com>

No pete, the current Weld implementation breaks other CDI features! Sample with @Named("javax") already given in my other post...


It sucks, face it. And no one is using it anyway.

LieGrue,
strub




>________________________________
> From: Pete Muir <pmuir at redhat.com>
>To: Martin Kouba <mkouba at redhat.com> 
>Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org> 
>Sent: Wednesday, 14 January 2015, 13:12
>Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." is not valid in an EL name.
> 
>
>
>I agree with Martin. We *should* fix this situation in the long term, which is what I proposed. However in the short term there is no problem with not passing a particular test from the EL spec. Additionally this is provably implementable as Weld implements this, and many Java EE containers pass. As there are no other spec defined beans javax, then we do not conflict with any other spec by implementing it this way.
>
>
>
>>
>>
>>On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>
>>Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>
>>well there are 2 points:
>>>1) a test should be added for it
>>>
>>There was a CDI TCK test since 1.1 (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). It has been modified a week ago (see also CDITCK-462) not to use "javax.enterprise.context.conversation.id".
>>
>>
>>2) test or not being certified means respecting the spec (pdf, javadoc
>>>+ tests themselve)
>>>
>>>So if there is this test a container can't be certified for EL + CDI
>>>at the same time
>>>
>>I don't think it's a problem. An EL TCK test can't evaluate "#{javax.enterprise.context.conversation.id}" as an illegal expression - it's obviously legal. The problem is "javax.enterprise.context.conversation.id" can't be simply used as a bean name. If it is, a workaround is needed (see also http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>
>>
>>
>>>
>>>Romain Manni-Bucau
>>>@rmannibucau
>>>http://www.tomitribe.com
>>>http://rmannibucau.wordpress.com
>>>https://github.com/rmannibucau
>>>
>>>
>>>2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>
>>>Which EL test?
>>>>
>>>>
>>>>On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>
>>>>>then it will not pass EL one
>>>>>
>>>>>
>>>>>Romain Manni-Bucau
>>>>>@rmannibucau
>>>>>http://www.tomitribe.com
>>>>>http://rmannibucau.wordpress.com
>>>>>https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>>No, a Java EE container needs to pass this test.
>>>>>>
>>>>>>
>>>>>>On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>
>>>>>>>so it means a JavaEE container will not pass this test but it is not an issue?
>>>>>>>
>>>>>>>
>>>>>>>Romain Manni-Bucau
>>>>>>>@rmannibucau
>>>>>>>http://www.tomitribe.com
>>>>>>>http://rmannibucau.wordpress.com
>>>>>>>https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>
>>>>>>>I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>>>>>>
>>>>>>>>
>>>>>>>>On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>>>>>>
>>>>>>>>>On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>>
>>>>>>>>>We need to go for both (A) and (B).
>>>>>>>>>>
>>>>>>>>>>We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>+1 for B (IMO it is not used that much)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Romain Manni-Bucau
>>>>>>>>>>>@rmannibucau
>>>>>>>>>>>http://www.tomitribe.com
>>>>>>>>>>>http://rmannibucau.wordpress.com
>>>>>>>>>>>https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>>
>>>>>>>>>>>I think further action is needed on this. Now that it has been confirmed
>>>>>>>>>>>>that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>>>>name we should either:
>>>>>>>>>>>>
>>>>>>>>>>>>A) Require all CDI implementations to adapt the property-based approach
>>>>>>>>>>>>which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>>B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>>>>>>it is a bug and applications should not use the name. (What about
>>>>>>>>>>>>compatibility with existing applications?)
>>>>>>>>>>>>
>>>>>>>>>>>>Jozef
>>>>>>>>>>>>
>>>>>>>>>>>>On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>Dear CDI fellows!
>>>>>>>>>>>>>
>>>>>>>>>>>>>I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Ed, thanks for helping us!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>LieGrue,
>>>>>>>>>>>>>strub
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Hello Mark,
>>>>>>>>>>>>>>>To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>>>must
>>>>>>>>>>>>>>be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>>>ago in the EL 3.0 EG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Ed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>--
>>>>>>>>>>>>>>| edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>| 42 days til DevNexus 2015
>>>>>>>>>>>>>>| 52 days til JavaLand 2015
>>>>>>>>>>>>>>| 62 days til CONFESS 2015
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>>cdi-dev mailing list
>>>>>>>>>>>>>cdi-dev at lists.jboss.org
>>>>>>>>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>cdi-dev mailing list
>>>>>>>>>>>>cdi-dev at lists.jboss.org
>>>>>>>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>cdi-dev mailing list
>>>>>>>>>>>cdi-dev at lists.jboss.org
>>>>>>>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>_______________________________________________
>>>cdi-dev mailing list
>>>cdi-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>


From pmuir at redhat.com  Wed Jan 14 10:49:48 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 15:49:48 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <1286498444.1123082.1421250411752.JavaMail.yahoo@jws11130.mail.ir2.yahoo.com>
References: <84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<1286498444.1123082.1421250411752.JavaMail.yahoo@jws11130.mail.ir2.yahoo.com>
Message-ID: <806C1FF7-B74E-4878-A0E9-C75D1727E16A@redhat.com>

I?m afraid I disagree with the reasoning you present and your statements below.

> On 14 Jan 2015, at 15:46, Mark Struberg <struberg at yahoo.de> wrote:
> 
> The spec only says that the Bean must have this name. All the rest is some 3-rd level 'implicit' arguing. The spec does NOT say that the EL "javax...." must give you a Conversation...
> 
> LieGrue,
> strub
> 
> 
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Jozef Hartinger <jharting at redhat.com>
>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Wednesday, 14 January 2015, 12:20
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>> 
>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and 
>> it is supportable.
>> 
>> 
>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> 
>> wrote:
>>> 
>>> So for CDI 1.2 the test that tests this should not be excluded after all, 
>> correct?
>>> 
>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>> We need to go for both (A) and (B).
>>>> 
>>>> We would need to deprecate the existing name before we can allow it to 
>> not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add 
>> an alternative that can be used, and then consider removing it in CDI 3. In the 
>> meantime for CDI 2, we will need to improve the TCK to check this more 
>> carefully.
>>>> 
>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
>> <rmannibucau at gmail.com> wrote:
>>>>> 
>>>>> +1 for B (IMO it is not used that much)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>> 
>>>>> 
>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
>> <jharting at redhat.com>:
>>>>>> I think further action is needed on this. Now that it has been 
>> confirmed
>>>>>> that "javax.enterprise.context.conversation" itself 
>> is not a valid EL
>>>>>> name we should either:
>>>>>> 
>>>>>> A) Require all CDI implementations to adapt the property-based 
>> approach
>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>> B) Declare publicly that although the CDI spec declares the 
>> given name,
>>>>>> it is a bug and applications should not use the name. (What 
>> about
>>>>>> compatibility with existing applications?)
>>>>>> 
>>>>>> Jozef
>>>>>> 
>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>> Dear CDI fellows!
>>>>>>> 
>>>>>>> I've received an answer regarding our EL question from 
>> the EL Spec Lead.
>>>>>>> 
>>>>>>> Ed, thanks for helping us!
>>>>>>> 
>>>>>>> 
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns 
>> <edward.burns at oracle.com> wrote:
>>>>>>>>> Hello Mark,
>>>>>>>> To close this out, no, "." is not valid in an 
>> EL name.  An EL name
>>>>>>>> must
>>>>>>>> be a java identifier.  I'm told this was discussed 
>> by Pete a long time
>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>> 
>>>>>>>> Ed
>>>>>>>> 
>>>>>>>> --
>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>> Note that for all code provided on this list, the provider 
>> licenses the code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider 
>> licenses the code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>> Note that for all code provided on this list, the provider licenses 
>> the code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code 
>> under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>> 



From pmuir at redhat.com  Wed Jan 14 10:51:22 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 15:51:22 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <2068903319.1089178.1421250559745.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com>
References: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<2068903319.1089178.1421250559745.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com>
Message-ID: <BFEEF4CA-F5E9-4600-8D57-F6DC3600835D@redhat.com>

As previously stated I don?t agree with your arguments, and I don?t believe you can prove ?no one is using it?.

> On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> wrote:
> 
> No pete, the current Weld implementation breaks other CDI features! Sample with @Named("javax") already given in my other post...
> 
> 
> It sucks, face it. And no one is using it anyway.
> 
> LieGrue,
> strub
> 
> 
> 
> 
>> ________________________________
>> From: Pete Muir <pmuir at redhat.com>
>> To: Martin Kouba <mkouba at redhat.com> 
>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org> 
>> Sent: Wednesday, 14 January 2015, 13:12
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." is not valid in an EL name.
>> 
>> 
>> 
>> I agree with Martin. We *should* fix this situation in the long term, which is what I proposed. However in the short term there is no problem with not passing a particular test from the EL spec. Additionally this is provably implementable as Weld implements this, and many Java EE containers pass. As there are no other spec defined beans javax, then we do not conflict with any other spec by implementing it this way.
>> 
>> 
>> 
>>> 
>>> 
>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> wrote:
>>> 
>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>> 
>>> well there are 2 points:
>>>> 1) a test should be added for it
>>>> 
>>> There was a CDI TCK test since 1.1 (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). It has been modified a week ago (see also CDITCK-462) not to use "javax.enterprise.context.conversation.id".
>>> 
>>> 
>>> 2) test or not being certified means respecting the spec (pdf, javadoc
>>>> + tests themselve)
>>>> 
>>>> So if there is this test a container can't be certified for EL + CDI
>>>> at the same time
>>>> 
>>> I don't think it's a problem. An EL TCK test can't evaluate "#{javax.enterprise.context.conversation.id}" as an illegal expression - it's obviously legal. The problem is "javax.enterprise.context.conversation.id" can't be simply used as a bean name. If it is, a workaround is needed (see also http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>> 
>>> 
>>> 
>>>> 
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>> 
>>>> 
>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>> 
>>>> Which EL test?
>>>>> 
>>>>> 
>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>> 
>>>>>> then it will not pass EL one
>>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> No, a Java EE container needs to pass this test.
>>>>>>> 
>>>>>>> 
>>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> so it means a JavaEE container will not pass this test but it is not an issue?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> I don?t think they should be excluded. The spec isn?t ambiguous about this, and it is supportable.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> So for CDI 1.2 the test that tests this should not be excluded after all, correct?
>>>>>>>>>> 
>>>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>>> 
>>>>>>>>>> We need to go for both (A) and (B).
>>>>>>>>>>> 
>>>>>>>>>>> We would need to deprecate the existing name before we can allow it to not be supported. This means CDI 3. So I would suggest we deprecate it in 2, add an alternative that can be used, and then consider removing it in CDI 3. In the meantime for CDI 2, we will need to improve the TCK to check this more carefully.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> +1 for B (IMO it is not used that much)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>>> 
>>>>>>>>>>>> I think further action is needed on this. Now that it has been confirmed
>>>>>>>>>>>>> that "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>>>>> name we should either:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> A) Require all CDI implementations to adapt the property-based approach
>>>>>>>>>>>>> which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>>> B) Declare publicly that although the CDI spec declares the given name,
>>>>>>>>>>>>> it is a bug and applications should not use the name. (What about
>>>>>>>>>>>>> compatibility with existing applications?)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Jozef
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I've received an answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Ed, thanks for helping us!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tuesday, 6 January 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>>>>>>> To close this out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>>>> must
>>>>>>>>>>>>>>> be a java identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>>>> ago in the EL 3.0 EG.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ed
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>> | 42 days til DevNexus 2015
>>>>>>>>>>>>>>> | 52 days til JavaLand 2015
>>>>>>>>>>>>>>> | 62 days til CONFESS 2015
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>> 
>>>>>>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> 
>> 



From struberg at yahoo.de  Wed Jan 14 10:52:17 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:52:17 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
References: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
Message-ID: <2131057575.1107849.1421250737125.JavaMail.yahoo@jws11138.mail.ir2.yahoo.com>

>> Also Weld implementation breaks some valid usages of EL (since
>> it is not done for javax only, right?).
>
> For example?

@Named("javax")
public class MyService {..}

LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 14:35
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> 
>>  On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com> 
> wrote:
>> 
>>  Well ATM there is no requirement it works
> 
> There is a requirement that everything in the spec should work, yes.
> 
>>  and I'm convinced another
>>  (better) solution will be found for coming versions
> 
> Yes, but we still have to implement the existing spec as it stands.
> 
>>  so I would really
>>  avoid to introduce a workaround on which users will not be able to
>>  rely.
> 
> This has been a requirement since version 1.0, a number of years. How has OWB 
> managed to not be compliant with this to date?
> 
>>  Also Weld implementation breaks some valid usages of EL (since
>>  it is not done for javax only, right?).
> 
> For example?
> 
> 
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>  I think you need to use the workaround of Weld. It works, and 
> implements the spec as it stands, and means the test will pass. You can argue 
> that the spec is not written in such a way that requires this to work, but you 
> are splitting hairs at this point, and it was the intent of the 1.0 EG that it 
> would work the way Weld implemented it.
>>> 
>>>>  On 14 Jan 2015, at 13:13, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>>>> 
>>>>  well issue is when you activate EL + CDI, if you respect both specs
>>>>  #{javax.enterprise.context.conversation.id} should fail - 
> agree we can
>>>>  always use the *workaround* of Weld but this is actually not 
> mandated
>>>>  by any spec excepted this test which was IMO an interpolation. 
> That's
>>>>  why i think this test shouldnt be kept even for 1.x versions.
>>>> 
>>>> 
>>>>  Romain Manni-Bucau
>>>>  @rmannibucau
>>>>  http://www.tomitribe.com
>>>>  http://rmannibucau.wordpress.com
>>>>  https://github.com/rmannibucau
>>>> 
>>>> 
>>>>  2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>  Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>> 
>>>>>>  If "there is no problem with not passing a particular 
> test from the EL
>>>>>>  spec" then there is no problem with not passing a 
> particular test from
>>>>>>  the CDI spec at EE level which seems wrong to me.
>>>>>> 
>>>>>>  Globally I'd just remove this test and keep it in Weld 
> vendor specific
>>>>>>  features.
>>>>>> 
>>>>>>  @martin: my 1) was for EL spec not CDI.
>>>>>> 
>>>>>>  About 2 
> "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>  is a property of conversation which is a property of 
> context which is
>>>>>>  a property of enterprise which is a property of javax which 
> is clearly
>>>>>>  not what is desired and opposed to what is in the CDI spec.
>>>>> 
>>>>> 
>>>>>  Sure. But EL cannot test this. From it's point of view the
>>>>>  "#{javax.enterprise.context.conversation.id}" 
> expression is ok. From CDI
>>>>>  point of view the name is wrong and cannot be used as it is...
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  Romain Manni-Bucau
>>>>>>  @rmannibucau
>>>>>>  http://www.tomitribe.com
>>>>>>  http://rmannibucau.wordpress.com
>>>>>>  https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>>  2015-01-14 13:12 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  I agree with Martin. We *should* fix this situation in 
> the long term,
>>>>>>>  which
>>>>>>>  is what I proposed. However in the short term there is 
> no problem with
>>>>>>>  not
>>>>>>>  passing a particular test from the EL spec. 
> Additionally this is provably
>>>>>>>  implementable as Weld implements this, and many Java EE 
> containers pass.
>>>>>>>  As
>>>>>>>  there are no other spec defined beans javax, then we do 
> not conflict with
>>>>>>>  any other spec by implementing it this way.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 12:10, Martin Kouba 
> <mkouba at redhat.com> wrote:
>>>>>>> 
>>>>>>>  Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>> 
>>>>>>>  well there are 2 points:
>>>>>>>  1) a test should be added for it
>>>>>>> 
>>>>>>> 
>>>>>>>  There was a CDI TCK test since 1.1
>>>>>>> 
>>>>>>> 
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>  It has been modified a week ago (see also CDITCK-462) 
> not to use
>>>>>>>  "javax.enterprise.context.conversation.id".
>>>>>>> 
>>>>>>>  2) test or not being certified means respecting the 
> spec (pdf, javadoc
>>>>>>>  + tests themselve)
>>>>>>> 
>>>>>>>  So if there is this test a container can't be 
> certified for EL + CDI
>>>>>>>  at the same time
>>>>>>> 
>>>>>>> 
>>>>>>>  I don't think it's a problem. An EL TCK test 
> can't evaluate
>>>>>>> 
> "#{javax.enterprise.context.conversation.id}" as an illegal 
> expression -
>>>>>>>  it's obviously legal. The problem is
>>>>>>>  "javax.enterprise.context.conversation.id" 
> can't be simply used as a bean
>>>>>>>  name. If it is, a workaround is needed (see also
>>>>>>> 
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:35 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  Which EL test?
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:30, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  then it will not pass EL one
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:27 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  No, a Java EE container needs to pass this test.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:21, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  so it means a JavaEE container will not pass this test 
> but it is not an
>>>>>>>  issue?
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:20 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  I don?t think they should be excluded. The spec isn?t 
> ambiguous about
>>>>>>>  this,
>>>>>>>  and it is supportable.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:13, Jozef Hartinger 
> <jharting at redhat.com> wrote:
>>>>>>> 
>>>>>>>  So for CDI 1.2 the test that tests this should not be 
> excluded after all,
>>>>>>>  correct?
>>>>>>> 
>>>>>>>  On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>> 
>>>>>>>  We need to go for both (A) and (B).
>>>>>>> 
>>>>>>>  We would need to deprecate the existing name before we 
> can allow it to
>>>>>>>  not
>>>>>>>  be supported. This means CDI 3. So I would suggest we 
> deprecate it in 2,
>>>>>>>  add
>>>>>>>  an alternative that can be used, and then consider 
> removing it in CDI 3.
>>>>>>>  In
>>>>>>>  the meantime for CDI 2, we will need to improve the TCK 
> to check this
>>>>>>>  more
>>>>>>>  carefully.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  +1 for B (IMO it is not used that much)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
> <jharting at redhat.com>:
>>>>>>> 
>>>>>>>  I think further action is needed on this. Now that it 
> has been confirmed
>>>>>>>  that "javax.enterprise.context.conversation" 
> itself is not a valid EL
>>>>>>>  name we should either:
>>>>>>> 
>>>>>>>  A) Require all CDI implementations to adapt the 
> property-based approach
>>>>>>>  which allows this to be implemented portably (as Weld 
> does)
>>>>>>>  B) Declare publicly that although the CDI spec declares 
> the given name,
>>>>>>>  it is a bug and applications should not use the name. 
> (What about
>>>>>>>  compatibility with existing applications?)
>>>>>>> 
>>>>>>>  Jozef
>>>>>>> 
>>>>>>>  On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>> 
>>>>>>>  Dear CDI fellows!
>>>>>>> 
>>>>>>>  I've received an answer regarding our EL question 
> from the EL Spec Lead.
>>>>>>> 
>>>>>>>  Ed, thanks for helping us!
>>>>>>> 
>>>>>>> 
>>>>>>>  LieGrue,
>>>>>>>  strub
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> <edward.burns at oracle.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  Hello Mark,
>>>>>>> 
>>>>>>>  To close this out, no, "." is not valid in an 
> EL name.  An EL name
>>>>>>>  must
>>>>>>>  be a java identifier.  I'm told this was discussed 
> by Pete a long time
>>>>>>>  ago in the EL 3.0 EG.
>>>>>>> 
>>>>>>>  Ed
>>>>>>> 
>>>>>>>  --
>>>>>>>  | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>  | 42 days til DevNexus 2015
>>>>>>>  | 52 days til JavaLand 2015
>>>>>>>  | 62 days til CONFESS 2015
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>


From struberg at yahoo.de  Wed Jan 14 10:59:07 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 15:59:07 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <BFEEF4CA-F5E9-4600-8D57-F6DC3600835D@redhat.com>
References: <BFEEF4CA-F5E9-4600-8D57-F6DC3600835D@redhat.com>
Message-ID: <2122016026.1122001.1421251147585.JavaMail.yahoo@jws11126.mail.ir2.yahoo.com>

Pete, the solution in Weld is a.) breaking other CDI spec paragraphs, b.) not clearly mandated and c.) randomly depending on the ELResolver order. 


It is just not a wise idea.

LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 16:51
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> As previously stated I don?t agree with your arguments, and I don?t believe you 
> can prove ?no one is using it?.
> 
> 
>>  On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> wrote:
>> 
>>  No pete, the current Weld implementation breaks other CDI features! Sample 
> with @Named("javax") already given in my other post...
>> 
>> 
>>  It sucks, face it. And no one is using it anyway.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>>  ________________________________
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: Martin Kouba <mkouba at redhat.com> 
>>>  Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
> <cdi-dev at lists.jboss.org> 
>>>  Sent: Wednesday, 14 January 2015, 13:12
>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
> is not valid in an EL name.
>>> 
>>> 
>>> 
>>>  I agree with Martin. We *should* fix this situation in the long term, 
> which is what I proposed. However in the short term there is no problem with not 
> passing a particular test from the EL spec. Additionally this is provably 
> implementable as Weld implements this, and many Java EE containers pass. As 
> there are no other spec defined beans javax, then we do not conflict with any 
> other spec by implementing it this way.
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>>  On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> 
> wrote:
>>>> 
>>>>  Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>> 
>>>>  well there are 2 points:
>>>>>  1) a test should be added for it
>>>>> 
>>>>  There was a CDI TCK test since 1.1 
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). 
> It has been modified a week ago (see also CDITCK-462) not to use 
> "javax.enterprise.context.conversation.id".
>>>> 
>>>> 
>>>>  2) test or not being certified means respecting the spec (pdf, 
> javadoc
>>>>>  + tests themselve)
>>>>> 
>>>>>  So if there is this test a container can't be certified for 
> EL + CDI
>>>>>  at the same time
>>>>> 
>>>>  I don't think it's a problem. An EL TCK test can't 
> evaluate "#{javax.enterprise.context.conversation.id}" as an 
> illegal expression - it's obviously legal. The problem is 
> "javax.enterprise.context.conversation.id" can't be simply used as 
> a bean name. If it is, a workaround is needed (see also 
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>  Romain Manni-Bucau
>>>>>  @rmannibucau
>>>>>  http://www.tomitribe.com
>>>>>  http://rmannibucau.wordpress.com
>>>>>  https://github.com/rmannibucau
>>>>> 
>>>>> 
>>>>>  2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>> 
>>>>>  Which EL test?
>>>>>> 
>>>>>> 
>>>>>>  On 14 Jan 2015, at 11:30, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>>>>>>> 
>>>>>>>  then it will not pass EL one
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:27 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  No, a Java EE container needs to pass this test.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  On 14 Jan 2015, at 11:21, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>>  so it means a JavaEE container will not pass 
> this test but it is not an issue?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  Romain Manni-Bucau
>>>>>>>>>  @rmannibucau
>>>>>>>>>  http://www.tomitribe.com
>>>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>>>  https://github.com/rmannibucau
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  2015-01-14 12:20 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>>>> 
>>>>>>>>>  I don?t think they should be excluded. The spec 
> isn?t ambiguous about this, and it is supportable.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>  On 14 Jan 2015, at 11:13, Jozef Hartinger 
> <jharting at redhat.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>  So for CDI 1.2 the test that tests this 
> should not be excluded after all, correct?
>>>>>>>>>>> 
>>>>>>>>>>>  On 01/14/2015 11:56 AM, Pete Muir 
> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>  We need to go for both (A) and (B).
>>>>>>>>>>>> 
>>>>>>>>>>>>  We would need to deprecate the 
> existing name before we can allow it to not be supported. This means CDI 3. So I 
> would suggest we deprecate it in 2, add an alternative that can be used, and 
> then consider removing it in CDI 3. In the meantime for CDI 2, we will need to 
> improve the TCK to check this more carefully.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>  On 14 Jan 2015, at 10:09, Romain 
> Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  +1 for B (IMO it is not used 
> that much)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  Romain Manni-Bucau
>>>>>>>>>>>>>  @rmannibucau
>>>>>>>>>>>>>  http://www.tomitribe.com
>>>>>>>>>>>>> 
> http://rmannibucau.wordpress.com
>>>>>>>>>>>>>  https://github.com/rmannibucau
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  2015-01-14 10:54 GMT+01:00 
> Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  I think further action is 
> needed on this. Now that it has been confirmed
>>>>>>>>>>>>>>  that 
> "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>>>>>>  name we should either:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  A) Require all CDI 
> implementations to adapt the property-based approach
>>>>>>>>>>>>>>  which allows this to be 
> implemented portably (as Weld does)
>>>>>>>>>>>>>>  B) Declare publicly that 
> although the CDI spec declares the given name,
>>>>>>>>>>>>>>  it is a bug and 
> applications should not use the name. (What about
>>>>>>>>>>>>>>  compatibility with existing 
> applications?)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  Jozef
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  On 01/08/2015 09:27 AM, 
> Mark Struberg wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  Dear CDI fellows!
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  I've received an 
> answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  Ed, thanks for helping 
> us!
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  LieGrue,
>>>>>>>>>>>>>>>  strub
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  On Tuesday, 6 January 
> 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  Hello Mark,
>>>>>>>>>>>>>>>>>  To close this 
> out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>>>>>  must
>>>>>>>>>>>>>>>>  be a java 
> identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>>>>>  ago in the EL 3.0 
> EG.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  Ed
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>  | 
> edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>>>  | 42 days til 
> DevNexus 2015
>>>>>>>>>>>>>>>>  | 52 days til 
> JavaLand 2015
>>>>>>>>>>>>>>>>  | 62 days til 
> CONFESS 2015
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
> _______________________________________________
>>>>>>>>>>>>>>>  cdi-dev mailing list
>>>>>>>>>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>> 
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  Note that for all code 
> provided on this list, the provider licenses the code under the Apache License, 
> Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided on this list, the provider waives all patent and other intellectual 
> property rights inherent in such information.
>>>>>>>>>>>>>>> 
> _______________________________________________
>>>>>>>>>>>>>>  cdi-dev mailing list
>>>>>>>>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>>>>>>>> 
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  Note that for all code 
> provided on this list, the provider licenses the code under the Apache License, 
> Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided on this list, the provider waives all patent and other intellectual 
> property rights inherent in such information.
>>>>>>>>>>>>>> 
> _______________________________________________
>>>>>>>>>>>>>  cdi-dev mailing list
>>>>>>>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>>>>>>> 
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  Note that for all code provided 
> on this list, the provider licenses the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  cdi-dev at lists.jboss.org
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>  Note that for all code provided on this list, the provider 
> licenses the code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>>> 
>>> 
>


From pmuir at redhat.com  Wed Jan 14 11:03:01 2015
From: pmuir at redhat.com (Pete Muir)
Date: Wed, 14 Jan 2015 16:03:01 +0000
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <2122016026.1122001.1421251147585.JavaMail.yahoo@jws11126.mail.ir2.yahoo.com>
References: <BFEEF4CA-F5E9-4600-8D57-F6DC3600835D@redhat.com>
	<2122016026.1122001.1421251147585.JavaMail.yahoo@jws11126.mail.ir2.yahoo.com>
Message-ID: <A981B6D4-C16C-4D94-BFCE-C5026DCB76B1@redhat.com>


> On 14 Jan 2015, at 15:59, Mark Struberg <struberg at yahoo.de> wrote:
> 
> Pete, the solution in Weld is a.) breaking other CDI spec paragraphs,

Which ones.

> b.) not clearly mandated

I disagree with this, I think the mandate is clear. The name is specified.

> and c.) randomly depending on the ELResolver order. 

The container must make sure that the ELResolver order is correct.

> 
> 
> It is just not a wise idea.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Mark Struberg <struberg at yahoo.de>
>> Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Wednesday, 14 January 2015, 16:51
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>> 
>> As previously stated I don?t agree with your arguments, and I don?t believe you 
>> can prove ?no one is using it?.
>> 
>> 
>>> On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> wrote:
>>> 
>>> No pete, the current Weld implementation breaks other CDI features! Sample 
>> with @Named("javax") already given in my other post...
>>> 
>>> 
>>> It sucks, face it. And no one is using it anyway.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>>> ________________________________
>>>> From: Pete Muir <pmuir at redhat.com>
>>>> To: Martin Kouba <mkouba at redhat.com> 
>>>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
>> <cdi-dev at lists.jboss.org> 
>>>> Sent: Wednesday, 14 January 2015, 13:12
>>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
>> is not valid in an EL name.
>>>> 
>>>> 
>>>> 
>>>> I agree with Martin. We *should* fix this situation in the long term, 
>> which is what I proposed. However in the short term there is no problem with not 
>> passing a particular test from the EL spec. Additionally this is provably 
>> implementable as Weld implements this, and many Java EE containers pass. As 
>> there are no other spec defined beans javax, then we do not conflict with any 
>> other spec by implementing it this way.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba at redhat.com> 
>> wrote:
>>>>> 
>>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>> 
>>>>> well there are 2 points:
>>>>>> 1) a test should be added for it
>>>>>> 
>>>>> There was a CDI TCK test since 1.1 
>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). 
>> It has been modified a week ago (see also CDITCK-462) not to use 
>> "javax.enterprise.context.conversation.id".
>>>>> 
>>>>> 
>>>>> 2) test or not being certified means respecting the spec (pdf, 
>> javadoc
>>>>>> + tests themselve)
>>>>>> 
>>>>>> So if there is this test a container can't be certified for 
>> EL + CDI
>>>>>> at the same time
>>>>>> 
>>>>> I don't think it's a problem. An EL TCK test can't 
>> evaluate "#{javax.enterprise.context.conversation.id}" as an 
>> illegal expression - it's obviously legal. The problem is 
>> "javax.enterprise.context.conversation.id" can't be simply used as 
>> a bean name. If it is, a workaround is needed (see also 
>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>> 
>>>>>> Which EL test?
>>>>>>> 
>>>>>>> 
>>>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau 
>> <rmannibucau at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> then it will not pass EL one
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau
>>>>>>>> http://www.tomitribe.com
>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>> https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir 
>> <pmuir at redhat.com>:
>>>>>>>> 
>>>>>>>> No, a Java EE container needs to pass this test.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau 
>> <rmannibucau at gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> so it means a JavaEE container will not pass 
>> this test but it is not an issue?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> @rmannibucau
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir 
>> <pmuir at redhat.com>:
>>>>>>>>>> 
>>>>>>>>>> I don?t think they should be excluded. The spec 
>> isn?t ambiguous about this, and it is supportable.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger 
>> <jharting at redhat.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> So for CDI 1.2 the test that tests this 
>> should not be excluded after all, correct?
>>>>>>>>>>>> 
>>>>>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir 
>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> We need to go for both (A) and (B).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We would need to deprecate the 
>> existing name before we can allow it to not be supported. This means CDI 3. So I 
>> would suggest we deprecate it in 2, add an alternative that can be used, and 
>> then consider removing it in CDI 3. In the meantime for CDI 2, we will need to 
>> improve the TCK to check this more carefully.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 14 Jan 2015, at 10:09, Romain 
>> Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1 for B (IMO it is not used 
>> that much)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>> @rmannibucau
>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>> 
>> http://rmannibucau.wordpress.com
>>>>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2015-01-14 10:54 GMT+01:00 
>> Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think further action is 
>> needed on this. Now that it has been confirmed
>>>>>>>>>>>>>>> that 
>> "javax.enterprise.context.conversation" itself is not a valid EL
>>>>>>>>>>>>>>> name we should either:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> A) Require all CDI 
>> implementations to adapt the property-based approach
>>>>>>>>>>>>>>> which allows this to be 
>> implemented portably (as Weld does)
>>>>>>>>>>>>>>> B) Declare publicly that 
>> although the CDI spec declares the given name,
>>>>>>>>>>>>>>> it is a bug and 
>> applications should not use the name. (What about
>>>>>>>>>>>>>>> compatibility with existing 
>> applications?)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Jozef
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 01/08/2015 09:27 AM, 
>> Mark Struberg wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Dear CDI fellows!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I've received an 
>> answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Ed, thanks for helping 
>> us!
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>>>>>> strub
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tuesday, 6 January 
>> 2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hello Mark,
>>>>>>>>>>>>>>>>>> To close this 
>> out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>>>>>> must
>>>>>>>>>>>>>>>>> be a java 
>> identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>>>>>> ago in the EL 3.0 
>> EG.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Ed
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> | 
>> edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>>>> | 42 days til 
>> DevNexus 2015
>>>>>>>>>>>>>>>>> | 52 days til 
>> JavaLand 2015
>>>>>>>>>>>>>>>>> | 62 days til 
>> CONFESS 2015
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>> _______________________________________________
>>>>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Note that for all code 
>> provided on this list, the provider licenses the code under the Apache License, 
>> Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
>> provided on this list, the provider waives all patent and other intellectual 
>> property rights inherent in such information.
>>>>>>>>>>>>>>>> 
>> _______________________________________________
>>>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Note that for all code 
>> provided on this list, the provider licenses the code under the Apache License, 
>> Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
>> provided on this list, the provider waives all patent and other intellectual 
>> property rights inherent in such information.
>>>>>>>>>>>>>>> 
>> _______________________________________________
>>>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Note that for all code provided 
>> on this list, the provider licenses the code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>> Note that for all code provided on this list, the provider 
>> licenses the code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the 
>> code under the Apache License, Version 2 
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
>> on this list, the provider waives all patent and other intellectual property 
>> rights inherent in such information.
>>>> 
>>>> 
>> 



From struberg at yahoo.de  Wed Jan 14 11:19:31 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 16:19:31 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <806C1FF7-B74E-4878-A0E9-C75D1727E16A@redhat.com>
References: <806C1FF7-B74E-4878-A0E9-C75D1727E16A@redhat.com>
Message-ID: <994171372.1157882.1421252371091.JavaMail.yahoo@jws11102.mail.ir2.yahoo.com>

paragraphs and arguing?

Here comes mine:
6.7.5 just defines
"The container provides a built-in bean with bean type Conversation, scope @RequestScoped, and qualifier @Default, named javax.enterprise.context.conversation."

It doesn't state that the bean must be available under 

#{javax.enterprise.context.conversation} to the EL. This is simply just implicated by the bean.name rules.

There are 3 usages defined for Bean<T>.getName().

1.) paragraph 3.13 The qualifier @Named at injection points: 

It is a Qualifier. Thus you could use 

@Inject 

@Named("javax.enterprise.context.conversation")
Object conversation;

2.) paragraph 11.3.7 Obtaining a Bean by name:
It makes a bean able to be looked up via BeanManager#getBeans(String)

public Set<Bean<?>> getBeans("javax.enterprise.context.conversation");


3.) paragraph 2.6 Bean names:

It makes a bean visible to EL. BUT read the specified paragraph really carefula!
"A bean may have a bean name. A bean with a name may be referred to by its name in Unified EL expressions. A valid bean name is a period-separated list of valid EL identifiers.

The important part is "list of _VALID_ EL identifiers"


What does this paragraph mean at all?

Does this mean that #{javax} is possible as is #{enterprise}, #{context} and #{conversation}? Because all those are valid EL identifiers, wheras the combined string is NOT a valid EL identifier.

If not and we go for your interpretation then we would also need to support code like 


@Named("oh.uh.some.other.weird.el.name"}
public class TotallyNonsenseService

You can turn this as you like. It simply makes no sense at all to support it as EL name.



But there is a third option: This is just no valid EL identifier and thus it is not exposed to EL but only to mechanism 1.) (@Inject @Named) and 2.) (getBeans(String)).




LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Jozef Hartinger <jharting at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 16:49
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> I?m afraid I disagree with the reasoning you present and your statements below.
> 
> 
>>  On 14 Jan 2015, at 15:46, Mark Struberg <struberg at yahoo.de> wrote:
>> 
>>  The spec only says that the Bean must have this name. All the rest is some 
> 3-rd level 'implicit' arguing. The spec does NOT say that the EL 
> "javax...." must give you a Conversation...
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: Jozef Hartinger <jharting at redhat.com>
>>>  Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
> <cdi-dev at lists.jboss.org>
>>>  Sent: Wednesday, 14 January 2015, 12:20
>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
> is not valid in an EL name.
>>> 
>>>  I don?t think they should be excluded. The spec isn?t ambiguous about 
> this, and 
>>>  it is supportable.
>>> 
>>> 
>>>>  On 14 Jan 2015, at 11:13, Jozef Hartinger 
> <jharting at redhat.com> 
>>>  wrote:
>>>> 
>>>>  So for CDI 1.2 the test that tests this should not be excluded 
> after all, 
>>>  correct?
>>>> 
>>>>  On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>  We need to go for both (A) and (B).
>>>>> 
>>>>>  We would need to deprecate the existing name before we can 
> allow it to 
>>>  not be supported. This means CDI 3. So I would suggest we deprecate it 
> in 2, add 
>>>  an alternative that can be used, and then consider removing it in CDI 
> 3. In the 
>>>  meantime for CDI 2, we will need to improve the TCK to check this more 
>>>  carefully.
>>>>> 
>>>>>>  On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
>>>  <rmannibucau at gmail.com> wrote:
>>>>>> 
>>>>>>  +1 for B (IMO it is not used that much)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  Romain Manni-Bucau
>>>>>>  @rmannibucau
>>>>>>  http://www.tomitribe.com
>>>>>>  http://rmannibucau.wordpress.com
>>>>>>  https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>>  2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
>>>  <jharting at redhat.com>:
>>>>>>>  I think further action is needed on this. Now that it 
> has been 
>>>  confirmed
>>>>>>>  that "javax.enterprise.context.conversation" 
> itself 
>>>  is not a valid EL
>>>>>>>  name we should either:
>>>>>>> 
>>>>>>>  A) Require all CDI implementations to adapt the 
> property-based 
>>>  approach
>>>>>>>  which allows this to be implemented portably (as Weld 
> does)
>>>>>>>  B) Declare publicly that although the CDI spec declares 
> the 
>>>  given name,
>>>>>>>  it is a bug and applications should not use the name. 
> (What 
>>>  about
>>>>>>>  compatibility with existing applications?)
>>>>>>> 
>>>>>>>  Jozef
>>>>>>> 
>>>>>>>  On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>  Dear CDI fellows!
>>>>>>>> 
>>>>>>>>  I've received an answer regarding our EL 
> question from 
>>>  the EL Spec Lead.
>>>>>>>> 
>>>>>>>>  Ed, thanks for helping us!
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  LieGrue,
>>>>>>>>  strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> 
>>>  <edward.burns at oracle.com> wrote:
>>>>>>>>>>  Hello Mark,
>>>>>>>>>  To close this out, no, "." is not 
> valid in an 
>>>  EL name.  An EL name
>>>>>>>>>  must
>>>>>>>>>  be a java identifier.  I'm told this was 
> discussed 
>>>  by Pete a long time
>>>>>>>>>  ago in the EL 3.0 EG.
>>>>>>>>> 
>>>>>>>>>  Ed
>>>>>>>>> 
>>>>>>>>>  --
>>>>>>>>>  | edward.burns at oracle.com | office: +1 407 458 
> 0017
>>>>>>>>>  | 42 days til DevNexus 2015
>>>>>>>>>  | 52 days til JavaLand 2015
>>>>>>>>>  | 62 days til CONFESS 2015
>>>>>>>>> 
>>>>>>>>  _______________________________________________
>>>>>>>>  cdi-dev mailing list
>>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>>  Note that for all code provided on this list, the 
> provider 
>>>  licenses the code under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider 
>>>  licenses the code under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>>>>  _______________________________________________
>>>>>>  cdi-dev mailing list
>>>>>>  cdi-dev at lists.jboss.org
>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>>  Note that for all code provided on this list, the provider 
> licenses 
>>>  the code under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>  Note that for all code provided on this list, the provider licenses the 
> code 
>>>  under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>> 
>


From struberg at yahoo.de  Wed Jan 14 11:22:31 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 14 Jan 2015 16:22:31 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <A981B6D4-C16C-4D94-BFCE-C5026DCB76B1@redhat.com>
References: <A981B6D4-C16C-4D94-BFCE-C5026DCB76B1@redhat.com>
Message-ID: <1297631480.1156145.1421252551103.JavaMail.yahoo@jws11118.mail.ir2.yahoo.com>

See my other mail:

@Named("javax")
public class MyService

is a perfectly valid CDI bean. Still it would be broken with Weld.

LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 17:03
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> 
>>  On 14 Jan 2015, at 15:59, Mark Struberg <struberg at yahoo.de> wrote:
>> 
>>  Pete, the solution in Weld is a.) breaking other CDI spec paragraphs,
> 
> Which ones.
> 
>>  b.) not clearly mandated
> 
> I disagree with this, I think the mandate is clear. The name is specified.
> 
>>  and c.) randomly depending on the ELResolver order. 
> 
> The container must make sure that the ELResolver order is correct.
> 
> 
>> 
>> 
>>  It is just not a wise idea.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: Mark Struberg <struberg at yahoo.de>
>>>  Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns 
> <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>>>  Sent: Wednesday, 14 January 2015, 16:51
>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
> is not valid in an EL name.
>>> 
>>>  As previously stated I don?t agree with your arguments, and I don?t 
> believe you 
>>>  can prove ?no one is using it?.
>>> 
>>> 
>>>>  On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> 
> wrote:
>>>> 
>>>>  No pete, the current Weld implementation breaks other CDI features! 
> Sample 
>>>  with @Named("javax") already given in my other post...
>>>> 
>>>> 
>>>>  It sucks, face it. And no one is using it anyway.
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>  ________________________________
>>>>>  From: Pete Muir <pmuir at redhat.com>
>>>>>  To: Martin Kouba <mkouba at redhat.com> 
>>>>>  Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
>>>  <cdi-dev at lists.jboss.org> 
>>>>>  Sent: Wednesday, 14 January 2015, 13:12
>>>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    
> "." 
>>>  is not valid in an EL name.
>>>>> 
>>>>> 
>>>>> 
>>>>>  I agree with Martin. We *should* fix this situation in the long 
> term, 
>>>  which is what I proposed. However in the short term there is no problem 
> with not 
>>>  passing a particular test from the EL spec. Additionally this is 
> provably 
>>>  implementable as Weld implements this, and many Java EE containers 
> pass. As 
>>>  there are no other spec defined beans javax, then we do not conflict 
> with any 
>>>  other spec by implementing it this way.
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  On 14 Jan 2015, at 12:10, Martin Kouba 
> <mkouba at redhat.com> 
>>>  wrote:
>>>>>> 
>>>>>>  Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>> 
>>>>>>  well there are 2 points:
>>>>>>>  1) a test should be added for it
>>>>>>> 
>>>>>>  There was a CDI TCK test since 1.1 
>>> 
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). 
> 
>>>  It has been modified a week ago (see also CDITCK-462) not to use 
>>>  "javax.enterprise.context.conversation.id".
>>>>>> 
>>>>>> 
>>>>>>  2) test or not being certified means respecting the spec 
> (pdf, 
>>>  javadoc
>>>>>>>  + tests themselve)
>>>>>>> 
>>>>>>>  So if there is this test a container can't be 
> certified for 
>>>  EL + CDI
>>>>>>>  at the same time
>>>>>>> 
>>>>>>  I don't think it's a problem. An EL TCK test 
> can't 
>>>  evaluate "#{javax.enterprise.context.conversation.id}" 
> as an 
>>>  illegal expression - it's obviously legal. The problem is 
>>>  "javax.enterprise.context.conversation.id" can't be 
> simply used as 
>>>  a bean name. If it is, a workaround is needed (see also 
>>>  http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:35 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  Which EL test?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  On 14 Jan 2015, at 11:30, Romain Manni-Bucau 
>>>  <rmannibucau at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>>  then it will not pass EL one
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  Romain Manni-Bucau
>>>>>>>>>  @rmannibucau
>>>>>>>>>  http://www.tomitribe.com
>>>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>>>  https://github.com/rmannibucau
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  2015-01-14 12:27 GMT+01:00 Pete Muir 
>>>  <pmuir at redhat.com>:
>>>>>>>>> 
>>>>>>>>>  No, a Java EE container needs to pass this 
> test.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>  On 14 Jan 2015, at 11:21, Romain 
> Manni-Bucau 
>>>  <rmannibucau at gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>  so it means a JavaEE container will not 
> pass 
>>>  this test but it is not an issue?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  Romain Manni-Bucau
>>>>>>>>>>>  @rmannibucau
>>>>>>>>>>>  http://www.tomitribe.com
>>>>>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>>>>>  https://github.com/rmannibucau
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  2015-01-14 12:20 GMT+01:00 Pete Muir 
>>>  <pmuir at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>  I don?t think they should be excluded. 
> The spec 
>>>  isn?t ambiguous about this, and it is supportable.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>  On 14 Jan 2015, at 11:13, Jozef 
> Hartinger 
>>>  <jharting at redhat.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  So for CDI 1.2 the test that 
> tests this 
>>>  should not be excluded after all, correct?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  On 01/14/2015 11:56 AM, Pete 
> Muir 
>>>  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  We need to go for both (A) and 
> (B).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  We would need to deprecate 
> the 
>>>  existing name before we can allow it to not be supported. This means 
> CDI 3. So I 
>>>  would suggest we deprecate it in 2, add an alternative that can be 
> used, and 
>>>  then consider removing it in CDI 3. In the meantime for CDI 2, we will 
> need to 
>>>  improve the TCK to check this more carefully.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  On 14 Jan 2015, at 10:09, 
> Romain 
>>>  Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  +1 for B (IMO it is not 
> used 
>>>  that much)
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  Romain Manni-Bucau
>>>>>>>>>>>>>>>  @rmannibucau
>>>>>>>>>>>>>>> 
> http://www.tomitribe.com
>>>>>>>>>>>>>>> 
>>>  http://rmannibucau.wordpress.com
>>>>>>>>>>>>>>> 
> https://github.com/rmannibucau
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  2015-01-14 10:54 
> GMT+01:00 
>>>  Jozef Hartinger <jharting at redhat.com>:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  I think further action 
> is 
>>>  needed on this. Now that it has been confirmed
>>>>>>>>>>>>>>>>  that 
>>>  "javax.enterprise.context.conversation" itself is not a valid 
> EL
>>>>>>>>>>>>>>>>  name we should 
> either:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  A) Require all CDI 
>>>  implementations to adapt the property-based approach
>>>>>>>>>>>>>>>>  which allows this 
> to be 
>>>  implemented portably (as Weld does)
>>>>>>>>>>>>>>>>  B) Declare publicly 
> that 
>>>  although the CDI spec declares the given name,
>>>>>>>>>>>>>>>>  it is a bug and 
>>>  applications should not use the name. (What about
>>>>>>>>>>>>>>>>  compatibility with 
> existing 
>>>  applications?)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  Jozef
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  On 01/08/2015 09:27 
> AM, 
>>>  Mark Struberg wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  Dear CDI fellows!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  I've 
> received an 
>>>  answer regarding our EL question from the EL Spec Lead.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  Ed, thanks for 
> helping 
>>>  us!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  LieGrue,
>>>>>>>>>>>>>>>>>  strub
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  On Tuesday, 6 
> January 
>>>  2015, 23:14, Edward Burns <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>  Hello Mark,
>>>>>>>>>>>>>>>>>>>  To 
> close this 
>>>  out, no, "." is not valid in an EL name.  An EL name
>>>>>>>>>>>>>>>>>>  must
>>>>>>>>>>>>>>>>>>  be a java 
>>>  identifier.  I'm told this was discussed by Pete a long time
>>>>>>>>>>>>>>>>>>  ago in the 
> EL 3.0 
>>>  EG.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>  Ed
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>  --
>>>>>>>>>>>>>>>>>>  | 
>>>  edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>>>>>  | 42 days 
> til 
>>>  DevNexus 2015
>>>>>>>>>>>>>>>>>>  | 52 days 
> til 
>>>  JavaLand 2015
>>>>>>>>>>>>>>>>>>  | 62 days 
> til 
>>>  CONFESS 2015
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>  _______________________________________________
>>>>>>>>>>>>>>>>>  cdi-dev mailing 
> list
>>>>>>>>>>>>>>>>> 
> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>>>> 
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>  Note that for 
> all code 
>>>  provided on this list, the provider licenses the code under the Apache 
> License, 
>>>  Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all 
> other ideas 
>>>  provided on this list, the provider waives all patent and other 
> intellectual 
>>>  property rights inherent in such information.
>>>>>>>>>>>>>>>>> 
>>>  _______________________________________________
>>>>>>>>>>>>>>>>  cdi-dev mailing 
> list
>>>>>>>>>>>>>>>> 
> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>>> 
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>  Note that for all 
> code 
>>>  provided on this list, the provider licenses the code under the Apache 
> License, 
>>>  Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all 
> other ideas 
>>>  provided on this list, the provider waives all patent and other 
> intellectual 
>>>  property rights inherent in such information.
>>>>>>>>>>>>>>>> 
>>>  _______________________________________________
>>>>>>>>>>>>>>>  cdi-dev mailing list
>>>>>>>>>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>> 
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>  Note that for all code 
> provided 
>>>  on this list, the provider licenses the code under the Apache License, 
> Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider 
>>>  licenses the code under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>>> 
>>>>> 
>>>>> 
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  cdi-dev at lists.jboss.org
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>  Note that for all code provided on this list, the provider 
> licenses the 
>>>  code under the Apache License, Version 2 
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided 
>>>  on this list, the provider waives all patent and other intellectual 
> property 
>>>  rights inherent in such information.
>>>>> 
>>>>> 
>>> 
>


From edward.burns at oracle.com  Wed Jan 14 15:58:36 2015
From: edward.burns at oracle.com (Edward Burns)
Date: Wed, 14 Jan 2015 12:58:36 -0800
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
Message-ID: <21686.55420.914616.573585@gargle.gargle.HOWL>

I hope I can be allowed to inject myself into this conversation.  I can
see a little emotional escalation creeping in here, so let's leave that
between the keyboard and the chair.  Now, some comments below:

>>>>> On Wed, 14 Jan 2015 12:12:57 +0000, Pete Muir <pmuir at redhat.com> said:

PM> I agree with Martin. We *should* fix this situation in the long
PM> term, which is what I proposed. However in the short term there is
PM> no problem with not passing a particular test from the EL
PM> spec. Additionally this is provably implementable as Weld implements
PM> this, and many Java EE containers pass. As there are no other spec
PM> defined beans javax, then we do not conflict with any other spec by
PM> implementing it this way.

>>>>> On Wed, 14 Jan 2015 15:52:17 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:

MS> @Named("javax")
MS> public class MyService {..}

>>>>> On Wed, 14 Jan 2015 16:22:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:

MS> is a perfectly valid CDI bean. Still it would be broken with Weld.

>>>>> On Wed, 14 Jan 2015 16:19:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:

MS> 6.7.5 just defines

Spec> "The container provides a built-in bean with bean type
Spec> Conversation, scope @RequestScoped, and qualifier @Default, named
Spec> javax.enterprise.context.conversation."

MS> It doesn't state that the bean must be available under 

MS> #{javax.enterprise.context.conversation} to the EL. This is simply
MS> just implicated by the bean.name rules.

MS> 3.) paragraph 2.6 Bean names:

MS> It makes a bean visible to EL. BUT read the specified paragraph really carefula!

Spec> "A bean may have a bean name. A bean with a name may be referred
Spec> to by its name in Unified EL expressions. A valid bean name is a
Spec> period-separated list of valid EL identifiers.

MS> The important part is "list of _VALID_ EL identifiers"

MS> What does this paragraph mean at all?

MS> Does this mean that #{javax} is possible as is #{enterprise},
MS> #{context} and #{conversation}? Because all those are valid EL
MS> identifiers, wheras the combined string is NOT a valid EL
MS> identifier.

MS> If not and we go for your interpretation then we would also need to
MS> support code like

MS> @Named("oh.uh.some.other.weird.el.name"}
MS> public class TotallyNonsenseService

MS> You can turn this as you like. It simply makes no sense at all to
MS> support it as EL name.

MS> But there is a third option: This is just no valid EL identifier and
MS> thus it is not exposed to EL but only to mechanism 1.) (@Inject
MS> @Named) and 2.) (getBeans(String)).

Along the line propopsed by Mark, the CDI spec section 6.7.5 could add
some text to this effect,

  For the purposes of exposing the conversation to EL, the conversation
  is exposed via the EL name "javax_enterprise_context_Conversation".

MS> And then break all applications which have a @Named("javax") public
MS> class MyBean?  It's simply not an option imo. It breaks lots of
MS> other specs and features. This is an XOR situation.

I agree we can't do that.  Instead we could just add some text that
states that there is no requirement for
"javax.enterprise.context.conversation" to be exposed as an EL name.

Would that work?

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| 36 days til DevNexus 2015
| 46 days til JavaLand 2015
| 56 days til CONFESS 2015

From rmannibucau at gmail.com  Wed Jan 14 16:01:02 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 14 Jan 2015 22:01:02 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <21686.55420.914616.573585@gargle.gargle.HOWL>
References: <21676.24106.508156.967850@gargle.gargle.HOWL>
	<262795979.6255188.1420705657357.JavaMail.yahoo@jws11135.mail.ir2.yahoo.com>
	<54B63CCC.3080208@redhat.com>
	<CACLE=7NpZcr8L3OOv03sA9bw+7E_E2nYdM9ROBTp1Wvk0RNTeA@mail.gmail.com>
	<231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<54B64F59.4030905@redhat.com>
	<84983B1F-4F6E-47FE-A5D2-0537DDDC1C97@redhat.com>
	<CACLE=7O0VXV02cpCjA0G+d6bGU1UAUAPTm9pLUHQ2mZ=ESGehA@mail.gmail.com>
	<BCE0D631-99E6-4A45-B1E9-67CD64E5336B@redhat.com>
	<CACLE=7Prca0TG0QFv-m6TxfshQJr5zKxyRhfAFRJjtDLKm2CBg@mail.gmail.com>
	<6E5E4EA1-C3B9-4D0A-A47D-1F119A1586AD@redhat.com>
	<CACLE=7NRjp3SMjzqKB4R7=vYiQgoWaz-TTEpBBOOspX201KK3g@mail.gmail.com>
	<54B65CA6.4000009@redhat.com>
	<6C9F8172-9695-4FCC-B257-73042843D12A@redhat.com>
	<21686.55420.914616.573585@gargle.gargle.HOWL>
Message-ID: <CACLE=7OWMrWM-_Y_tYH5OCL+Ht6L=O2-ay_tTbDQFm1SY_eHEQ@mail.gmail.com>

Agree a SHOULD instead of a MUST for - and only for - EL would be a
good compromise.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-14 21:58 GMT+01:00 Edward Burns <edward.burns at oracle.com>:
> I hope I can be allowed to inject myself into this conversation.  I can
> see a little emotional escalation creeping in here, so let's leave that
> between the keyboard and the chair.  Now, some comments below:
>
>>>>>> On Wed, 14 Jan 2015 12:12:57 +0000, Pete Muir <pmuir at redhat.com> said:
>
> PM> I agree with Martin. We *should* fix this situation in the long
> PM> term, which is what I proposed. However in the short term there is
> PM> no problem with not passing a particular test from the EL
> PM> spec. Additionally this is provably implementable as Weld implements
> PM> this, and many Java EE containers pass. As there are no other spec
> PM> defined beans javax, then we do not conflict with any other spec by
> PM> implementing it this way.
>
>>>>>> On Wed, 14 Jan 2015 15:52:17 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> @Named("javax")
> MS> public class MyService {..}
>
>>>>>> On Wed, 14 Jan 2015 16:22:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> is a perfectly valid CDI bean. Still it would be broken with Weld.
>
>>>>>> On Wed, 14 Jan 2015 16:19:31 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:
>
> MS> 6.7.5 just defines
>
> Spec> "The container provides a built-in bean with bean type
> Spec> Conversation, scope @RequestScoped, and qualifier @Default, named
> Spec> javax.enterprise.context.conversation."
>
> MS> It doesn't state that the bean must be available under
>
> MS> #{javax.enterprise.context.conversation} to the EL. This is simply
> MS> just implicated by the bean.name rules.
>
> MS> 3.) paragraph 2.6 Bean names:
>
> MS> It makes a bean visible to EL. BUT read the specified paragraph really carefula!
>
> Spec> "A bean may have a bean name. A bean with a name may be referred
> Spec> to by its name in Unified EL expressions. A valid bean name is a
> Spec> period-separated list of valid EL identifiers.
>
> MS> The important part is "list of _VALID_ EL identifiers"
>
> MS> What does this paragraph mean at all?
>
> MS> Does this mean that #{javax} is possible as is #{enterprise},
> MS> #{context} and #{conversation}? Because all those are valid EL
> MS> identifiers, wheras the combined string is NOT a valid EL
> MS> identifier.
>
> MS> If not and we go for your interpretation then we would also need to
> MS> support code like
>
> MS> @Named("oh.uh.some.other.weird.el.name"}
> MS> public class TotallyNonsenseService
>
> MS> You can turn this as you like. It simply makes no sense at all to
> MS> support it as EL name.
>
> MS> But there is a third option: This is just no valid EL identifier and
> MS> thus it is not exposed to EL but only to mechanism 1.) (@Inject
> MS> @Named) and 2.) (getBeans(String)).
>
> Along the line propopsed by Mark, the CDI spec section 6.7.5 could add
> some text to this effect,
>
>   For the purposes of exposing the conversation to EL, the conversation
>   is exposed via the EL name "javax_enterprise_context_Conversation".
>
> MS> And then break all applications which have a @Named("javax") public
> MS> class MyBean?  It's simply not an option imo. It breaks lots of
> MS> other specs and features. This is an XOR situation.
>
> I agree we can't do that.  Instead we could just add some text that
> states that there is no requirement for
> "javax.enterprise.context.conversation" to be exposed as an EL name.
>
> Would that work?
>
> Ed
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | 36 days til DevNexus 2015
> | 46 days til JavaLand 2015
> | 56 days til CONFESS 2015

From struberg at yahoo.de  Thu Jan 15 02:40:49 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 15 Jan 2015 07:40:49 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
References: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
Message-ID: <626240826.1412846.1421307650013.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com>

> This has been a requirement since version 1.0, a number of years. How has OWB
> managed to not be compliant with this to date?


I quickly checked the logs for the CDI-1.0 tck run and it seems that the test even passes if #{javax.enterprise.context.conversation.id} resolves to null. Not sure why though.


The other point is that OWB doesn't claim to pass the full TCK but only the SE parts. This is the same as for Weld. With the CDI container alone you simply cannot pass those.

The EE part is being tested when being integrated into an EE server (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an additional ELResolver for it? But I honestly doubt it. 



> Yes, but we still have to implement the existing spec as it stands.
I understand that we cannot make sure that nobody ever used this. But it contradicts other (older) EE specs and the current wording is imo not that clear that it is really mandatory to support it (as outlined in my other mail).

There is also a very easy hack to get this back if a user really wants:

@Named("javax")
public class ConversationElHelperJavax {

 public ConversationElHelperEnterprise getEnterprise() {..}


 public class ConversationElHelperEnterprise {
  public ConversationElHelperConversation getConversation()


}

and the most inner class just returns the current Conversation instance.


Thus a user can totally easily get this behaviour by himself IF he needs it!


LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 14:35
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> 
>>  On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com> 
> wrote:
>> 
>>  Well ATM there is no requirement it works
> 
> There is a requirement that everything in the spec should work, yes.
> 
>>  and I'm convinced another
>>  (better) solution will be found for coming versions
> 
> Yes, but we still have to implement the existing spec as it stands.
> 
>>  so I would really
>>  avoid to introduce a workaround on which users will not be able to
>>  rely.
> 
> This has been a requirement since version 1.0, a number of years. How has OWB 
> managed to not be compliant with this to date?
> 
>>  Also Weld implementation breaks some valid usages of EL (since
>>  it is not done for javax only, right?).
> 
> For example?
> 
> 
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>  I think you need to use the workaround of Weld. It works, and 
> implements the spec as it stands, and means the test will pass. You can argue 
> that the spec is not written in such a way that requires this to work, but you 
> are splitting hairs at this point, and it was the intent of the 1.0 EG that it 
> would work the way Weld implemented it.
>>> 
>>>>  On 14 Jan 2015, at 13:13, Romain Manni-Bucau 
> <rmannibucau at gmail.com> wrote:
>>>> 
>>>>  well issue is when you activate EL + CDI, if you respect both specs
>>>>  #{javax.enterprise.context.conversation.id} should fail - 
> agree we can
>>>>  always use the *workaround* of Weld but this is actually not 
> mandated
>>>>  by any spec excepted this test which was IMO an interpolation. 
> That's
>>>>  why i think this test shouldnt be kept even for 1.x versions.
>>>> 
>>>> 
>>>>  Romain Manni-Bucau
>>>>  @rmannibucau
>>>>  http://www.tomitribe.com
>>>>  http://rmannibucau.wordpress.com
>>>>  https://github.com/rmannibucau
>>>> 
>>>> 
>>>>  2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>  Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>> 
>>>>>>  If "there is no problem with not passing a particular 
> test from the EL
>>>>>>  spec" then there is no problem with not passing a 
> particular test from
>>>>>>  the CDI spec at EE level which seems wrong to me.
>>>>>> 
>>>>>>  Globally I'd just remove this test and keep it in Weld 
> vendor specific
>>>>>>  features.
>>>>>> 
>>>>>>  @martin: my 1) was for EL spec not CDI.
>>>>>> 
>>>>>>  About 2 
> "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>  is a property of conversation which is a property of 
> context which is
>>>>>>  a property of enterprise which is a property of javax which 
> is clearly
>>>>>>  not what is desired and opposed to what is in the CDI spec.
>>>>> 
>>>>> 
>>>>>  Sure. But EL cannot test this. From it's point of view the
>>>>>  "#{javax.enterprise.context.conversation.id}" 
> expression is ok. From CDI
>>>>>  point of view the name is wrong and cannot be used as it is...
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>  Romain Manni-Bucau
>>>>>>  @rmannibucau
>>>>>>  http://www.tomitribe.com
>>>>>>  http://rmannibucau.wordpress.com
>>>>>>  https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>>  2015-01-14 13:12 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  I agree with Martin. We *should* fix this situation in 
> the long term,
>>>>>>>  which
>>>>>>>  is what I proposed. However in the short term there is 
> no problem with
>>>>>>>  not
>>>>>>>  passing a particular test from the EL spec. 
> Additionally this is provably
>>>>>>>  implementable as Weld implements this, and many Java EE 
> containers pass.
>>>>>>>  As
>>>>>>>  there are no other spec defined beans javax, then we do 
> not conflict with
>>>>>>>  any other spec by implementing it this way.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 12:10, Martin Kouba 
> <mkouba at redhat.com> wrote:
>>>>>>> 
>>>>>>>  Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>> 
>>>>>>>  well there are 2 points:
>>>>>>>  1) a test should be added for it
>>>>>>> 
>>>>>>> 
>>>>>>>  There was a CDI TCK test since 1.1
>>>>>>> 
>>>>>>> 
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>  It has been modified a week ago (see also CDITCK-462) 
> not to use
>>>>>>>  "javax.enterprise.context.conversation.id".
>>>>>>> 
>>>>>>>  2) test or not being certified means respecting the 
> spec (pdf, javadoc
>>>>>>>  + tests themselve)
>>>>>>> 
>>>>>>>  So if there is this test a container can't be 
> certified for EL + CDI
>>>>>>>  at the same time
>>>>>>> 
>>>>>>> 
>>>>>>>  I don't think it's a problem. An EL TCK test 
> can't evaluate
>>>>>>> 
> "#{javax.enterprise.context.conversation.id}" as an illegal 
> expression -
>>>>>>>  it's obviously legal. The problem is
>>>>>>>  "javax.enterprise.context.conversation.id" 
> can't be simply used as a bean
>>>>>>>  name. If it is, a workaround is needed (see also
>>>>>>> 
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:35 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  Which EL test?
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:30, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  then it will not pass EL one
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:27 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  No, a Java EE container needs to pass this test.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:21, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  so it means a JavaEE container will not pass this test 
> but it is not an
>>>>>>>  issue?
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 12:20 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>> 
>>>>>>>  I don?t think they should be excluded. The spec isn?t 
> ambiguous about
>>>>>>>  this,
>>>>>>>  and it is supportable.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 11:13, Jozef Hartinger 
> <jharting at redhat.com> wrote:
>>>>>>> 
>>>>>>>  So for CDI 1.2 the test that tests this should not be 
> excluded after all,
>>>>>>>  correct?
>>>>>>> 
>>>>>>>  On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>> 
>>>>>>>  We need to go for both (A) and (B).
>>>>>>> 
>>>>>>>  We would need to deprecate the existing name before we 
> can allow it to
>>>>>>>  not
>>>>>>>  be supported. This means CDI 3. So I would suggest we 
> deprecate it in 2,
>>>>>>>  add
>>>>>>>  an alternative that can be used, and then consider 
> removing it in CDI 3.
>>>>>>>  In
>>>>>>>  the meantime for CDI 2, we will need to improve the TCK 
> to check this
>>>>>>>  more
>>>>>>>  carefully.
>>>>>>> 
>>>>>>>  On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  +1 for B (IMO it is not used that much)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  Romain Manni-Bucau
>>>>>>>  @rmannibucau
>>>>>>>  http://www.tomitribe.com
>>>>>>>  http://rmannibucau.wordpress.com
>>>>>>>  https://github.com/rmannibucau
>>>>>>> 
>>>>>>> 
>>>>>>>  2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
> <jharting at redhat.com>:
>>>>>>> 
>>>>>>>  I think further action is needed on this. Now that it 
> has been confirmed
>>>>>>>  that "javax.enterprise.context.conversation" 
> itself is not a valid EL
>>>>>>>  name we should either:
>>>>>>> 
>>>>>>>  A) Require all CDI implementations to adapt the 
> property-based approach
>>>>>>>  which allows this to be implemented portably (as Weld 
> does)
>>>>>>>  B) Declare publicly that although the CDI spec declares 
> the given name,
>>>>>>>  it is a bug and applications should not use the name. 
> (What about
>>>>>>>  compatibility with existing applications?)
>>>>>>> 
>>>>>>>  Jozef
>>>>>>> 
>>>>>>>  On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>> 
>>>>>>>  Dear CDI fellows!
>>>>>>> 
>>>>>>>  I've received an answer regarding our EL question 
> from the EL Spec Lead.
>>>>>>> 
>>>>>>>  Ed, thanks for helping us!
>>>>>>> 
>>>>>>> 
>>>>>>>  LieGrue,
>>>>>>>  strub
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  On Tuesday, 6 January 2015, 23:14, Edward Burns 
> <edward.burns at oracle.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>  Hello Mark,
>>>>>>> 
>>>>>>>  To close this out, no, "." is not valid in an 
> EL name.  An EL name
>>>>>>>  must
>>>>>>>  be a java identifier.  I'm told this was discussed 
> by Pete a long time
>>>>>>>  ago in the EL 3.0 EG.
>>>>>>> 
>>>>>>>  Ed
>>>>>>> 
>>>>>>>  --
>>>>>>>  | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>  | 42 days til DevNexus 2015
>>>>>>>  | 52 days til JavaLand 2015
>>>>>>>  | 62 days til CONFESS 2015
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at lists.jboss.org
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>>  Note that for all code provided on this list, the 
> provider licenses the
>>>>>>>  code
>>>>>>>  under the Apache License, Version 2
>>>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For 
> all other ideas
>>>>>>>  provided on this list, the provider waives all patent 
> and other
>>>>>>>  intellectual
>>>>>>>  property rights inherent in such information.
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>


From mkouba at redhat.com  Thu Jan 15 03:16:33 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 15 Jan 2015 09:16:33 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <626240826.1412846.1421307650013.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com>
References: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
	<626240826.1412846.1421307650013.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com>
Message-ID: <54B77761.6000706@redhat.com>

Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>> This has been a requirement since version 1.0, a number of years. How has OWB
>> managed to not be compliant with this to date?
>
>
> I quickly checked the logs for the CDI-1.0 tck run and it seems that the test even passes if #{javax.enterprise.context.conversation.id} resolves to null. Not sure why though.
>
>
> The other point is that OWB doesn't claim to pass the full TCK but only the SE parts. This is the same as for Weld. With the CDI container alone you simply cannot pass those.
>
> The EE part is being tested when being integrated into an EE server (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an additional ELResolver for it? But I honestly doubt it.
>
>
>
>> Yes, but we still have to implement the existing spec as it stands.
> I understand that we cannot make sure that nobody ever used this. But it contradicts other (older) EE specs and the current wording is imo not that clear that it is really mandatory to support it (as outlined in my other mail).
>
> There is also a very easy hack to get this back if a user really wants:
>
> @Named("javax")
> public class ConversationElHelperJavax {
>
>   public ConversationElHelperEnterprise getEnterprise() {..}
>
>
>   public class ConversationElHelperEnterprise {
>    public ConversationElHelperConversation getConversation()
>
>
> }
>
> and the most inner class just returns the current Conversation instance.
>
>
> Thus a user can totally easily get this behaviour by himself IF he needs it!

Wouldn't be better (from the user point of view) to provide such a bean 
in OWB? Just for compatibility reasons. Of course, we should also 
explicitly state that "javax.enterprise.context.conversation" is 
deprecated and users and encouraged not to use it...

Moreover, I think there are more users using 
"javax.enterprise.context.conversation" than users having a CDI bean 
with name "javax".

>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Wednesday, 14 January 2015, 14:35
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>>
>>
>>>   On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>>
>>>   Well ATM there is no requirement it works
>>
>> There is a requirement that everything in the spec should work, yes.
>>
>>>   and I'm convinced another
>>>   (better) solution will be found for coming versions
>>
>> Yes, but we still have to implement the existing spec as it stands.
>>
>>>   so I would really
>>>   avoid to introduce a workaround on which users will not be able to
>>>   rely.
>>
>> This has been a requirement since version 1.0, a number of years. How has OWB
>> managed to not be compliant with this to date?
>>
>>>   Also Weld implementation breaks some valid usages of EL (since
>>>   it is not done for javax only, right?).
>>
>> For example?
>>
>>
>>>
>>>
>>>   Romain Manni-Bucau
>>>   @rmannibucau
>>>   http://www.tomitribe.com
>>>   http://rmannibucau.wordpress.com
>>>   https://github.com/rmannibucau
>>>
>>>
>>>   2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>   I think you need to use the workaround of Weld. It works, and
>> implements the spec as it stands, and means the test will pass. You can argue
>> that the spec is not written in such a way that requires this to work, but you
>> are splitting hairs at this point, and it was the intent of the 1.0 EG that it
>> would work the way Weld implemented it.
>>>>
>>>>>   On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>> <rmannibucau at gmail.com> wrote:
>>>>>
>>>>>   well issue is when you activate EL + CDI, if you respect both specs
>>>>>   #{javax.enterprise.context.conversation.id} should fail -
>> agree we can
>>>>>   always use the *workaround* of Weld but this is actually not
>> mandated
>>>>>   by any spec excepted this test which was IMO an interpolation.
>> That's
>>>>>   why i think this test shouldnt be kept even for 1.x versions.
>>>>>
>>>>>
>>>>>   Romain Manni-Bucau
>>>>>   @rmannibucau
>>>>>   http://www.tomitribe.com
>>>>>   http://rmannibucau.wordpress.com
>>>>>   https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>   2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>>   Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>>>
>>>>>>>   If "there is no problem with not passing a particular
>> test from the EL
>>>>>>>   spec" then there is no problem with not passing a
>> particular test from
>>>>>>>   the CDI spec at EE level which seems wrong to me.
>>>>>>>
>>>>>>>   Globally I'd just remove this test and keep it in Weld
>> vendor specific
>>>>>>>   features.
>>>>>>>
>>>>>>>   @martin: my 1) was for EL spec not CDI.
>>>>>>>
>>>>>>>   About 2
>> "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>>   is a property of conversation which is a property of
>> context which is
>>>>>>>   a property of enterprise which is a property of javax which
>> is clearly
>>>>>>>   not what is desired and opposed to what is in the CDI spec.
>>>>>>
>>>>>>
>>>>>>   Sure. But EL cannot test this. From it's point of view the
>>>>>>   "#{javax.enterprise.context.conversation.id}"
>> expression is ok. From CDI
>>>>>>   point of view the name is wrong and cannot be used as it is...
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   Romain Manni-Bucau
>>>>>>>   @rmannibucau
>>>>>>>   http://www.tomitribe.com
>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>   https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>   2015-01-14 13:12 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>>
>>>>>>>>   I agree with Martin. We *should* fix this situation in
>> the long term,
>>>>>>>>   which
>>>>>>>>   is what I proposed. However in the short term there is
>> no problem with
>>>>>>>>   not
>>>>>>>>   passing a particular test from the EL spec.
>> Additionally this is provably
>>>>>>>>   implementable as Weld implements this, and many Java EE
>> containers pass.
>>>>>>>>   As
>>>>>>>>   there are no other spec defined beans javax, then we do
>> not conflict with
>>>>>>>>   any other spec by implementing it this way.
>>>>>>>>
>>>>>>>>   On 14 Jan 2015, at 12:10, Martin Kouba
>> <mkouba at redhat.com> wrote:
>>>>>>>>
>>>>>>>>   Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>>>
>>>>>>>>   well there are 2 points:
>>>>>>>>   1) a test should be added for it
>>>>>>>>
>>>>>>>>
>>>>>>>>   There was a CDI TCK test since 1.1
>>>>>>>>
>>>>>>>>
>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>   It has been modified a week ago (see also CDITCK-462)
>> not to use
>>>>>>>>   "javax.enterprise.context.conversation.id".
>>>>>>>>
>>>>>>>>   2) test or not being certified means respecting the
>> spec (pdf, javadoc
>>>>>>>>   + tests themselve)
>>>>>>>>
>>>>>>>>   So if there is this test a container can't be
>> certified for EL + CDI
>>>>>>>>   at the same time
>>>>>>>>
>>>>>>>>
>>>>>>>>   I don't think it's a problem. An EL TCK test
>> can't evaluate
>>>>>>>>
>> "#{javax.enterprise.context.conversation.id}" as an illegal
>> expression -
>>>>>>>>   it's obviously legal. The problem is
>>>>>>>>   "javax.enterprise.context.conversation.id"
>> can't be simply used as a bean
>>>>>>>>   name. If it is, a workaround is needed (see also
>>>>>>>>
>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   Romain Manni-Bucau
>>>>>>>>   @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>   2015-01-14 12:35 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>>
>>>>>>>>   Which EL test?
>>>>>>>>
>>>>>>>>   On 14 Jan 2015, at 11:30, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>   then it will not pass EL one
>>>>>>>>
>>>>>>>>
>>>>>>>>   Romain Manni-Bucau
>>>>>>>>   @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>   2015-01-14 12:27 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>>
>>>>>>>>   No, a Java EE container needs to pass this test.
>>>>>>>>
>>>>>>>>   On 14 Jan 2015, at 11:21, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>   so it means a JavaEE container will not pass this test
>> but it is not an
>>>>>>>>   issue?
>>>>>>>>
>>>>>>>>
>>>>>>>>   Romain Manni-Bucau
>>>>>>>>   @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>   2015-01-14 12:20 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>>
>>>>>>>>   I don?t think they should be excluded. The spec isn?t
>> ambiguous about
>>>>>>>>   this,
>>>>>>>>   and it is supportable.
>>>>>>>>
>>>>>>>>   On 14 Jan 2015, at 11:13, Jozef Hartinger
>> <jharting at redhat.com> wrote:
>>>>>>>>
>>>>>>>>   So for CDI 1.2 the test that tests this should not be
>> excluded after all,
>>>>>>>>   correct?
>>>>>>>>
>>>>>>>>   On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>
>>>>>>>>   We need to go for both (A) and (B).
>>>>>>>>
>>>>>>>>   We would need to deprecate the existing name before we
>> can allow it to
>>>>>>>>   not
>>>>>>>>   be supported. This means CDI 3. So I would suggest we
>> deprecate it in 2,
>>>>>>>>   add
>>>>>>>>   an alternative that can be used, and then consider
>> removing it in CDI 3.
>>>>>>>>   In
>>>>>>>>   the meantime for CDI 2, we will need to improve the TCK
>> to check this
>>>>>>>>   more
>>>>>>>>   carefully.
>>>>>>>>
>>>>>>>>   On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>   +1 for B (IMO it is not used that much)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   Romain Manni-Bucau
>>>>>>>>   @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>   2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>> <jharting at redhat.com>:
>>>>>>>>
>>>>>>>>   I think further action is needed on this. Now that it
>> has been confirmed
>>>>>>>>   that "javax.enterprise.context.conversation"
>> itself is not a valid EL
>>>>>>>>   name we should either:
>>>>>>>>
>>>>>>>>   A) Require all CDI implementations to adapt the
>> property-based approach
>>>>>>>>   which allows this to be implemented portably (as Weld
>> does)
>>>>>>>>   B) Declare publicly that although the CDI spec declares
>> the given name,
>>>>>>>>   it is a bug and applications should not use the name.
>> (What about
>>>>>>>>   compatibility with existing applications?)
>>>>>>>>
>>>>>>>>   Jozef
>>>>>>>>
>>>>>>>>   On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>   Dear CDI fellows!
>>>>>>>>
>>>>>>>>   I've received an answer regarding our EL question
>> from the EL Spec Lead.
>>>>>>>>
>>>>>>>>   Ed, thanks for helping us!
>>>>>>>>
>>>>>>>>
>>>>>>>>   LieGrue,
>>>>>>>>   strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   On Tuesday, 6 January 2015, 23:14, Edward Burns
>> <edward.burns at oracle.com>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>   Hello Mark,
>>>>>>>>
>>>>>>>>   To close this out, no, "." is not valid in an
>> EL name.  An EL name
>>>>>>>>   must
>>>>>>>>   be a java identifier.  I'm told this was discussed
>> by Pete a long time
>>>>>>>>   ago in the EL 3.0 EG.
>>>>>>>>
>>>>>>>>   Ed
>>>>>>>>
>>>>>>>>   --
>>>>>>>>   | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>   | 42 days til DevNexus 2015
>>>>>>>>   | 52 days til JavaLand 2015
>>>>>>>>   | 62 days til CONFESS 2015
>>>>>>>>
>>>>>>>>   _______________________________________________
>>>>>>>>   cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>   Note that for all code provided on this list, the
>> provider licenses the
>>>>>>>>   code
>>>>>>>>   under the Apache License, Version 2
>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>>>   provided on this list, the provider waives all patent
>> and other
>>>>>>>>   intellectual
>>>>>>>>   property rights inherent in such information.
>>>>>>>>
>>>>>>>>   _______________________________________________
>>>>>>>>   cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>   Note that for all code provided on this list, the
>> provider licenses the
>>>>>>>>   code
>>>>>>>>   under the Apache License, Version 2
>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>>>   provided on this list, the provider waives all patent
>> and other
>>>>>>>>   intellectual
>>>>>>>>   property rights inherent in such information.
>>>>>>>>
>>>>>>>>   _______________________________________________
>>>>>>>>   cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>   Note that for all code provided on this list, the
>> provider licenses the
>>>>>>>>   code
>>>>>>>>   under the Apache License, Version 2
>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>>>   provided on this list, the provider waives all patent
>> and other
>>>>>>>>   intellectual
>>>>>>>>   property rights inherent in such information.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   _______________________________________________
>>>>>>>>   cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>   Note that for all code provided on this list, the
>> provider licenses the
>>>>>>>>   code
>>>>>>>>   under the Apache License, Version 2
>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas
>>>>>>>>   provided on this list, the provider waives all patent
>> and other
>>>>>>>>   intellectual
>>>>>>>>   property rights inherent in such information.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

From rmannibucau at gmail.com  Thu Jan 15 03:23:43 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 15 Jan 2015 09:23:43 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B77761.6000706@redhat.com>
References: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>
	<626240826.1412846.1421307650013.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com>
	<54B77761.6000706@redhat.com>
Message-ID: <CACLE=7PDeupF0G2RRJeemu=ren8qZyksiLMp7F174qU8avHsqg@mail.gmail.com>

-1 to provide a bean "javax" it is worse than hacking EL to support it
since it also impacts other cases.

That said as Mark showed not having it is not a blocker for a user so
why not just adding the "SHOULD support for EL" since spec(s) dont
proove it is mandatory since EE 6.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
> Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>>>
>>> This has been a requirement since version 1.0, a number of years. How has
>>> OWB
>>> managed to not be compliant with this to date?
>>
>>
>>
>> I quickly checked the logs for the CDI-1.0 tck run and it seems that the
>> test even passes if #{javax.enterprise.context.conversation.id} resolves to
>> null. Not sure why though.
>>
>>
>> The other point is that OWB doesn't claim to pass the full TCK but only
>> the SE parts. This is the same as for Weld. With the CDI container alone you
>> simply cannot pass those.
>>
>> The EE part is being tested when being integrated into an EE server
>> (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an
>> additional ELResolver for it? But I honestly doubt it.
>>
>>
>>
>>> Yes, but we still have to implement the existing spec as it stands.
>>
>> I understand that we cannot make sure that nobody ever used this. But it
>> contradicts other (older) EE specs and the current wording is imo not that
>> clear that it is really mandatory to support it (as outlined in my other
>> mail).
>>
>> There is also a very easy hack to get this back if a user really wants:
>>
>> @Named("javax")
>> public class ConversationElHelperJavax {
>>
>>   public ConversationElHelperEnterprise getEnterprise() {..}
>>
>>
>>   public class ConversationElHelperEnterprise {
>>    public ConversationElHelperConversation getConversation()
>>
>>
>> }
>>
>> and the most inner class just returns the current Conversation instance.
>>
>>
>> Thus a user can totally easily get this behaviour by himself IF he needs
>> it!
>
>
> Wouldn't be better (from the user point of view) to provide such a bean in
> OWB? Just for compatibility reasons. Of course, we should also explicitly
> state that "javax.enterprise.context.conversation" is deprecated and users
> and encouraged not to use it...
>
> Moreover, I think there are more users using
> "javax.enterprise.context.conversation" than users having a CDI bean with
> name "javax".
>
>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>>
>>> From: Pete Muir <pmuir at redhat.com>
>>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev
>>> <cdi-dev at lists.jboss.org>
>>> Sent: Wednesday, 14 January 2015, 14:35
>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." is not valid
>>> in an EL name.
>>>
>>>
>>>>   On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>
>>> wrote:
>>>>
>>>>
>>>>   Well ATM there is no requirement it works
>>>
>>>
>>> There is a requirement that everything in the spec should work, yes.
>>>
>>>>   and I'm convinced another
>>>>   (better) solution will be found for coming versions
>>>
>>>
>>> Yes, but we still have to implement the existing spec as it stands.
>>>
>>>>   so I would really
>>>>   avoid to introduce a workaround on which users will not be able to
>>>>   rely.
>>>
>>>
>>> This has been a requirement since version 1.0, a number of years. How has
>>> OWB
>>> managed to not be compliant with this to date?
>>>
>>>>   Also Weld implementation breaks some valid usages of EL (since
>>>>   it is not done for javax only, right?).
>>>
>>>
>>> For example?
>>>
>>>
>>>>
>>>>
>>>>   Romain Manni-Bucau
>>>>   @rmannibucau
>>>>   http://www.tomitribe.com
>>>>   http://rmannibucau.wordpress.com
>>>>   https://github.com/rmannibucau
>>>>
>>>>
>>>>   2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>
>>>>>   I think you need to use the workaround of Weld. It works, and
>>>
>>> implements the spec as it stands, and means the test will pass. You can
>>> argue
>>> that the spec is not written in such a way that requires this to work,
>>> but you
>>> are splitting hairs at this point, and it was the intent of the 1.0 EG
>>> that it
>>> would work the way Weld implemented it.
>>>>>
>>>>>
>>>>>>   On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>>>
>>> <rmannibucau at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>   well issue is when you activate EL + CDI, if you respect both specs
>>>>>>   #{javax.enterprise.context.conversation.id} should fail -
>>>
>>> agree we can
>>>>>>
>>>>>>   always use the *workaround* of Weld but this is actually not
>>>
>>> mandated
>>>>>>
>>>>>>   by any spec excepted this test which was IMO an interpolation.
>>>
>>> That's
>>>>>>
>>>>>>   why i think this test shouldnt be kept even for 1.x versions.
>>>>>>
>>>>>>
>>>>>>   Romain Manni-Bucau
>>>>>>   @rmannibucau
>>>>>>   http://www.tomitribe.com
>>>>>>   http://rmannibucau.wordpress.com
>>>>>>   https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>   2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>>>
>>>>>>>   Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>>>>
>>>>>>>>
>>>>>>>>   If "there is no problem with not passing a particular
>>>
>>> test from the EL
>>>>>>>>
>>>>>>>>   spec" then there is no problem with not passing a
>>>
>>> particular test from
>>>>>>>>
>>>>>>>>   the CDI spec at EE level which seems wrong to me.
>>>>>>>>
>>>>>>>>   Globally I'd just remove this test and keep it in Weld
>>>
>>> vendor specific
>>>>>>>>
>>>>>>>>   features.
>>>>>>>>
>>>>>>>>   @martin: my 1) was for EL spec not CDI.
>>>>>>>>
>>>>>>>>   About 2
>>>
>>> "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>>>
>>>>>>>>   is a property of conversation which is a property of
>>>
>>> context which is
>>>>>>>>
>>>>>>>>   a property of enterprise which is a property of javax which
>>>
>>> is clearly
>>>>>>>>
>>>>>>>>   not what is desired and opposed to what is in the CDI spec.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   Sure. But EL cannot test this. From it's point of view the
>>>>>>>   "#{javax.enterprise.context.conversation.id}"
>>>
>>> expression is ok. From CDI
>>>>>>>
>>>>>>>   point of view the name is wrong and cannot be used as it is...
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   Romain Manni-Bucau
>>>>>>>>   @rmannibucau
>>>>>>>>   http://www.tomitribe.com
>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>   2015-01-14 13:12 GMT+01:00 Pete Muir
>>>
>>> <pmuir at redhat.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I agree with Martin. We *should* fix this situation in
>>>
>>> the long term,
>>>>>>>>>
>>>>>>>>>   which
>>>>>>>>>   is what I proposed. However in the short term there is
>>>
>>> no problem with
>>>>>>>>>
>>>>>>>>>   not
>>>>>>>>>   passing a particular test from the EL spec.
>>>
>>> Additionally this is provably
>>>>>>>>>
>>>>>>>>>   implementable as Weld implements this, and many Java EE
>>>
>>> containers pass.
>>>>>>>>>
>>>>>>>>>   As
>>>>>>>>>   there are no other spec defined beans javax, then we do
>>>
>>> not conflict with
>>>>>>>>>
>>>>>>>>>   any other spec by implementing it this way.
>>>>>>>>>
>>>>>>>>>   On 14 Jan 2015, at 12:10, Martin Kouba
>>>
>>> <mkouba at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>>>>
>>>>>>>>>   well there are 2 points:
>>>>>>>>>   1) a test should be added for it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   There was a CDI TCK test since 1.1
>>>>>>>>>
>>>>>>>>>
>>>
>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>>
>>>>>>>>>   It has been modified a week ago (see also CDITCK-462)
>>>
>>> not to use
>>>>>>>>>
>>>>>>>>>   "javax.enterprise.context.conversation.id".
>>>>>>>>>
>>>>>>>>>   2) test or not being certified means respecting the
>>>
>>> spec (pdf, javadoc
>>>>>>>>>
>>>>>>>>>   + tests themselve)
>>>>>>>>>
>>>>>>>>>   So if there is this test a container can't be
>>>
>>> certified for EL + CDI
>>>>>>>>>
>>>>>>>>>   at the same time
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I don't think it's a problem. An EL TCK test
>>>
>>> can't evaluate
>>>>>>>>>
>>>>>>>>>
>>> "#{javax.enterprise.context.conversation.id}" as an illegal
>>> expression -
>>>>>>>>>
>>>>>>>>>   it's obviously legal. The problem is
>>>>>>>>>   "javax.enterprise.context.conversation.id"
>>>
>>> can't be simply used as a bean
>>>>>>>>>
>>>>>>>>>   name. If it is, a workaround is needed (see also
>>>>>>>>>
>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Romain Manni-Bucau
>>>>>>>>>   @rmannibucau
>>>>>>>>>   http://www.tomitribe.com
>>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   2015-01-14 12:35 GMT+01:00 Pete Muir
>>>
>>> <pmuir at redhat.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Which EL test?
>>>>>>>>>
>>>>>>>>>   On 14 Jan 2015, at 11:30, Romain Manni-Bucau
>>>
>>> <rmannibucau at gmail.com>
>>>>>>>>>
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>>   then it will not pass EL one
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Romain Manni-Bucau
>>>>>>>>>   @rmannibucau
>>>>>>>>>   http://www.tomitribe.com
>>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   2015-01-14 12:27 GMT+01:00 Pete Muir
>>>
>>> <pmuir at redhat.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   No, a Java EE container needs to pass this test.
>>>>>>>>>
>>>>>>>>>   On 14 Jan 2015, at 11:21, Romain Manni-Bucau
>>>
>>> <rmannibucau at gmail.com>
>>>>>>>>>
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>>   so it means a JavaEE container will not pass this test
>>>
>>> but it is not an
>>>>>>>>>
>>>>>>>>>   issue?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Romain Manni-Bucau
>>>>>>>>>   @rmannibucau
>>>>>>>>>   http://www.tomitribe.com
>>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   2015-01-14 12:20 GMT+01:00 Pete Muir
>>>
>>> <pmuir at redhat.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I don?t think they should be excluded. The spec isn?t
>>>
>>> ambiguous about
>>>>>>>>>
>>>>>>>>>   this,
>>>>>>>>>   and it is supportable.
>>>>>>>>>
>>>>>>>>>   On 14 Jan 2015, at 11:13, Jozef Hartinger
>>>
>>> <jharting at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   So for CDI 1.2 the test that tests this should not be
>>>
>>> excluded after all,
>>>>>>>>>
>>>>>>>>>   correct?
>>>>>>>>>
>>>>>>>>>   On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>>
>>>>>>>>>   We need to go for both (A) and (B).
>>>>>>>>>
>>>>>>>>>   We would need to deprecate the existing name before we
>>>
>>> can allow it to
>>>>>>>>>
>>>>>>>>>   not
>>>>>>>>>   be supported. This means CDI 3. So I would suggest we
>>>
>>> deprecate it in 2,
>>>>>>>>>
>>>>>>>>>   add
>>>>>>>>>   an alternative that can be used, and then consider
>>>
>>> removing it in CDI 3.
>>>>>>>>>
>>>>>>>>>   In
>>>>>>>>>   the meantime for CDI 2, we will need to improve the TCK
>>>
>>> to check this
>>>>>>>>>
>>>>>>>>>   more
>>>>>>>>>   carefully.
>>>>>>>>>
>>>>>>>>>   On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>
>>> <rmannibucau at gmail.com>
>>>>>>>>>
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>>   +1 for B (IMO it is not used that much)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Romain Manni-Bucau
>>>>>>>>>   @rmannibucau
>>>>>>>>>   http://www.tomitribe.com
>>>>>>>>>   http://rmannibucau.wordpress.com
>>>>>>>>>   https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>
>>> <jharting at redhat.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I think further action is needed on this. Now that it
>>>
>>> has been confirmed
>>>>>>>>>
>>>>>>>>>   that "javax.enterprise.context.conversation"
>>>
>>> itself is not a valid EL
>>>>>>>>>
>>>>>>>>>   name we should either:
>>>>>>>>>
>>>>>>>>>   A) Require all CDI implementations to adapt the
>>>
>>> property-based approach
>>>>>>>>>
>>>>>>>>>   which allows this to be implemented portably (as Weld
>>>
>>> does)
>>>>>>>>>
>>>>>>>>>   B) Declare publicly that although the CDI spec declares
>>>
>>> the given name,
>>>>>>>>>
>>>>>>>>>   it is a bug and applications should not use the name.
>>>
>>> (What about
>>>>>>>>>
>>>>>>>>>   compatibility with existing applications?)
>>>>>>>>>
>>>>>>>>>   Jozef
>>>>>>>>>
>>>>>>>>>   On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>
>>>>>>>>>   Dear CDI fellows!
>>>>>>>>>
>>>>>>>>>   I've received an answer regarding our EL question
>>>
>>> from the EL Spec Lead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   Ed, thanks for helping us!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   LieGrue,
>>>>>>>>>   strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>
>>> <edward.burns at oracle.com>
>>>>>>>>>
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>>   Hello Mark,
>>>>>>>>>
>>>>>>>>>   To close this out, no, "." is not valid in an
>>>
>>> EL name.  An EL name
>>>>>>>>>
>>>>>>>>>   must
>>>>>>>>>   be a java identifier.  I'm told this was discussed
>>>
>>> by Pete a long time
>>>>>>>>>
>>>>>>>>>   ago in the EL 3.0 EG.
>>>>>>>>>
>>>>>>>>>   Ed
>>>>>>>>>
>>>>>>>>>   --
>>>>>>>>>   | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>   | 42 days til DevNexus 2015
>>>>>>>>>   | 52 days til JavaLand 2015
>>>>>>>>>   | 62 days til CONFESS 2015
>>>>>>>>>
>>>>>>>>>   _______________________________________________
>>>>>>>>>   cdi-dev mailing list
>>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>   Note that for all code provided on this list, the
>>>
>>> provider licenses the
>>>>>>>>>
>>>>>>>>>   code
>>>>>>>>>   under the Apache License, Version 2
>>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>
>>> all other ideas
>>>>>>>>>
>>>>>>>>>   provided on this list, the provider waives all patent
>>>
>>> and other
>>>>>>>>>
>>>>>>>>>   intellectual
>>>>>>>>>   property rights inherent in such information.
>>>>>>>>>
>>>>>>>>>   _______________________________________________
>>>>>>>>>   cdi-dev mailing list
>>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>   Note that for all code provided on this list, the
>>>
>>> provider licenses the
>>>>>>>>>
>>>>>>>>>   code
>>>>>>>>>   under the Apache License, Version 2
>>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>
>>> all other ideas
>>>>>>>>>
>>>>>>>>>   provided on this list, the provider waives all patent
>>>
>>> and other
>>>>>>>>>
>>>>>>>>>   intellectual
>>>>>>>>>   property rights inherent in such information.
>>>>>>>>>
>>>>>>>>>   _______________________________________________
>>>>>>>>>   cdi-dev mailing list
>>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>   Note that for all code provided on this list, the
>>>
>>> provider licenses the
>>>>>>>>>
>>>>>>>>>   code
>>>>>>>>>   under the Apache License, Version 2
>>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>
>>> all other ideas
>>>>>>>>>
>>>>>>>>>   provided on this list, the provider waives all patent
>>>
>>> and other
>>>>>>>>>
>>>>>>>>>   intellectual
>>>>>>>>>   property rights inherent in such information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   _______________________________________________
>>>>>>>>>   cdi-dev mailing list
>>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>   Note that for all code provided on this list, the
>>>
>>> provider licenses the
>>>>>>>>>
>>>>>>>>>   code
>>>>>>>>>   under the Apache License, Version 2
>>>>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>
>>> all other ideas
>>>>>>>>>
>>>>>>>>>   provided on this list, the provider waives all patent
>>>
>>> and other
>>>>>>>>>
>>>>>>>>>   intellectual
>>>>>>>>>   property rights inherent in such information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided
>>> on this list, the provider waives all patent and other intellectual
>>> property
>>> rights inherent in such information.
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
>>
>


From jharting at redhat.com  Thu Jan 15 04:46:48 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 10:46:48 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7PDeupF0G2RRJeemu=ren8qZyksiLMp7F174qU8avHsqg@mail.gmail.com>
References: <961398DB-B47B-48D7-BE13-A341D127947B@redhat.com>	<626240826.1412846.1421307650013.JavaMail.yahoo@jws11142.mail.ir2.yahoo.com>	<54B77761.6000706@redhat.com>
	<CACLE=7PDeupF0G2RRJeemu=ren8qZyksiLMp7F174qU8avHsqg@mail.gmail.com>
Message-ID: <54B78C88.4020409@redhat.com>

After looking into the spec again it became apparent to me that this is 
not an issue of a poorly chosen name for a built-in bean as it may look 
like at the first glance. Instead, CDI seems to define bean names on top 
of EL. It says:

"A valid bean name is a period-separated list of valid EL identifiers."

It even goes further and says:
"The following strings are valid bean names: com.acme.settings"

This means that a bean name *does not have to be a valid EL name*. It 
has to be a period-separated list of valid EL identifiers i.e. a valid 
EL expression. This implies that a CDI implementation needs to have a 
special mechanism for resolving a bean from an EL expression which 
recognizes the concept of bean names built on top of EL names (like Weld 
does).


On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote:
> -1 to provide a bean "javax" it is worse than hacking EL to support it
> since it also impacts other cases.
>
> That said as Mark showed not having it is not a blocker for a user so
> why not just adding the "SHOULD support for EL" since spec(s) dont
> proove it is mandatory since EE 6.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>> Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>>>> This has been a requirement since version 1.0, a number of years. How has
>>>> OWB
>>>> managed to not be compliant with this to date?
>>>
>>>
>>> I quickly checked the logs for the CDI-1.0 tck run and it seems that the
>>> test even passes if #{javax.enterprise.context.conversation.id} resolves to
>>> null. Not sure why though.
>>>
>>>
>>> The other point is that OWB doesn't claim to pass the full TCK but only
>>> the SE parts. This is the same as for Weld. With the CDI container alone you
>>> simply cannot pass those.
>>>
>>> The EE part is being tested when being integrated into an EE server
>>> (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an
>>> additional ELResolver for it? But I honestly doubt it.
>>>
>>>
>>>
>>>> Yes, but we still have to implement the existing spec as it stands.
>>> I understand that we cannot make sure that nobody ever used this. But it
>>> contradicts other (older) EE specs and the current wording is imo not that
>>> clear that it is really mandatory to support it (as outlined in my other
>>> mail).
>>>
>>> There is also a very easy hack to get this back if a user really wants:
>>>
>>> @Named("javax")
>>> public class ConversationElHelperJavax {
>>>
>>>    public ConversationElHelperEnterprise getEnterprise() {..}
>>>
>>>
>>>    public class ConversationElHelperEnterprise {
>>>     public ConversationElHelperConversation getConversation()
>>>
>>>
>>> }
>>>
>>> and the most inner class just returns the current Conversation instance.
>>>
>>>
>>> Thus a user can totally easily get this behaviour by himself IF he needs
>>> it!
>>
>> Wouldn't be better (from the user point of view) to provide such a bean in
>> OWB? Just for compatibility reasons. Of course, we should also explicitly
>> state that "javax.enterprise.context.conversation" is deprecated and users
>> and encouraged not to use it...
>>
>> Moreover, I think there are more users using
>> "javax.enterprise.context.conversation" than users having a CDI bean with
>> name "javax".
>>
>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Pete Muir <pmuir at redhat.com>
>>>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev
>>>> <cdi-dev at lists.jboss.org>
>>>> Sent: Wednesday, 14 January 2015, 14:35
>>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." is not valid
>>>> in an EL name.
>>>>
>>>>
>>>>>    On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau at gmail.com>
>>>> wrote:
>>>>>
>>>>>    Well ATM there is no requirement it works
>>>>
>>>> There is a requirement that everything in the spec should work, yes.
>>>>
>>>>>    and I'm convinced another
>>>>>    (better) solution will be found for coming versions
>>>>
>>>> Yes, but we still have to implement the existing spec as it stands.
>>>>
>>>>>    so I would really
>>>>>    avoid to introduce a workaround on which users will not be able to
>>>>>    rely.
>>>>
>>>> This has been a requirement since version 1.0, a number of years. How has
>>>> OWB
>>>> managed to not be compliant with this to date?
>>>>
>>>>>    Also Weld implementation breaks some valid usages of EL (since
>>>>>    it is not done for javax only, right?).
>>>>
>>>> For example?
>>>>
>>>>
>>>>>
>>>>>    Romain Manni-Bucau
>>>>>    @rmannibucau
>>>>>    http://www.tomitribe.com
>>>>>    http://rmannibucau.wordpress.com
>>>>>    https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>    2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>>>>>>    I think you need to use the workaround of Weld. It works, and
>>>> implements the spec as it stands, and means the test will pass. You can
>>>> argue
>>>> that the spec is not written in such a way that requires this to work,
>>>> but you
>>>> are splitting hairs at this point, and it was the intent of the 1.0 EG
>>>> that it
>>>> would work the way Weld implemented it.
>>>>>>
>>>>>>>    On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>>>> <rmannibucau at gmail.com> wrote:
>>>>>>>
>>>>>>>    well issue is when you activate EL + CDI, if you respect both specs
>>>>>>>    #{javax.enterprise.context.conversation.id} should fail -
>>>> agree we can
>>>>>>>    always use the *workaround* of Weld but this is actually not
>>>> mandated
>>>>>>>    by any spec excepted this test which was IMO an interpolation.
>>>> That's
>>>>>>>    why i think this test shouldnt be kept even for 1.x versions.
>>>>>>>
>>>>>>>
>>>>>>>    Romain Manni-Bucau
>>>>>>>    @rmannibucau
>>>>>>>    http://www.tomitribe.com
>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>    https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>    2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>>>>>    Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a):
>>>>>>>>>
>>>>>>>>>    If "there is no problem with not passing a particular
>>>> test from the EL
>>>>>>>>>    spec" then there is no problem with not passing a
>>>> particular test from
>>>>>>>>>    the CDI spec at EE level which seems wrong to me.
>>>>>>>>>
>>>>>>>>>    Globally I'd just remove this test and keep it in Weld
>>>> vendor specific
>>>>>>>>>    features.
>>>>>>>>>
>>>>>>>>>    @martin: my 1) was for EL spec not CDI.
>>>>>>>>>
>>>>>>>>>    About 2
>>>> "#{javax.enterprise.context.conversation.id}" is legal if id
>>>>>>>>>    is a property of conversation which is a property of
>>>> context which is
>>>>>>>>>    a property of enterprise which is a property of javax which
>>>> is clearly
>>>>>>>>>    not what is desired and opposed to what is in the CDI spec.
>>>>>>>>
>>>>>>>>
>>>>>>>>    Sure. But EL cannot test this. From it's point of view the
>>>>>>>>    "#{javax.enterprise.context.conversation.id}"
>>>> expression is ok. From CDI
>>>>>>>>    point of view the name is wrong and cannot be used as it is...
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    Romain Manni-Bucau
>>>>>>>>>    @rmannibucau
>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    2015-01-14 13:12 GMT+01:00 Pete Muir
>>>> <pmuir at redhat.com>:
>>>>>>>>>>
>>>>>>>>>>    I agree with Martin. We *should* fix this situation in
>>>> the long term,
>>>>>>>>>>    which
>>>>>>>>>>    is what I proposed. However in the short term there is
>>>> no problem with
>>>>>>>>>>    not
>>>>>>>>>>    passing a particular test from the EL spec.
>>>> Additionally this is provably
>>>>>>>>>>    implementable as Weld implements this, and many Java EE
>>>> containers pass.
>>>>>>>>>>    As
>>>>>>>>>>    there are no other spec defined beans javax, then we do
>>>> not conflict with
>>>>>>>>>>    any other spec by implementing it this way.
>>>>>>>>>>
>>>>>>>>>>    On 14 Jan 2015, at 12:10, Martin Kouba
>>>> <mkouba at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>    Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a):
>>>>>>>>>>
>>>>>>>>>>    well there are 2 points:
>>>>>>>>>>    1) a test should be added for it
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    There was a CDI TCK test since 1.1
>>>>>>>>>>
>>>>>>>>>>
>>>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>>>    It has been modified a week ago (see also CDITCK-462)
>>>> not to use
>>>>>>>>>>    "javax.enterprise.context.conversation.id".
>>>>>>>>>>
>>>>>>>>>>    2) test or not being certified means respecting the
>>>> spec (pdf, javadoc
>>>>>>>>>>    + tests themselve)
>>>>>>>>>>
>>>>>>>>>>    So if there is this test a container can't be
>>>> certified for EL + CDI
>>>>>>>>>>    at the same time
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    I don't think it's a problem. An EL TCK test
>>>> can't evaluate
>>>>>>>>>>
>>>> "#{javax.enterprise.context.conversation.id}" as an illegal
>>>> expression -
>>>>>>>>>>    it's obviously legal. The problem is
>>>>>>>>>>    "javax.enterprise.context.conversation.id"
>>>> can't be simply used as a bean
>>>>>>>>>>    name. If it is, a workaround is needed (see also
>>>>>>>>>>
>>>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Romain Manni-Bucau
>>>>>>>>>>    @rmannibucau
>>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    2015-01-14 12:35 GMT+01:00 Pete Muir
>>>> <pmuir at redhat.com>:
>>>>>>>>>>
>>>>>>>>>>    Which EL test?
>>>>>>>>>>
>>>>>>>>>>    On 14 Jan 2015, at 11:30, Romain Manni-Bucau
>>>> <rmannibucau at gmail.com>
>>>>>>>>>>    wrote:
>>>>>>>>>>
>>>>>>>>>>    then it will not pass EL one
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Romain Manni-Bucau
>>>>>>>>>>    @rmannibucau
>>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    2015-01-14 12:27 GMT+01:00 Pete Muir
>>>> <pmuir at redhat.com>:
>>>>>>>>>>
>>>>>>>>>>    No, a Java EE container needs to pass this test.
>>>>>>>>>>
>>>>>>>>>>    On 14 Jan 2015, at 11:21, Romain Manni-Bucau
>>>> <rmannibucau at gmail.com>
>>>>>>>>>>    wrote:
>>>>>>>>>>
>>>>>>>>>>    so it means a JavaEE container will not pass this test
>>>> but it is not an
>>>>>>>>>>    issue?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Romain Manni-Bucau
>>>>>>>>>>    @rmannibucau
>>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    2015-01-14 12:20 GMT+01:00 Pete Muir
>>>> <pmuir at redhat.com>:
>>>>>>>>>>
>>>>>>>>>>    I don?t think they should be excluded. The spec isn?t
>>>> ambiguous about
>>>>>>>>>>    this,
>>>>>>>>>>    and it is supportable.
>>>>>>>>>>
>>>>>>>>>>    On 14 Jan 2015, at 11:13, Jozef Hartinger
>>>> <jharting at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>    So for CDI 1.2 the test that tests this should not be
>>>> excluded after all,
>>>>>>>>>>    correct?
>>>>>>>>>>
>>>>>>>>>>    On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>>>>>>>>
>>>>>>>>>>    We need to go for both (A) and (B).
>>>>>>>>>>
>>>>>>>>>>    We would need to deprecate the existing name before we
>>>> can allow it to
>>>>>>>>>>    not
>>>>>>>>>>    be supported. This means CDI 3. So I would suggest we
>>>> deprecate it in 2,
>>>>>>>>>>    add
>>>>>>>>>>    an alternative that can be used, and then consider
>>>> removing it in CDI 3.
>>>>>>>>>>    In
>>>>>>>>>>    the meantime for CDI 2, we will need to improve the TCK
>>>> to check this
>>>>>>>>>>    more
>>>>>>>>>>    carefully.
>>>>>>>>>>
>>>>>>>>>>    On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>> <rmannibucau at gmail.com>
>>>>>>>>>>    wrote:
>>>>>>>>>>
>>>>>>>>>>    +1 for B (IMO it is not used that much)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Romain Manni-Bucau
>>>>>>>>>>    @rmannibucau
>>>>>>>>>>    http://www.tomitribe.com
>>>>>>>>>>    http://rmannibucau.wordpress.com
>>>>>>>>>>    https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>> <jharting at redhat.com>:
>>>>>>>>>>
>>>>>>>>>>    I think further action is needed on this. Now that it
>>>> has been confirmed
>>>>>>>>>>    that "javax.enterprise.context.conversation"
>>>> itself is not a valid EL
>>>>>>>>>>    name we should either:
>>>>>>>>>>
>>>>>>>>>>    A) Require all CDI implementations to adapt the
>>>> property-based approach
>>>>>>>>>>    which allows this to be implemented portably (as Weld
>>>> does)
>>>>>>>>>>    B) Declare publicly that although the CDI spec declares
>>>> the given name,
>>>>>>>>>>    it is a bug and applications should not use the name.
>>>> (What about
>>>>>>>>>>    compatibility with existing applications?)
>>>>>>>>>>
>>>>>>>>>>    Jozef
>>>>>>>>>>
>>>>>>>>>>    On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>
>>>>>>>>>>    Dear CDI fellows!
>>>>>>>>>>
>>>>>>>>>>    I've received an answer regarding our EL question
>>>> from the EL Spec Lead.
>>>>>>>>>>
>>>>>>>>>>    Ed, thanks for helping us!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    LieGrue,
>>>>>>>>>>    strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>> <edward.burns at oracle.com>
>>>>>>>>>>    wrote:
>>>>>>>>>>
>>>>>>>>>>    Hello Mark,
>>>>>>>>>>
>>>>>>>>>>    To close this out, no, "." is not valid in an
>>>> EL name.  An EL name
>>>>>>>>>>    must
>>>>>>>>>>    be a java identifier.  I'm told this was discussed
>>>> by Pete a long time
>>>>>>>>>>    ago in the EL 3.0 EG.
>>>>>>>>>>
>>>>>>>>>>    Ed
>>>>>>>>>>
>>>>>>>>>>    --
>>>>>>>>>>    | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>    | 42 days til DevNexus 2015
>>>>>>>>>>    | 52 days til JavaLand 2015
>>>>>>>>>>    | 62 days til CONFESS 2015
>>>>>>>>>>
>>>>>>>>>>    _______________________________________________
>>>>>>>>>>    cdi-dev mailing list
>>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>    Note that for all code provided on this list, the
>>>> provider licenses the
>>>>>>>>>>    code
>>>>>>>>>>    under the Apache License, Version 2
>>>>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>> all other ideas
>>>>>>>>>>    provided on this list, the provider waives all patent
>>>> and other
>>>>>>>>>>    intellectual
>>>>>>>>>>    property rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>    _______________________________________________
>>>>>>>>>>    cdi-dev mailing list
>>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>    Note that for all code provided on this list, the
>>>> provider licenses the
>>>>>>>>>>    code
>>>>>>>>>>    under the Apache License, Version 2
>>>>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>> all other ideas
>>>>>>>>>>    provided on this list, the provider waives all patent
>>>> and other
>>>>>>>>>>    intellectual
>>>>>>>>>>    property rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>    _______________________________________________
>>>>>>>>>>    cdi-dev mailing list
>>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>    Note that for all code provided on this list, the
>>>> provider licenses the
>>>>>>>>>>    code
>>>>>>>>>>    under the Apache License, Version 2
>>>>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>> all other ideas
>>>>>>>>>>    provided on this list, the provider waives all patent
>>>> and other
>>>>>>>>>>    intellectual
>>>>>>>>>>    property rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    _______________________________________________
>>>>>>>>>>    cdi-dev mailing list
>>>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>    Note that for all code provided on this list, the
>>>> provider licenses the
>>>>>>>>>>    code
>>>>>>>>>>    under the Apache License, Version 2
>>>>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>> all other ideas
>>>>>>>>>>    provided on this list, the provider waives all patent
>>>> and other
>>>>>>>>>>    intellectual
>>>>>>>>>>    property rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code
>>>> under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided
>>>> on this list, the provider waives all patent and other intellectual
>>>> property
>>>> rights inherent in such information.
>>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
>>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From jharting at redhat.com  Thu Jan 15 04:46:53 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 10:46:53 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <647471825.1124217.1421250317312.JavaMail.yahoo@jws11129.mail.ir2.yahoo.com>
References: <231901D8-E6AD-4BCD-A38C-E38A2DDF1553@redhat.com>
	<647471825.1124217.1421250317312.JavaMail.yahoo@jws11129.mail.ir2.yahoo.com>
Message-ID: <54B78C8D.3030201@redhat.com>

The @Named("javax") argument is not valid. The spec says:

Suppose two beans are both available for injection in a certain war, and 
either:
- the two beans have the same bean name and the name is not resolvable, or
- the bean name of one bean is of the form x.y, where y is a valid bean 
name, and x is the bean
name of the other bean,
the container automatically detects the problem and treats it as a 
deployment problem.

So we have two beans:
- javax.enterprise.context.conversation (the built-in one)
- javax (Marks's bean)

now:

1) the bean name of one bean is of the form x.y, where y is a valid bean 
name - that is javax.enterprise.context.conversation
x = javax
y = enterprise.context.conversation
2) and x is the bean name of the other bean - same as the name of Mark's 
@Named("javax") bean
3) the container automatically detects the problem and treats it as a 
deployment problem

Therefore, a bean named @Named("javax") will cause a deployment problem 
no matter whether it is actually available via EL or not.

To summarize, the spec already anticipates the problem and forbids this 
case explicitly.


On 01/14/2015 04:45 PM, Mark Struberg wrote:
> And then break all applications which have a @Named("javax") public class MyBean?
> It's simply not an option imo. It breaks lots of other specs and features. This is an XOR situation.
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns <edward.burns at oracle.com>
>> Sent: Wednesday, 14 January 2015, 11:56
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>>
>> We need to go for both (A) and (B).
>>
>> We would need to deprecate the existing name before we can allow it to not be
>> supported. This means CDI 3. So I would suggest we deprecate it in 2, add an
>> alternative that can be used, and then consider removing it in CDI 3. In the
>> meantime for CDI 2, we will need to improve the TCK to check this more
>> carefully.
>>
>>>   On 14 Jan 2015, at 10:09, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>>   +1 for B (IMO it is not used that much)
>>>
>>>
>>>
>>>
>>>   Romain Manni-Bucau
>>>   @rmannibucau
>>>   http://www.tomitribe.com
>>>   http://rmannibucau.wordpress.com
>>>   https://github.com/rmannibucau
>>>
>>>
>>>   2015-01-14 10:54 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>   I think further action is needed on this. Now that it has been
>> confirmed
>>>>   that "javax.enterprise.context.conversation" itself is not a
>> valid EL
>>>>   name we should either:
>>>>
>>>>   A) Require all CDI implementations to adapt the property-based approach
>>>>   which allows this to be implemented portably (as Weld does)
>>>>   B) Declare publicly that although the CDI spec declares the given name,
>>>>   it is a bug and applications should not use the name. (What about
>>>>   compatibility with existing applications?)
>>>>
>>>>   Jozef
>>>>
>>>>   On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>   Dear CDI fellows!
>>>>>
>>>>>   I've received an answer regarding our EL question from the EL
>> Spec Lead.
>>>>>   Ed, thanks for helping us!
>>>>>
>>>>>
>>>>>   LieGrue,
>>>>>   strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>   On Tuesday, 6 January 2015, 23:14, Edward Burns
>> <edward.burns at oracle.com> wrote:
>>>>>>>   Hello Mark,
>>>>>>   To close this out, no, "." is not valid in an EL
>> name.  An EL name
>>>>>>   must
>>>>>>   be a java identifier.  I'm told this was discussed by Pete
>> a long time
>>>>>>   ago in the EL 3.0 EG.
>>>>>>
>>>>>>   Ed
>>>>>>
>>>>>>   --
>>>>>>   | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>   | 42 days til DevNexus 2015
>>>>>>   | 52 days til JavaLand 2015
>>>>>>   | 62 days til CONFESS 2015
>>>>>>
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>>>   _______________________________________________
>>>>   cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
>>>   _______________________________________________
>>>   cdi-dev mailing list
>>>   cdi-dev at lists.jboss.org
>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


From struberg at yahoo.de  Thu Jan 15 05:04:54 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 15 Jan 2015 10:04:54 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <54B78C88.4020409@redhat.com>
References: <54B78C88.4020409@redhat.com>
Message-ID: <1210022827.1519071.1421316294249.JavaMail.yahoo@jws11137.mail.ir2.yahoo.com>

Weld does that, really?

so if I have
@Named("such.a.broken.pattern")
public class MyFunnyBean

then weld would properly resolve the following EL?

#{such.a.broken.pattern}


really?

If not then I will of course create a Weld blocker bug (*).


LieGrue,
strub



(*) just joking, but I hope you got my point.



----- Original Message -----
> From: Jozef Hartinger <jharting at redhat.com>
> To: Romain Manni-Bucau <rmannibucau at gmail.com>; Martin Kouba <mkouba at redhat.com>
> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Thursday, 15 January 2015, 10:46
> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
> 
> After looking into the spec again it became apparent to me that this is 
> not an issue of a poorly chosen name for a built-in bean as it may look 
> like at the first glance. Instead, CDI seems to define bean names on top 
> of EL. It says:
> 
> "A valid bean name is a period-separated list of valid EL 
> identifiers."
> 
> It even goes further and says:
> "The following strings are valid bean names: com.acme.settings"
> 
> This means that a bean name *does not have to be a valid EL name*. It 
> has to be a period-separated list of valid EL identifiers i.e. a valid 
> EL expression. This implies that a CDI implementation needs to have a 
> special mechanism for resolving a bean from an EL expression which 
> recognizes the concept of bean names built on top of EL names (like Weld 
> does).
> 
> 
> On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote:
>>  -1 to provide a bean "javax" it is worse than hacking EL to 
> support it
>>  since it also impacts other cases.
>> 
>>  That said as Mark showed not having it is not a blocker for a user so
>>  why not just adding the "SHOULD support for EL" since spec(s) 
> dont
>>  proove it is mandatory since EE 6.
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>  Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>>>>>  This has been a requirement since version 1.0, a number of 
> years. How has
>>>>>  OWB
>>>>>  managed to not be compliant with this to date?
>>>> 
>>>> 
>>>>  I quickly checked the logs for the CDI-1.0 tck run and it seems 
> that the
>>>>  test even passes if 
> #{javax.enterprise.context.conversation.id} resolves to
>>>>  null. Not sure why though.
>>>> 
>>>> 
>>>>  The other point is that OWB doesn't claim to pass the full TCK 
> but only
>>>>  the SE parts. This is the same as for Weld. With the CDI container 
> alone you
>>>>  simply cannot pass those.
>>>> 
>>>>  The EE part is being tested when being integrated into an EE server
>>>>  (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an
>>>>  additional ELResolver for it? But I honestly doubt it.
>>>> 
>>>> 
>>>> 
>>>>>  Yes, but we still have to implement the existing spec as it 
> stands.
>>>>  I understand that we cannot make sure that nobody ever used this. 
> But it
>>>>  contradicts other (older) EE specs and the current wording is imo 
> not that
>>>>  clear that it is really mandatory to support it (as outlined in my 
> other
>>>>  mail).
>>>> 
>>>>  There is also a very easy hack to get this back if a user really 
> wants:
>>>> 
>>>>  @Named("javax")
>>>>  public class ConversationElHelperJavax {
>>>> 
>>>>     public ConversationElHelperEnterprise getEnterprise() {..}
>>>> 
>>>> 
>>>>     public class ConversationElHelperEnterprise {
>>>>      public ConversationElHelperConversation getConversation()
>>>> 
>>>> 
>>>>  }
>>>> 
>>>>  and the most inner class just returns the current Conversation 
> instance.
>>>> 
>>>> 
>>>>  Thus a user can totally easily get this behaviour by himself IF he 
> needs
>>>>  it!
>>> 
>>>  Wouldn't be better (from the user point of view) to provide such a 
> bean in
>>>  OWB? Just for compatibility reasons. Of course, we should also 
> explicitly
>>>  state that "javax.enterprise.context.conversation" is 
> deprecated and users
>>>  and encouraged not to use it...
>>> 
>>>  Moreover, I think there are more users using
>>>  "javax.enterprise.context.conversation" than users having a 
> CDI bean with
>>>  name "javax".
>>> 
>>> 
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
>>>> 
>>>> 
>>>>  ----- Original Message -----
>>>>>  From: Pete Muir <pmuir at redhat.com>
>>>>>  To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>  Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev
>>>>>  <cdi-dev at lists.jboss.org>
>>>>>  Sent: Wednesday, 14 January 2015, 14:35
>>>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    
> "." is not valid
>>>>>  in an EL name.
>>>>> 
>>>>> 
>>>>>>     On 14 Jan 2015, at 13:31, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>  wrote:
>>>>>> 
>>>>>>     Well ATM there is no requirement it works
>>>>> 
>>>>>  There is a requirement that everything in the spec should work, 
> yes.
>>>>> 
>>>>>>     and I'm convinced another
>>>>>>     (better) solution will be found for coming versions
>>>>> 
>>>>>  Yes, but we still have to implement the existing spec as it 
> stands.
>>>>> 
>>>>>>     so I would really
>>>>>>     avoid to introduce a workaround on which users will not 
> be able to
>>>>>>     rely.
>>>>> 
>>>>>  This has been a requirement since version 1.0, a number of 
> years. How has
>>>>>  OWB
>>>>>  managed to not be compliant with this to date?
>>>>> 
>>>>>>     Also Weld implementation breaks some valid usages of EL 
> (since
>>>>>>     it is not done for javax only, right?).
>>>>> 
>>>>>  For example?
>>>>> 
>>>>> 
>>>>>> 
>>>>>>     Romain Manni-Bucau
>>>>>>     @rmannibucau
>>>>>>     http://www.tomitribe.com
>>>>>>     http://rmannibucau.wordpress.com
>>>>>>     https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>>     2015-01-14 14:28 GMT+01:00 Pete Muir 
> <pmuir at redhat.com>:
>>>>>>>     I think you need to use the workaround of Weld. It 
> works, and
>>>>>  implements the spec as it stands, and means the test will pass. 
> You can
>>>>>  argue
>>>>>  that the spec is not written in such a way that requires this 
> to work,
>>>>>  but you
>>>>>  are splitting hairs at this point, and it was the intent of the 
> 1.0 EG
>>>>>  that it
>>>>>  would work the way Weld implemented it.
>>>>>>> 
>>>>>>>>     On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>>>>>  <rmannibucau at gmail.com> wrote:
>>>>>>>> 
>>>>>>>>     well issue is when you activate EL + CDI, if you 
> respect both specs
>>>>>>>>     #{javax.enterprise.context.conversation.id} 
> should fail -
>>>>>  agree we can
>>>>>>>>     always use the *workaround* of Weld but this is 
> actually not
>>>>>  mandated
>>>>>>>>     by any spec excepted this test which was IMO an 
> interpolation.
>>>>>  That's
>>>>>>>>     why i think this test shouldnt be kept even for 
> 1.x versions.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>     Romain Manni-Bucau
>>>>>>>>     @rmannibucau
>>>>>>>>     http://www.tomitribe.com
>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>     https://github.com/rmannibucau
>>>>>>>> 
>>>>>>>> 
>>>>>>>>     2015-01-14 14:09 GMT+01:00 Martin Kouba 
> <mkouba at redhat.com>:
>>>>>>>>>     Dne 14.1.2015 v 13:42 Romain Manni-Bucau 
> napsal(a):
>>>>>>>>>> 
>>>>>>>>>>     If "there is no problem with not 
> passing a particular
>>>>>  test from the EL
>>>>>>>>>>     spec" then there is no problem with 
> not passing a
>>>>>  particular test from
>>>>>>>>>>     the CDI spec at EE level which seems 
> wrong to me.
>>>>>>>>>> 
>>>>>>>>>>     Globally I'd just remove this test 
> and keep it in Weld
>>>>>  vendor specific
>>>>>>>>>>     features.
>>>>>>>>>> 
>>>>>>>>>>     @martin: my 1) was for EL spec not CDI.
>>>>>>>>>> 
>>>>>>>>>>     About 2
>>>>>  "#{javax.enterprise.context.conversation.id}" is 
> legal if id
>>>>>>>>>>     is a property of conversation which is a 
> property of
>>>>>  context which is
>>>>>>>>>>     a property of enterprise which is a 
> property of javax which
>>>>>  is clearly
>>>>>>>>>>     not what is desired and opposed to what 
> is in the CDI spec.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>     Sure. But EL cannot test this. From it's 
> point of view the
>>>>>>>>>     
> "#{javax.enterprise.context.conversation.id}"
>>>>>  expression is ok. From CDI
>>>>>>>>>     point of view the name is wrong and cannot 
> be used as it is...
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>     @rmannibucau
>>>>>>>>>>     http://www.tomitribe.com
>>>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>     2015-01-14 13:12 GMT+01:00 Pete Muir
>>>>>  <pmuir at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>     I agree with Martin. We *should* fix 
> this situation in
>>>>>  the long term,
>>>>>>>>>>>     which
>>>>>>>>>>>     is what I proposed. However in the 
> short term there is
>>>>>  no problem with
>>>>>>>>>>>     not
>>>>>>>>>>>     passing a particular test from the 
> EL spec.
>>>>>  Additionally this is provably
>>>>>>>>>>>     implementable as Weld implements 
> this, and many Java EE
>>>>>  containers pass.
>>>>>>>>>>>     As
>>>>>>>>>>>     there are no other spec defined 
> beans javax, then we do
>>>>>  not conflict with
>>>>>>>>>>>     any other spec by implementing it 
> this way.
>>>>>>>>>>> 
>>>>>>>>>>>     On 14 Jan 2015, at 12:10, Martin 
> Kouba
>>>>>  <mkouba at redhat.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     Dne 14.1.2015 v 12:43 Romain 
> Manni-Bucau napsal(a):
>>>>>>>>>>> 
>>>>>>>>>>>     well there are 2 points:
>>>>>>>>>>>     1) a test should be added for it
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     There was a CDI TCK test since 1.1
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>> 
> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>>>>     It has been modified a week ago (see 
> also CDITCK-462)
>>>>>  not to use
>>>>>>>>>>>     
> "javax.enterprise.context.conversation.id".
>>>>>>>>>>> 
>>>>>>>>>>>     2) test or not being certified means 
> respecting the
>>>>>  spec (pdf, javadoc
>>>>>>>>>>>     + tests themselve)
>>>>>>>>>>> 
>>>>>>>>>>>     So if there is this test a container 
> can't be
>>>>>  certified for EL + CDI
>>>>>>>>>>>     at the same time
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     I don't think it's a 
> problem. An EL TCK test
>>>>>  can't evaluate
>>>>>>>>>>> 
>>>>>  "#{javax.enterprise.context.conversation.id}" as 
> an illegal
>>>>>  expression -
>>>>>>>>>>>     it's obviously legal. The 
> problem is
>>>>>>>>>>>     
> "javax.enterprise.context.conversation.id"
>>>>>  can't be simply used as a bean
>>>>>>>>>>>     name. If it is, a workaround is 
> needed (see also
>>>>>>>>>>> 
>>>>> 
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>>     @rmannibucau
>>>>>>>>>>>     http://www.tomitribe.com
>>>>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     2015-01-14 12:35 GMT+01:00 Pete Muir
>>>>>  <pmuir at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>     Which EL test?
>>>>>>>>>>> 
>>>>>>>>>>>     On 14 Jan 2015, at 11:30, Romain 
> Manni-Bucau
>>>>>  <rmannibucau at gmail.com>
>>>>>>>>>>>     wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     then it will not pass EL one
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>>     @rmannibucau
>>>>>>>>>>>     http://www.tomitribe.com
>>>>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     2015-01-14 12:27 GMT+01:00 Pete Muir
>>>>>  <pmuir at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>     No, a Java EE container needs to 
> pass this test.
>>>>>>>>>>> 
>>>>>>>>>>>     On 14 Jan 2015, at 11:21, Romain 
> Manni-Bucau
>>>>>  <rmannibucau at gmail.com>
>>>>>>>>>>>     wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     so it means a JavaEE container will 
> not pass this test
>>>>>  but it is not an
>>>>>>>>>>>     issue?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>>     @rmannibucau
>>>>>>>>>>>     http://www.tomitribe.com
>>>>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     2015-01-14 12:20 GMT+01:00 Pete Muir
>>>>>  <pmuir at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>     I don?t think they should be 
> excluded. The spec isn?t
>>>>>  ambiguous about
>>>>>>>>>>>     this,
>>>>>>>>>>>     and it is supportable.
>>>>>>>>>>> 
>>>>>>>>>>>     On 14 Jan 2015, at 11:13, Jozef 
> Hartinger
>>>>>  <jharting at redhat.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     So for CDI 1.2 the test that tests 
> this should not be
>>>>>  excluded after all,
>>>>>>>>>>>     correct?
>>>>>>>>>>> 
>>>>>>>>>>>     On 01/14/2015 11:56 AM, Pete Muir 
> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     We need to go for both (A) and (B).
>>>>>>>>>>> 
>>>>>>>>>>>     We would need to deprecate the 
> existing name before we
>>>>>  can allow it to
>>>>>>>>>>>     not
>>>>>>>>>>>     be supported. This means CDI 3. So I 
> would suggest we
>>>>>  deprecate it in 2,
>>>>>>>>>>>     add
>>>>>>>>>>>     an alternative that can be used, and 
> then consider
>>>>>  removing it in CDI 3.
>>>>>>>>>>>     In
>>>>>>>>>>>     the meantime for CDI 2, we will need 
> to improve the TCK
>>>>>  to check this
>>>>>>>>>>>     more
>>>>>>>>>>>     carefully.
>>>>>>>>>>> 
>>>>>>>>>>>     On 14 Jan 2015, at 10:09, Romain 
> Manni-Bucau
>>>>>  <rmannibucau at gmail.com>
>>>>>>>>>>>     wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     +1 for B (IMO it is not used that 
> much)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     Romain Manni-Bucau
>>>>>>>>>>>     @rmannibucau
>>>>>>>>>>>     http://www.tomitribe.com
>>>>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     2015-01-14 10:54 GMT+01:00 Jozef 
> Hartinger
>>>>>  <jharting at redhat.com>:
>>>>>>>>>>> 
>>>>>>>>>>>     I think further action is needed on 
> this. Now that it
>>>>>  has been confirmed
>>>>>>>>>>>     that 
> "javax.enterprise.context.conversation"
>>>>>  itself is not a valid EL
>>>>>>>>>>>     name we should either:
>>>>>>>>>>> 
>>>>>>>>>>>     A) Require all CDI implementations 
> to adapt the
>>>>>  property-based approach
>>>>>>>>>>>     which allows this to be implemented 
> portably (as Weld
>>>>>  does)
>>>>>>>>>>>     B) Declare publicly that although 
> the CDI spec declares
>>>>>  the given name,
>>>>>>>>>>>     it is a bug and applications should 
> not use the name.
>>>>>  (What about
>>>>>>>>>>>     compatibility with existing 
> applications?)
>>>>>>>>>>> 
>>>>>>>>>>>     Jozef
>>>>>>>>>>> 
>>>>>>>>>>>     On 01/08/2015 09:27 AM, Mark 
> Struberg wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     Dear CDI fellows!
>>>>>>>>>>> 
>>>>>>>>>>>     I've received an answer 
> regarding our EL question
>>>>>  from the EL Spec Lead.
>>>>>>>>>>> 
>>>>>>>>>>>     Ed, thanks for helping us!
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     LieGrue,
>>>>>>>>>>>     strub
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     On Tuesday, 6 January 2015, 23:14, 
> Edward Burns
>>>>>  <edward.burns at oracle.com>
>>>>>>>>>>>     wrote:
>>>>>>>>>>> 
>>>>>>>>>>>     Hello Mark,
>>>>>>>>>>> 
>>>>>>>>>>>     To close this out, no, "." 
> is not valid in an
>>>>>  EL name.  An EL name
>>>>>>>>>>>     must
>>>>>>>>>>>     be a java identifier.  I'm told 
> this was discussed
>>>>>  by Pete a long time
>>>>>>>>>>>     ago in the EL 3.0 EG.
>>>>>>>>>>> 
>>>>>>>>>>>     Ed
>>>>>>>>>>> 
>>>>>>>>>>>     --
>>>>>>>>>>>     | edward.burns at oracle.com | office: 
> +1 407 458 0017
>>>>>>>>>>>     | 42 days til DevNexus 2015
>>>>>>>>>>>     | 52 days til JavaLand 2015
>>>>>>>>>>>     | 62 days til CONFESS 2015
>>>>>>>>>>> 
>>>>>>>>>>>     
> _______________________________________________
>>>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>>>     
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>>     Note that for all code provided on 
> this list, the
>>>>>  provider licenses the
>>>>>>>>>>>     code
>>>>>>>>>>>     under the Apache License, Version 2
>>>>>>>>>>>     
> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>  all other ideas
>>>>>>>>>>>     provided on this list, the provider 
> waives all patent
>>>>>  and other
>>>>>>>>>>>     intellectual
>>>>>>>>>>>     property rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>>     
> _______________________________________________
>>>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>>>     
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>>     Note that for all code provided on 
> this list, the
>>>>>  provider licenses the
>>>>>>>>>>>     code
>>>>>>>>>>>     under the Apache License, Version 2
>>>>>>>>>>>     
> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>  all other ideas
>>>>>>>>>>>     provided on this list, the provider 
> waives all patent
>>>>>  and other
>>>>>>>>>>>     intellectual
>>>>>>>>>>>     property rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>>     
> _______________________________________________
>>>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>>>     
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>>     Note that for all code provided on 
> this list, the
>>>>>  provider licenses the
>>>>>>>>>>>     code
>>>>>>>>>>>     under the Apache License, Version 2
>>>>>>>>>>>     
> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>  all other ideas
>>>>>>>>>>>     provided on this list, the provider 
> waives all patent
>>>>>  and other
>>>>>>>>>>>     intellectual
>>>>>>>>>>>     property rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>     
> _______________________________________________
>>>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>>>     
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>>     Note that for all code provided on 
> this list, the
>>>>>  provider licenses the
>>>>>>>>>>>     code
>>>>>>>>>>>     under the Apache License, Version 2
>>>>>>>>>>>     
> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>  all other ideas
>>>>>>>>>>>     provided on this list, the provider 
> waives all patent
>>>>>  and other
>>>>>>>>>>>     intellectual
>>>>>>>>>>>     property rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>> 
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  cdi-dev at lists.jboss.org
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>  Note that for all code provided on this list, the provider 
> licenses the
>>>>>  code
>>>>>  under the Apache License, Version 2
>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all 
> other ideas
>>>>>  provided
>>>>>  on this list, the provider waives all patent and other 
> intellectual
>>>>>  property
>>>>>  rights inherent in such information.
>>>>> 
>>>>  _______________________________________________
>>>>  cdi-dev mailing list
>>>>  cdi-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>  Note that for all code provided on this list, the provider licenses 
> the
>>>>  code under the Apache License, Version 2
>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other 
> ideas
>>>>  provided on this list, the provider waives all patent and other 
> intellectual
>>>>  property rights inherent in such information.
>>>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
>


From struberg at yahoo.de  Thu Jan 15 05:11:52 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 15 Jan 2015 10:11:52 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <54B78C8D.3030201@redhat.com>
References: <54B78C8D.3030201@redhat.com>
Message-ID: <1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>

Jozef, your argumentation is flawed already at the very beginning. Currently there is no bean with the name "javax", thus "x.y ... and x is the bean name of the other bean" will not be a problem.

All that javax is simply not a bean name but a dirty hack in the ELResolver. That is something totally different.

Thus the rest of your argumentation chain is also invalid.

LieGrue,
strub


> On Thursday, 15 January 2015, 10:47, Jozef Hartinger <jharting at redhat.com> wrote:
> >T he @Named("javax") argument is not valid. The spec says:
> 
> Suppose two beans are both available for injection in a certain war, and 
> either:
> - the two beans have the same bean name and the name is not resolvable, or
> - the bean name of one bean is of the form x.y, where y is a valid bean 
> name, and x is the bean
> name of the other bean,
> the container automatically detects the problem and treats it as a 
> deployment problem.
> 
> So we have two beans:
> - javax.enterprise.context.conversation (the built-in one)
> - javax (Marks's bean)
> 
> now:
> 
> 1) the bean name of one bean is of the form x.y, where y is a valid bean 
> name - that is javax.enterprise.context.conversation
> x = javax
> y = enterprise.context.conversation
> 2) and x is the bean name of the other bean - same as the name of Mark's 
> @Named("javax") bean
> 3) the container automatically detects the problem and treats it as a 
> deployment problem
> 
> Therefore, a bean named @Named("javax") will cause a deployment 
> problem 
> no matter whether it is actually available via EL or not.
> 
> To summarize, the spec already anticipates the problem and forbids this 
> case explicitly.
> 
> 
> 
> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>  And then break all applications which have a @Named("javax") 
> public class MyBean?
>>  It's simply not an option imo. It breaks lots of other specs and 
> features. This is an XOR situation.
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>  Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns 
> <edward.burns at oracle.com>
>>>  Sent: Wednesday, 14 January 2015, 11:56
>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
> is not valid in an EL name.
>>> 
>>>  We need to go for both (A) and (B).
>>> 
>>>  We would need to deprecate the existing name before we can allow it to 
> not be
>>>  supported. This means CDI 3. So I would suggest we deprecate it in 2, 
> add an
>>>  alternative that can be used, and then consider removing it in CDI 3. 
> In the
>>>  meantime for CDI 2, we will need to improve the TCK to check this more
>>>  carefully.
>>> 
>>>>    On 14 Jan 2015, at 10:09, Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>  wrote:
>>>>    +1 for B (IMO it is not used that much)
>>>> 
>>>> 
>>>> 
>>>> 
>>>>    Romain Manni-Bucau
>>>>    @rmannibucau
>>>>   http://www.tomitribe.com
>>>>   http://rmannibucau.wordpress.com
>>>>   https://github.com/rmannibucau
>>>> 
>>>> 
>>>>    2015-01-14 10:54 GMT+01:00 Jozef Hartinger 
> <jharting at redhat.com>:
>>>>>    I think further action is needed on this. Now that it has 
> been
>>>  confirmed
>>>>>    that "javax.enterprise.context.conversation" itself 
> is not a
>>>  valid EL
>>>>>    name we should either:
>>>>> 
>>>>>    A) Require all CDI implementations to adapt the 
> property-based approach
>>>>>    which allows this to be implemented portably (as Weld does)
>>>>>    B) Declare publicly that although the CDI spec declares the 
> given name,
>>>>>    it is a bug and applications should not use the name. (What 
> about
>>>>>    compatibility with existing applications?)
>>>>> 
>>>>>    Jozef
>>>>> 
>>>>>    On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>    Dear CDI fellows!
>>>>>> 
>>>>>>    I've received an answer regarding our EL question 
> from the EL
>>>  Spec Lead.
>>>>>>    Ed, thanks for helping us!
>>>>>> 
>>>>>> 
>>>>>>    LieGrue,
>>>>>>    strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>    On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>  <edward.burns at oracle.com> wrote:
>>>>>>>>    Hello Mark,
>>>>>>>    To close this out, no, "." is not valid in 
> an EL
>>>  name.  An EL name
>>>>>>>    must
>>>>>>>    be a java identifier.  I'm told this was 
> discussed by Pete
>>>  a long time
>>>>>>>    ago in the EL 3.0 EG.
>>>>>>> 
>>>>>>>    Ed
>>>>>>> 
>>>>>>>    --
>>>>>>>    | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>    | 42 days til DevNexus 2015
>>>>>>>    | 52 days til JavaLand 2015
>>>>>>>    | 62 days til CONFESS 2015
>>>>>>> 
>>>>>>    _______________________________________________
>>>>>>    cdi-dev mailing list
>>>>>>   cdi-dev at lists.jboss.org
>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> 
>>>>>>    Note that for all code provided on this list, the 
> provider licenses
>>>  the code under the Apache License, Version 2
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided
>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>  rights inherent in such information.
>>>>>    _______________________________________________
>>>>>    cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>>    Note that for all code provided on this list, the provider 
> licenses the
>>>  code under the Apache License, Version 2
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided
>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>  rights inherent in such information.
>>> 
>>>>    _______________________________________________
>>>>    cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>>    Note that for all code provided on this list, the provider 
> licenses the
>>>  code under the Apache License, Version 2
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided
>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>  rights inherent in such information.
>>> 
>>> 
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>>  Note that for all code provided on this list, the provider licenses the 
> code
>>>  under the Apache License, Version 2
>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided
>>>  on this list, the provider waives all patent and other intellectual 
> property
>>>  rights inherent in such information.
>>> 
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>>  Note that for all code provided on this list, the provider licenses the 
> code under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided 
> on this list, the provider waives all patent and other intellectual property 
> rights inherent in such information.
> 

From jharting at redhat.com  Thu Jan 15 05:22:20 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 11:22:20 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <1210022827.1519071.1421316294249.JavaMail.yahoo@jws11137.mail.ir2.yahoo.com>
References: <54B78C88.4020409@redhat.com>
	<1210022827.1519071.1421316294249.JavaMail.yahoo@jws11137.mail.ir2.yahoo.com>
Message-ID: <54B794DC.6090900@redhat.com>


On 01/15/2015 11:04 AM, Mark Struberg wrote:
> Weld does that, really?
>
> so if I have
> @Named("such.a.broken.pattern")
> public class MyFunnyBean
>
> then weld would properly resolve the following EL?
>
> #{such.a.broken.pattern}
>
>
> really?
Yes, that's exactly what Weld has been doing since 2009 (as required by 
the spec) ;-)
>
> If not then I will of course create a Weld blocker bug (*).
In that case this would be a reasonable thing to do.
>
>
> LieGrue,
> strub
>
>
>
> (*) just joking, but I hope you got my point.
>
>
>
> ----- Original Message -----
>> From: Jozef Hartinger <jharting at redhat.com>
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>; Martin Kouba <mkouba at redhat.com>
>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Thursday, 15 January 2015, 10:46
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
>>
>> After looking into the spec again it became apparent to me that this is
>> not an issue of a poorly chosen name for a built-in bean as it may look
>> like at the first glance. Instead, CDI seems to define bean names on top
>> of EL. It says:
>>
>> "A valid bean name is a period-separated list of valid EL
>> identifiers."
>>
>> It even goes further and says:
>> "The following strings are valid bean names: com.acme.settings"
>>
>> This means that a bean name *does not have to be a valid EL name*. It
>> has to be a period-separated list of valid EL identifiers i.e. a valid
>> EL expression. This implies that a CDI implementation needs to have a
>> special mechanism for resolving a bean from an EL expression which
>> recognizes the concept of bean names built on top of EL names (like Weld
>> does).
>>
>>
>> On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote:
>>>   -1 to provide a bean "javax" it is worse than hacking EL to
>> support it
>>>   since it also impacts other cases.
>>>
>>>   That said as Mark showed not having it is not a blocker for a user so
>>>   why not just adding the "SHOULD support for EL" since spec(s)
>> dont
>>>   proove it is mandatory since EE 6.
>>>
>>>
>>>   Romain Manni-Bucau
>>>   @rmannibucau
>>>   http://www.tomitribe.com
>>>   http://rmannibucau.wordpress.com
>>>   https://github.com/rmannibucau
>>>
>>>
>>>   2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>>   Dne 15.1.2015 v 08:40 Mark Struberg napsal(a):
>>>>>>   This has been a requirement since version 1.0, a number of
>> years. How has
>>>>>>   OWB
>>>>>>   managed to not be compliant with this to date?
>>>>>
>>>>>   I quickly checked the logs for the CDI-1.0 tck run and it seems
>> that the
>>>>>   test even passes if
>> #{javax.enterprise.context.conversation.id} resolves to
>>>>>   null. Not sure why though.
>>>>>
>>>>>
>>>>>   The other point is that OWB doesn't claim to pass the full TCK
>> but only
>>>>>   the SE parts. This is the same as for Weld. With the CDI container
>> alone you
>>>>>   simply cannot pass those.
>>>>>
>>>>>   The EE part is being tested when being integrated into an EE server
>>>>>   (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an
>>>>>   additional ELResolver for it? But I honestly doubt it.
>>>>>
>>>>>
>>>>>
>>>>>>   Yes, but we still have to implement the existing spec as it
>> stands.
>>>>>   I understand that we cannot make sure that nobody ever used this.
>> But it
>>>>>   contradicts other (older) EE specs and the current wording is imo
>> not that
>>>>>   clear that it is really mandatory to support it (as outlined in my
>> other
>>>>>   mail).
>>>>>
>>>>>   There is also a very easy hack to get this back if a user really
>> wants:
>>>>>   @Named("javax")
>>>>>   public class ConversationElHelperJavax {
>>>>>
>>>>>      public ConversationElHelperEnterprise getEnterprise() {..}
>>>>>
>>>>>
>>>>>      public class ConversationElHelperEnterprise {
>>>>>       public ConversationElHelperConversation getConversation()
>>>>>
>>>>>
>>>>>   }
>>>>>
>>>>>   and the most inner class just returns the current Conversation
>> instance.
>>>>>
>>>>>   Thus a user can totally easily get this behaviour by himself IF he
>> needs
>>>>>   it!
>>>>   Wouldn't be better (from the user point of view) to provide such a
>> bean in
>>>>   OWB? Just for compatibility reasons. Of course, we should also
>> explicitly
>>>>   state that "javax.enterprise.context.conversation" is
>> deprecated and users
>>>>   and encouraged not to use it...
>>>>
>>>>   Moreover, I think there are more users using
>>>>   "javax.enterprise.context.conversation" than users having a
>> CDI bean with
>>>>   name "javax".
>>>>
>>>>
>>>>>   LieGrue,
>>>>>   strub
>>>>>
>>>>>
>>>>>
>>>>>   ----- Original Message -----
>>>>>>   From: Pete Muir <pmuir at redhat.com>
>>>>>>   To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>   Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev
>>>>>>   <cdi-dev at lists.jboss.org>
>>>>>>   Sent: Wednesday, 14 January 2015, 14:35
>>>>>>   Subject: Re: [cdi-dev] Answer from EL spec lead: no,
>> "." is not valid
>>>>>>   in an EL name.
>>>>>>
>>>>>>
>>>>>>>      On 14 Jan 2015, at 13:31, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>>>   wrote:
>>>>>>>      Well ATM there is no requirement it works
>>>>>>   There is a requirement that everything in the spec should work,
>> yes.
>>>>>>>      and I'm convinced another
>>>>>>>      (better) solution will be found for coming versions
>>>>>>   Yes, but we still have to implement the existing spec as it
>> stands.
>>>>>>>      so I would really
>>>>>>>      avoid to introduce a workaround on which users will not
>> be able to
>>>>>>>      rely.
>>>>>>   This has been a requirement since version 1.0, a number of
>> years. How has
>>>>>>   OWB
>>>>>>   managed to not be compliant with this to date?
>>>>>>
>>>>>>>      Also Weld implementation breaks some valid usages of EL
>> (since
>>>>>>>      it is not done for javax only, right?).
>>>>>>   For example?
>>>>>>
>>>>>>
>>>>>>>      Romain Manni-Bucau
>>>>>>>      @rmannibucau
>>>>>>>      http://www.tomitribe.com
>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>      https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>      2015-01-14 14:28 GMT+01:00 Pete Muir
>> <pmuir at redhat.com>:
>>>>>>>>      I think you need to use the workaround of Weld. It
>> works, and
>>>>>>   implements the spec as it stands, and means the test will pass.
>> You can
>>>>>>   argue
>>>>>>   that the spec is not written in such a way that requires this
>> to work,
>>>>>>   but you
>>>>>>   are splitting hairs at this point, and it was the intent of the
>> 1.0 EG
>>>>>>   that it
>>>>>>   would work the way Weld implemented it.
>>>>>>>>>      On 14 Jan 2015, at 13:13, Romain Manni-Bucau
>>>>>>   <rmannibucau at gmail.com> wrote:
>>>>>>>>>      well issue is when you activate EL + CDI, if you
>> respect both specs
>>>>>>>>>      #{javax.enterprise.context.conversation.id}
>> should fail -
>>>>>>   agree we can
>>>>>>>>>      always use the *workaround* of Weld but this is
>> actually not
>>>>>>   mandated
>>>>>>>>>      by any spec excepted this test which was IMO an
>> interpolation.
>>>>>>   That's
>>>>>>>>>      why i think this test shouldnt be kept even for
>> 1.x versions.
>>>>>>>>>
>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>      @rmannibucau
>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>      2015-01-14 14:09 GMT+01:00 Martin Kouba
>> <mkouba at redhat.com>:
>>>>>>>>>>      Dne 14.1.2015 v 13:42 Romain Manni-Bucau
>> napsal(a):
>>>>>>>>>>>      If "there is no problem with not
>> passing a particular
>>>>>>   test from the EL
>>>>>>>>>>>      spec" then there is no problem with
>> not passing a
>>>>>>   particular test from
>>>>>>>>>>>      the CDI spec at EE level which seems
>> wrong to me.
>>>>>>>>>>>      Globally I'd just remove this test
>> and keep it in Weld
>>>>>>   vendor specific
>>>>>>>>>>>      features.
>>>>>>>>>>>
>>>>>>>>>>>      @martin: my 1) was for EL spec not CDI.
>>>>>>>>>>>
>>>>>>>>>>>      About 2
>>>>>>   "#{javax.enterprise.context.conversation.id}" is
>> legal if id
>>>>>>>>>>>      is a property of conversation which is a
>> property of
>>>>>>   context which is
>>>>>>>>>>>      a property of enterprise which is a
>> property of javax which
>>>>>>   is clearly
>>>>>>>>>>>      not what is desired and opposed to what
>> is in the CDI spec.
>>>>>>>>>>
>>>>>>>>>>      Sure. But EL cannot test this. From it's
>> point of view the
>>>>>>>>>>      
>> "#{javax.enterprise.context.conversation.id}"
>>>>>>   expression is ok. From CDI
>>>>>>>>>>      point of view the name is wrong and cannot
>> be used as it is...
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>>>      @rmannibucau
>>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      2015-01-14 13:12 GMT+01:00 Pete Muir
>>>>>>   <pmuir at redhat.com>:
>>>>>>>>>>>>      I agree with Martin. We *should* fix
>> this situation in
>>>>>>   the long term,
>>>>>>>>>>>>      which
>>>>>>>>>>>>      is what I proposed. However in the
>> short term there is
>>>>>>   no problem with
>>>>>>>>>>>>      not
>>>>>>>>>>>>      passing a particular test from the
>> EL spec.
>>>>>>   Additionally this is provably
>>>>>>>>>>>>      implementable as Weld implements
>> this, and many Java EE
>>>>>>   containers pass.
>>>>>>>>>>>>      As
>>>>>>>>>>>>      there are no other spec defined
>> beans javax, then we do
>>>>>>   not conflict with
>>>>>>>>>>>>      any other spec by implementing it
>> this way.
>>>>>>>>>>>>      On 14 Jan 2015, at 12:10, Martin
>> Kouba
>>>>>>   <mkouba at redhat.com> wrote:
>>>>>>>>>>>>      Dne 14.1.2015 v 12:43 Romain
>> Manni-Bucau napsal(a):
>>>>>>>>>>>>      well there are 2 points:
>>>>>>>>>>>>      1) a test should be added for it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      There was a CDI TCK test since 1.1
>>>>>>>>>>>>
>>>>>>>>>>>>
>> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest).
>>>>>>>>>>>>      It has been modified a week ago (see
>> also CDITCK-462)
>>>>>>   not to use
>>>>>>>>>>>>      
>> "javax.enterprise.context.conversation.id".
>>>>>>>>>>>>      2) test or not being certified means
>> respecting the
>>>>>>   spec (pdf, javadoc
>>>>>>>>>>>>      + tests themselve)
>>>>>>>>>>>>
>>>>>>>>>>>>      So if there is this test a container
>> can't be
>>>>>>   certified for EL + CDI
>>>>>>>>>>>>      at the same time
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      I don't think it's a
>> problem. An EL TCK test
>>>>>>   can't evaluate
>>>>>>   "#{javax.enterprise.context.conversation.id}" as
>> an illegal
>>>>>>   expression -
>>>>>>>>>>>>      it's obviously legal. The
>> problem is
>>>>>>>>>>>>      
>> "javax.enterprise.context.conversation.id"
>>>>>>   can't be simply used as a bean
>>>>>>>>>>>>      name. If it is, a workaround is
>> needed (see also
>> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>>>>      @rmannibucau
>>>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      2015-01-14 12:35 GMT+01:00 Pete Muir
>>>>>>   <pmuir at redhat.com>:
>>>>>>>>>>>>      Which EL test?
>>>>>>>>>>>>
>>>>>>>>>>>>      On 14 Jan 2015, at 11:30, Romain
>> Manni-Bucau
>>>>>>   <rmannibucau at gmail.com>
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      then it will not pass EL one
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>>>>      @rmannibucau
>>>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      2015-01-14 12:27 GMT+01:00 Pete Muir
>>>>>>   <pmuir at redhat.com>:
>>>>>>>>>>>>      No, a Java EE container needs to
>> pass this test.
>>>>>>>>>>>>      On 14 Jan 2015, at 11:21, Romain
>> Manni-Bucau
>>>>>>   <rmannibucau at gmail.com>
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      so it means a JavaEE container will
>> not pass this test
>>>>>>   but it is not an
>>>>>>>>>>>>      issue?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>>>>      @rmannibucau
>>>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      2015-01-14 12:20 GMT+01:00 Pete Muir
>>>>>>   <pmuir at redhat.com>:
>>>>>>>>>>>>      I don?t think they should be
>> excluded. The spec isn?t
>>>>>>   ambiguous about
>>>>>>>>>>>>      this,
>>>>>>>>>>>>      and it is supportable.
>>>>>>>>>>>>
>>>>>>>>>>>>      On 14 Jan 2015, at 11:13, Jozef
>> Hartinger
>>>>>>   <jharting at redhat.com> wrote:
>>>>>>>>>>>>      So for CDI 1.2 the test that tests
>> this should not be
>>>>>>   excluded after all,
>>>>>>>>>>>>      correct?
>>>>>>>>>>>>
>>>>>>>>>>>>      On 01/14/2015 11:56 AM, Pete Muir
>> wrote:
>>>>>>>>>>>>      We need to go for both (A) and (B).
>>>>>>>>>>>>
>>>>>>>>>>>>      We would need to deprecate the
>> existing name before we
>>>>>>   can allow it to
>>>>>>>>>>>>      not
>>>>>>>>>>>>      be supported. This means CDI 3. So I
>> would suggest we
>>>>>>   deprecate it in 2,
>>>>>>>>>>>>      add
>>>>>>>>>>>>      an alternative that can be used, and
>> then consider
>>>>>>   removing it in CDI 3.
>>>>>>>>>>>>      In
>>>>>>>>>>>>      the meantime for CDI 2, we will need
>> to improve the TCK
>>>>>>   to check this
>>>>>>>>>>>>      more
>>>>>>>>>>>>      carefully.
>>>>>>>>>>>>
>>>>>>>>>>>>      On 14 Jan 2015, at 10:09, Romain
>> Manni-Bucau
>>>>>>   <rmannibucau at gmail.com>
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      +1 for B (IMO it is not used that
>> much)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      Romain Manni-Bucau
>>>>>>>>>>>>      @rmannibucau
>>>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      2015-01-14 10:54 GMT+01:00 Jozef
>> Hartinger
>>>>>>   <jharting at redhat.com>:
>>>>>>>>>>>>      I think further action is needed on
>> this. Now that it
>>>>>>   has been confirmed
>>>>>>>>>>>>      that
>> "javax.enterprise.context.conversation"
>>>>>>   itself is not a valid EL
>>>>>>>>>>>>      name we should either:
>>>>>>>>>>>>
>>>>>>>>>>>>      A) Require all CDI implementations
>> to adapt the
>>>>>>   property-based approach
>>>>>>>>>>>>      which allows this to be implemented
>> portably (as Weld
>>>>>>   does)
>>>>>>>>>>>>      B) Declare publicly that although
>> the CDI spec declares
>>>>>>   the given name,
>>>>>>>>>>>>      it is a bug and applications should
>> not use the name.
>>>>>>   (What about
>>>>>>>>>>>>      compatibility with existing
>> applications?)
>>>>>>>>>>>>      Jozef
>>>>>>>>>>>>
>>>>>>>>>>>>      On 01/08/2015 09:27 AM, Mark
>> Struberg wrote:
>>>>>>>>>>>>      Dear CDI fellows!
>>>>>>>>>>>>
>>>>>>>>>>>>      I've received an answer
>> regarding our EL question
>>>>>>   from the EL Spec Lead.
>>>>>>>>>>>>      Ed, thanks for helping us!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      LieGrue,
>>>>>>>>>>>>      strub
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      On Tuesday, 6 January 2015, 23:14,
>> Edward Burns
>>>>>>   <edward.burns at oracle.com>
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      Hello Mark,
>>>>>>>>>>>>
>>>>>>>>>>>>      To close this out, no, "."
>> is not valid in an
>>>>>>   EL name.  An EL name
>>>>>>>>>>>>      must
>>>>>>>>>>>>      be a java identifier.  I'm told
>> this was discussed
>>>>>>   by Pete a long time
>>>>>>>>>>>>      ago in the EL 3.0 EG.
>>>>>>>>>>>>
>>>>>>>>>>>>      Ed
>>>>>>>>>>>>
>>>>>>>>>>>>      --
>>>>>>>>>>>>      | edward.burns at oracle.com | office:
>> +1 407 458 0017
>>>>>>>>>>>>      | 42 days til DevNexus 2015
>>>>>>>>>>>>      | 52 days til JavaLand 2015
>>>>>>>>>>>>      | 62 days til CONFESS 2015
>>>>>>>>>>>>
>>>>>>>>>>>>      
>> _______________________________________________
>>>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>>      
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>      Note that for all code provided on
>> this list, the
>>>>>>   provider licenses the
>>>>>>>>>>>>      code
>>>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>>>      
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>>   all other ideas
>>>>>>>>>>>>      provided on this list, the provider
>> waives all patent
>>>>>>   and other
>>>>>>>>>>>>      intellectual
>>>>>>>>>>>>      property rights inherent in such
>> information.
>>>>>>>>>>>>      
>> _______________________________________________
>>>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>>      
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>      Note that for all code provided on
>> this list, the
>>>>>>   provider licenses the
>>>>>>>>>>>>      code
>>>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>>>      
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>>   all other ideas
>>>>>>>>>>>>      provided on this list, the provider
>> waives all patent
>>>>>>   and other
>>>>>>>>>>>>      intellectual
>>>>>>>>>>>>      property rights inherent in such
>> information.
>>>>>>>>>>>>      
>> _______________________________________________
>>>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>>      
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>      Note that for all code provided on
>> this list, the
>>>>>>   provider licenses the
>>>>>>>>>>>>      code
>>>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>>>      
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>>   all other ideas
>>>>>>>>>>>>      provided on this list, the provider
>> waives all patent
>>>>>>   and other
>>>>>>>>>>>>      intellectual
>>>>>>>>>>>>      property rights inherent in such
>> information.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      
>> _______________________________________________
>>>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>>      
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>      Note that for all code provided on
>> this list, the
>>>>>>   provider licenses the
>>>>>>>>>>>>      code
>>>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>>>      
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For
>>>>>>   all other ideas
>>>>>>>>>>>>      provided on this list, the provider
>> waives all patent
>>>>>>   and other
>>>>>>>>>>>>      intellectual
>>>>>>>>>>>>      property rights inherent in such
>> information.
>>>>>>>>>>>>
>>>>>>   _______________________________________________
>>>>>>   cdi-dev mailing list
>>>>>>   cdi-dev at lists.jboss.org
>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>   Note that for all code provided on this list, the provider
>> licenses the
>>>>>>   code
>>>>>>   under the Apache License, Version 2
>>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>> other ideas
>>>>>>   provided
>>>>>>   on this list, the provider waives all patent and other
>> intellectual
>>>>>>   property
>>>>>>   rights inherent in such information.
>>>>>>
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>> the
>>>>>   code under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>> ideas
>>>>>   provided on this list, the provider waives all patent and other
>> intellectual
>>>>>   property rights inherent in such information.
>>>>>
>>>   _______________________________________________
>>>   cdi-dev mailing list
>>>   cdi-dev at lists.jboss.org
>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>


From jharting at redhat.com  Thu Jan 15 05:22:44 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 11:22:44 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
Message-ID: <54B794F4.4090202@redhat.com>


On 01/15/2015 11:11 AM, Mark Struberg wrote:
> Jozef, your argumentation is flawed already at the very beginning. Currently there is no bean with the name "javax", thus "x.y ... and x is the bean name of the other bean" will not be a problem.
>
> All that javax is simply not a bean name but a dirty hack in the ELResolver. That is something totally different.
Mark, please read the e-mail again. I am not saying there are two beans 
named "javax". I am saying there are two beans with the following names:

- javax.enterprise.context.conversation (the built-in one)
- javax (Marks's bean)

where the former one is in form x.y where y is a valid bean name:
(javax) . (enterprise.context.conversation)

and thus since javax is both x above and a bean name of Mark's bean, 
this results in an exception.

>
> Thus the rest of your argumentation chain is also invalid.
>
> LieGrue,
> strub
>
>
>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger <jharting at redhat.com> wrote:
>>> T he @Named("javax") argument is not valid. The spec says:
>> Suppose two beans are both available for injection in a certain war, and
>> either:
>> - the two beans have the same bean name and the name is not resolvable, or
>> - the bean name of one bean is of the form x.y, where y is a valid bean
>> name, and x is the bean
>> name of the other bean,
>> the container automatically detects the problem and treats it as a
>> deployment problem.
>>
>> So we have two beans:
>> - javax.enterprise.context.conversation (the built-in one)
>> - javax (Marks's bean)
>>
>> now:
>>
>> 1) the bean name of one bean is of the form x.y, where y is a valid bean
>> name - that is javax.enterprise.context.conversation
>> x = javax
>> y = enterprise.context.conversation
>> 2) and x is the bean name of the other bean - same as the name of Mark's
>> @Named("javax") bean
>> 3) the container automatically detects the problem and treats it as a
>> deployment problem
>>
>> Therefore, a bean named @Named("javax") will cause a deployment
>> problem
>> no matter whether it is actually available via EL or not.
>>
>> To summarize, the spec already anticipates the problem and forbids this
>> case explicitly.
>>
>>
>>
>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>   And then break all applications which have a @Named("javax")
>> public class MyBean?
>>>   It's simply not an option imo. It breaks lots of other specs and
>> features. This is an XOR situation.
>>>
>>>   LieGrue,
>>>   strub
>>>
>>>
>>>
>>>
>>>   ----- Original Message -----
>>>>   From: Pete Muir <pmuir at redhat.com>
>>>>   To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>   Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>> <edward.burns at oracle.com>
>>>>   Sent: Wednesday, 14 January 2015, 11:56
>>>>   Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>> is not valid in an EL name.
>>>>   We need to go for both (A) and (B).
>>>>
>>>>   We would need to deprecate the existing name before we can allow it to
>> not be
>>>>   supported. This means CDI 3. So I would suggest we deprecate it in 2,
>> add an
>>>>   alternative that can be used, and then consider removing it in CDI 3.
>> In the
>>>>   meantime for CDI 2, we will need to improve the TCK to check this more
>>>>   carefully.
>>>>
>>>>>     On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>> <rmannibucau at gmail.com>
>>>>   wrote:
>>>>>     +1 for B (IMO it is not used that much)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     Romain Manni-Bucau
>>>>>     @rmannibucau
>>>>>    http://www.tomitribe.com
>>>>>    http://rmannibucau.wordpress.com
>>>>>    https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>     2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>> <jharting at redhat.com>:
>>>>>>     I think further action is needed on this. Now that it has
>> been
>>>>   confirmed
>>>>>>     that "javax.enterprise.context.conversation" itself
>> is not a
>>>>   valid EL
>>>>>>     name we should either:
>>>>>>
>>>>>>     A) Require all CDI implementations to adapt the
>> property-based approach
>>>>>>     which allows this to be implemented portably (as Weld does)
>>>>>>     B) Declare publicly that although the CDI spec declares the
>> given name,
>>>>>>     it is a bug and applications should not use the name. (What
>> about
>>>>>>     compatibility with existing applications?)
>>>>>>
>>>>>>     Jozef
>>>>>>
>>>>>>     On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>     Dear CDI fellows!
>>>>>>>
>>>>>>>     I've received an answer regarding our EL question
>> from the EL
>>>>   Spec Lead.
>>>>>>>     Ed, thanks for helping us!
>>>>>>>
>>>>>>>
>>>>>>>     LieGrue,
>>>>>>>     strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>   <edward.burns at oracle.com> wrote:
>>>>>>>>>     Hello Mark,
>>>>>>>>     To close this out, no, "." is not valid in
>> an EL
>>>>   name.  An EL name
>>>>>>>>     must
>>>>>>>>     be a java identifier.  I'm told this was
>> discussed by Pete
>>>>   a long time
>>>>>>>>     ago in the EL 3.0 EG.
>>>>>>>>
>>>>>>>>     Ed
>>>>>>>>
>>>>>>>>     --
>>>>>>>>     | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>     | 42 days til DevNexus 2015
>>>>>>>>     | 52 days til JavaLand 2015
>>>>>>>>     | 62 days til CONFESS 2015
>>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cdi-dev mailing list
>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>     Note that for all code provided on this list, the
>> provider licenses
>>>>   the code under the Apache License, Version 2
>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>   rights inherent in such information.
>>>>>>     _______________________________________________
>>>>>>     cdi-dev mailing list
>>>>>>    cdi-dev at lists.jboss.org
>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>     Note that for all code provided on this list, the provider
>> licenses the
>>>>   code under the Apache License, Version 2
>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>   rights inherent in such information.
>>>>
>>>>>     _______________________________________________
>>>>>     cdi-dev mailing list
>>>>>    cdi-dev at lists.jboss.org
>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>     Note that for all code provided on this list, the provider
>> licenses the
>>>>   code under the Apache License, Version 2
>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>   rights inherent in such information.
>>>>
>>>>
>>>>   _______________________________________________
>>>>   cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>   Note that for all code provided on this list, the provider licenses the
>> code
>>>>   under the Apache License, Version 2
>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>>   on this list, the provider waives all patent and other intellectual
>> property
>>>>   rights inherent in such information.
>>>>
>>>   _______________________________________________
>>>   cdi-dev mailing list
>>>   cdi-dev at lists.jboss.org
>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>   Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>> on this list, the provider waives all patent and other intellectual property
>> rights inherent in such information.
>>


From rmannibucau at gmail.com  Thu Jan 15 05:27:10 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 15 Jan 2015 11:27:10 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B794F4.4090202@redhat.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
Message-ID: <CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>

""A valid bean name is a period-separated list of valid EL
identifiers."" explicitely means a bean name is not a valid EL
identifier if it contains a period: all its parts are valid but put
together it is not more valid (as explained in EL spec with the period
meaning BTW).

This pattern is just not usable - I guess it is not used at all BTW:

@Named("team1.superBean") and @Named("team1.superBean.enriched") will
lead to conflicts and that's things I saw several times in spring apps
which are clearly not possible using CDI + EL properly.




Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>
>> Jozef, your argumentation is flawed already at the very beginning.
>> Currently there is no bean with the name "javax", thus "x.y ... and x is the
>> bean name of the other bean" will not be a problem.
>>
>> All that javax is simply not a bean name but a dirty hack in the
>> ELResolver. That is something totally different.
>
> Mark, please read the e-mail again. I am not saying there are two beans
> named "javax". I am saying there are two beans with the following names:
>
> - javax.enterprise.context.conversation (the built-in one)
> - javax (Marks's bean)
>
> where the former one is in form x.y where y is a valid bean name:
> (javax) . (enterprise.context.conversation)
>
> and thus since javax is both x above and a bean name of Mark's bean, this
> results in an exception.
>
>
>>
>> Thus the rest of your argumentation chain is also invalid.
>>
>> LieGrue,
>> strub
>>
>>
>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>> <jharting at redhat.com> wrote:
>>>>
>>>> T he @Named("javax") argument is not valid. The spec says:
>>>
>>> Suppose two beans are both available for injection in a certain war, and
>>> either:
>>> - the two beans have the same bean name and the name is not resolvable,
>>> or
>>> - the bean name of one bean is of the form x.y, where y is a valid bean
>>> name, and x is the bean
>>> name of the other bean,
>>> the container automatically detects the problem and treats it as a
>>> deployment problem.
>>>
>>> So we have two beans:
>>> - javax.enterprise.context.conversation (the built-in one)
>>> - javax (Marks's bean)
>>>
>>> now:
>>>
>>> 1) the bean name of one bean is of the form x.y, where y is a valid bean
>>> name - that is javax.enterprise.context.conversation
>>> x = javax
>>> y = enterprise.context.conversation
>>> 2) and x is the bean name of the other bean - same as the name of Mark's
>>> @Named("javax") bean
>>> 3) the container automatically detects the problem and treats it as a
>>> deployment problem
>>>
>>> Therefore, a bean named @Named("javax") will cause a deployment
>>> problem
>>> no matter whether it is actually available via EL or not.
>>>
>>> To summarize, the spec already anticipates the problem and forbids this
>>> case explicitly.
>>>
>>>
>>>
>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>
>>>>   And then break all applications which have a @Named("javax")
>>>
>>> public class MyBean?
>>>>
>>>>   It's simply not an option imo. It breaks lots of other specs and
>>>
>>> features. This is an XOR situation.
>>>>
>>>>
>>>>   LieGrue,
>>>>   strub
>>>>
>>>>
>>>>
>>>>
>>>>   ----- Original Message -----
>>>>>
>>>>>   From: Pete Muir <pmuir at redhat.com>
>>>>>   To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>   Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>
>>> <edward.burns at oracle.com>
>>>>>
>>>>>   Sent: Wednesday, 14 January 2015, 11:56
>>>>>   Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>
>>> is not valid in an EL name.
>>>>>
>>>>>   We need to go for both (A) and (B).
>>>>>
>>>>>   We would need to deprecate the existing name before we can allow it
>>>>> to
>>>
>>> not be
>>>>>
>>>>>   supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>
>>> add an
>>>>>
>>>>>   alternative that can be used, and then consider removing it in CDI 3.
>>>
>>> In the
>>>>>
>>>>>   meantime for CDI 2, we will need to improve the TCK to check this
>>>>> more
>>>>>   carefully.
>>>>>
>>>>>>     On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>
>>> <rmannibucau at gmail.com>
>>>>>
>>>>>   wrote:
>>>>>>
>>>>>>     +1 for B (IMO it is not used that much)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Romain Manni-Bucau
>>>>>>     @rmannibucau
>>>>>>    http://www.tomitribe.com
>>>>>>    http://rmannibucau.wordpress.com
>>>>>>    https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>     2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>
>>> <jharting at redhat.com>:
>>>>>>>
>>>>>>>     I think further action is needed on this. Now that it has
>>>
>>> been
>>>>>
>>>>>   confirmed
>>>>>>>
>>>>>>>     that "javax.enterprise.context.conversation" itself
>>>
>>> is not a
>>>>>
>>>>>   valid EL
>>>>>>>
>>>>>>>     name we should either:
>>>>>>>
>>>>>>>     A) Require all CDI implementations to adapt the
>>>
>>> property-based approach
>>>>>>>
>>>>>>>     which allows this to be implemented portably (as Weld does)
>>>>>>>     B) Declare publicly that although the CDI spec declares the
>>>
>>> given name,
>>>>>>>
>>>>>>>     it is a bug and applications should not use the name. (What
>>>
>>> about
>>>>>>>
>>>>>>>     compatibility with existing applications?)
>>>>>>>
>>>>>>>     Jozef
>>>>>>>
>>>>>>>     On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>     Dear CDI fellows!
>>>>>>>>
>>>>>>>>     I've received an answer regarding our EL question
>>>
>>> from the EL
>>>>>
>>>>>   Spec Lead.
>>>>>>>>
>>>>>>>>     Ed, thanks for helping us!
>>>>>>>>
>>>>>>>>
>>>>>>>>     LieGrue,
>>>>>>>>     strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>     On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>
>>>>>   <edward.burns at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>     Hello Mark,
>>>>>>>>>
>>>>>>>>>     To close this out, no, "." is not valid in
>>>
>>> an EL
>>>>>
>>>>>   name.  An EL name
>>>>>>>>>
>>>>>>>>>     must
>>>>>>>>>     be a java identifier.  I'm told this was
>>>
>>> discussed by Pete
>>>>>
>>>>>   a long time
>>>>>>>>>
>>>>>>>>>     ago in the EL 3.0 EG.
>>>>>>>>>
>>>>>>>>>     Ed
>>>>>>>>>
>>>>>>>>>     --
>>>>>>>>>     | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>     | 42 days til DevNexus 2015
>>>>>>>>>     | 52 days til JavaLand 2015
>>>>>>>>>     | 62 days til CONFESS 2015
>>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the
>>>
>>> provider licenses
>>>>>
>>>>>   the code under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>> ideas
>>>
>>> provided
>>>>>
>>>>>   on this list, the provider waives all patent and other intellectual
>>>
>>> property
>>>>>
>>>>>   rights inherent in such information.
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cdi-dev mailing list
>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>     Note that for all code provided on this list, the provider
>>>
>>> licenses the
>>>>>
>>>>>   code under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>> ideas
>>>
>>> provided
>>>>>
>>>>>   on this list, the provider waives all patent and other intellectual
>>>
>>> property
>>>>>
>>>>>   rights inherent in such information.
>>>>>
>>>>>>     _______________________________________________
>>>>>>     cdi-dev mailing list
>>>>>>    cdi-dev at lists.jboss.org
>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>     Note that for all code provided on this list, the provider
>>>
>>> licenses the
>>>>>
>>>>>   code under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>> ideas
>>>
>>> provided
>>>>>
>>>>>   on this list, the provider waives all patent and other intellectual
>>>
>>> property
>>>>>
>>>>>   rights inherent in such information.
>>>>>
>>>>>
>>>>>   _______________________________________________
>>>>>   cdi-dev mailing list
>>>>>   cdi-dev at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>   Note that for all code provided on this list, the provider licenses
>>>>> the
>>>
>>> code
>>>>>
>>>>>   under the Apache License, Version 2
>>>>>   (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>> ideas
>>>
>>> provided
>>>>>
>>>>>   on this list, the provider waives all patent and other intellectual
>>>
>>> property
>>>>>
>>>>>   rights inherent in such information.
>>>>>
>>>>   _______________________________________________
>>>>   cdi-dev mailing list
>>>>   cdi-dev at lists.jboss.org
>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>   Note that for all code provided on this list, the provider licenses
>>>> the
>>>
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided
>>> on this list, the provider waives all patent and other intellectual
>>> property
>>> rights inherent in such information.
>>>
>

From jharting at redhat.com  Thu Jan 15 05:33:05 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 11:33:05 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
Message-ID: <54B79761.5020906@redhat.com>


On 01/15/2015 11:27 AM, Romain Manni-Bucau wrote:
> ""A valid bean name is a period-separated list of valid EL
> identifiers."" explicitely means a bean name is not a valid EL
> identifier if it contains a period: all its parts are valid but put
> together it is not more valid (as explained in EL spec with the period
> meaning BTW).
Yes, a bean name is not necessarily a valid EL identifier. It however is 
a valid EL expression.
>
> This pattern is just not usable - I guess it is not used at all BTW:
>
> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
> lead to conflicts and that's things I saw several times in spring apps
> which are clearly not possible using CDI + EL properly.
Yes and these conflicts are handled by the spec. See 5.3.1
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>> Jozef, your argumentation is flawed already at the very beginning.
>>> Currently there is no bean with the name "javax", thus "x.y ... and x is the
>>> bean name of the other bean" will not be a problem.
>>>
>>> All that javax is simply not a bean name but a dirty hack in the
>>> ELResolver. That is something totally different.
>> Mark, please read the e-mail again. I am not saying there are two beans
>> named "javax". I am saying there are two beans with the following names:
>>
>> - javax.enterprise.context.conversation (the built-in one)
>> - javax (Marks's bean)
>>
>> where the former one is in form x.y where y is a valid bean name:
>> (javax) . (enterprise.context.conversation)
>>
>> and thus since javax is both x above and a bean name of Mark's bean, this
>> results in an exception.
>>
>>
>>> Thus the rest of your argumentation chain is also invalid.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>> <jharting at redhat.com> wrote:
>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>> Suppose two beans are both available for injection in a certain war, and
>>>> either:
>>>> - the two beans have the same bean name and the name is not resolvable,
>>>> or
>>>> - the bean name of one bean is of the form x.y, where y is a valid bean
>>>> name, and x is the bean
>>>> name of the other bean,
>>>> the container automatically detects the problem and treats it as a
>>>> deployment problem.
>>>>
>>>> So we have two beans:
>>>> - javax.enterprise.context.conversation (the built-in one)
>>>> - javax (Marks's bean)
>>>>
>>>> now:
>>>>
>>>> 1) the bean name of one bean is of the form x.y, where y is a valid bean
>>>> name - that is javax.enterprise.context.conversation
>>>> x = javax
>>>> y = enterprise.context.conversation
>>>> 2) and x is the bean name of the other bean - same as the name of Mark's
>>>> @Named("javax") bean
>>>> 3) the container automatically detects the problem and treats it as a
>>>> deployment problem
>>>>
>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>> problem
>>>> no matter whether it is actually available via EL or not.
>>>>
>>>> To summarize, the spec already anticipates the problem and forbids this
>>>> case explicitly.
>>>>
>>>>
>>>>
>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>    And then break all applications which have a @Named("javax")
>>>> public class MyBean?
>>>>>    It's simply not an option imo. It breaks lots of other specs and
>>>> features. This is an XOR situation.
>>>>>
>>>>>    LieGrue,
>>>>>    strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    ----- Original Message -----
>>>>>>    From: Pete Muir <pmuir at redhat.com>
>>>>>>    To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>    Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>> <edward.burns at oracle.com>
>>>>>>    Sent: Wednesday, 14 January 2015, 11:56
>>>>>>    Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>> is not valid in an EL name.
>>>>>>    We need to go for both (A) and (B).
>>>>>>
>>>>>>    We would need to deprecate the existing name before we can allow it
>>>>>> to
>>>> not be
>>>>>>    supported. This means CDI 3. So I would suggest we deprecate it in 2,
>>>> add an
>>>>>>    alternative that can be used, and then consider removing it in CDI 3.
>>>> In the
>>>>>>    meantime for CDI 2, we will need to improve the TCK to check this
>>>>>> more
>>>>>>    carefully.
>>>>>>
>>>>>>>      On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>> <rmannibucau at gmail.com>
>>>>>>    wrote:
>>>>>>>      +1 for B (IMO it is not used that much)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>      Romain Manni-Bucau
>>>>>>>      @rmannibucau
>>>>>>>     http://www.tomitribe.com
>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>     https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>      2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>> <jharting at redhat.com>:
>>>>>>>>      I think further action is needed on this. Now that it has
>>>> been
>>>>>>    confirmed
>>>>>>>>      that "javax.enterprise.context.conversation" itself
>>>> is not a
>>>>>>    valid EL
>>>>>>>>      name we should either:
>>>>>>>>
>>>>>>>>      A) Require all CDI implementations to adapt the
>>>> property-based approach
>>>>>>>>      which allows this to be implemented portably (as Weld does)
>>>>>>>>      B) Declare publicly that although the CDI spec declares the
>>>> given name,
>>>>>>>>      it is a bug and applications should not use the name. (What
>>>> about
>>>>>>>>      compatibility with existing applications?)
>>>>>>>>
>>>>>>>>      Jozef
>>>>>>>>
>>>>>>>>      On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>      Dear CDI fellows!
>>>>>>>>>
>>>>>>>>>      I've received an answer regarding our EL question
>>>> from the EL
>>>>>>    Spec Lead.
>>>>>>>>>      Ed, thanks for helping us!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>      LieGrue,
>>>>>>>>>      strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>      On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>    <edward.burns at oracle.com> wrote:
>>>>>>>>>>>      Hello Mark,
>>>>>>>>>>      To close this out, no, "." is not valid in
>>>> an EL
>>>>>>    name.  An EL name
>>>>>>>>>>      must
>>>>>>>>>>      be a java identifier.  I'm told this was
>>>> discussed by Pete
>>>>>>    a long time
>>>>>>>>>>      ago in the EL 3.0 EG.
>>>>>>>>>>
>>>>>>>>>>      Ed
>>>>>>>>>>
>>>>>>>>>>      --
>>>>>>>>>>      | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>      | 42 days til DevNexus 2015
>>>>>>>>>>      | 52 days til JavaLand 2015
>>>>>>>>>>      | 62 days til CONFESS 2015
>>>>>>>>>>
>>>>>>>>>      _______________________________________________
>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>      Note that for all code provided on this list, the
>>>> provider licenses
>>>>>>    the code under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas
>>>> provided
>>>>>>    on this list, the provider waives all patent and other intellectual
>>>> property
>>>>>>    rights inherent in such information.
>>>>>>>>      _______________________________________________
>>>>>>>>      cdi-dev mailing list
>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>      Note that for all code provided on this list, the provider
>>>> licenses the
>>>>>>    code under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas
>>>> provided
>>>>>>    on this list, the provider waives all patent and other intellectual
>>>> property
>>>>>>    rights inherent in such information.
>>>>>>
>>>>>>>      _______________________________________________
>>>>>>>      cdi-dev mailing list
>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>      Note that for all code provided on this list, the provider
>>>> licenses the
>>>>>>    code under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas
>>>> provided
>>>>>>    on this list, the provider waives all patent and other intellectual
>>>> property
>>>>>>    rights inherent in such information.
>>>>>>
>>>>>>
>>>>>>    _______________________________________________
>>>>>>    cdi-dev mailing list
>>>>>>    cdi-dev at lists.jboss.org
>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>    Note that for all code provided on this list, the provider licenses
>>>>>> the
>>>> code
>>>>>>    under the Apache License, Version 2
>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas
>>>> provided
>>>>>>    on this list, the provider waives all patent and other intellectual
>>>> property
>>>>>>    rights inherent in such information.
>>>>>>
>>>>>    _______________________________________________
>>>>>    cdi-dev mailing list
>>>>>    cdi-dev at lists.jboss.org
>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>    Note that for all code provided on this list, the provider licenses
>>>>> the
>>>> code under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>> provided
>>>> on this list, the provider waives all patent and other intellectual
>>>> property
>>>> rights inherent in such information.
>>>>


From rmannibucau at gmail.com  Thu Jan 15 05:35:51 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 15 Jan 2015 11:35:51 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B79761.5020906@redhat.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
Message-ID: <CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>

>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>> lead to conflicts and that's things I saw several times in spring apps
>> which are clearly not possible using CDI + EL properly.
>
> Yes and these conflicts are handled by the spec. See 5.3.1
>

Hmm not sure. If enriched is a property of the first bean then spec
doesn't help.

>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>
>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>
>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>> Currently there is no bean with the name "javax", thus "x.y ... and x is
>>>> the
>>>> bean name of the other bean" will not be a problem.
>>>>
>>>> All that javax is simply not a bean name but a dirty hack in the
>>>> ELResolver. That is something totally different.
>>>
>>> Mark, please read the e-mail again. I am not saying there are two beans
>>> named "javax". I am saying there are two beans with the following names:
>>>
>>> - javax.enterprise.context.conversation (the built-in one)
>>> - javax (Marks's bean)
>>>
>>> where the former one is in form x.y where y is a valid bean name:
>>> (javax) . (enterprise.context.conversation)
>>>
>>> and thus since javax is both x above and a bean name of Mark's bean, this
>>> results in an exception.
>>>
>>>
>>>> Thus the rest of your argumentation chain is also invalid.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>> <jharting at redhat.com> wrote:
>>>>>>
>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>
>>>>> Suppose two beans are both available for injection in a certain war,
>>>>> and
>>>>> either:
>>>>> - the two beans have the same bean name and the name is not resolvable,
>>>>> or
>>>>> - the bean name of one bean is of the form x.y, where y is a valid bean
>>>>> name, and x is the bean
>>>>> name of the other bean,
>>>>> the container automatically detects the problem and treats it as a
>>>>> deployment problem.
>>>>>
>>>>> So we have two beans:
>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>> - javax (Marks's bean)
>>>>>
>>>>> now:
>>>>>
>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>> bean
>>>>> name - that is javax.enterprise.context.conversation
>>>>> x = javax
>>>>> y = enterprise.context.conversation
>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>> Mark's
>>>>> @Named("javax") bean
>>>>> 3) the container automatically detects the problem and treats it as a
>>>>> deployment problem
>>>>>
>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>> problem
>>>>> no matter whether it is actually available via EL or not.
>>>>>
>>>>> To summarize, the spec already anticipates the problem and forbids this
>>>>> case explicitly.
>>>>>
>>>>>
>>>>>
>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>
>>>>>>    And then break all applications which have a @Named("javax")
>>>>>
>>>>> public class MyBean?
>>>>>>
>>>>>>    It's simply not an option imo. It breaks lots of other specs and
>>>>>
>>>>> features. This is an XOR situation.
>>>>>>
>>>>>>
>>>>>>    LieGrue,
>>>>>>    strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    ----- Original Message -----
>>>>>>>
>>>>>>>    From: Pete Muir <pmuir at redhat.com>
>>>>>>>    To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>    Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>
>>>>> <edward.burns at oracle.com>
>>>>>>>
>>>>>>>    Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>    Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>
>>>>> is not valid in an EL name.
>>>>>>>
>>>>>>>    We need to go for both (A) and (B).
>>>>>>>
>>>>>>>    We would need to deprecate the existing name before we can allow
>>>>>>> it
>>>>>>> to
>>>>>
>>>>> not be
>>>>>>>
>>>>>>>    supported. This means CDI 3. So I would suggest we deprecate it in
>>>>>>> 2,
>>>>>
>>>>> add an
>>>>>>>
>>>>>>>    alternative that can be used, and then consider removing it in CDI
>>>>>>> 3.
>>>>>
>>>>> In the
>>>>>>>
>>>>>>>    meantime for CDI 2, we will need to improve the TCK to check this
>>>>>>> more
>>>>>>>    carefully.
>>>>>>>
>>>>>>>>      On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>
>>>>> <rmannibucau at gmail.com>
>>>>>>>
>>>>>>>    wrote:
>>>>>>>>
>>>>>>>>      +1 for B (IMO it is not used that much)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>      Romain Manni-Bucau
>>>>>>>>      @rmannibucau
>>>>>>>>     http://www.tomitribe.com
>>>>>>>>     http://rmannibucau.wordpress.com
>>>>>>>>     https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>      2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>
>>>>> <jharting at redhat.com>:
>>>>>>>>>
>>>>>>>>>      I think further action is needed on this. Now that it has
>>>>>
>>>>> been
>>>>>>>
>>>>>>>    confirmed
>>>>>>>>>
>>>>>>>>>      that "javax.enterprise.context.conversation" itself
>>>>>
>>>>> is not a
>>>>>>>
>>>>>>>    valid EL
>>>>>>>>>
>>>>>>>>>      name we should either:
>>>>>>>>>
>>>>>>>>>      A) Require all CDI implementations to adapt the
>>>>>
>>>>> property-based approach
>>>>>>>>>
>>>>>>>>>      which allows this to be implemented portably (as Weld does)
>>>>>>>>>      B) Declare publicly that although the CDI spec declares the
>>>>>
>>>>> given name,
>>>>>>>>>
>>>>>>>>>      it is a bug and applications should not use the name. (What
>>>>>
>>>>> about
>>>>>>>>>
>>>>>>>>>      compatibility with existing applications?)
>>>>>>>>>
>>>>>>>>>      Jozef
>>>>>>>>>
>>>>>>>>>      On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>
>>>>>>>>>>      Dear CDI fellows!
>>>>>>>>>>
>>>>>>>>>>      I've received an answer regarding our EL question
>>>>>
>>>>> from the EL
>>>>>>>
>>>>>>>    Spec Lead.
>>>>>>>>>>
>>>>>>>>>>      Ed, thanks for helping us!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>      LieGrue,
>>>>>>>>>>      strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>      On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>
>>>>>>>    <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      Hello Mark,
>>>>>>>>>>>
>>>>>>>>>>>      To close this out, no, "." is not valid in
>>>>>
>>>>> an EL
>>>>>>>
>>>>>>>    name.  An EL name
>>>>>>>>>>>
>>>>>>>>>>>      must
>>>>>>>>>>>      be a java identifier.  I'm told this was
>>>>>
>>>>> discussed by Pete
>>>>>>>
>>>>>>>    a long time
>>>>>>>>>>>
>>>>>>>>>>>      ago in the EL 3.0 EG.
>>>>>>>>>>>
>>>>>>>>>>>      Ed
>>>>>>>>>>>
>>>>>>>>>>>      --
>>>>>>>>>>>      | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>      | 42 days til DevNexus 2015
>>>>>>>>>>>      | 52 days til JavaLand 2015
>>>>>>>>>>>      | 62 days til CONFESS 2015
>>>>>>>>>>>
>>>>>>>>>>      _______________________________________________
>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>      Note that for all code provided on this list, the
>>>>>
>>>>> provider licenses
>>>>>>>
>>>>>>>    the code under the Apache License, Version 2
>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas
>>>>>
>>>>> provided
>>>>>>>
>>>>>>>    on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>
>>>>> property
>>>>>>>
>>>>>>>    rights inherent in such information.
>>>>>>>>>
>>>>>>>>>      _______________________________________________
>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>
>>>>> licenses the
>>>>>>>
>>>>>>>    code under the Apache License, Version 2
>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas
>>>>>
>>>>> provided
>>>>>>>
>>>>>>>    on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>
>>>>> property
>>>>>>>
>>>>>>>    rights inherent in such information.
>>>>>>>
>>>>>>>>      _______________________________________________
>>>>>>>>      cdi-dev mailing list
>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>
>>>>> licenses the
>>>>>>>
>>>>>>>    code under the Apache License, Version 2
>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas
>>>>>
>>>>> provided
>>>>>>>
>>>>>>>    on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>
>>>>> property
>>>>>>>
>>>>>>>    rights inherent in such information.
>>>>>>>
>>>>>>>
>>>>>>>    _______________________________________________
>>>>>>>    cdi-dev mailing list
>>>>>>>    cdi-dev at lists.jboss.org
>>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>    Note that for all code provided on this list, the provider
>>>>>>> licenses
>>>>>>> the
>>>>>
>>>>> code
>>>>>>>
>>>>>>>    under the Apache License, Version 2
>>>>>>>    (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas
>>>>>
>>>>> provided
>>>>>>>
>>>>>>>    on this list, the provider waives all patent and other
>>>>>>> intellectual
>>>>>
>>>>> property
>>>>>>>
>>>>>>>    rights inherent in such information.
>>>>>>>
>>>>>>    _______________________________________________
>>>>>>    cdi-dev mailing list
>>>>>>    cdi-dev at lists.jboss.org
>>>>>>    https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>    Note that for all code provided on this list, the provider licenses
>>>>>> the
>>>>>
>>>>> code under the Apache License, Version 2
>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>> provided
>>>>> on this list, the provider waives all patent and other intellectual
>>>>> property
>>>>> rights inherent in such information.
>>>>>
>

From jharting at redhat.com  Thu Jan 15 06:59:00 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 15 Jan 2015 12:59:00 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
Message-ID: <54B7AB84.5020800@redhat.com>


On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>> lead to conflicts and that's things I saw several times in spring apps
>>> which are clearly not possible using CDI + EL properly.
>> Yes and these conflicts are handled by the spec. See 5.3.1
>>
> Hmm not sure. If enriched is a property of the first bean then spec
> doesn't help.
The spec deals with exactly these types of cases in 5.3.1
>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x is
>>>>> the
>>>>> bean name of the other bean" will not be a problem.
>>>>>
>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>> ELResolver. That is something totally different.
>>>> Mark, please read the e-mail again. I am not saying there are two beans
>>>> named "javax". I am saying there are two beans with the following names:
>>>>
>>>> - javax.enterprise.context.conversation (the built-in one)
>>>> - javax (Marks's bean)
>>>>
>>>> where the former one is in form x.y where y is a valid bean name:
>>>> (javax) . (enterprise.context.conversation)
>>>>
>>>> and thus since javax is both x above and a bean name of Mark's bean, this
>>>> results in an exception.
>>>>
>>>>
>>>>> Thus the rest of your argumentation chain is also invalid.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>> <jharting at redhat.com> wrote:
>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>> Suppose two beans are both available for injection in a certain war,
>>>>>> and
>>>>>> either:
>>>>>> - the two beans have the same bean name and the name is not resolvable,
>>>>>> or
>>>>>> - the bean name of one bean is of the form x.y, where y is a valid bean
>>>>>> name, and x is the bean
>>>>>> name of the other bean,
>>>>>> the container automatically detects the problem and treats it as a
>>>>>> deployment problem.
>>>>>>
>>>>>> So we have two beans:
>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>> - javax (Marks's bean)
>>>>>>
>>>>>> now:
>>>>>>
>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>> bean
>>>>>> name - that is javax.enterprise.context.conversation
>>>>>> x = javax
>>>>>> y = enterprise.context.conversation
>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>> Mark's
>>>>>> @Named("javax") bean
>>>>>> 3) the container automatically detects the problem and treats it as a
>>>>>> deployment problem
>>>>>>
>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>> problem
>>>>>> no matter whether it is actually available via EL or not.
>>>>>>
>>>>>> To summarize, the spec already anticipates the problem and forbids this
>>>>>> case explicitly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>     And then break all applications which have a @Named("javax")
>>>>>> public class MyBean?
>>>>>>>     It's simply not an option imo. It breaks lots of other specs and
>>>>>> features. This is an XOR situation.
>>>>>>>
>>>>>>>     LieGrue,
>>>>>>>     strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     ----- Original Message -----
>>>>>>>>     From: Pete Muir <pmuir at redhat.com>
>>>>>>>>     To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>     Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>> <edward.burns at oracle.com>
>>>>>>>>     Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>     Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>> is not valid in an EL name.
>>>>>>>>     We need to go for both (A) and (B).
>>>>>>>>
>>>>>>>>     We would need to deprecate the existing name before we can allow
>>>>>>>> it
>>>>>>>> to
>>>>>> not be
>>>>>>>>     supported. This means CDI 3. So I would suggest we deprecate it in
>>>>>>>> 2,
>>>>>> add an
>>>>>>>>     alternative that can be used, and then consider removing it in CDI
>>>>>>>> 3.
>>>>>> In the
>>>>>>>>     meantime for CDI 2, we will need to improve the TCK to check this
>>>>>>>> more
>>>>>>>>     carefully.
>>>>>>>>
>>>>>>>>>       On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>> <rmannibucau at gmail.com>
>>>>>>>>     wrote:
>>>>>>>>>       +1 for B (IMO it is not used that much)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       Romain Manni-Bucau
>>>>>>>>>       @rmannibucau
>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>> <jharting at redhat.com>:
>>>>>>>>>>       I think further action is needed on this. Now that it has
>>>>>> been
>>>>>>>>     confirmed
>>>>>>>>>>       that "javax.enterprise.context.conversation" itself
>>>>>> is not a
>>>>>>>>     valid EL
>>>>>>>>>>       name we should either:
>>>>>>>>>>
>>>>>>>>>>       A) Require all CDI implementations to adapt the
>>>>>> property-based approach
>>>>>>>>>>       which allows this to be implemented portably (as Weld does)
>>>>>>>>>>       B) Declare publicly that although the CDI spec declares the
>>>>>> given name,
>>>>>>>>>>       it is a bug and applications should not use the name. (What
>>>>>> about
>>>>>>>>>>       compatibility with existing applications?)
>>>>>>>>>>
>>>>>>>>>>       Jozef
>>>>>>>>>>
>>>>>>>>>>       On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>       Dear CDI fellows!
>>>>>>>>>>>
>>>>>>>>>>>       I've received an answer regarding our EL question
>>>>>> from the EL
>>>>>>>>     Spec Lead.
>>>>>>>>>>>       Ed, thanks for helping us!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       LieGrue,
>>>>>>>>>>>       strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>       On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>     <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>       Hello Mark,
>>>>>>>>>>>>       To close this out, no, "." is not valid in
>>>>>> an EL
>>>>>>>>     name.  An EL name
>>>>>>>>>>>>       must
>>>>>>>>>>>>       be a java identifier.  I'm told this was
>>>>>> discussed by Pete
>>>>>>>>     a long time
>>>>>>>>>>>>       ago in the EL 3.0 EG.
>>>>>>>>>>>>
>>>>>>>>>>>>       Ed
>>>>>>>>>>>>
>>>>>>>>>>>>       --
>>>>>>>>>>>>       | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>       | 42 days til DevNexus 2015
>>>>>>>>>>>>       | 52 days til JavaLand 2015
>>>>>>>>>>>>       | 62 days til CONFESS 2015
>>>>>>>>>>>>
>>>>>>>>>>>       _______________________________________________
>>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>       Note that for all code provided on this list, the
>>>>>> provider licenses
>>>>>>>>     the code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>>>       _______________________________________________
>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>> licenses the
>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>>>       _______________________________________________
>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>> licenses the
>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the provider
>>>>>>>> licenses
>>>>>>>> the
>>>>>> code
>>>>>>>>     under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cdi-dev mailing list
>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>     Note that for all code provided on this list, the provider licenses
>>>>>>> the
>>>>>> code under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided
>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>> property
>>>>>> rights inherent in such information.
>>>>>>


From rmannibucau at gmail.com  Thu Jan 15 08:44:59 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 15 Jan 2015 14:44:59 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B7AB84.5020800@redhat.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
	<54B7AB84.5020800@redhat.com>
Message-ID: <CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>

@Jozef: can you quote it please - sorry if it is obvious but I dont
see it in 5.3.1, I look 1.2 version BTW. It only deals with names
where or CDI where here we conflict between resolvers.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
> On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>>>
>>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>>> lead to conflicts and that's things I saw several times in spring apps
>>>> which are clearly not possible using CDI + EL properly.
>>>
>>> Yes and these conflicts are handled by the spec. See 5.3.1
>>>
>> Hmm not sure. If enriched is a property of the first bean then spec
>> doesn't help.
>
> The spec deals with exactly these types of cases in 5.3.1
>
>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>
>>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>
>>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x
>>>>>> is
>>>>>> the
>>>>>> bean name of the other bean" will not be a problem.
>>>>>>
>>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>>> ELResolver. That is something totally different.
>>>>>
>>>>> Mark, please read the e-mail again. I am not saying there are two beans
>>>>> named "javax". I am saying there are two beans with the following
>>>>> names:
>>>>>
>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>> - javax (Marks's bean)
>>>>>
>>>>> where the former one is in form x.y where y is a valid bean name:
>>>>> (javax) . (enterprise.context.conversation)
>>>>>
>>>>> and thus since javax is both x above and a bean name of Mark's bean,
>>>>> this
>>>>> results in an exception.
>>>>>
>>>>>
>>>>>> Thus the rest of your argumentation chain is also invalid.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>
>>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>>>
>>>>>>> Suppose two beans are both available for injection in a certain war,
>>>>>>> and
>>>>>>> either:
>>>>>>> - the two beans have the same bean name and the name is not
>>>>>>> resolvable,
>>>>>>> or
>>>>>>> - the bean name of one bean is of the form x.y, where y is a valid
>>>>>>> bean
>>>>>>> name, and x is the bean
>>>>>>> name of the other bean,
>>>>>>> the container automatically detects the problem and treats it as a
>>>>>>> deployment problem.
>>>>>>>
>>>>>>> So we have two beans:
>>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>>> - javax (Marks's bean)
>>>>>>>
>>>>>>> now:
>>>>>>>
>>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>>> bean
>>>>>>> name - that is javax.enterprise.context.conversation
>>>>>>> x = javax
>>>>>>> y = enterprise.context.conversation
>>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>>> Mark's
>>>>>>> @Named("javax") bean
>>>>>>> 3) the container automatically detects the problem and treats it as a
>>>>>>> deployment problem
>>>>>>>
>>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>>> problem
>>>>>>> no matter whether it is actually available via EL or not.
>>>>>>>
>>>>>>> To summarize, the spec already anticipates the problem and forbids
>>>>>>> this
>>>>>>> case explicitly.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>     And then break all applications which have a @Named("javax")
>>>>>>>
>>>>>>> public class MyBean?
>>>>>>>>
>>>>>>>>     It's simply not an option imo. It breaks lots of other specs and
>>>>>>>
>>>>>>> features. This is an XOR situation.
>>>>>>>>
>>>>>>>>
>>>>>>>>     LieGrue,
>>>>>>>>     strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     ----- Original Message -----
>>>>>>>>>
>>>>>>>>>     From: Pete Muir <pmuir at redhat.com>
>>>>>>>>>     To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>>     Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>>>
>>>>>>> <edward.burns at oracle.com>
>>>>>>>>>
>>>>>>>>>     Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>>     Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>>>
>>>>>>> is not valid in an EL name.
>>>>>>>>>
>>>>>>>>>     We need to go for both (A) and (B).
>>>>>>>>>
>>>>>>>>>     We would need to deprecate the existing name before we can
>>>>>>>>> allow
>>>>>>>>> it
>>>>>>>>> to
>>>>>>>
>>>>>>> not be
>>>>>>>>>
>>>>>>>>>     supported. This means CDI 3. So I would suggest we deprecate it
>>>>>>>>> in
>>>>>>>>> 2,
>>>>>>>
>>>>>>> add an
>>>>>>>>>
>>>>>>>>>     alternative that can be used, and then consider removing it in
>>>>>>>>> CDI
>>>>>>>>> 3.
>>>>>>>
>>>>>>> In the
>>>>>>>>>
>>>>>>>>>     meantime for CDI 2, we will need to improve the TCK to check
>>>>>>>>> this
>>>>>>>>> more
>>>>>>>>>     carefully.
>>>>>>>>>
>>>>>>>>>>       On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>>>
>>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>
>>>>>>>>>     wrote:
>>>>>>>>>>
>>>>>>>>>>       +1 for B (IMO it is not used that much)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       Romain Manni-Bucau
>>>>>>>>>>       @rmannibucau
>>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>>>
>>>>>>> <jharting at redhat.com>:
>>>>>>>>>>>
>>>>>>>>>>>       I think further action is needed on this. Now that it has
>>>>>>>
>>>>>>> been
>>>>>>>>>
>>>>>>>>>     confirmed
>>>>>>>>>>>
>>>>>>>>>>>       that "javax.enterprise.context.conversation" itself
>>>>>>>
>>>>>>> is not a
>>>>>>>>>
>>>>>>>>>     valid EL
>>>>>>>>>>>
>>>>>>>>>>>       name we should either:
>>>>>>>>>>>
>>>>>>>>>>>       A) Require all CDI implementations to adapt the
>>>>>>>
>>>>>>> property-based approach
>>>>>>>>>>>
>>>>>>>>>>>       which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>       B) Declare publicly that although the CDI spec declares the
>>>>>>>
>>>>>>> given name,
>>>>>>>>>>>
>>>>>>>>>>>       it is a bug and applications should not use the name. (What
>>>>>>>
>>>>>>> about
>>>>>>>>>>>
>>>>>>>>>>>       compatibility with existing applications?)
>>>>>>>>>>>
>>>>>>>>>>>       Jozef
>>>>>>>>>>>
>>>>>>>>>>>       On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>       Dear CDI fellows!
>>>>>>>>>>>>
>>>>>>>>>>>>       I've received an answer regarding our EL question
>>>>>>>
>>>>>>> from the EL
>>>>>>>>>
>>>>>>>>>     Spec Lead.
>>>>>>>>>>>>
>>>>>>>>>>>>       Ed, thanks for helping us!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>       LieGrue,
>>>>>>>>>>>>       strub
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>       On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>>
>>>>>>>>>     <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       Hello Mark,
>>>>>>>>>>>>>
>>>>>>>>>>>>>       To close this out, no, "." is not valid in
>>>>>>>
>>>>>>> an EL
>>>>>>>>>
>>>>>>>>>     name.  An EL name
>>>>>>>>>>>>>
>>>>>>>>>>>>>       must
>>>>>>>>>>>>>       be a java identifier.  I'm told this was
>>>>>>>
>>>>>>> discussed by Pete
>>>>>>>>>
>>>>>>>>>     a long time
>>>>>>>>>>>>>
>>>>>>>>>>>>>       ago in the EL 3.0 EG.
>>>>>>>>>>>>>
>>>>>>>>>>>>>       Ed
>>>>>>>>>>>>>
>>>>>>>>>>>>>       --
>>>>>>>>>>>>>       | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>       | 42 days til DevNexus 2015
>>>>>>>>>>>>>       | 52 days til JavaLand 2015
>>>>>>>>>>>>>       | 62 days til CONFESS 2015
>>>>>>>>>>>>>
>>>>>>>>>>>>       _______________________________________________
>>>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>>       Note that for all code provided on this list, the
>>>>>>>
>>>>>>> provider licenses
>>>>>>>>>
>>>>>>>>>     the code under the Apache License, Version 2
>>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>> other
>>>>>>>>> ideas
>>>>>>>
>>>>>>> provided
>>>>>>>>>
>>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>>> intellectual
>>>>>>>
>>>>>>> property
>>>>>>>>>
>>>>>>>>>     rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>>>       _______________________________________________
>>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>>>
>>>>>>> licenses the
>>>>>>>>>
>>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>> other
>>>>>>>>> ideas
>>>>>>>
>>>>>>> provided
>>>>>>>>>
>>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>>> intellectual
>>>>>>>
>>>>>>> property
>>>>>>>>>
>>>>>>>>>     rights inherent in such information.
>>>>>>>>>
>>>>>>>>>>       _______________________________________________
>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>>>
>>>>>>> licenses the
>>>>>>>>>
>>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>> other
>>>>>>>>> ideas
>>>>>>>
>>>>>>> provided
>>>>>>>>>
>>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>>> intellectual
>>>>>>>
>>>>>>> property
>>>>>>>>>
>>>>>>>>>     rights inherent in such information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     _______________________________________________
>>>>>>>>>     cdi-dev mailing list
>>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>     Note that for all code provided on this list, the provider
>>>>>>>>> licenses
>>>>>>>>> the
>>>>>>>
>>>>>>> code
>>>>>>>>>
>>>>>>>>>     under the Apache License, Version 2
>>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>> other
>>>>>>>>> ideas
>>>>>>>
>>>>>>> provided
>>>>>>>>>
>>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>>> intellectual
>>>>>>>
>>>>>>> property
>>>>>>>>>
>>>>>>>>>     rights inherent in such information.
>>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the provider
>>>>>>>> licenses
>>>>>>>> the
>>>>>>>
>>>>>>> code under the Apache License, Version 2
>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>> ideas
>>>>>>> provided
>>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>>> property
>>>>>>> rights inherent in such information.
>>>>>>>
>

From edward.burns at oracle.com  Thu Jan 15 13:05:01 2015
From: edward.burns at oracle.com (Edward Burns)
Date: Thu, 15 Jan 2015 10:05:01 -0800
Subject: [cdi-dev] Fw: Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <2144953826.4022.1420846874617.JavaMail.yahoo@jws11158.mail.ir2.yahoo.com>
References: <21679.57502.550468.694335@gargle.gargle.HOWL>
	<2144953826.4022.1420846874617.JavaMail.yahoo@jws11158.mail.ir2.yahoo.com>
Message-ID: <21688.333.991295.925079@gargle.gargle.HOWL>

>>>>> On Fri, 9 Jan 2015 23:41:14 +0000 (UTC), Mark Struberg <struberg at yahoo.de> said:

MS> Ah oh sorry, but you are Servlet spec lead, right? Somehow I get
MS> confused by which parts are now an own JSR and EL was originally
MS> maintained under the Servlet EG umbrella, right?

Yes, Servlet and JSF.

Ed


-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| 35 days til DevNexus 2015
| 45 days til JavaLand 2015
| 55 days til CONFESS 2015

From jharting at redhat.com  Fri Jan 16 02:10:50 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 16 Jan 2015 08:10:50 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
	<54B7AB84.5020800@redhat.com>
	<CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>
Message-ID: <54B8B97A.4080801@redhat.com>

OK, the relevant part goes:

"If the bean name of one bean is of the form x.y, where y is a valid 
bean name, and x is the bean name of the other bean,
the container automatically detects the problem and treats it as a 
deployment problem."

Let's have:
@Named("team1.superBean.enriched") class Bean1
@Named("team1.superBean") class Bean2

Now
1) "If the bean name of one bean is of the form x.y"

We can match the "x.y" pattern on Bean1's name as:
(team1.superBean) . (enriched)
thus:
x = team1.superBean
y = enriched

2) "where y is a valid bean name"
"enriched" is indeed a valid bean name

3) "and x is the bean name of the other bean"
x ("team1.superBean") is at the same time the name of Bean2

4) Therefore, "the container automatically detects the problem and 
treats it as a deployment problem".

Therefore, this scenario does not become a conflict at runtime.

HTH,
Jozef




On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
> @Jozef: can you quote it please - sorry if it is obvious but I dont
> see it in 5.3.1, I look 1.2 version BTW. It only deals with names
> where or CDI where here we conflict between resolvers.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>>>> lead to conflicts and that's things I saw several times in spring apps
>>>>> which are clearly not possible using CDI + EL properly.
>>>> Yes and these conflicts are handled by the spec. See 5.3.1
>>>>
>>> Hmm not sure. If enriched is a property of the first bean then spec
>>> doesn't help.
>> The spec deals with exactly these types of cases in 5.3.1
>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x
>>>>>>> is
>>>>>>> the
>>>>>>> bean name of the other bean" will not be a problem.
>>>>>>>
>>>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>>>> ELResolver. That is something totally different.
>>>>>> Mark, please read the e-mail again. I am not saying there are two beans
>>>>>> named "javax". I am saying there are two beans with the following
>>>>>> names:
>>>>>>
>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>> - javax (Marks's bean)
>>>>>>
>>>>>> where the former one is in form x.y where y is a valid bean name:
>>>>>> (javax) . (enterprise.context.conversation)
>>>>>>
>>>>>> and thus since javax is both x above and a bean name of Mark's bean,
>>>>>> this
>>>>>> results in an exception.
>>>>>>
>>>>>>
>>>>>>> Thus the rest of your argumentation chain is also invalid.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>>>> Suppose two beans are both available for injection in a certain war,
>>>>>>>> and
>>>>>>>> either:
>>>>>>>> - the two beans have the same bean name and the name is not
>>>>>>>> resolvable,
>>>>>>>> or
>>>>>>>> - the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>> bean
>>>>>>>> name, and x is the bean
>>>>>>>> name of the other bean,
>>>>>>>> the container automatically detects the problem and treats it as a
>>>>>>>> deployment problem.
>>>>>>>>
>>>>>>>> So we have two beans:
>>>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>>>> - javax (Marks's bean)
>>>>>>>>
>>>>>>>> now:
>>>>>>>>
>>>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>> bean
>>>>>>>> name - that is javax.enterprise.context.conversation
>>>>>>>> x = javax
>>>>>>>> y = enterprise.context.conversation
>>>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>>>> Mark's
>>>>>>>> @Named("javax") bean
>>>>>>>> 3) the container automatically detects the problem and treats it as a
>>>>>>>> deployment problem
>>>>>>>>
>>>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>>>> problem
>>>>>>>> no matter whether it is actually available via EL or not.
>>>>>>>>
>>>>>>>> To summarize, the spec already anticipates the problem and forbids
>>>>>>>> this
>>>>>>>> case explicitly.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>>>      And then break all applications which have a @Named("javax")
>>>>>>>> public class MyBean?
>>>>>>>>>      It's simply not an option imo. It breaks lots of other specs and
>>>>>>>> features. This is an XOR situation.
>>>>>>>>>
>>>>>>>>>      LieGrue,
>>>>>>>>>      strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>      ----- Original Message -----
>>>>>>>>>>      From: Pete Muir <pmuir at redhat.com>
>>>>>>>>>>      To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>>>      Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>>>> <edward.burns at oracle.com>
>>>>>>>>>>      Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>>>      Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>>>> is not valid in an EL name.
>>>>>>>>>>      We need to go for both (A) and (B).
>>>>>>>>>>
>>>>>>>>>>      We would need to deprecate the existing name before we can
>>>>>>>>>> allow
>>>>>>>>>> it
>>>>>>>>>> to
>>>>>>>> not be
>>>>>>>>>>      supported. This means CDI 3. So I would suggest we deprecate it
>>>>>>>>>> in
>>>>>>>>>> 2,
>>>>>>>> add an
>>>>>>>>>>      alternative that can be used, and then consider removing it in
>>>>>>>>>> CDI
>>>>>>>>>> 3.
>>>>>>>> In the
>>>>>>>>>>      meantime for CDI 2, we will need to improve the TCK to check
>>>>>>>>>> this
>>>>>>>>>> more
>>>>>>>>>>      carefully.
>>>>>>>>>>
>>>>>>>>>>>        On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>>      wrote:
>>>>>>>>>>>        +1 for B (IMO it is not used that much)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        Romain Manni-Bucau
>>>>>>>>>>>        @rmannibucau
>>>>>>>>>>>       http://www.tomitribe.com
>>>>>>>>>>>       http://rmannibucau.wordpress.com
>>>>>>>>>>>       https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>>>> <jharting at redhat.com>:
>>>>>>>>>>>>        I think further action is needed on this. Now that it has
>>>>>>>> been
>>>>>>>>>>      confirmed
>>>>>>>>>>>>        that "javax.enterprise.context.conversation" itself
>>>>>>>> is not a
>>>>>>>>>>      valid EL
>>>>>>>>>>>>        name we should either:
>>>>>>>>>>>>
>>>>>>>>>>>>        A) Require all CDI implementations to adapt the
>>>>>>>> property-based approach
>>>>>>>>>>>>        which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>>        B) Declare publicly that although the CDI spec declares the
>>>>>>>> given name,
>>>>>>>>>>>>        it is a bug and applications should not use the name. (What
>>>>>>>> about
>>>>>>>>>>>>        compatibility with existing applications?)
>>>>>>>>>>>>
>>>>>>>>>>>>        Jozef
>>>>>>>>>>>>
>>>>>>>>>>>>        On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>>        Dear CDI fellows!
>>>>>>>>>>>>>
>>>>>>>>>>>>>        I've received an answer regarding our EL question
>>>>>>>> from the EL
>>>>>>>>>>      Spec Lead.
>>>>>>>>>>>>>        Ed, thanks for helping us!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>        LieGrue,
>>>>>>>>>>>>>        strub
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>        On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>>>      <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>>>        Hello Mark,
>>>>>>>>>>>>>>        To close this out, no, "." is not valid in
>>>>>>>> an EL
>>>>>>>>>>      name.  An EL name
>>>>>>>>>>>>>>        must
>>>>>>>>>>>>>>        be a java identifier.  I'm told this was
>>>>>>>> discussed by Pete
>>>>>>>>>>      a long time
>>>>>>>>>>>>>>        ago in the EL 3.0 EG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Ed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        --
>>>>>>>>>>>>>>        | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>        | 42 days til DevNexus 2015
>>>>>>>>>>>>>>        | 52 days til JavaLand 2015
>>>>>>>>>>>>>>        | 62 days til CONFESS 2015
>>>>>>>>>>>>>>
>>>>>>>>>>>>>        _______________________________________________
>>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>> provider licenses
>>>>>>>>>>      the code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>> property
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>>>        _______________________________________________
>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>>        Note that for all code provided on this list, the provider
>>>>>>>> licenses the
>>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>> property
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>>        _______________________________________________
>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>        Note that for all code provided on this list, the provider
>>>>>>>> licenses the
>>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>> property
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>      _______________________________________________
>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>>> licenses
>>>>>>>>>> the
>>>>>>>> code
>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>> property
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>      _______________________________________________
>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>> licenses
>>>>>>>>> the
>>>>>>>> code under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>>>> property
>>>>>>>> rights inherent in such information.
>>>>>>>>


From rmannibucau at gmail.com  Fri Jan 16 02:20:06 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 16 Jan 2015 08:20:06 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <54B8B97A.4080801@redhat.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
	<54B7AB84.5020800@redhat.com>
	<CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>
	<54B8B97A.4080801@redhat.com>
Message-ID: <CACLE=7O6Ym4vNVmXxbyFr1CDAL98RAYA9qz20uogeQNpQ_0ojw@mail.gmail.com>

Hmm

Does it mean CDI cant add javax.enterprise.xxx bean? Or even other specs
cant add javax.xxx beans?
 Le 16 janv. 2015 08:10, "Jozef Hartinger" <jharting at redhat.com> a ?crit :

> OK, the relevant part goes:
>
> "If the bean name of one bean is of the form x.y, where y is a valid bean
> name, and x is the bean name of the other bean,
> the container automatically detects the problem and treats it as a
> deployment problem."
>
> Let's have:
> @Named("team1.superBean.enriched") class Bean1
> @Named("team1.superBean") class Bean2
>
> Now
> 1) "If the bean name of one bean is of the form x.y"
>
> We can match the "x.y" pattern on Bean1's name as:
> (team1.superBean) . (enriched)
> thus:
> x = team1.superBean
> y = enriched
>
> 2) "where y is a valid bean name"
> "enriched" is indeed a valid bean name
>
> 3) "and x is the bean name of the other bean"
> x ("team1.superBean") is at the same time the name of Bean2
>
> 4) Therefore, "the container automatically detects the problem and treats
> it as a deployment problem".
>
> Therefore, this scenario does not become a conflict at runtime.
>
> HTH,
> Jozef
>
>
>
>
> On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
>
>> @Jozef: can you quote it please - sorry if it is obvious but I dont
>> see it in 5.3.1, I look 1.2 version BTW. It only deals with names
>> where or CDI where here we conflict between resolvers.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>
>>> On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>>
>>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>>>>> lead to conflicts and that's things I saw several times in spring apps
>>>>>> which are clearly not possible using CDI + EL properly.
>>>>>>
>>>>> Yes and these conflicts are handled by the spec. See 5.3.1
>>>>>
>>>>>  Hmm not sure. If enriched is a property of the first bean then spec
>>>> doesn't help.
>>>>
>>> The spec deals with exactly these types of cases in 5.3.1
>>>
>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>>
>>>>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>>
>>>>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>>>>> Currently there is no bean with the name "javax", thus "x.y ... and
>>>>>>>> x
>>>>>>>> is
>>>>>>>> the
>>>>>>>> bean name of the other bean" will not be a problem.
>>>>>>>>
>>>>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>>>>> ELResolver. That is something totally different.
>>>>>>>>
>>>>>>> Mark, please read the e-mail again. I am not saying there are two
>>>>>>> beans
>>>>>>> named "javax". I am saying there are two beans with the following
>>>>>>> names:
>>>>>>>
>>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>>> - javax (Marks's bean)
>>>>>>>
>>>>>>> where the former one is in form x.y where y is a valid bean name:
>>>>>>> (javax) . (enterprise.context.conversation)
>>>>>>>
>>>>>>> and thus since javax is both x above and a bean name of Mark's bean,
>>>>>>> this
>>>>>>> results in an exception.
>>>>>>>
>>>>>>>
>>>>>>>  Thus the rest of your argumentation chain is also invalid.
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>  On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>>>>>>
>>>>>>>>> Suppose two beans are both available for injection in a certain
>>>>>>>>> war,
>>>>>>>>> and
>>>>>>>>> either:
>>>>>>>>> - the two beans have the same bean name and the name is not
>>>>>>>>> resolvable,
>>>>>>>>> or
>>>>>>>>> - the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>>> bean
>>>>>>>>> name, and x is the bean
>>>>>>>>> name of the other bean,
>>>>>>>>> the container automatically detects the problem and treats it as a
>>>>>>>>> deployment problem.
>>>>>>>>>
>>>>>>>>> So we have two beans:
>>>>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>>>>> - javax (Marks's bean)
>>>>>>>>>
>>>>>>>>> now:
>>>>>>>>>
>>>>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>>> bean
>>>>>>>>> name - that is javax.enterprise.context.conversation
>>>>>>>>> x = javax
>>>>>>>>> y = enterprise.context.conversation
>>>>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>>>>> Mark's
>>>>>>>>> @Named("javax") bean
>>>>>>>>> 3) the container automatically detects the problem and treats it
>>>>>>>>> as a
>>>>>>>>> deployment problem
>>>>>>>>>
>>>>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>>>>> problem
>>>>>>>>> no matter whether it is actually available via EL or not.
>>>>>>>>>
>>>>>>>>> To summarize, the spec already anticipates the problem and forbids
>>>>>>>>> this
>>>>>>>>> case explicitly.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>>>
>>>>>>>>>>      And then break all applications which have a @Named("javax")
>>>>>>>>>>
>>>>>>>>> public class MyBean?
>>>>>>>>>
>>>>>>>>>>      It's simply not an option imo. It breaks lots of other specs
>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>> features. This is an XOR situation.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>      LieGrue,
>>>>>>>>>>      strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>      ----- Original Message -----
>>>>>>>>>>
>>>>>>>>>>>      From: Pete Muir <pmuir at redhat.com>
>>>>>>>>>>>      To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>>>>      Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>>>>>>>
>>>>>>>>>> <edward.burns at oracle.com>
>>>>>>>>>
>>>>>>>>>>      Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>>>>      Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>>>>>>>
>>>>>>>>>> is not valid in an EL name.
>>>>>>>>>
>>>>>>>>>>      We need to go for both (A) and (B).
>>>>>>>>>>>
>>>>>>>>>>>      We would need to deprecate the existing name before we can
>>>>>>>>>>> allow
>>>>>>>>>>> it
>>>>>>>>>>> to
>>>>>>>>>>>
>>>>>>>>>> not be
>>>>>>>>>
>>>>>>>>>>      supported. This means CDI 3. So I would suggest we deprecate
>>>>>>>>>>> it
>>>>>>>>>>> in
>>>>>>>>>>> 2,
>>>>>>>>>>>
>>>>>>>>>> add an
>>>>>>>>>
>>>>>>>>>>      alternative that can be used, and then consider removing it
>>>>>>>>>>> in
>>>>>>>>>>> CDI
>>>>>>>>>>> 3.
>>>>>>>>>>>
>>>>>>>>>> In the
>>>>>>>>>
>>>>>>>>>>      meantime for CDI 2, we will need to improve the TCK to check
>>>>>>>>>>> this
>>>>>>>>>>> more
>>>>>>>>>>>      carefully.
>>>>>>>>>>>
>>>>>>>>>>>         On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>>>>>>>>
>>>>>>>>>>> <rmannibucau at gmail.com>
>>>>>>>>>
>>>>>>>>>>      wrote:
>>>>>>>>>>>
>>>>>>>>>>>>        +1 for B (IMO it is not used that much)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>        Romain Manni-Bucau
>>>>>>>>>>>>        @rmannibucau
>>>>>>>>>>>>       http://www.tomitribe.com
>>>>>>>>>>>>       http://rmannibucau.wordpress.com
>>>>>>>>>>>>       https://github.com/rmannibucau
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>        2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>>>>>>>>
>>>>>>>>>>> <jharting at redhat.com>:
>>>>>>>>>
>>>>>>>>>>        I think further action is needed on this. Now that it has
>>>>>>>>>>>>>
>>>>>>>>>>>> been
>>>>>>>>>
>>>>>>>>>>      confirmed
>>>>>>>>>>>
>>>>>>>>>>>>        that "javax.enterprise.context.conversation" itself
>>>>>>>>>>>>>
>>>>>>>>>>>> is not a
>>>>>>>>>
>>>>>>>>>>      valid EL
>>>>>>>>>>>
>>>>>>>>>>>>        name we should either:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        A) Require all CDI implementations to adapt the
>>>>>>>>>>>>>
>>>>>>>>>>>> property-based approach
>>>>>>>>>
>>>>>>>>>>        which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>>>        B) Declare publicly that although the CDI spec declares
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> given name,
>>>>>>>>>
>>>>>>>>>>        it is a bug and applications should not use the name. (What
>>>>>>>>>>>>>
>>>>>>>>>>>> about
>>>>>>>>>
>>>>>>>>>>        compatibility with existing applications?)
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Jozef
>>>>>>>>>>>>>
>>>>>>>>>>>>>        On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Dear CDI fellows!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        I've received an answer regarding our EL question
>>>>>>>>>>>>>>
>>>>>>>>>>>>> from the EL
>>>>>>>>>
>>>>>>>>>>      Spec Lead.
>>>>>>>>>>>
>>>>>>>>>>>>        Ed, thanks for helping us!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        LieGrue,
>>>>>>>>>>>>>>        strub
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      <edward.burns at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>        Hello Mark,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        To close this out, no, "." is not valid in
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> an EL
>>>>>>>>>
>>>>>>>>>>      name.  An EL name
>>>>>>>>>>>
>>>>>>>>>>>>        must
>>>>>>>>>>>>>>>        be a java identifier.  I'm told this was
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> discussed by Pete
>>>>>>>>>
>>>>>>>>>>      a long time
>>>>>>>>>>>
>>>>>>>>>>>>        ago in the EL 3.0 EG.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        Ed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        --
>>>>>>>>>>>>>>>        | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>>        | 42 days til DevNexus 2015
>>>>>>>>>>>>>>>        | 52 days til JavaLand 2015
>>>>>>>>>>>>>>>        | 62 days til CONFESS 2015
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> provider licenses
>>>>>>>>>
>>>>>>>>>>      the code under the Apache License, Version 2
>>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>> other
>>>>>>>>>>> ideas
>>>>>>>>>>>
>>>>>>>>>> provided
>>>>>>>>>
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>>> intellectual
>>>>>>>>>>>
>>>>>>>>>> property
>>>>>>>>>
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>>>>        _______________________________________________
>>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>>>>>>> provider
>>>>>>>>>>>>>
>>>>>>>>>>>> licenses the
>>>>>>>>>
>>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>> other
>>>>>>>>>>> ideas
>>>>>>>>>>>
>>>>>>>>>> provided
>>>>>>>>>
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>>> intellectual
>>>>>>>>>>>
>>>>>>>>>> property
>>>>>>>>>
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>>>>>> provider
>>>>>>>>>>>>
>>>>>>>>>>> licenses the
>>>>>>>>>
>>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>> other
>>>>>>>>>>> ideas
>>>>>>>>>>>
>>>>>>>>>> provided
>>>>>>>>>
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>>> intellectual
>>>>>>>>>>>
>>>>>>>>>> property
>>>>>>>>>
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      _______________________________________________
>>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>>>> licenses
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>> code
>>>>>>>>>
>>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>> other
>>>>>>>>>>> ideas
>>>>>>>>>>>
>>>>>>>>>> provided
>>>>>>>>>
>>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>>> intellectual
>>>>>>>>>>>
>>>>>>>>>> property
>>>>>>>>>
>>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>>
>>>>>>>>>>>       _______________________________________________
>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>>> licenses
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>> code under the Apache License, Version 2
>>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>> ideas
>>>>>>>>> provided
>>>>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>>>>> property
>>>>>>>>> rights inherent in such information.
>>>>>>>>>
>>>>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/c273c141/attachment-0001.html 

From rmannibucau at gmail.com  Fri Jan 16 02:20:10 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Fri, 16 Jan 2015 08:20:10 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
	"." is not valid in an EL name.
In-Reply-To: <CACLE=7O6Ym4vNVmXxbyFr1CDAL98RAYA9qz20uogeQNpQ_0ojw@mail.gmail.com>
References: <54B78C8D.3030201@redhat.com>
	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>
	<54B794F4.4090202@redhat.com>
	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>
	<54B79761.5020906@redhat.com>
	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>
	<54B7AB84.5020800@redhat.com>
	<CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>
	<54B8B97A.4080801@redhat.com>
	<CACLE=7O6Ym4vNVmXxbyFr1CDAL98RAYA9qz20uogeQNpQ_0ojw@mail.gmail.com>
Message-ID: <CACLE=7O05wqAG8YFATNfEzk_wHDSk7ktZtD0L1+Yj7QmgzpSRg@mail.gmail.com>

Hmm

Does it mean CDI cant add javax.enterprise.xxx bean? Or even other specs
cant add javax.xxx beans?
 Le 16 janv. 2015 08:10, "Jozef Hartinger" <jharting at redhat.com> a ?crit :

OK, the relevant part goes:

"If the bean name of one bean is of the form x.y, where y is a valid bean
name, and x is the bean name of the other bean,

the container automatically detects the problem and treats it as a
deployment problem."

Let's have:
@Named("team1.superBean.enriched") class Bean1
@Named("team1.superBean") class Bean2

Now
1) "If the bean name of one bean is of the form x.y"

We can match the "x.y" pattern on Bean1's name as:
(team1.superBean) . (enriched)
thus:
x = team1.superBean
y = enriched

2) "where y is a valid bean name"
"enriched" is indeed a valid bean name

3) "and x is the bean name of the other bean"
x ("team1.superBean") is at the same time the name of Bean2

4) Therefore, "the container automatically detects the problem and treats
it as a deployment problem".

Therefore, this scenario does not become a conflict at runtime.

HTH,
Jozef





On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:

> @Jozef: can you quote it please - sorry if it is obvious but I dont
> see it in 5.3.1, I look 1.2 version BTW. It only deals with names
> where or CDI where here we conflict between resolvers.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
>> On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>
>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>>>> lead to conflicts and that's things I saw several times in spring apps
>>>>> which are clearly not possible using CDI + EL properly.
>>>>>
>>>> Yes and these conflicts are handled by the spec. See 5.3.1
>>>>
>>>>  Hmm not sure. If enriched is a property of the first bean then spec
>>> doesn't help.
>>>
>> The spec deals with exactly these types of cases in 5.3.1
>>
>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>
>>>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>
>>>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x
>>>>>>> is
>>>>>>> the
>>>>>>> bean name of the other bean" will not be a problem.
>>>>>>>
>>>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>>>> ELResolver. That is something totally different.
>>>>>>>
>>>>>> Mark, please read the e-mail again. I am not saying there are two
>>>>>> beans
>>>>>> named "javax". I am saying there are two beans with the following
>>>>>> names:
>>>>>>
>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>> - javax (Marks's bean)
>>>>>>
>>>>>> where the former one is in form x.y where y is a valid bean name:
>>>>>> (javax) . (enterprise.context.conversation)
>>>>>>
>>>>>> and thus since javax is both x above and a bean name of Mark's bean,
>>>>>> this
>>>>>> results in an exception.
>>>>>>
>>>>>>
>>>>>>  Thus the rest of your argumentation chain is also invalid.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>  On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>>>>>
>>>>>>>> Suppose two beans are both available for injection in a certain war,
>>>>>>>> and
>>>>>>>> either:
>>>>>>>> - the two beans have the same bean name and the name is not
>>>>>>>> resolvable,
>>>>>>>> or
>>>>>>>> - the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>> bean
>>>>>>>> name, and x is the bean
>>>>>>>> name of the other bean,
>>>>>>>> the container automatically detects the problem and treats it as a
>>>>>>>> deployment problem.
>>>>>>>>
>>>>>>>> So we have two beans:
>>>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>>>> - javax (Marks's bean)
>>>>>>>>
>>>>>>>> now:
>>>>>>>>
>>>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>>>> bean
>>>>>>>> name - that is javax.enterprise.context.conversation
>>>>>>>> x = javax
>>>>>>>> y = enterprise.context.conversation
>>>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>>>> Mark's
>>>>>>>> @Named("javax") bean
>>>>>>>> 3) the container automatically detects the problem and treats it as
>>>>>>>> a
>>>>>>>> deployment problem
>>>>>>>>
>>>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>>>> problem
>>>>>>>> no matter whether it is actually available via EL or not.
>>>>>>>>
>>>>>>>> To summarize, the spec already anticipates the problem and forbids
>>>>>>>> this
>>>>>>>> case explicitly.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>>      And then break all applications which have a @Named("javax")
>>>>>>>>>
>>>>>>>> public class MyBean?
>>>>>>>>
>>>>>>>>>      It's simply not an option imo. It breaks lots of other specs
>>>>>>>>> and
>>>>>>>>>
>>>>>>>> features. This is an XOR situation.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>      LieGrue,
>>>>>>>>>      strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>      ----- Original Message -----
>>>>>>>>>
>>>>>>>>>>      From: Pete Muir <pmuir at redhat.com>
>>>>>>>>>>      To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>>>      Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>>>>>>
>>>>>>>>> <edward.burns at oracle.com>
>>>>>>>>
>>>>>>>>>      Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>>>      Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>>>>>>
>>>>>>>>> is not valid in an EL name.
>>>>>>>>
>>>>>>>>>      We need to go for both (A) and (B).
>>>>>>>>>>
>>>>>>>>>>      We would need to deprecate the existing name before we can
>>>>>>>>>> allow
>>>>>>>>>> it
>>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>> not be
>>>>>>>>
>>>>>>>>>      supported. This means CDI 3. So I would suggest we deprecate
>>>>>>>>>> it
>>>>>>>>>> in
>>>>>>>>>> 2,
>>>>>>>>>>
>>>>>>>>> add an
>>>>>>>>
>>>>>>>>>      alternative that can be used, and then consider removing it in
>>>>>>>>>> CDI
>>>>>>>>>> 3.
>>>>>>>>>>
>>>>>>>>> In the
>>>>>>>>
>>>>>>>>>      meantime for CDI 2, we will need to improve the TCK to check
>>>>>>>>>> this
>>>>>>>>>> more
>>>>>>>>>>      carefully.
>>>>>>>>>>
>>>>>>>>>>         On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>>>>>>>
>>>>>>>>>> <rmannibucau at gmail.com>
>>>>>>>>
>>>>>>>>>      wrote:
>>>>>>>>>>
>>>>>>>>>>>        +1 for B (IMO it is not used that much)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        Romain Manni-Bucau
>>>>>>>>>>>        @rmannibucau
>>>>>>>>>>>       http://www.tomitribe.com
>>>>>>>>>>>       http://rmannibucau.wordpress.com
>>>>>>>>>>>       https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>>>>>>>
>>>>>>>>>> <jharting at redhat.com>:
>>>>>>>>
>>>>>>>>>        I think further action is needed on this. Now that it has
>>>>>>>>>>>>
>>>>>>>>>>> been
>>>>>>>>
>>>>>>>>>      confirmed
>>>>>>>>>>
>>>>>>>>>>>        that "javax.enterprise.context.conversation" itself
>>>>>>>>>>>>
>>>>>>>>>>> is not a
>>>>>>>>
>>>>>>>>>      valid EL
>>>>>>>>>>
>>>>>>>>>>>        name we should either:
>>>>>>>>>>>>
>>>>>>>>>>>>        A) Require all CDI implementations to adapt the
>>>>>>>>>>>>
>>>>>>>>>>> property-based approach
>>>>>>>>
>>>>>>>>>        which allows this to be implemented portably (as Weld does)
>>>>>>>>>>>>        B) Declare publicly that although the CDI spec declares
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> given name,
>>>>>>>>
>>>>>>>>>        it is a bug and applications should not use the name. (What
>>>>>>>>>>>>
>>>>>>>>>>> about
>>>>>>>>
>>>>>>>>>        compatibility with existing applications?)
>>>>>>>>>>>>
>>>>>>>>>>>>        Jozef
>>>>>>>>>>>>
>>>>>>>>>>>>        On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>        Dear CDI fellows!
>>>>>>>>>>>>>
>>>>>>>>>>>>>        I've received an answer regarding our EL question
>>>>>>>>>>>>>
>>>>>>>>>>>> from the EL
>>>>>>>>
>>>>>>>>>      Spec Lead.
>>>>>>>>>>
>>>>>>>>>>>        Ed, thanks for helping us!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>        LieGrue,
>>>>>>>>>>>>>        strub
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>>>>>>>
>>>>>>>>>>>>>      <edward.burns at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>        Hello Mark,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        To close this out, no, "." is not valid in
>>>>>>>>>>>>>>
>>>>>>>>>>>>> an EL
>>>>>>>>
>>>>>>>>>      name.  An EL name
>>>>>>>>>>
>>>>>>>>>>>        must
>>>>>>>>>>>>>>        be a java identifier.  I'm told this was
>>>>>>>>>>>>>>
>>>>>>>>>>>>> discussed by Pete
>>>>>>>>
>>>>>>>>>      a long time
>>>>>>>>>>
>>>>>>>>>>>        ago in the EL 3.0 EG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Ed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        --
>>>>>>>>>>>>>>        | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>        | 42 days til DevNexus 2015
>>>>>>>>>>>>>>        | 52 days til JavaLand 2015
>>>>>>>>>>>>>>        | 62 days til CONFESS 2015
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>>>>>>>
>>>>>>>>>>>> provider licenses
>>>>>>>>
>>>>>>>>>      the code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>>>>
>>>>>>>>> provided
>>>>>>>>
>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>>>>
>>>>>>>>> property
>>>>>>>>
>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>>        _______________________________________________
>>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>
>>>>>>>>>>>>        Note that for all code provided on this list, the
>>>>>>>>>>>> provider
>>>>>>>>>>>>
>>>>>>>>>>> licenses the
>>>>>>>>
>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>>>>
>>>>>>>>> provided
>>>>>>>>
>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>>>>
>>>>>>>>> property
>>>>>>>>
>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>        cdi-dev mailing list
>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>       https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>        Note that for all code provided on this list, the provider
>>>>>>>>>>>
>>>>>>>>>> licenses the
>>>>>>>>
>>>>>>>>>      code under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>>>>
>>>>>>>>> provided
>>>>>>>>
>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>>>>
>>>>>>>>> property
>>>>>>>>
>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>      _______________________________________________
>>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>>> licenses
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>> code
>>>>>>>>
>>>>>>>>>      under the Apache License, Version 2
>>>>>>>>>>      (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>> other
>>>>>>>>>> ideas
>>>>>>>>>>
>>>>>>>>> provided
>>>>>>>>
>>>>>>>>>      on this list, the provider waives all patent and other
>>>>>>>>>> intellectual
>>>>>>>>>>
>>>>>>>>> property
>>>>>>>>
>>>>>>>>>      rights inherent in such information.
>>>>>>>>>>
>>>>>>>>>>       _______________________________________________
>>>>>>>>>      cdi-dev mailing list
>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>      Note that for all code provided on this list, the provider
>>>>>>>>> licenses
>>>>>>>>> the
>>>>>>>>>
>>>>>>>> code under the Apache License, Version 2
>>>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>>>> provided
>>>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>>>> property
>>>>>>>> rights inherent in such information.
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/a6dc19b8/attachment-0001.html 

From jharting at redhat.com  Fri Jan 16 02:32:05 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 16 Jan 2015 08:32:05 +0100
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <CACLE=7O05wqAG8YFATNfEzk_wHDSk7ktZtD0L1+Yj7QmgzpSRg@mail.gmail.com>
References: <54B78C8D.3030201@redhat.com>	<1624515023.1523839.1421316712475.JavaMail.yahoo@jws11125.mail.ir2.yahoo.com>	<54B794F4.4090202@redhat.com>	<CACLE=7N1JzWCj2SBtOzoRPkE71ZAX0uinZ0Phu3VySd89oa0sQ@mail.gmail.com>	<54B79761.5020906@redhat.com>	<CACLE=7NjHgro1cON3tkKQsGwxx9+JCdBaod8FLDv0VCvSe7KOA@mail.gmail.com>	<54B7AB84.5020800@redhat.com>	<CACLE=7Pxhpv6gg0hExDNGihE7PEpsh2Wk_1r6xcnLG7voBjKoQ@mail.gmail.com>	<54B8B97A.4080801@redhat.com>	<CACLE=7O6Ym4vNVmXxbyFr1CDAL98RAYA9qz20uogeQNpQ_0ojw@mail.gmail.com>
	<CACLE=7O05wqAG8YFATNfEzk_wHDSk7ktZtD0L1+Yj7QmgzpSRg@mail.gmail.com>
Message-ID: <54B8BE75.6020407@redhat.com>

No, it means that since we have the bean name 
"javax.enterprise.context.conversation" defined, the following bean 
names are not allowed to be defined by a different bean:

javax
javax.enterprise
javax.enterprise.context
and of course javax.enterprise.context.conversation

All the others, e.g. javax.enterprise.foo or javax.bar are fine.


On 01/16/2015 08:20 AM, Romain Manni-Bucau wrote:
>
> Hmm
>
> Does it mean CDI cant add javax.enterprise.xxx bean? Or even other 
> specs cant add javax.xxx beans?
>
> Le 16 janv. 2015 08:10, "Jozef Hartinger" <jharting at redhat.com 
> <mailto:jharting at redhat.com>> a ?crit :
>
>     OK, the relevant part goes:
>
>     "If the bean name of one bean is of the form x.y, where y is a
>     valid bean name, and x is the bean name of the other bean,
>
>     the container automatically detects the problem and treats it as a
>     deployment problem."
>
>     Let's have:
>     @Named("team1.superBean.enriched") class Bean1
>     @Named("team1.superBean") class Bean2
>
>     Now
>     1) "If the bean name of one bean is of the form x.y"
>
>     We can match the "x.y" pattern on Bean1's name as:
>     (team1.superBean) . (enriched)
>     thus:
>     x = team1.superBean
>     y = enriched
>
>     2) "where y is a valid bean name"
>     "enriched" is indeed a valid bean name
>
>     3) "and x is the bean name of the other bean"
>     x ("team1.superBean") is at the same time the name of Bean2
>
>     4) Therefore, "the container automatically detects the problem and
>     treats it as a deployment problem".
>
>     Therefore, this scenario does not become a conflict at runtime.
>
>     HTH,
>     Jozef
>
>
>
>
>
>     On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
>
>         @Jozef: can you quote it please - sorry if it is obvious but I
>         dont
>         see it in 5.3.1, I look 1.2 version BTW. It only deals with names
>         where or CDI where here we conflict between resolvers.
>
>
>         Romain Manni-Bucau
>         @rmannibucau
>         http://www.tomitribe.com
>         http://rmannibucau.wordpress.com
>         https://github.com/rmannibucau
>
>
>         2015-01-15 12:59 GMT+01:00 Jozef Hartinger
>         <jharting at redhat.com <mailto:jharting at redhat.com>>:
>
>             On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>
>                         @Named("team1.superBean") and
>                         @Named("team1.superBean.enriched") will
>                         lead to conflicts and that's things I saw
>                         several times in spring apps
>                         which are clearly not possible using CDI + EL
>                         properly.
>
>                     Yes and these conflicts are handled by the spec.
>                     See 5.3.1
>
>                 Hmm not sure. If enriched is a property of the first
>                 bean then spec
>                 doesn't help.
>
>             The spec deals with exactly these types of cases in 5.3.1
>
>
>                         Romain Manni-Bucau
>                         @rmannibucau
>                         http://www.tomitribe.com
>                         http://rmannibucau.wordpress.com
>                         https://github.com/rmannibucau
>
>
>                         2015-01-15 11:22 GMT+01:00 Jozef Hartinger
>                         <jharting at redhat.com
>                         <mailto:jharting at redhat.com>>:
>
>                             On 01/15/2015 11:11 AM, Mark Struberg wrote:
>
>                                 Jozef, your argumentation is flawed
>                                 already at the very beginning.
>                                 Currently there is no bean with the
>                                 name "javax", thus "x.y ... and x
>                                 is
>                                 the
>                                 bean name of the other bean" will not
>                                 be a problem.
>
>                                 All that javax is simply not a bean
>                                 name but a dirty hack in the
>                                 ELResolver. That is something totally
>                                 different.
>
>                             Mark, please read the e-mail again. I am
>                             not saying there are two beans
>                             named "javax". I am saying there are two
>                             beans with the following
>                             names:
>
>                             - javax.enterprise.context.conversation
>                             (the built-in one)
>                             - javax (Marks's bean)
>
>                             where the former one is in form x.y where
>                             y is a valid bean name:
>                             (javax) . (enterprise.context.conversation)
>
>                             and thus since javax is both x above and a
>                             bean name of Mark's bean,
>                             this
>                             results in an exception.
>
>
>                                 Thus the rest of your argumentation
>                                 chain is also invalid.
>
>                                 LieGrue,
>                                 strub
>
>
>                                     On Thursday, 15 January 2015,
>                                     10:47, Jozef Hartinger
>                                     <jharting at redhat.com
>                                     <mailto:jharting at redhat.com>> wrote:
>
>                                         T he @Named("javax") argument
>                                         is not valid. The spec says:
>
>                                     Suppose two beans are both
>                                     available for injection in a
>                                     certain war,
>                                     and
>                                     either:
>                                     - the two beans have the same bean
>                                     name and the name is not
>                                     resolvable,
>                                     or
>                                     - the bean name of one bean is of
>                                     the form x.y, where y is a valid
>                                     bean
>                                     name, and x is the bean
>                                     name of the other bean,
>                                     the container automatically
>                                     detects the problem and treats it as a
>                                     deployment problem.
>
>                                     So we have two beans:
>                                     -
>                                     javax.enterprise.context.conversation
>                                     (the built-in one)
>                                     - javax (Marks's bean)
>
>                                     now:
>
>                                     1) the bean name of one bean is of
>                                     the form x.y, where y is a valid
>                                     bean
>                                     name - that is
>                                     javax.enterprise.context.conversation
>                                     x = javax
>                                     y = enterprise.context.conversation
>                                     2) and x is the bean name of the
>                                     other bean - same as the name of
>                                     Mark's
>                                     @Named("javax") bean
>                                     3) the container automatically
>                                     detects the problem and treats it as a
>                                     deployment problem
>
>                                     Therefore, a bean named
>                                     @Named("javax") will cause a
>                                     deployment
>                                     problem
>                                     no matter whether it is actually
>                                     available via EL or not.
>
>                                     To summarize, the spec already
>                                     anticipates the problem and forbids
>                                     this
>                                     case explicitly.
>
>
>
>                                     On 01/14/2015 04:45 PM, Mark
>                                     Struberg wrote:
>
>                                              And then break all
>                                         applications which have a
>                                         @Named("javax")
>
>                                     public class MyBean?
>
>                                              It's simply not an option
>                                         imo. It breaks lots of other
>                                         specs and
>
>                                     features. This is an XOR situation.
>
>
>                                              LieGrue,
>                                              strub
>
>
>
>
>                                              ----- Original Message -----
>
>                                                  From: Pete Muir
>                                             <pmuir at redhat.com
>                                             <mailto:pmuir at redhat.com>>
>                                                  To: Romain
>                                             Manni-Bucau
>                                             <rmannibucau at gmail.com
>                                             <mailto:rmannibucau at gmail.com>>
>                                                  Cc: Cdi-dev
>                                             <cdi-dev at lists.jboss.org
>                                             <mailto:cdi-dev at lists.jboss.org>>;
>                                             Edward Burns
>
>                                     <edward.burns at oracle.com
>                                     <mailto:edward.burns at oracle.com>>
>
>                                                  Sent: Wednesday, 14
>                                             January 2015, 11:56
>                                                  Subject: Re:
>                                             [cdi-dev] Answer from EL
>                                             spec lead: no,    "."
>
>                                     is not valid in an EL name.
>
>                                                  We need to go for
>                                             both (A) and (B).
>
>                                                  We would need to
>                                             deprecate the existing
>                                             name before we can
>                                             allow
>                                             it
>                                             to
>
>                                     not be
>
>                                                  supported. This means
>                                             CDI 3. So I would suggest
>                                             we deprecate it
>                                             in
>                                             2,
>
>                                     add an
>
>                                                  alternative that can
>                                             be used, and then consider
>                                             removing it in
>                                             CDI
>                                             3.
>
>                                     In the
>
>                                                  meantime for CDI 2,
>                                             we will need to improve
>                                             the TCK to check
>                                             this
>                                             more
>                                                  carefully.
>
>                                                        On 14 Jan 2015,
>                                                 at 10:09, Romain
>                                                 Manni-Bucau
>
>                                     <rmannibucau at gmail.com
>                                     <mailto:rmannibucau at gmail.com>>
>
>                                                  wrote:
>
>                                                        +1 for B (IMO
>                                                 it is not used that much)
>
>
>
>
>                                                        Romain Manni-Bucau
>                                                        @rmannibucau
>                                                 http://www.tomitribe.com
>                                                 http://rmannibucau.wordpress.com
>                                                 https://github.com/rmannibucau
>
>
>                                                        2015-01-14
>                                                 10:54 GMT+01:00 Jozef
>                                                 Hartinger
>
>                                     <jharting at redhat.com
>                                     <mailto:jharting at redhat.com>>:
>
>                                                            I think
>                                                     further action is
>                                                     needed on this.
>                                                     Now that it has
>
>                                     been
>
>                                                  confirmed
>
>                                                            that
>                                                     "javax.enterprise.context.conversation"
>                                                     itself
>
>                                     is not a
>
>                                                  valid EL
>
>                                                            name we
>                                                     should either:
>
>                                                            A) Require
>                                                     all CDI
>                                                     implementations to
>                                                     adapt the
>
>                                     property-based approach
>
>                                                            which
>                                                     allows this to be
>                                                     implemented
>                                                     portably (as Weld
>                                                     does)
>                                                            B) Declare
>                                                     publicly that
>                                                     although the CDI
>                                                     spec declares the
>
>                                     given name,
>
>                                                            it is a bug
>                                                     and applications
>                                                     should not use the
>                                                     name. (What
>
>                                     about
>
>                                                          
>                                                      compatibility
>                                                     with existing
>                                                     applications?)
>
>                                                            Jozef
>
>                                                            On
>                                                     01/08/2015 09:27
>                                                     AM, Mark Struberg
>                                                     wrote:
>
>                                                                Dear
>                                                         CDI fellows!
>
>                                                                I've
>                                                         received an
>                                                         answer
>                                                         regarding our
>                                                         EL question
>
>                                     from the EL
>
>                                                  Spec Lead.
>
>                                                                Ed,
>                                                         thanks for
>                                                         helping us!
>
>
>                                                                LieGrue,
>                                                                strub
>
>
>
>
>                                                                    On
>                                                             Tuesday, 6
>                                                             January
>                                                             2015,
>                                                             23:14,
>                                                             Edward Burns
>
>                                                
>                                              <edward.burns at oracle.com
>                                             <mailto:edward.burns at oracle.com>>
>                                             wrote:
>
>                                                                      
>                                                                  Hello
>                                                                 Mark,
>
>                                                                    To
>                                                             close this
>                                                             out, no,
>                                                             "." is not
>                                                             valid in
>
>                                     an EL
>
>                                                  name.  An EL name
>
>                                                                    must
>                                                                    be
>                                                             a java
>                                                             identifier. I'm
>                                                             told this was
>
>                                     discussed by Pete
>
>                                                  a long time
>
>                                                                    ago
>                                                             in the EL
>                                                             3.0 EG.
>
>                                                                    Ed
>
>                                                                    --
>                                                                    |
>                                                             edward.burns at oracle.com
>                                                             <mailto:edward.burns at oracle.com>
>                                                             | office:
>                                                             +1 407 458
>                                                             0017
>                                                                    |
>                                                             42 days
>                                                             til
>                                                             DevNexus 2015
>                                                                    |
>                                                             52 days
>                                                             til
>                                                             JavaLand 2015
>                                                                    |
>                                                             62 days
>                                                             til
>                                                             CONFESS 2015
>
>                                                          _______________________________________________
>                                                                cdi-dev
>                                                         mailing list
>                                                         cdi-dev at lists.jboss.org
>                                                         <mailto:cdi-dev at lists.jboss.org>
>                                                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>                                                                Note
>                                                         that for all
>                                                         code provided
>                                                         on this list, the
>
>                                     provider licenses
>
>                                                  the code under the
>                                             Apache License, Version 2
>                                                
>                                              (http://www.apache.org/licenses/LICENSE-2.0.html).
>                                             For all
>                                             other
>                                             ideas
>
>                                     provided
>
>                                                  on this list, the
>                                             provider waives all patent
>                                             and other
>                                             intellectual
>
>                                     property
>
>                                                  rights inherent in
>                                             such information.
>
>                                                      _______________________________________________
>                                                            cdi-dev
>                                                     mailing list
>                                                     cdi-dev at lists.jboss.org
>                                                     <mailto:cdi-dev at lists.jboss.org>
>                                                     https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>                                                            Note that
>                                                     for all code
>                                                     provided on this
>                                                     list, the provider
>
>                                     licenses the
>
>                                                  code under the Apache
>                                             License, Version 2
>                                                
>                                              (http://www.apache.org/licenses/LICENSE-2.0.html).
>                                             For all
>                                             other
>                                             ideas
>
>                                     provided
>
>                                                  on this list, the
>                                             provider waives all patent
>                                             and other
>                                             intellectual
>
>                                     property
>
>                                                  rights inherent in
>                                             such information.
>
>                                                      
>                                                  _______________________________________________
>                                                        cdi-dev mailing
>                                                 list
>                                                 cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>                                                 https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>                                                        Note that for
>                                                 all code provided on
>                                                 this list, the provider
>
>                                     licenses the
>
>                                                  code under the Apache
>                                             License, Version 2
>                                                
>                                              (http://www.apache.org/licenses/LICENSE-2.0.html).
>                                             For all
>                                             other
>                                             ideas
>
>                                     provided
>
>                                                  on this list, the
>                                             provider waives all patent
>                                             and other
>                                             intellectual
>
>                                     property
>
>                                                  rights inherent in
>                                             such information.
>
>
>                                                
>                                              _______________________________________________
>                                                  cdi-dev mailing list
>                                             cdi-dev at lists.jboss.org
>                                             <mailto:cdi-dev at lists.jboss.org>
>                                             https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>                                                  Note that for all
>                                             code provided on this
>                                             list, the provider
>                                             licenses
>                                             the
>
>                                     code
>
>                                                  under the Apache
>                                             License, Version 2
>                                                
>                                              (http://www.apache.org/licenses/LICENSE-2.0.html).
>                                             For all
>                                             other
>                                             ideas
>
>                                     provided
>
>                                                  on this list, the
>                                             provider waives all patent
>                                             and other
>                                             intellectual
>
>                                     property
>
>                                                  rights inherent in
>                                             such information.
>
>                                            
>                                          _______________________________________________
>                                              cdi-dev mailing list
>                                         cdi-dev at lists.jboss.org
>                                         <mailto:cdi-dev at lists.jboss.org>
>                                         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>                                              Note that for all code
>                                         provided on this list, the
>                                         provider
>                                         licenses
>                                         the
>
>                                     code under the Apache License,
>                                     Version 2
>                                     (http://www.apache.org/licenses/LICENSE-2.0.html).
>                                     For all other
>                                     ideas
>                                     provided
>                                     on this list, the provider waives
>                                     all patent and other intellectual
>                                     property
>                                     rights inherent in such information.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/f0c0a841/attachment-0001.html 

From struberg at yahoo.de  Fri Jan 16 02:37:18 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 16 Jan 2015 07:37:18 +0000 (UTC)
Subject: [cdi-dev] Answer from EL spec lead: no,
 "." is not valid in an EL name.
In-Reply-To: <54B8B97A.4080801@redhat.com>
References: <54B8B97A.4080801@redhat.com>
Message-ID: <1378158084.2027963.1421393838445.JavaMail.yahoo@jws11163.mail.ir2.yahoo.com>

Hi!

I'm still not sure whether this feature (basically having CDI to introduce own EL namespaces) is really useful. In any case it was a badly advertised if not to say well hidden one.
Otoh if this really IS a feature and the name of our Conversation is not just a special exception then I am ok with implementing this IF we come to the conclusion that it is really ok with the other specs.
 
Basically we somehow ditch the rest of the whole ELResolver mechanism and 'overrule' it that way.
The overall issue is that we can only detect naming conflicts inside CDI but have no chance to see whether an other ELResolver already occupies that namespace. I'm not sure if the EL EG is aware of what we do with that. This is really a highlander [1] approach, we don't let others air to breath that way. Of course it technically seems legit and also covered by the CDI spec - and it is not up to me alone to decide whether we like to do that or not.


LieGrue,
strub


[1] http://www.c2.com/cgi/wiki?HighlanderPrinciple



> On Friday, 16 January 2015, 8:11, Jozef Hartinger <jharting at redhat.com> wrote:
> > OK, the relevant part goes:
> 
> "If the bean name of one bean is of the form x.y, where y is a valid 
> bean name, and x is the bean name of the other bean,
> the container automatically detects the problem and treats it as a 
> deployment problem."
> 
> Let's have:
> @Named("team1.superBean.enriched") class Bean1
> @Named("team1.superBean") class Bean2
> 
> Now
> 1) "If the bean name of one bean is of the form x.y"
> 
> We can match the "x.y" pattern on Bean1's name as:
> (team1.superBean) . (enriched)
> thus:
> x = team1.superBean
> y = enriched
> 
> 2) "where y is a valid bean name"
> "enriched" is indeed a valid bean name
> 
> 3) "and x is the bean name of the other bean"
> x ("team1.superBean") is at the same time the name of Bean2
> 
> 4) Therefore, "the container automatically detects the problem and 
> treats it as a deployment problem".
> 
> Therefore, this scenario does not become a conflict at runtime.
> 
> HTH,
> Jozef
> 
> 
> 
> 
> 
> On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
>>  @Jozef: can you quote it please - sorry if it is obvious but I dont
>>  see it in 5.3.1, I look 1.2 version BTW. It only deals with names
>>  where or CDI where here we conflict between resolvers.
>> 
>> 
>>  Romain Manni-Bucau
>>  @rmannibucau
>>  http://www.tomitribe.com
>>  http://rmannibucau.wordpress.com
>>  https://github.com/rmannibucau
>> 
>> 
>>  2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>  On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>>>>>  @Named("team1.superBean") and 
> @Named("team1.superBean.enriched") will
>>>>>>  lead to conflicts and that's things I saw several times 
> in spring apps
>>>>>>  which are clearly not possible using CDI + EL properly.
>>>>>  Yes and these conflicts are handled by the spec. See 5.3.1
>>>>> 
>>>>  Hmm not sure. If enriched is a property of the first bean then spec
>>>>  doesn't help.
>>>  The spec deals with exactly these types of cases in 5.3.1
>>> 
>>>>>> 
>>>>>>  Romain Manni-Bucau
>>>>>>  @rmannibucau
>>>>>>  http://www.tomitribe.com
>>>>>>  http://rmannibucau.wordpress.com
>>>>>>  https://github.com/rmannibucau
>>>>>> 
>>>>>> 
>>>>>>  2015-01-15 11:22 GMT+01:00 Jozef Hartinger 
> <jharting at redhat.com>:
>>>>>>>  On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>>>  Jozef, your argumentation is flawed already at the 
> very beginning.
>>>>>>>>  Currently there is no bean with the name 
> "javax", thus "x.y ... and x
>>>>>>>>  is
>>>>>>>>  the
>>>>>>>>  bean name of the other bean" will not be a 
> problem.
>>>>>>>> 
>>>>>>>>  All that javax is simply not a bean name but a 
> dirty hack in the
>>>>>>>>  ELResolver. That is something totally different.
>>>>>>>  Mark, please read the e-mail again. I am not saying 
> there are two beans
>>>>>>>  named "javax". I am saying there are two 
> beans with the following
>>>>>>>  names:
>>>>>>> 
>>>>>>>  - javax.enterprise.context.conversation (the built-in 
> one)
>>>>>>>  - javax (Marks's bean)
>>>>>>> 
>>>>>>>  where the former one is in form x.y where y is a valid 
> bean name:
>>>>>>>  (javax) . (enterprise.context.conversation)
>>>>>>> 
>>>>>>>  and thus since javax is both x above and a bean name of 
> Mark's bean,
>>>>>>>  this
>>>>>>>  results in an exception.
>>>>>>> 
>>>>>>> 
>>>>>>>>  Thus the rest of your argumentation chain is also 
> invalid.
>>>>>>>> 
>>>>>>>>  LieGrue,
>>>>>>>>  strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>  On Thursday, 15 January 2015, 10:47, Jozef 
> Hartinger
>>>>>>>>>  <jharting at redhat.com> wrote:
>>>>>>>>>>  T he @Named("javax") argument is 
> not valid. The spec says:
>>>>>>>>>  Suppose two beans are both available for 
> injection in a certain war,
>>>>>>>>>  and
>>>>>>>>>  either:
>>>>>>>>>  - the two beans have the same bean name and the 
> name is not
>>>>>>>>>  resolvable,
>>>>>>>>>  or
>>>>>>>>>  - the bean name of one bean is of the form x.y, 
> where y is a valid
>>>>>>>>>  bean
>>>>>>>>>  name, and x is the bean
>>>>>>>>>  name of the other bean,
>>>>>>>>>  the container automatically detects the problem 
> and treats it as a
>>>>>>>>>  deployment problem.
>>>>>>>>> 
>>>>>>>>>  So we have two beans:
>>>>>>>>>  - javax.enterprise.context.conversation (the 
> built-in one)
>>>>>>>>>  - javax (Marks's bean)
>>>>>>>>> 
>>>>>>>>>  now:
>>>>>>>>> 
>>>>>>>>>  1) the bean name of one bean is of the form 
> x.y, where y is a valid
>>>>>>>>>  bean
>>>>>>>>>  name - that is 
> javax.enterprise.context.conversation
>>>>>>>>>  x = javax
>>>>>>>>>  y = enterprise.context.conversation
>>>>>>>>>  2) and x is the bean name of the other bean - 
> same as the name of
>>>>>>>>>  Mark's
>>>>>>>>>  @Named("javax") bean
>>>>>>>>>  3) the container automatically detects the 
> problem and treats it as a
>>>>>>>>>  deployment problem
>>>>>>>>> 
>>>>>>>>>  Therefore, a bean named 
> @Named("javax") will cause a deployment
>>>>>>>>>  problem
>>>>>>>>>  no matter whether it is actually available via 
> EL or not.
>>>>>>>>> 
>>>>>>>>>  To summarize, the spec already anticipates the 
> problem and forbids
>>>>>>>>>  this
>>>>>>>>>  case explicitly.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>>>>       And then break all applications which 
> have a @Named("javax")
>>>>>>>>>  public class MyBean?
>>>>>>>>>>       It's simply not an option imo. It 
> breaks lots of other specs and
>>>>>>>>>  features. This is an XOR situation.
>>>>>>>>>> 
>>>>>>>>>>       LieGrue,
>>>>>>>>>>       strub
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>       ----- Original Message -----
>>>>>>>>>>>       From: Pete Muir 
> <pmuir at redhat.com>
>>>>>>>>>>>       To: Romain Manni-Bucau 
> <rmannibucau at gmail.com>
>>>>>>>>>>>       Cc: Cdi-dev 
> <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>>>>>  <edward.burns at oracle.com>
>>>>>>>>>>>       Sent: Wednesday, 14 January 2015, 
> 11:56
>>>>>>>>>>>       Subject: Re: [cdi-dev] Answer from 
> EL spec lead: no,    "."
>>>>>>>>>  is not valid in an EL name.
>>>>>>>>>>>       We need to go for both (A) and 
> (B).
>>>>>>>>>>> 
>>>>>>>>>>>       We would need to deprecate the 
> existing name before we can
>>>>>>>>>>>  allow
>>>>>>>>>>>  it
>>>>>>>>>>>  to
>>>>>>>>>  not be
>>>>>>>>>>>       supported. This means CDI 3. So I 
> would suggest we deprecate it
>>>>>>>>>>>  in
>>>>>>>>>>>  2,
>>>>>>>>>  add an
>>>>>>>>>>>       alternative that can be used, and 
> then consider removing it in
>>>>>>>>>>>  CDI
>>>>>>>>>>>  3.
>>>>>>>>>  In the
>>>>>>>>>>>       meantime for CDI 2, we will need 
> to improve the TCK to check
>>>>>>>>>>>  this
>>>>>>>>>>>  more
>>>>>>>>>>>       carefully.
>>>>>>>>>>> 
>>>>>>>>>>>>         On 14 Jan 2015, at 10:09, 
> Romain Manni-Bucau
>>>>>>>>>  <rmannibucau at gmail.com>
>>>>>>>>>>>       wrote:
>>>>>>>>>>>>         +1 for B (IMO it is not used 
> that much)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>         Romain Manni-Bucau
>>>>>>>>>>>>         @rmannibucau
>>>>>>>>>>>>       http://www.tomitribe.com
>>>>>>>>>>>>       
> http://rmannibucau.wordpress.com
>>>>>>>>>>>>       https://github.com/rmannibucau
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>         2015-01-14 10:54 GMT+01:00 
> Jozef Hartinger
>>>>>>>>>  <jharting at redhat.com>:
>>>>>>>>>>>>>         I think further action 
> is needed on this. Now that it has
>>>>>>>>>  been
>>>>>>>>>>>       confirmed
>>>>>>>>>>>>>         that 
> "javax.enterprise.context.conversation" itself
>>>>>>>>>  is not a
>>>>>>>>>>>       valid EL
>>>>>>>>>>>>>         name we should either:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         A) Require all CDI 
> implementations to adapt the
>>>>>>>>>  property-based approach
>>>>>>>>>>>>>         which allows this to be 
> implemented portably (as Weld does)
>>>>>>>>>>>>>         B) Declare publicly that 
> although the CDI spec declares the
>>>>>>>>>  given name,
>>>>>>>>>>>>>         it is a bug and 
> applications should not use the name. (What
>>>>>>>>>  about
>>>>>>>>>>>>>         compatibility with 
> existing applications?)
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         Jozef
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         On 01/08/2015 09:27 AM, 
> Mark Struberg wrote:
>>>>>>>>>>>>>>         Dear CDI fellows!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>         I've received an 
> answer regarding our EL question
>>>>>>>>>  from the EL
>>>>>>>>>>>       Spec Lead.
>>>>>>>>>>>>>>         Ed, thanks for 
> helping us!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>         LieGrue,
>>>>>>>>>>>>>>         strub
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>         On Tuesday, 6 
> January 2015, 23:14, Edward Burns
>>>>>>>>>>>       <edward.burns at oracle.com> 
> wrote:
>>>>>>>>>>>>>>>>         Hello Mark,
>>>>>>>>>>>>>>>         To close this 
> out, no, "." is not valid in
>>>>>>>>>  an EL
>>>>>>>>>>>       name.  An EL name
>>>>>>>>>>>>>>>         must
>>>>>>>>>>>>>>>         be a java 
> identifier.  I'm told this was
>>>>>>>>>  discussed by Pete
>>>>>>>>>>>       a long time
>>>>>>>>>>>>>>>         ago in the EL 
> 3.0 EG.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>         Ed
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>         --
>>>>>>>>>>>>>>>         | 
> edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>>>>         | 42 days til 
> DevNexus 2015
>>>>>>>>>>>>>>>         | 52 days til 
> JavaLand 2015
>>>>>>>>>>>>>>>         | 62 days til 
> CONFESS 2015
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>         
> _______________________________________________
>>>>>>>>>>>>>>         cdi-dev mailing list
>>>>>>>>>>>>>>       
> cdi-dev at lists.jboss.org
>>>>>>>>>>>>>>       
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>         Note that for all 
> code provided on this list, the
>>>>>>>>>  provider licenses
>>>>>>>>>>>       the code under the Apache License, 
> Version 2
>>>>>>>>>>>       
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>>  other
>>>>>>>>>>>  ideas
>>>>>>>>>  provided
>>>>>>>>>>>       on this list, the provider waives 
> all patent and other
>>>>>>>>>>>  intellectual
>>>>>>>>>  property
>>>>>>>>>>>       rights inherent in such 
> information.
>>>>>>>>>>>>>         
> _______________________________________________
>>>>>>>>>>>>>         cdi-dev mailing list
>>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>>       
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         Note that for all code 
> provided on this list, the provider
>>>>>>>>>  licenses the
>>>>>>>>>>>       code under the Apache License, 
> Version 2
>>>>>>>>>>>       
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>>  other
>>>>>>>>>>>  ideas
>>>>>>>>>  provided
>>>>>>>>>>>       on this list, the provider waives 
> all patent and other
>>>>>>>>>>>  intellectual
>>>>>>>>>  property
>>>>>>>>>>>       rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>>>         
> _______________________________________________
>>>>>>>>>>>>         cdi-dev mailing list
>>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>>       
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>> 
>>>>>>>>>>>>         Note that for all code 
> provided on this list, the provider
>>>>>>>>>  licenses the
>>>>>>>>>>>       code under the Apache License, 
> Version 2
>>>>>>>>>>>       
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>>  other
>>>>>>>>>>>  ideas
>>>>>>>>>  provided
>>>>>>>>>>>       on this list, the provider waives 
> all patent and other
>>>>>>>>>>>  intellectual
>>>>>>>>>  property
>>>>>>>>>>>       rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>       
> _______________________________________________
>>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>>       
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>>>>>>>>>>>       Note that for all code provided on 
> this list, the provider
>>>>>>>>>>>  licenses
>>>>>>>>>>>  the
>>>>>>>>>  code
>>>>>>>>>>>       under the Apache License, Version 
> 2
>>>>>>>>>>>       
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all
>>>>>>>>>>>  other
>>>>>>>>>>>  ideas
>>>>>>>>>  provided
>>>>>>>>>>>       on this list, the provider waives 
> all patent and other
>>>>>>>>>>>  intellectual
>>>>>>>>>  property
>>>>>>>>>>>       rights inherent in such 
> information.
>>>>>>>>>>> 
>>>>>>>>>>       
> _______________________________________________
>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>       cdi-dev at lists.jboss.org
>>>>>>>>>>       
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>> 
>>>>>>>>>>       Note that for all code provided on 
> this list, the provider
>>>>>>>>>>  licenses
>>>>>>>>>>  the
>>>>>>>>>  code under the Apache License, Version 2
>>>>>>>>> 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>>>  ideas
>>>>>>>>>  provided
>>>>>>>>>  on this list, the provider waives all patent 
> and other intellectual
>>>>>>>>>  property
>>>>>>>>>  rights inherent in such information.
>>>>>>>>> 
> 

From arjan.tijms at gmail.com  Fri Jan 16 12:17:24 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 16 Jan 2015 18:17:24 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
Message-ID: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>

Hi,

I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.

Originally I had defined my interceptor as follows;

@Interceptor
@Asynchronous
@Priority(APPLICATION)
public class AsynchronousInterceptor implements Serializable {

    private static final long serialVersionUID = 1L;

    @Resource
    private ManagedExecutorService managedExecutorService;

    @AroundInvoke
    public Object submitAsync(InvocationContext ctx) throws Exception {
        return new FutureDelegator(managedExecutorService.submit( ()-> {
return ctx.proceed(); } ));
    }

}

With FutureDelegator as follows:

public class FutureDelegator implements Future<Object> {

    private Future<?> future;

    public FutureDelegator(Future<?> future) {
        this.future = future;
    }

    @Override
    public Object get() throws InterruptedException, ExecutionException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
        if (asyncResult == null) {
            return null;
        }

        return asyncResult.get();
    }

    @Override
    public Object get(long timeout, TimeUnit unit) throws
InterruptedException,    ExecutionException, TimeoutException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout,
unit);
        if (asyncResult == null) {
            return null;
        }

        return asyncResult.get();
    }

    @Override
    public boolean cancel(boolean mayInterruptIfRunning) {
        return future.cancel(mayInterruptIfRunning);
    }

    @Override
    public boolean isCancelled() {
        return future.isCancelled();
    }
    @Override
    public boolean isDone() {
        return future.isDone();
    }

}

This of course didn't quite work, as the InvocationContext will be reset
after the @AroundInvoke method returns, and an infinite intercept loop
results (on Weld).

I got it to work though on Weld by using a thread local check to break that
loop:

@Interceptor
@Asynchronous
@Priority(PLATFORM_BEFORE)
public class AsynchronousInterceptor implements Serializable {

    private static final long serialVersionUID = 1L;

    @Resource
    private ManagedExecutorService managedExecutorService;

    private static final ThreadLocal<Boolean> asyncInvocation = new
ThreadLocal<Boolean>();

    @AroundInvoke
    public synchronized Object submitAsync(InvocationContext ctx) throws
Exception {

        if (TRUE.equals(asyncInvocation.get())) {
            return ctx.proceed();
        }

        return new FutureDelegator(managedExecutorService.submit( ()-> {
            try {
                asyncInvocation.set(TRUE);
                return ctx.proceed();
            } finally {
                 asyncInvocation.remove();
            }
        }));
    }

}

But I've got a feeling this works just by chance and not because the
workaround is so clever.

What do you guys think, what would be the best way to support this with the
current CDI version? Or would CDI/Interceptors need something like
Servlet's async support, where the InvocationContext is put into async mode
whereafter it "simply" allows an other thread to continue processing on it?

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/75436b38/attachment.html 

From jharting at redhat.com  Fri Jan 16 16:41:33 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 16 Jan 2015 22:41:33 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
Message-ID: <54B9858D.7010909@redhat.com>

Hi Arjan,

I did some changes recently in Weld interceptors and this usecase now 
works smoothly. The code is not part of a release yet. See this test for 
a simple implementation of an @Async interceptor (basically the same as 
your initial attempt). Note that the chain is repeatable but at the same 
time it is not reset after dispatch to a different thread so you no 
longer need the ThreadLocal nor any other workaround.

https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java

Jozef

On 01/16/2015 06:17 PM, arjan tijms wrote:
> Hi,
>
> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>
> Originally I had defined my interceptor as follows;
>
> @Interceptor
> @Asynchronous
> @Priority(APPLICATION)
> public class AsynchronousInterceptor implements Serializable {
>
>     private static final long serialVersionUID = 1L;
>
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>
>     @AroundInvoke
>     public Object submitAsync(InvocationContext ctx) throws Exception {
>         return new FutureDelegator(managedExecutorService.submit( ()-> 
> { return ctx.proceed(); } ));
>     }
>
> }
>
> With FutureDelegator as follows:
>
> public class FutureDelegator implements Future<Object> {
>
>     private Future<?> future;
>
>     public FutureDelegator(Future<?> future) {
>         this.future = future;
>     }
>
>     @Override
>     public Object get() throws InterruptedException, ExecutionException {
>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>         if (asyncResult == null) {
>             return null;
>         }
>
>         return asyncResult.get();
>     }
>
>     @Override
>     public Object get(long timeout, TimeUnit unit) throws 
> InterruptedException,    ExecutionException, TimeoutException {
>         AsyncResult<?> asyncResult = (AsyncResult<?>) 
> future.get(timeout, unit);
>         if (asyncResult == null) {
>             return null;
>         }
>
>         return asyncResult.get();
>     }
>
>     @Override
>     public boolean cancel(boolean mayInterruptIfRunning) {
>         return future.cancel(mayInterruptIfRunning);
>     }
>
>     @Override
>     public boolean isCancelled() {
>         return future.isCancelled();
>     }
>     @Override
>     public boolean isDone() {
>         return future.isDone();
>     }
>
> }
>
> This of course didn't quite work, as the InvocationContext will be 
> reset after the @AroundInvoke method returns, and an infinite 
> intercept loop results (on Weld).
>
> I got it to work though on Weld by using a thread local check to break 
> that loop:
>
> @Interceptor
> @Asynchronous
> @Priority(PLATFORM_BEFORE)
> public class AsynchronousInterceptor implements Serializable {
>
>     private static final long serialVersionUID = 1L;
>
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>
>     private static final ThreadLocal<Boolean> asyncInvocation = new 
> ThreadLocal<Boolean>();
>
>     @AroundInvoke
>     public synchronized Object submitAsync(InvocationContext ctx) 
> throws Exception {
>
>         if (TRUE.equals(asyncInvocation.get())) {
>             return ctx.proceed();
>         }
>
>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>             try {
>                 asyncInvocation.set(TRUE);
>                 return ctx.proceed();
>             } finally {
>                  asyncInvocation.remove();
>             }
>         }));
>     }
>
> }
>
> But I've got a feeling this works just by chance and not because the 
> workaround is so clever.
>
> What do you guys think, what would be the best way to support this 
> with the current CDI version? Or would CDI/Interceptors need something 
> like Servlet's async support, where the InvocationContext is put into 
> async mode whereafter it "simply" allows an other thread to continue 
> processing on it?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/3c3ab5f7/attachment-0001.html 

From arjan.tijms at gmail.com  Fri Jan 16 18:32:13 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 17 Jan 2015 00:32:13 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <54B9858D.7010909@redhat.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
	<54B9858D.7010909@redhat.com>
Message-ID: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>

Hi,

On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
wrote:

>  Hi Arjan,
>
> I did some changes recently in Weld interceptors and this usecase now
> works smoothly. The code is not part of a release yet. See this test for a
> simple implementation of an @Async interceptor (basically the same as your
> initial attempt). Note that the chain is repeatable but at the same time it
> is not reset after dispatch to a different thread so you no longer need the
> ThreadLocal nor any other workaround.
>

That's quite a coincidence, it's indeed rather similar ;)

I wonder how it now works though, as the InvocationContext "ctx" does not
seem to be made aware that it's been dispatched to a different thread from
within the code. Does it use an internal thread local to keep state or so?

I'll also try to see what this does on OWB. Do you think this is something
that should work, or just something that Weld happens to support regardless
of the spec?

Kind regards,
Arjan




>
>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>
> Jozef
>
>
> On 01/16/2015 06:17 PM, arjan tijms wrote:
>
>  Hi,
>
>  I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>
> Originally I had defined my interceptor as follows;
>
> @Interceptor
> @Asynchronous
> @Priority(APPLICATION)
> public class AsynchronousInterceptor implements Serializable {
>
>     private static final long serialVersionUID = 1L;
>
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>
>     @AroundInvoke
>     public Object submitAsync(InvocationContext ctx) throws Exception {
>         return new FutureDelegator(managedExecutorService.submit( ()-> {
> return ctx.proceed(); } ));
>     }
>
> }
>
>  With FutureDelegator as follows:
>
> public class FutureDelegator implements Future<Object> {
>
>     private Future<?> future;
>
>     public FutureDelegator(Future<?> future) {
>         this.future = future;
>     }
>
>     @Override
>     public Object get() throws InterruptedException, ExecutionException {
>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>         if (asyncResult == null) {
>             return null;
>         }
>
>         return asyncResult.get();
>     }
>
>     @Override
>     public Object get(long timeout, TimeUnit unit) throws
> InterruptedException,    ExecutionException, TimeoutException {
>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout,
> unit);
>         if (asyncResult == null) {
>             return null;
>         }
>
>         return asyncResult.get();
>     }
>
>     @Override
>     public boolean cancel(boolean mayInterruptIfRunning) {
>         return future.cancel(mayInterruptIfRunning);
>     }
>
>     @Override
>     public boolean isCancelled() {
>         return future.isCancelled();
>     }
>     @Override
>     public boolean isDone() {
>         return future.isDone();
>     }
>
> }
>
>  This of course didn't quite work, as the InvocationContext will be reset
> after the @AroundInvoke method returns, and an infinite intercept loop
> results (on Weld).
>
> I got it to work though on Weld by using a thread local check to break
> that loop:
>
> @Interceptor
> @Asynchronous
> @Priority(PLATFORM_BEFORE)
> public class AsynchronousInterceptor implements Serializable {
>
>     private static final long serialVersionUID = 1L;
>
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>
>     private static final ThreadLocal<Boolean> asyncInvocation = new
> ThreadLocal<Boolean>();
>
>     @AroundInvoke
>     public synchronized Object submitAsync(InvocationContext ctx) throws
> Exception {
>
>         if (TRUE.equals(asyncInvocation.get())) {
>             return ctx.proceed();
>         }
>
>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>             try {
>                 asyncInvocation.set(TRUE);
>                 return ctx.proceed();
>             } finally {
>                  asyncInvocation.remove();
>             }
>         }));
>     }
>
> }
>
>  But I've got a feeling this works just by chance and not because the
> workaround is so clever.
>
>  What do you guys think, what would be the best way to support this with
> the current CDI version? Or would CDI/Interceptors need something like
> Servlet's async support, where the InvocationContext is put into async mode
> whereafter it "simply" allows an other thread to continue processing on it?
>
>  Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/2ecc8ac1/attachment.html 

From antonio.goncalves at gmail.com  Sat Jan 17 05:02:29 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sat, 17 Jan 2015 11:02:29 +0100
Subject: [cdi-dev]  What about nested conversation ?
Message-ID: <CA+ZZq98qYObTtLHN4-AbVJ4uT+_xOEF60WXUhrHeDVBGXODgkA@mail.gmail.com>

Hi all,

The MVC spec is wondering about having extra scopes or not (and if yes,
build them on top of CDI).

They brought this old topic : nested conversation.

Should we think about it for the CDI 2.0 release ?

WDYT ?

Antonio


On Fri, Jan 16, 2015 at 11:32 PM, Adrian Gonzalez <adr_gonzalez at yahoo.fr>
wrote:

>
> For CDI conversation scope :
> It's really a pain to use (you must mark begin and end, only one scope :
> no nested conversations, etc...)
> CODI and Deltaspike created their own ConversationScope which are easier
> to use in real life applications.
> see
> http://deltaspike.apache.org/documentation/jsf.html#__grouped_conversations
> Also see WindowScope in Deltaspike.
>
>

-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/b3aa081c/attachment.html 

From arne.limburg at openknowledge.de  Sat Jan 17 05:05:14 2015
From: arne.limburg at openknowledge.de (Arne Limburg)
Date: Sat, 17 Jan 2015 10:05:14 +0000
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
Message-ID: <D0DFF142.4C83C%arne.limburg@openknowledge.de>

Hi Arjan,

Since we almost don?t use ThreadLocals in OWB, I guess, this should work out of the box.
Did a quick check of the interceptor code and see no issues with handling over the InvocationContext to another thread. However, the InvocationContext has some internal state that could get confused, if proceed() is called in parallel from two different threads, but that?s another thing. Just give it a try and tell us about the result :-)

Cheers,
Arne

Von: arjan tijms <arjan.tijms at gmail.com<mailto:arjan.tijms at gmail.com>>
Datum: Samstag, 17. Januar 2015 00:32
An: Jozef Hartinger <jharting at redhat.com<mailto:jharting at redhat.com>>
Cc: "cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>" <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Betreff: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI

Hi,

On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com<mailto:jharting at redhat.com>> wrote:
Hi Arjan,

I did some changes recently in Weld interceptors and this usecase now works smoothly. The code is not part of a release yet. See this test for a simple implementation of an @Async interceptor (basically the same as your initial attempt). Note that the chain is repeatable but at the same time it is not reset after dispatch to a different thread so you no longer need the ThreadLocal nor any other workaround.

That's quite a coincidence, it's indeed rather similar ;)

I wonder how it now works though, as the InvocationContext "ctx" does not seem to be made aware that it's been dispatched to a different thread from within the code. Does it use an internal thread local to keep state or so?

I'll also try to see what this does on OWB. Do you think this is something that should work, or just something that Weld happens to support regardless of the spec?

Kind regards,
Arjan




https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java

Jozef


On 01/16/2015 06:17 PM, arjan tijms wrote:
Hi,

I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.

Originally I had defined my interceptor as follows;

@Interceptor
@Asynchronous
@Priority(APPLICATION)
public class AsynchronousInterceptor implements Serializable {

    private static final long serialVersionUID = 1L;

    @Resource
    private ManagedExecutorService managedExecutorService;

    @AroundInvoke
    public Object submitAsync(InvocationContext ctx) throws Exception {
        return new FutureDelegator(managedExecutorService.submit( ()-> { return ctx.proceed(); } ));
    }

}

With FutureDelegator as follows:

public class FutureDelegator implements Future<Object> {

    private Future<?> future;

    public FutureDelegator(Future<?> future) {
        this.future = future;
    }

    @Override
    public Object get() throws InterruptedException, ExecutionException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
        if (asyncResult == null) {
            return null;
        }

        return asyncResult.get();
    }

    @Override
    public Object get(long timeout, TimeUnit unit) throws InterruptedException,    ExecutionException, TimeoutException {
        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout, unit);
        if (asyncResult == null) {
            return null;
        }

        return asyncResult.get();
    }

    @Override
    public boolean cancel(boolean mayInterruptIfRunning) {
        return future.cancel(mayInterruptIfRunning);
    }

    @Override
    public boolean isCancelled() {
        return future.isCancelled();
    }
    @Override
    public boolean isDone() {
        return future.isDone();
    }

}

This of course didn't quite work, as the InvocationContext will be reset after the @AroundInvoke method returns, and an infinite intercept loop results (on Weld).

I got it to work though on Weld by using a thread local check to break that loop:

@Interceptor
@Asynchronous
@Priority(PLATFORM_BEFORE)
public class AsynchronousInterceptor implements Serializable {

    private static final long serialVersionUID = 1L;

    @Resource
    private ManagedExecutorService managedExecutorService;

    private static final ThreadLocal<Boolean> asyncInvocation = new ThreadLocal<Boolean>();

    @AroundInvoke
    public synchronized Object submitAsync(InvocationContext ctx) throws Exception {

        if (TRUE.equals(asyncInvocation.get())) {
            return ctx.proceed();
        }

        return new FutureDelegator(managedExecutorService.submit( ()-> {
            try {
                asyncInvocation.set(TRUE);
                return ctx.proceed();
            } finally {
                 asyncInvocation.remove();
            }
        }));
    }

}

But I've got a feeling this works just by chance and not because the workaround is so clever.

What do you guys think, what would be the best way to support this with the current CDI version? Or would CDI/Interceptors need something like Servlet's async support, where the InvocationContext is put into async mode whereafter it "simply" allows an other thread to continue processing on it?

Kind regards,
Arjan Tijms








_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/e43e746c/attachment-0001.html 

From antonio.goncalves at gmail.com  Sat Jan 17 05:05:14 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sat, 17 Jan 2015 11:05:14 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
	<54B9858D.7010909@redhat.com>
	<CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
Message-ID: <CA+ZZq99NxFLio1BaUeXYGARi89gt+fLgiPtbEQQELV0F935szg@mail.gmail.com>

@arjan Your example is base on  ManagedExecutorService from the Java EE
Concurrency spec. That's one topic we've been wondering about : should the
@Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
it looks like the spec might not be updated.

Antonio

On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>
>>  Hi Arjan,
>>
>> I did some changes recently in Weld interceptors and this usecase now
>> works smoothly. The code is not part of a release yet. See this test for a
>> simple implementation of an @Async interceptor (basically the same as your
>> initial attempt). Note that the chain is repeatable but at the same time it
>> is not reset after dispatch to a different thread so you no longer need the
>> ThreadLocal nor any other workaround.
>>
>
> That's quite a coincidence, it's indeed rather similar ;)
>
> I wonder how it now works though, as the InvocationContext "ctx" does not
> seem to be made aware that it's been dispatched to a different thread from
> within the code. Does it use an internal thread local to keep state or so?
>
> I'll also try to see what this does on OWB. Do you think this is something
> that should work, or just something that Weld happens to support regardless
> of the spec?
>
> Kind regards,
> Arjan
>
>
>
>
>>
>>
>> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>
>> Jozef
>>
>>
>> On 01/16/2015 06:17 PM, arjan tijms wrote:
>>
>>  Hi,
>>
>>  I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>
>> Originally I had defined my interceptor as follows;
>>
>> @Interceptor
>> @Asynchronous
>> @Priority(APPLICATION)
>> public class AsynchronousInterceptor implements Serializable {
>>
>>     private static final long serialVersionUID = 1L;
>>
>>     @Resource
>>     private ManagedExecutorService managedExecutorService;
>>
>>     @AroundInvoke
>>     public Object submitAsync(InvocationContext ctx) throws Exception {
>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>> return ctx.proceed(); } ));
>>     }
>>
>> }
>>
>>  With FutureDelegator as follows:
>>
>> public class FutureDelegator implements Future<Object> {
>>
>>     private Future<?> future;
>>
>>     public FutureDelegator(Future<?> future) {
>>         this.future = future;
>>     }
>>
>>     @Override
>>     public Object get() throws InterruptedException, ExecutionException {
>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>>         if (asyncResult == null) {
>>             return null;
>>         }
>>
>>         return asyncResult.get();
>>     }
>>
>>     @Override
>>     public Object get(long timeout, TimeUnit unit) throws
>> InterruptedException,    ExecutionException, TimeoutException {
>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout,
>> unit);
>>         if (asyncResult == null) {
>>             return null;
>>         }
>>
>>         return asyncResult.get();
>>     }
>>
>>     @Override
>>     public boolean cancel(boolean mayInterruptIfRunning) {
>>         return future.cancel(mayInterruptIfRunning);
>>     }
>>
>>     @Override
>>     public boolean isCancelled() {
>>         return future.isCancelled();
>>     }
>>     @Override
>>     public boolean isDone() {
>>         return future.isDone();
>>     }
>>
>> }
>>
>>  This of course didn't quite work, as the InvocationContext will be
>> reset after the @AroundInvoke method returns, and an infinite intercept
>> loop results (on Weld).
>>
>> I got it to work though on Weld by using a thread local check to break
>> that loop:
>>
>> @Interceptor
>> @Asynchronous
>> @Priority(PLATFORM_BEFORE)
>> public class AsynchronousInterceptor implements Serializable {
>>
>>     private static final long serialVersionUID = 1L;
>>
>>     @Resource
>>     private ManagedExecutorService managedExecutorService;
>>
>>     private static final ThreadLocal<Boolean> asyncInvocation = new
>> ThreadLocal<Boolean>();
>>
>>     @AroundInvoke
>>     public synchronized Object submitAsync(InvocationContext ctx) throws
>> Exception {
>>
>>         if (TRUE.equals(asyncInvocation.get())) {
>>             return ctx.proceed();
>>         }
>>
>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>>             try {
>>                 asyncInvocation.set(TRUE);
>>                 return ctx.proceed();
>>             } finally {
>>                  asyncInvocation.remove();
>>             }
>>         }));
>>     }
>>
>> }
>>
>>  But I've got a feeling this works just by chance and not because the
>> workaround is so clever.
>>
>>  What do you guys think, what would be the best way to support this with
>> the current CDI version? Or would CDI/Interceptors need something like
>> Servlet's async support, where the InvocationContext is put into async mode
>> whereafter it "simply" allows an other thread to continue processing on it?
>>
>>  Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/89cdd90a/attachment.html 

From struberg at yahoo.de  Sat Jan 17 05:34:15 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 17 Jan 2015 10:34:15 +0000 (UTC)
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <D0DFF142.4C83C%arne.limburg@openknowledge.de>
References: <D0DFF142.4C83C%arne.limburg@openknowledge.de>
Message-ID: <1108908118.2603390.1421490855239.JavaMail.yahoo@jws11170.mail.ir2.yahoo.com>

I think in OWB-1.1.x and OWB-1.0.x there have been a few more ThreadLocals. But we almost totally got rid of them in OWB-1.2.x and 1.5.x.
I also cannot say what impact any additional EJB hooks in e.g. WebSphere and SAP have...
LieGrue,
strub


On Saturday, 17 January 2015, 11:06, Arne Limburg <arne.limburg at openknowledge.de> wrote:


>
>
>Hi Arjan,
>
>
>Since we almost don?t use ThreadLocals in OWB, I guess, this should work out of the box.
>Did a quick check of the interceptor code and see no issues with handling over the InvocationContext to another thread. However, the InvocationContext has some internal state that could get confused, if proceed() is called in parallel from two different threads, but that?s another thing. Just give it a try and tell us about the result :-)
>
>
>Cheers,
>Arne
>
>
>Von: arjan tijms <arjan.tijms at gmail.com>
>Datum: Samstag, 17. Januar 2015 00:32
>An: Jozef Hartinger <jharting at redhat.com>
>Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>Betreff: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
>
>
>
>Hi,
>
>
>
>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com> wrote:
>
>Hi Arjan,
>>
>>I did some changes recently in Weld interceptors and this usecase now works smoothly. The code is not part of a release yet. See this test for a simple implementation of an @Async interceptor (basically the same as your initial attempt). Note that the chain
is repeatable but at the same time it is not reset after dispatch to a different thread so you no longer need the ThreadLocal nor any other workaround.
>>
>
>
>That's quite a coincidence, it's indeed rather similar ;)
>
>
>I wonder how it now works though, as the InvocationContext "ctx" does not seem to be made aware that it's been dispatched to a different thread from within the code. Does it use an internal thread local to keep state or so?
>
>
>I'll also try to see what this does on OWB. Do you think this is something that should work, or just something that Weld happens to support regardless of the spec?
>
>
>Kind regards,
>Arjan
>
>
>
>
> 
>
>>https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>
>>Jozef 
>>
>>
>>
>>On 01/16/2015 06:17 PM, arjan tijms wrote:
>>
>>Hi,
>>>
>>>
I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>>
>>>Originally I had defined my interceptor as follows;
>>>
>>>@Interceptor
>>>@Asynchronous
>>>@Priority(APPLICATION)
>>>public class AsynchronousInterceptor implements Serializable {
>>>
>>>    private static final long serialVersionUID = 1L;
>>>    
>>>    @Resource
>>>    private ManagedExecutorService managedExecutorService;
>>>
>>>    @AroundInvoke
>>>    public Object submitAsync(InvocationContext ctx) throws Exception {
>>>        return new FutureDelegator(managedExecutorService.submit( ()-> { return ctx.proceed(); } ));
>>>    }
>>>
>>>}
>>>
>>>
>>>With FutureDelegator as follows:
>>>
>>>public class FutureDelegator implements Future<Object> {
>>>    
>>>    private Future<?> future;
>>>    
>>>    public FutureDelegator(Future<?> future) {
>>>        this.future = future;
>>>    }
>>>
>>>    @Override
>>>    public Object get() throws InterruptedException, ExecutionException {
>>>        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>>>        if (asyncResult == null) {
>>>            return null;
>>>        }
>>>        
>>>        return asyncResult.get(); 
>>>    }
>>>    
>>>    @Override
>>>    public Object get(long timeout, TimeUnit unit) throws InterruptedException,    ExecutionException, TimeoutException {
>>>        AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout, unit);
>>>        if (asyncResult == null) {
>>>            return null;
>>>        }
>>>        
>>>        return asyncResult.get(); 
>>>    }
>>>    
>>>    @Override
>>>    public boolean cancel(boolean mayInterruptIfRunning) {
>>>        return future.cancel(mayInterruptIfRunning);
>>>    }
>>>    
>>>    @Override
>>>    public boolean isCancelled() {
>>>        return future.isCancelled();
>>>    }
>>>    @Override
>>>    public boolean isDone() {
>>>        return future.isDone();
>>>    }
>>>    
>>>}
>>>
>>>
>>>This of course didn't quite work, as the InvocationContext will be reset after the @AroundInvoke method returns, and an infinite intercept loop results (on Weld).
>>>
>>>I got it to work though on Weld by using a thread local check to break that loop:
>>>
>>>@Interceptor
>>>@Asynchronous
>>>@Priority(PLATFORM_BEFORE)
>>>public class AsynchronousInterceptor implements Serializable {
>>>
>>>    private static final long serialVersionUID = 1L;
>>>    
>>>    @Resource
>>>    private ManagedExecutorService managedExecutorService;
>>>    
>>>    private static final ThreadLocal<Boolean> asyncInvocation = new ThreadLocal<Boolean>();
>>>
>>>    @AroundInvoke
>>>    public synchronized Object submitAsync(InvocationContext ctx) throws Exception {
>>>        
>>>        if (TRUE.equals(asyncInvocation.get())) {
>>>            return ctx.proceed();
>>>        }
>>>        
>>>        return new FutureDelegator(managedExecutorService.submit( ()-> { 
>>>            try {
>>>                asyncInvocation.set(TRUE);
>>>                return ctx.proceed();
>>>            } finally {
>>>                 asyncInvocation.remove();
>>>            }
>>>        }));
>>>    }
>>>
>>>}
>>>
>>>
>>>But I've got a feeling this works just by chance and not because the workaround is so clever.
>>>
>>>
>>>What do you guys think, what would be the best way to support this with the current CDI version? Or would CDI/Interceptors need something like Servlet's async support, where the InvocationContext is put into async mode whereafter it "simply" allows an other thread to continue processing on it?
>>>
>>>
>>>Kind regards,
>>>Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
cdi-dev mailing list cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>


From arjan.tijms at gmail.com  Sat Jan 17 07:11:11 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 17 Jan 2015 13:11:11 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CA+ZZq99NxFLio1BaUeXYGARi89gt+fLgiPtbEQQELV0F935szg@mail.gmail.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
	<54B9858D.7010909@redhat.com>
	<CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
	<CA+ZZq99NxFLio1BaUeXYGARi89gt+fLgiPtbEQQELV0F935szg@mail.gmail.com>
Message-ID: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>

Hi,

On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
antonio.goncalves at gmail.com> wrote:

> @arjan Your example is base on  ManagedExecutorService from the Java EE
> Concurrency spec. That's one topic we've been wondering about : should the
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> it looks like the spec might not be updated.
>

The example I showed here would IMHO best be placed in the Java EE
Concurrency spec. That would in my opinion be a perfect analogy to
@Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
Concurrency, so theoretically it could also be put into a third spec.

Personally I would find it strange to put something in spec A, when it may
better belong in spec B, just because spec B is not updated. What's holding
the update of Java EE Concurrency back? If most of the EG members would be
of the opinion that an @Asynchronous interceptor belongs best in Java EE
Concurrency, then we can just update that spec, right?

I know that MR releases can be quite fast and agile process wise, while
still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
and I think the setup time was pretty fast. Mid feb 2013 we created the
JIRA issues, the MR draft was published early march 2013 and the release
was with EE 7 end may 2013.

If it would just be about putting a few interceptors formally in Java EE
Concurrency, then why not do such small update for it?

Kind regards,
Arjan


>
> Antonio
>
> On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
>> wrote:
>>
>>>  Hi Arjan,
>>>
>>> I did some changes recently in Weld interceptors and this usecase now
>>> works smoothly. The code is not part of a release yet. See this test for a
>>> simple implementation of an @Async interceptor (basically the same as your
>>> initial attempt). Note that the chain is repeatable but at the same time it
>>> is not reset after dispatch to a different thread so you no longer need the
>>> ThreadLocal nor any other workaround.
>>>
>>
>> That's quite a coincidence, it's indeed rather similar ;)
>>
>> I wonder how it now works though, as the InvocationContext "ctx" does not
>> seem to be made aware that it's been dispatched to a different thread from
>> within the code. Does it use an internal thread local to keep state or so?
>>
>> I'll also try to see what this does on OWB. Do you think this is
>> something that should work, or just something that Weld happens to support
>> regardless of the spec?
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>>
>>>
>>> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>>
>>> Jozef
>>>
>>>
>>> On 01/16/2015 06:17 PM, arjan tijms wrote:
>>>
>>>  Hi,
>>>
>>>  I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>>
>>> Originally I had defined my interceptor as follows;
>>>
>>> @Interceptor
>>> @Asynchronous
>>> @Priority(APPLICATION)
>>> public class AsynchronousInterceptor implements Serializable {
>>>
>>>     private static final long serialVersionUID = 1L;
>>>
>>>     @Resource
>>>     private ManagedExecutorService managedExecutorService;
>>>
>>>     @AroundInvoke
>>>     public Object submitAsync(InvocationContext ctx) throws Exception {
>>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>>> return ctx.proceed(); } ));
>>>     }
>>>
>>> }
>>>
>>>  With FutureDelegator as follows:
>>>
>>> public class FutureDelegator implements Future<Object> {
>>>
>>>     private Future<?> future;
>>>
>>>     public FutureDelegator(Future<?> future) {
>>>         this.future = future;
>>>     }
>>>
>>>     @Override
>>>     public Object get() throws InterruptedException, ExecutionException {
>>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>>>         if (asyncResult == null) {
>>>             return null;
>>>         }
>>>
>>>         return asyncResult.get();
>>>     }
>>>
>>>     @Override
>>>     public Object get(long timeout, TimeUnit unit) throws
>>> InterruptedException,    ExecutionException, TimeoutException {
>>>         AsyncResult<?> asyncResult = (AsyncResult<?>)
>>> future.get(timeout, unit);
>>>         if (asyncResult == null) {
>>>             return null;
>>>         }
>>>
>>>         return asyncResult.get();
>>>     }
>>>
>>>     @Override
>>>     public boolean cancel(boolean mayInterruptIfRunning) {
>>>         return future.cancel(mayInterruptIfRunning);
>>>     }
>>>
>>>     @Override
>>>     public boolean isCancelled() {
>>>         return future.isCancelled();
>>>     }
>>>     @Override
>>>     public boolean isDone() {
>>>         return future.isDone();
>>>     }
>>>
>>> }
>>>
>>>  This of course didn't quite work, as the InvocationContext will be
>>> reset after the @AroundInvoke method returns, and an infinite intercept
>>> loop results (on Weld).
>>>
>>> I got it to work though on Weld by using a thread local check to break
>>> that loop:
>>>
>>> @Interceptor
>>> @Asynchronous
>>> @Priority(PLATFORM_BEFORE)
>>> public class AsynchronousInterceptor implements Serializable {
>>>
>>>     private static final long serialVersionUID = 1L;
>>>
>>>     @Resource
>>>     private ManagedExecutorService managedExecutorService;
>>>
>>>     private static final ThreadLocal<Boolean> asyncInvocation = new
>>> ThreadLocal<Boolean>();
>>>
>>>     @AroundInvoke
>>>     public synchronized Object submitAsync(InvocationContext ctx) throws
>>> Exception {
>>>
>>>         if (TRUE.equals(asyncInvocation.get())) {
>>>             return ctx.proceed();
>>>         }
>>>
>>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>>>             try {
>>>                 asyncInvocation.set(TRUE);
>>>                 return ctx.proceed();
>>>             } finally {
>>>                  asyncInvocation.remove();
>>>             }
>>>         }));
>>>     }
>>>
>>> }
>>>
>>>  But I've got a feeling this works just by chance and not because the
>>> workaround is so clever.
>>>
>>>  What do you guys think, what would be the best way to support this
>>> with the current CDI version? Or would CDI/Interceptors need something like
>>> Servlet's async support, where the InvocationContext is put into async mode
>>> whereafter it "simply" allows an other thread to continue processing on it?
>>>
>>>  Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/0b8212d3/attachment.html 

From struberg at yahoo.de  Sat Jan 17 07:53:04 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 17 Jan 2015 12:53:04 +0000 (UTC)
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>
References: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>
Message-ID: <1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>

EE concurrency spec needs an update anyway. It currently doesn't explicitly require @RequestScoped beans to be supported on a new Thread. That breaks tons of frameworks and makes it barely usable in EE7.

LieGrue,
strub

On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com> wrote:


>
>
>Hi,
>
>
>
>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
>
>@arjan Your example is base on  ManagedExecutorService from the Java EE Concurrency spec. That's one topic we've been wondering about : should the @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But it looks like the spec might not be updated.
>
>
>The example I showed here would IMHO best be placed in the Java EE Concurrency spec. That would in my opinion be a perfect analogy to @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and Concurrency, so theoretically it could also be put into a third spec.
>
>
>Personally I would find it strange to put something in spec A, when it may better belong in spec B, just because spec B is not updated. What's holding the update of Java EE Concurrency back? If most of the EG members would be of the opinion that an @Asynchronous interceptor belongs best in Java EE Concurrency, then we can just update that spec, right?
>
>
>I know that MR releases can be quite fast and agile process wise, while still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member) and I think the setup time was pretty fast. Mid feb 2013 we created the JIRA issues, the MR draft was published early march 2013 and the release was with EE 7 end may 2013.
>
>
>If it would just be about putting a few interceptors formally in Java EE Concurrency, then why not do such small update for it?
>
>
>Kind regards,
>Arjan
> 
>
>>
>>Antonio
>>
>>
>>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>Hi,
>>>
>>>
>>>
>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com> wrote:
>>>
>>>Hi Arjan,
>>>>
>>>>I did some changes recently in Weld interceptors and this usecase
    now works smoothly. The code is not part of a release yet. See this
    test for a simple implementation of an @Async interceptor (basically
    the same as your initial attempt). Note that the chain is repeatable
    but at the same time it is not reset after dispatch to a different
    thread so you no longer need the ThreadLocal nor any other
    workaround.
>>>>
>>>
>>>
>>>That's quite a coincidence, it's indeed rather similar ;)
>>>
>>>
>>>I wonder how it now works though, as the InvocationContext "ctx" does not seem to be made aware that it's been dispatched to a different thread from within the code. Does it use an internal thread local to keep state or so?
>>>
>>>
>>>I'll also try to see what this does on OWB. Do you think this is something that should work, or just something that Weld happens to support regardless of the spec?
>>>
>>>
>>>Kind regards,
>>>Arjan
>>>
>>>
>>>
>>>
>>> 
>>>
>>>>https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>>>
>>>>Jozef
>>>>
>>>>
>>>>
>>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
>>>>
>>>>Hi,
>>>>>
>>>>>
I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>>>>
>>>>>Originally I had defined my interceptor as follows;
>>>>>
>>>>>@Interceptor
>>>>>@Asynchronous
>>>>>@Priority(APPLICATION)
>>>>>public class AsynchronousInterceptor implements Serializable {
>>>>>
>>>>>    private static final long serialVersionUID = 1L;
>>>>>    
>>>>>    @Resource
>>>>>    private ManagedExecutorService managedExecutorService;
>>>>>
>>>>>    @AroundInvoke
>>>>>    public Object submitAsync(InvocationContext ctx) throws
          Exception {
>>>>>        return new
          FutureDelegator(managedExecutorService.submit( ()-> {
          return ctx.proceed(); } ));
>>>>>    }
>>>>>
>>>>>}
>>>>>
>>>>>
>>>>>With FutureDelegator as follows:
>>>>>
>>>>>public class FutureDelegator implements Future<Object> {
>>>>>    
>>>>>    private Future<?> future;
>>>>>    
>>>>>    public FutureDelegator(Future<?> future) {
>>>>>        this.future = future;
>>>>>    }
>>>>>
>>>>>    @Override
>>>>>    public Object get() throws InterruptedException,
          ExecutionException {
>>>>>        AsyncResult<?> asyncResult =
          (AsyncResult<?>) future.get();
>>>>>        if (asyncResult == null) {
>>>>>            return null;
>>>>>        }
>>>>>        
>>>>>        return asyncResult.get(); 
>>>>>    }
>>>>>    
>>>>>    @Override
>>>>>    public Object get(long timeout, TimeUnit unit) throws
          InterruptedException,    ExecutionException, TimeoutException
          {
>>>>>        AsyncResult<?> asyncResult =
          (AsyncResult<?>) future.get(timeout, unit);
>>>>>        if (asyncResult == null) {
>>>>>            return null;
>>>>>        }
>>>>>        
>>>>>        return asyncResult.get(); 
>>>>>    }
>>>>>    
>>>>>    @Override
>>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
>>>>>        return future.cancel(mayInterruptIfRunning);
>>>>>    }
>>>>>    
>>>>>    @Override
>>>>>    public boolean isCancelled() {
>>>>>        return future.isCancelled();
>>>>>    }
>>>>>    @Override
>>>>>    public boolean isDone() {
>>>>>        return future.isDone();
>>>>>    }
>>>>>    
>>>>>}
>>>>>
>>>>>
>>>>>This of course didn't quite work, as the InvocationContext will be reset after the @AroundInvoke method returns, and an infinite intercept loop results (on Weld).
>>>>>
>>>>>I got it to work though on Weld by using a thread local check
          to break that loop:
>>>>>
>>>>>@Interceptor
>>>>>@Asynchronous
>>>>>@Priority(PLATFORM_BEFORE)
>>>>>public class AsynchronousInterceptor implements Serializable {
>>>>>
>>>>>    private static final long serialVersionUID = 1L;
>>>>>    
>>>>>    @Resource
>>>>>    private ManagedExecutorService managedExecutorService;
>>>>>    
>>>>>    private static final ThreadLocal<Boolean>
          asyncInvocation = new ThreadLocal<Boolean>();
>>>>>
>>>>>    @AroundInvoke
>>>>>    public synchronized Object submitAsync(InvocationContext
          ctx) throws Exception {
>>>>>        
>>>>>        if (TRUE.equals(asyncInvocation.get())) {
>>>>>            return ctx.proceed();
>>>>>        }
>>>>>        
>>>>>        return new
          FutureDelegator(managedExecutorService.submit( ()-> { 
>>>>>            try {
>>>>>                asyncInvocation.set(TRUE);
>>>>>                return ctx.proceed();
>>>>>            } finally {
>>>>>                 asyncInvocation.remove();
>>>>>            }
>>>>>        }));
>>>>>    }
>>>>>
>>>>>}
>>>>>
>>>>>
>>>>>But I've got a feeling this works just by chance and not because the workaround is so clever.
>>>>>
>>>>>
>>>>>What do you guys think, what would be the best way to support this with the current CDI version? Or would CDI/Interceptors need something like Servlet's async support, where the InvocationContext is put into async mode whereafter it "simply" allows an other thread to continue processing on it?
>>>>>
>>>>>
>>>>>Kind regards,
>>>>>Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>
>>>_______________________________________________
>>>cdi-dev mailing list
>>>cdi-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>
>>
>>
>>-- 
>>
>>Antonio Goncalves 
>>Software architect, Java Champion and Pluralsight author
>>
>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>

From rmannibucau at gmail.com  Sat Jan 17 08:03:35 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sat, 17 Jan 2015 14:03:35 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>
References: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>
	<1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>
Message-ID: <CACLE=7Oa4Fy-4QaS80_vGXEefysypr9iRT8wG0qoSwQx5oA29g@mail.gmail.com>

+1 for ee concurrency
Le 17 janv. 2015 13:53, "Mark Struberg" <struberg at yahoo.de> a ?crit :

> EE concurrency spec needs an update anyway. It currently doesn't
> explicitly require @RequestScoped beans to be supported on a new Thread.
> That breaks tons of frameworks and makes it barely usable in EE7.
>
> LieGrue,
> strub
>
> On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>
> >
> >
> >Hi,
> >
> >
> >
> >On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> >
> >@arjan Your example is base on  ManagedExecutorService from the Java EE
> Concurrency spec. That's one topic we've been wondering about : should the
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> it looks like the spec might not be updated.
> >
> >
> >The example I showed here would IMHO best be placed in the Java EE
> Concurrency spec. That would in my opinion be a perfect analogy to
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
> Concurrency, so theoretically it could also be put into a third spec.
> >
> >
> >Personally I would find it strange to put something in spec A, when it
> may better belong in spec B, just because spec B is not updated. What's
> holding the update of Java EE Concurrency back? If most of the EG members
> would be of the opinion that an @Asynchronous interceptor belongs best in
> Java EE Concurrency, then we can just update that spec, right?
> >
> >
> >I know that MR releases can be quite fast and agile process wise, while
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
> and I think the setup time was pretty fast. Mid feb 2013 we created the
> JIRA issues, the MR draft was published early march 2013 and the release
> was with EE 7 end may 2013.
> >
> >
> >If it would just be about putting a few interceptors formally in Java EE
> Concurrency, then why not do such small update for it?
> >
> >
> >Kind regards,
> >Arjan
> >
> >
> >>
> >>Antonio
> >>
> >>
> >>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >>Hi,
> >>>
> >>>
> >>>
> >>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> >>>
> >>>Hi Arjan,
> >>>>
> >>>>I did some changes recently in Weld interceptors and this usecase
>     now works smoothly. The code is not part of a release yet. See this
>     test for a simple implementation of an @Async interceptor (basically
>     the same as your initial attempt). Note that the chain is repeatable
>     but at the same time it is not reset after dispatch to a different
>     thread so you no longer need the ThreadLocal nor any other
>     workaround.
> >>>>
> >>>
> >>>
> >>>That's quite a coincidence, it's indeed rather similar ;)
> >>>
> >>>
> >>>I wonder how it now works though, as the InvocationContext "ctx" does
> not seem to be made aware that it's been dispatched to a different thread
> from within the code. Does it use an internal thread local to keep state or
> so?
> >>>
> >>>
> >>>I'll also try to see what this does on OWB. Do you think this is
> something that should work, or just something that Weld happens to support
> regardless of the spec?
> >>>
> >>>
> >>>Kind regards,
> >>>Arjan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>>>
> >>>>Jozef
> >>>>
> >>>>
> >>>>
> >>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>>>
> >>>>Hi,
> >>>>>
> >>>>>
> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
> >>>>>
> >>>>>Originally I had defined my interceptor as follows;
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(APPLICATION)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public Object submitAsync(InvocationContext ctx) throws
>           Exception {
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
>           return ctx.proceed(); } ));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>With FutureDelegator as follows:
> >>>>>
> >>>>>public class FutureDelegator implements Future<Object> {
> >>>>>
> >>>>>    private Future<?> future;
> >>>>>
> >>>>>    public FutureDelegator(Future<?> future) {
> >>>>>        this.future = future;
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get() throws InterruptedException,
>           ExecutionException {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get();
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get(long timeout, TimeUnit unit) throws
>           InterruptedException,    ExecutionException, TimeoutException
>           {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get(timeout, unit);
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
> >>>>>        return future.cancel(mayInterruptIfRunning);
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean isCancelled() {
> >>>>>        return future.isCancelled();
> >>>>>    }
> >>>>>    @Override
> >>>>>    public boolean isDone() {
> >>>>>        return future.isDone();
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>This of course didn't quite work, as the InvocationContext will be
> reset after the @AroundInvoke method returns, and an infinite intercept
> loop results (on Weld).
> >>>>>
> >>>>>I got it to work though on Weld by using a thread local check
>           to break that loop:
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(PLATFORM_BEFORE)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    private static final ThreadLocal<Boolean>
>           asyncInvocation = new ThreadLocal<Boolean>();
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public synchronized Object submitAsync(InvocationContext
>           ctx) throws Exception {
> >>>>>
> >>>>>        if (TRUE.equals(asyncInvocation.get())) {
> >>>>>            return ctx.proceed();
> >>>>>        }
> >>>>>
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
> >>>>>            try {
> >>>>>                asyncInvocation.set(TRUE);
> >>>>>                return ctx.proceed();
> >>>>>            } finally {
> >>>>>                 asyncInvocation.remove();
> >>>>>            }
> >>>>>        }));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>But I've got a feeling this works just by chance and not because the
> workaround is so clever.
> >>>>>
> >>>>>
> >>>>>What do you guys think, what would be the best way to support this
> with the current CDI version? Or would CDI/Interceptors need something like
> Servlet's async support, where the InvocationContext is put into async mode
> whereafter it "simply" allows an other thread to continue processing on it?
> >>>>>
> >>>>>
> >>>>>Kind regards,
> >>>>>Arjan Tijms
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> cdi-dev mailing list cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
> provided on this list, the provider licenses the code under the Apache
> License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
> all other ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >>>>
> >>>
> >>>_______________________________________________
> >>>cdi-dev mailing list
> >>>cdi-dev at lists.jboss.org
> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>>Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>
> >>
> >>
> >>--
> >>
> >>Antonio Goncalves
> >>Software architect, Java Champion and Pluralsight author
> >>
> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >_______________________________________________
> >cdi-dev mailing list
> >cdi-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/d742a2aa/attachment.html 

From werner.keil at gmail.com  Sat Jan 17 08:17:33 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sat, 17 Jan 2015 14:17:33 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
Message-ID: <CAAGawe0ip65gSL=A+O_zH1Rb7uFsS3Fw32a5yagX19TQ03Poxg@mail.gmail.com>

+1

I know JMS 2.x is just about to publish its first change via Errata/MR long
before the actual JSR for 2.1 is going to improve it further towards EE 8.
So it should not be a problem for Concurrency Utility JSR to do the same.

Werner

On Sat, Jan 17, 2015 at 1:53 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Building EJB-like @Asynchronous via interceptor in CDI
>       (arjan tijms)
>    2. Re: Building EJB-like @Asynchronous via interceptor in CDI
>       (Mark Struberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 17 Jan 2015 13:11:11 +0100
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
>         in CDI
> To: Antonio Goncalves <antonio.goncalves at gmail.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-
> AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
>
> > @arjan Your example is base on  ManagedExecutorService from the Java EE
> > Concurrency spec. That's one topic we've been wondering about : should
> the
> > @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> > it looks like the spec might not be updated.
> >
>
> The example I showed here would IMHO best be placed in the Java EE
> Concurrency spec. That would in my opinion be a perfect analogy to
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
> Concurrency, so theoretically it could also be put into a third spec.
>
> Personally I would find it strange to put something in spec A, when it may
> better belong in spec B, just because spec B is not updated. What's holding
> the update of Java EE Concurrency back? If most of the EG members would be
> of the opinion that an @Asynchronous interceptor belongs best in Java EE
> Concurrency, then we can just update that spec, right?
>
> I know that MR releases can be quite fast and agile process wise, while
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
> and I think the setup time was pretty fast. Mid feb 2013 we created the
> JIRA issues, the MR draft was published early march 2013 and the release
> was with EE 7 end may 2013.
>
> If it would just be about putting a few interceptors formally in Java EE
> Concurrency, then why not do such small update for it?
>
> Kind regards,
> Arjan
>
>
> >
> > Antonio
> >
> > On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> >> wrote:
> >>
> >>>  Hi Arjan,
> >>>
> >>> I did some changes recently in Weld interceptors and this usecase now
> >>> works smoothly. The code is not part of a release yet. See this test
> for a
> >>> simple implementation of an @Async interceptor (basically the same as
> your
> >>> initial attempt). Note that the chain is repeatable but at the same
> time it
> >>> is not reset after dispatch to a different thread so you no longer
> need the
> >>> ThreadLocal nor any other workaround.
> >>>
> >>
> >> That's quite a coincidence, it's indeed rather similar ;)
> >>
> >> I wonder how it now works though, as the InvocationContext "ctx" does
> not
> >> seem to be made aware that it's been dispatched to a different thread
> from
> >> within the code. Does it use an internal thread local to keep state or
> so?
> >>
> >> I'll also try to see what this does on OWB. Do you think this is
> >> something that should work, or just something that Weld happens to
> support
> >> regardless of the spec?
> >>
> >> Kind regards,
> >> Arjan
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>>
> >>> Jozef
> >>>
> >>>
> >>> On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>>
> >>>  Hi,
> >>>
> >>>  I'm attempting to emulate EJB's @Asynchronous in CDI using
> interceptors.
> >>>
> >>> Originally I had defined my interceptor as follows;
> >>>
> >>> @Interceptor
> >>> @Asynchronous
> >>> @Priority(APPLICATION)
> >>> public class AsynchronousInterceptor implements Serializable {
> >>>
> >>>     private static final long serialVersionUID = 1L;
> >>>
> >>>     @Resource
> >>>     private ManagedExecutorService managedExecutorService;
> >>>
> >>>     @AroundInvoke
> >>>     public Object submitAsync(InvocationContext ctx) throws Exception {
> >>>         return new FutureDelegator(managedExecutorService.submit( ()->
> {
> >>> return ctx.proceed(); } ));
> >>>     }
> >>>
> >>> }
> >>>
> >>>  With FutureDelegator as follows:
> >>>
> >>> public class FutureDelegator implements Future<Object> {
> >>>
> >>>     private Future<?> future;
> >>>
> >>>     public FutureDelegator(Future<?> future) {
> >>>         this.future = future;
> >>>     }
> >>>
> >>>     @Override
> >>>     public Object get() throws InterruptedException,
> ExecutionException {
> >>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
> >>>         if (asyncResult == null) {
> >>>             return null;
> >>>         }
> >>>
> >>>         return asyncResult.get();
> >>>     }
> >>>
> >>>     @Override
> >>>     public Object get(long timeout, TimeUnit unit) throws
> >>> InterruptedException,    ExecutionException, TimeoutException {
> >>>         AsyncResult<?> asyncResult = (AsyncResult<?>)
> >>> future.get(timeout, unit);
> >>>         if (asyncResult == null) {
> >>>             return null;
> >>>         }
> >>>
> >>>         return asyncResult.get();
> >>>     }
> >>>
> >>>     @Override
> >>>     public boolean cancel(boolean mayInterruptIfRunning) {
> >>>         return future.cancel(mayInterruptIfRunning);
> >>>     }
> >>>
> >>>     @Override
> >>>     public boolean isCancelled() {
> >>>         return future.isCancelled();
> >>>     }
> >>>     @Override
> >>>     public boolean isDone() {
> >>>         return future.isDone();
> >>>     }
> >>>
> >>> }
> >>>
> >>>  This of course didn't quite work, as the InvocationContext will be
> >>> reset after the @AroundInvoke method returns, and an infinite intercept
> >>> loop results (on Weld).
> >>>
> >>> I got it to work though on Weld by using a thread local check to break
> >>> that loop:
> >>>
> >>> @Interceptor
> >>> @Asynchronous
> >>> @Priority(PLATFORM_BEFORE)
> >>> public class AsynchronousInterceptor implements Serializable {
> >>>
> >>>     private static final long serialVersionUID = 1L;
> >>>
> >>>     @Resource
> >>>     private ManagedExecutorService managedExecutorService;
> >>>
> >>>     private static final ThreadLocal<Boolean> asyncInvocation = new
> >>> ThreadLocal<Boolean>();
> >>>
> >>>     @AroundInvoke
> >>>     public synchronized Object submitAsync(InvocationContext ctx)
> throws
> >>> Exception {
> >>>
> >>>         if (TRUE.equals(asyncInvocation.get())) {
> >>>             return ctx.proceed();
> >>>         }
> >>>
> >>>         return new FutureDelegator(managedExecutorService.submit( ()->
> {
> >>>             try {
> >>>                 asyncInvocation.set(TRUE);
> >>>                 return ctx.proceed();
> >>>             } finally {
> >>>                  asyncInvocation.remove();
> >>>             }
> >>>         }));
> >>>     }
> >>>
> >>> }
> >>>
> >>>  But I've got a feeling this works just by chance and not because the
> >>> workaround is so clever.
> >>>
> >>>  What do you guys think, what would be the best way to support this
> >>> with the current CDI version? Or would CDI/Interceptors need something
> like
> >>> Servlet's async support, where the InvocationContext is put into async
> mode
> >>> whereafter it "simply" allows an other thread to continue processing
> on it?
> >>>
> >>>  Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://
> lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (
> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual property rights inherent in such information.
> >>
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site <http://www.antoniogoncalves.org> | Twitter
> > <http://twitter.com/agoncal> | LinkedIn
> > <http://www.linkedin.com/in/agoncal> | Pluralsight
> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/0b8212d3/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Sat, 17 Jan 2015 12:53:04 +0000 (UTC)
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
>         in CDI
> To: arjan tijms <arjan.tijms at gmail.com>,        Antonio Goncalves
>         <antonio.goncalves at gmail.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> 1515863897.2700554.1421499184135.JavaMail.yahoo at jws11122.mail.ir2.yahoo.com
> >
>
> Content-Type: text/plain; charset=UTF-8
>
> EE concurrency spec needs an update anyway. It currently doesn't
> explicitly require @RequestScoped beans to be supported on a new Thread.
> That breaks tons of frameworks and makes it barely usable in EE7.
>
> LieGrue,
> strub
>
> On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>
> >
> >
> >Hi,
> >
> >
> >
> >On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> >
> >@arjan Your example is base on  ManagedExecutorService from the Java EE
> Concurrency spec. That's one topic we've been wondering about : should the
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> it looks like the spec might not be updated.
> >
> >
> >The example I showed here would IMHO best be placed in the Java EE
> Concurrency spec. That would in my opinion be a perfect analogy to
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
> Concurrency, so theoretically it could also be put into a third spec.
> >
> >
> >Personally I would find it strange to put something in spec A, when it
> may better belong in spec B, just because spec B is not updated. What's
> holding the update of Java EE Concurrency back? If most of the EG members
> would be of the opinion that an @Asynchronous interceptor belongs best in
> Java EE Concurrency, then we can just update that spec, right?
> >
> >
> >I know that MR releases can be quite fast and agile process wise, while
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
> and I think the setup time was pretty fast. Mid feb 2013 we created the
> JIRA issues, the MR draft was published early march 2013 and the release
> was with EE 7 end may 2013.
> >
> >
> >If it would just be about putting a few interceptors formally in Java EE
> Concurrency, then why not do such small update for it?
> >
> >
> >Kind regards,
> >Arjan
> >
> >
> >>
> >>Antonio
> >>
> >>
> >>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >>Hi,
> >>>
> >>>
> >>>
> >>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> >>>
> >>>Hi Arjan,
> >>>>
> >>>>I did some changes recently in Weld interceptors and this usecase
>     now works smoothly. The code is not part of a release yet. See this
>     test for a simple implementation of an @Async interceptor (basically
>     the same as your initial attempt). Note that the chain is repeatable
>     but at the same time it is not reset after dispatch to a different
>     thread so you no longer need the ThreadLocal nor any other
>     workaround.
> >>>>
> >>>
> >>>
> >>>That's quite a coincidence, it's indeed rather similar ;)
> >>>
> >>>
> >>>I wonder how it now works though, as the InvocationContext "ctx" does
> not seem to be made aware that it's been dispatched to a different thread
> from within the code. Does it use an internal thread local to keep state or
> so?
> >>>
> >>>
> >>>I'll also try to see what this does on OWB. Do you think this is
> something that should work, or just something that Weld happens to support
> regardless of the spec?
> >>>
> >>>
> >>>Kind regards,
> >>>Arjan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>>>
> >>>>Jozef
> >>>>
> >>>>
> >>>>
> >>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>>>
> >>>>Hi,
> >>>>>
> >>>>>
> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
> >>>>>
> >>>>>Originally I had defined my interceptor as follows;
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(APPLICATION)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public Object submitAsync(InvocationContext ctx) throws
>           Exception {
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
>           return ctx.proceed(); } ));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>With FutureDelegator as follows:
> >>>>>
> >>>>>public class FutureDelegator implements Future<Object> {
> >>>>>
> >>>>>    private Future<?> future;
> >>>>>
> >>>>>    public FutureDelegator(Future<?> future) {
> >>>>>        this.future = future;
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get() throws InterruptedException,
>           ExecutionException {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get();
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get(long timeout, TimeUnit unit) throws
>           InterruptedException,    ExecutionException, TimeoutException
>           {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get(timeout, unit);
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
> >>>>>        return future.cancel(mayInterruptIfRunning);
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean isCancelled() {
> >>>>>        return future.isCancelled();
> >>>>>    }
> >>>>>    @Override
> >>>>>    public boolean isDone() {
> >>>>>        return future.isDone();
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>This of course didn't quite work, as the InvocationContext will be
> reset after the @AroundInvoke method returns, and an infinite intercept
> loop results (on Weld).
> >>>>>
> >>>>>I got it to work though on Weld by using a thread local check
>           to break that loop:
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(PLATFORM_BEFORE)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    private static final ThreadLocal<Boolean>
>           asyncInvocation = new ThreadLocal<Boolean>();
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public synchronized Object submitAsync(InvocationContext
>           ctx) throws Exception {
> >>>>>
> >>>>>        if (TRUE.equals(asyncInvocation.get())) {
> >>>>>            return ctx.proceed();
> >>>>>        }
> >>>>>
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
> >>>>>            try {
> >>>>>                asyncInvocation.set(TRUE);
> >>>>>                return ctx.proceed();
> >>>>>            } finally {
> >>>>>                 asyncInvocation.remove();
> >>>>>            }
> >>>>>        }));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>But I've got a feeling this works just by chance and not because the
> workaround is so clever.
> >>>>>
> >>>>>
> >>>>>What do you guys think, what would be the best way to support this
> with the current CDI version? Or would CDI/Interceptors need something like
> Servlet's async support, where the InvocationContext is put into async mode
> whereafter it "simply" allows an other thread to continue processing on it?
> >>>>>
> >>>>>
> >>>>>Kind regards,
> >>>>>Arjan Tijms
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> cdi-dev mailing list cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
> provided on this list, the provider licenses the code under the Apache
> License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
> all other ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >>>>
> >>>
> >>>_______________________________________________
> >>>cdi-dev mailing list
> >>>cdi-dev at lists.jboss.org
> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>>Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>
> >>
> >>
> >>--
> >>
> >>Antonio Goncalves
> >>Software architect, Java Champion and Pluralsight author
> >>
> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >_______________________________________________
> >cdi-dev mailing list
> >cdi-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 50, Issue 35
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/a5d69236/attachment-0001.html 

From antonio.goncalves at gmail.com  Sat Jan 17 10:30:49 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Sat, 17 Jan 2015 16:30:49 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>
References: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>
	<1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>
Message-ID: <CA+ZZq98B9R+udvkcofSM=MF_9Uh+jXDHP6oMB4k8Tcrh7puJ4g@mail.gmail.com>

@Arjan, remember the email I sent to the EE EG entitled "Status of the Java
EE 8 specifications". Bill Shannon replied :

*We agree on the long term vision.  This is almost entirely a resource
issue.  In order to do this, we have to stop doing something else, or we
have to delay the release.  Based on the feedback we've gotten from the
community, the things we've chosen to work on right now are the most
important.  We'd like to do what you suggest below as well, but it's most
likely going to have to be done later.*

So I don't know how we could "push" for an MR of the EE Concurrency spec.
Any idea ? Except harassing Bill to add resources to the EE Concurrency
spec and taking other resources out somewhere else... I don't know how we
could do this.

@Mark EE Concurreny could also add a @ThreadScoped like the one in Weld
(but with a EE meaning).

Antonio


On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <struberg at yahoo.de> wrote:

> EE concurrency spec needs an update anyway. It currently doesn't
> explicitly require @RequestScoped beans to be supported on a new Thread.
> That breaks tons of frameworks and makes it barely usable in EE7.
>
> LieGrue,
> strub
>
> On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>
> >
> >
> >Hi,
> >
> >
> >
> >On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> >
> >@arjan Your example is base on  ManagedExecutorService from the Java EE
> Concurrency spec. That's one topic we've been wondering about : should the
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> it looks like the spec might not be updated.
> >
> >
> >The example I showed here would IMHO best be placed in the Java EE
> Concurrency spec. That would in my opinion be a perfect analogy to
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
> Concurrency, so theoretically it could also be put into a third spec.
> >
> >
> >Personally I would find it strange to put something in spec A, when it
> may better belong in spec B, just because spec B is not updated. What's
> holding the update of Java EE Concurrency back? If most of the EG members
> would be of the opinion that an @Asynchronous interceptor belongs best in
> Java EE Concurrency, then we can just update that spec, right?
> >
> >
> >I know that MR releases can be quite fast and agile process wise, while
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
> and I think the setup time was pretty fast. Mid feb 2013 we created the
> JIRA issues, the MR draft was published early march 2013 and the release
> was with EE 7 end may 2013.
> >
> >
> >If it would just be about putting a few interceptors formally in Java EE
> Concurrency, then why not do such small update for it?
> >
> >
> >Kind regards,
> >Arjan
> >
> >
> >>
> >>Antonio
> >>
> >>
> >>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >>Hi,
> >>>
> >>>
> >>>
> >>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> >>>
> >>>Hi Arjan,
> >>>>
> >>>>I did some changes recently in Weld interceptors and this usecase
>     now works smoothly. The code is not part of a release yet. See this
>     test for a simple implementation of an @Async interceptor (basically
>     the same as your initial attempt). Note that the chain is repeatable
>     but at the same time it is not reset after dispatch to a different
>     thread so you no longer need the ThreadLocal nor any other
>     workaround.
> >>>>
> >>>
> >>>
> >>>That's quite a coincidence, it's indeed rather similar ;)
> >>>
> >>>
> >>>I wonder how it now works though, as the InvocationContext "ctx" does
> not seem to be made aware that it's been dispatched to a different thread
> from within the code. Does it use an internal thread local to keep state or
> so?
> >>>
> >>>
> >>>I'll also try to see what this does on OWB. Do you think this is
> something that should work, or just something that Weld happens to support
> regardless of the spec?
> >>>
> >>>
> >>>Kind regards,
> >>>Arjan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>>>
> >>>>Jozef
> >>>>
> >>>>
> >>>>
> >>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>>>
> >>>>Hi,
> >>>>>
> >>>>>
> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
> >>>>>
> >>>>>Originally I had defined my interceptor as follows;
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(APPLICATION)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public Object submitAsync(InvocationContext ctx) throws
>           Exception {
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
>           return ctx.proceed(); } ));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>With FutureDelegator as follows:
> >>>>>
> >>>>>public class FutureDelegator implements Future<Object> {
> >>>>>
> >>>>>    private Future<?> future;
> >>>>>
> >>>>>    public FutureDelegator(Future<?> future) {
> >>>>>        this.future = future;
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get() throws InterruptedException,
>           ExecutionException {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get();
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public Object get(long timeout, TimeUnit unit) throws
>           InterruptedException,    ExecutionException, TimeoutException
>           {
> >>>>>        AsyncResult<?> asyncResult =
>           (AsyncResult<?>) future.get(timeout, unit);
> >>>>>        if (asyncResult == null) {
> >>>>>            return null;
> >>>>>        }
> >>>>>
> >>>>>        return asyncResult.get();
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
> >>>>>        return future.cancel(mayInterruptIfRunning);
> >>>>>    }
> >>>>>
> >>>>>    @Override
> >>>>>    public boolean isCancelled() {
> >>>>>        return future.isCancelled();
> >>>>>    }
> >>>>>    @Override
> >>>>>    public boolean isDone() {
> >>>>>        return future.isDone();
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>This of course didn't quite work, as the InvocationContext will be
> reset after the @AroundInvoke method returns, and an infinite intercept
> loop results (on Weld).
> >>>>>
> >>>>>I got it to work though on Weld by using a thread local check
>           to break that loop:
> >>>>>
> >>>>>@Interceptor
> >>>>>@Asynchronous
> >>>>>@Priority(PLATFORM_BEFORE)
> >>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>
> >>>>>    private static final long serialVersionUID = 1L;
> >>>>>
> >>>>>    @Resource
> >>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>
> >>>>>    private static final ThreadLocal<Boolean>
>           asyncInvocation = new ThreadLocal<Boolean>();
> >>>>>
> >>>>>    @AroundInvoke
> >>>>>    public synchronized Object submitAsync(InvocationContext
>           ctx) throws Exception {
> >>>>>
> >>>>>        if (TRUE.equals(asyncInvocation.get())) {
> >>>>>            return ctx.proceed();
> >>>>>        }
> >>>>>
> >>>>>        return new
>           FutureDelegator(managedExecutorService.submit( ()-> {
> >>>>>            try {
> >>>>>                asyncInvocation.set(TRUE);
> >>>>>                return ctx.proceed();
> >>>>>            } finally {
> >>>>>                 asyncInvocation.remove();
> >>>>>            }
> >>>>>        }));
> >>>>>    }
> >>>>>
> >>>>>}
> >>>>>
> >>>>>
> >>>>>But I've got a feeling this works just by chance and not because the
> workaround is so clever.
> >>>>>
> >>>>>
> >>>>>What do you guys think, what would be the best way to support this
> with the current CDI version? Or would CDI/Interceptors need something like
> Servlet's async support, where the InvocationContext is put into async mode
> whereafter it "simply" allows an other thread to continue processing on it?
> >>>>>
> >>>>>
> >>>>>Kind regards,
> >>>>>Arjan Tijms
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> cdi-dev mailing list cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
> provided on this list, the provider licenses the code under the Apache
> License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
> all other ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >>>>
> >>>
> >>>_______________________________________________
> >>>cdi-dev mailing list
> >>>cdi-dev at lists.jboss.org
> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>>Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>
> >>
> >>
> >>--
> >>
> >>Antonio Goncalves
> >>Software architect, Java Champion and Pluralsight author
> >>
> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
> >
> >_______________________________________________
> >cdi-dev mailing list
> >cdi-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/58da433b/attachment.html 

From struberg at yahoo.de  Sat Jan 17 10:58:06 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 17 Jan 2015 15:58:06 +0000 (UTC)
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CA+ZZq98B9R+udvkcofSM=MF_9Uh+jXDHP6oMB4k8Tcrh7puJ4g@mail.gmail.com>
References: <CA+ZZq98B9R+udvkcofSM=MF_9Uh+jXDHP6oMB4k8Tcrh7puJ4g@mail.gmail.com>
Message-ID: <1807377505.2717120.1421510286847.JavaMail.yahoo@jws11147.mail.ir2.yahoo.com>

@Antonio: and where/how to start this context? Boils down to the exactly same issue.

Also remember that @RequestScoped IS already almost the same as it must be there for every EJB invocation, @Asynchronous, @Startup @Singleton @PostConstruct methods, JMS invocations, etc, etc 

LieGrue,
strub
On Saturday, 17 January 2015, 16:31, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:


>
>
>@Arjan, remember the email I sent to the EE EG entitled "Status of the Java EE 8 specifications". Bill Shannon replied : 
>
>
>We agree on the long term vision.  This is almost entirely a resource issue.  In order to do this, we have to stop doing something else, or we have to delay the release.  Based on the feedback we've gotten from the community, the things we've chosen to work on right now are the most important.  We'd like to do what you suggest below as well, but it's most likely going to have to be done later.
>
>
>
>So I don't know how we could "push" for an MR of the EE Concurrency spec. Any idea ? Except harassing Bill to add resources to the EE Concurrency spec and taking other resources out somewhere else... I don't know how we could do this.
>
>
>@Mark EE Concurreny could also add a @ThreadScoped like the one in Weld (but with a EE meaning).
>
>
>Antonio
>
>
>
>
>On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <struberg at yahoo.de> wrote:
>
>EE concurrency spec needs an update anyway. It currently doesn't explicitly require @RequestScoped beans to be supported on a new Thread. That breaks tons of frameworks and makes it barely usable in EE7.
>>
>>LieGrue,
>>strub
>>
>>
>>On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>
>>>
>>>
>>>Hi,
>>>
>>>
>>>
>>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <antonio.goncalves at gmail.com> wrote:
>>>
>>>@arjan Your example is base on  ManagedExecutorService from the Java EE Concurrency spec. That's one topic we've been wondering about : should the @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But it looks like the spec might not be updated.
>>>
>>>
>>>The example I showed here would IMHO best be placed in the Java EE Concurrency spec. That would in my opinion be a perfect analogy to @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and Concurrency, so theoretically it could also be put into a third spec.
>>>
>>>
>>>Personally I would find it strange to put something in spec A, when it may better belong in spec B, just because spec B is not updated. What's holding the update of Java EE Concurrency back? If most of the EG members would be of the opinion that an @Asynchronous interceptor belongs best in Java EE Concurrency, then we can just update that spec, right?
>>>
>>>
>>>I know that MR releases can be quite fast and agile process wise, while still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member) and I think the setup time was pretty fast. Mid feb 2013 we created the JIRA issues, the MR draft was published early march 2013 and the release was with EE 7 end may 2013.
>>>
>>>
>>>If it would just be about putting a few interceptors formally in Java EE Concurrency, then why not do such small update for it?
>>>
>>>
>>>Kind regards,
>>>Arjan
>>>
>>>
>>>>
>>>>Antonio
>>>>
>>>>
>>>>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>
>>>>Hi,
>>>>>
>>>>>
>>>>>
>>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com> wrote:
>>>>>
>>>>>Hi Arjan,
>>>>>>
>>>>>>I did some changes recently in Weld interceptors and this usecase
>>    now works smoothly. The code is not part of a release yet. See this
>>    test for a simple implementation of an @Async interceptor (basically
>>    the same as your initial attempt). Note that the chain is repeatable
>>    but at the same time it is not reset after dispatch to a different
>>    thread so you no longer need the ThreadLocal nor any other
>>    workaround.
>>>>>>
>>>>>
>>>>>
>>>>>That's quite a coincidence, it's indeed rather similar ;)
>>>>>
>>>>>
>>>>>I wonder how it now works though, as the InvocationContext "ctx" does not seem to be made aware that it's been dispatched to a different thread from within the code. Does it use an internal thread local to keep state or so?
>>>>>
>>>>>
>>>>>I'll also try to see what this does on OWB. Do you think this is something that should work, or just something that Weld happens to support regardless of the spec?
>>>>>
>>>>>
>>>>>Kind regards,
>>>>>Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>>>>>
>>>>>>Jozef
>>>>>>
>>>>>>
>>>>>>
>>>>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
>>>>>>
>>>>>>Hi,
>>>>>>>
>>>>>>>
>>I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>>>>>>
>>>>>>>Originally I had defined my interceptor as follows;
>>>>>>>
>>>>>>>@Interceptor
>>>>>>>@Asynchronous
>>>>>>>@Priority(APPLICATION)
>>>>>>>public class AsynchronousInterceptor implements Serializable {
>>>>>>>
>>>>>>>    private static final long serialVersionUID = 1L;
>>>>>>>
>>>>>>>    @Resource
>>>>>>>    private ManagedExecutorService managedExecutorService;
>>>>>>>
>>>>>>>    @AroundInvoke
>>>>>>>    public Object submitAsync(InvocationContext ctx) throws
>>          Exception {
>>>>>>>        return new
>>          FutureDelegator(managedExecutorService.submit( ()-> {
>>          return ctx.proceed(); } ));
>>>>>>>    }
>>>>>>>
>>>>>>>}
>>>>>>>
>>>>>>>
>>>>>>>With FutureDelegator as follows:
>>>>>>>
>>>>>>>public class FutureDelegator implements Future<Object> {
>>>>>>>
>>>>>>>    private Future<?> future;
>>>>>>>
>>>>>>>    public FutureDelegator(Future<?> future) {
>>>>>>>        this.future = future;
>>>>>>>    }
>>>>>>>
>>>>>>>    @Override
>>>>>>>    public Object get() throws InterruptedException,
>>          ExecutionException {
>>>>>>>        AsyncResult<?> asyncResult =
>>          (AsyncResult<?>) future.get();
>>>>>>>        if (asyncResult == null) {
>>>>>>>            return null;
>>>>>>>        }
>>>>>>>
>>>>>>>        return asyncResult.get();
>>>>>>>    }
>>>>>>>
>>>>>>>    @Override
>>>>>>>    public Object get(long timeout, TimeUnit unit) throws
>>          InterruptedException,    ExecutionException, TimeoutException
>>          {
>>>>>>>        AsyncResult<?> asyncResult =
>>          (AsyncResult<?>) future.get(timeout, unit);
>>>>>>>        if (asyncResult == null) {
>>>>>>>            return null;
>>>>>>>        }
>>>>>>>
>>>>>>>        return asyncResult.get();
>>>>>>>    }
>>>>>>>
>>>>>>>    @Override
>>>>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
>>>>>>>        return future.cancel(mayInterruptIfRunning);
>>>>>>>    }
>>>>>>>
>>>>>>>    @Override
>>>>>>>    public boolean isCancelled() {
>>>>>>>        return future.isCancelled();
>>>>>>>    }
>>>>>>>    @Override
>>>>>>>    public boolean isDone() {
>>>>>>>        return future.isDone();
>>>>>>>    }
>>>>>>>
>>>>>>>}
>>>>>>>
>>>>>>>
>>>>>>>This of course didn't quite work, as the InvocationContext will be reset after the @AroundInvoke method returns, and an infinite intercept loop results (on Weld).
>>>>>>>
>>>>>>>I got it to work though on Weld by using a thread local check
>>          to break that loop:
>>>>>>>
>>>>>>>@Interceptor
>>>>>>>@Asynchronous
>>>>>>>@Priority(PLATFORM_BEFORE)
>>>>>>>public class AsynchronousInterceptor implements Serializable {
>>>>>>>
>>>>>>>    private static final long serialVersionUID = 1L;
>>>>>>>
>>>>>>>    @Resource
>>>>>>>    private ManagedExecutorService managedExecutorService;
>>>>>>>
>>>>>>>    private static final ThreadLocal<Boolean>
>>          asyncInvocation = new ThreadLocal<Boolean>();
>>>>>>>
>>>>>>>    @AroundInvoke
>>>>>>>    public synchronized Object submitAsync(InvocationContext
>>          ctx) throws Exception {
>>>>>>>
>>>>>>>        if (TRUE.equals(asyncInvocation.get())) {
>>>>>>>            return ctx.proceed();
>>>>>>>        }
>>>>>>>
>>>>>>>        return new
>>          FutureDelegator(managedExecutorService.submit( ()-> {
>>>>>>>            try {
>>>>>>>                asyncInvocation.set(TRUE);
>>>>>>>                return ctx.proceed();
>>>>>>>            } finally {
>>>>>>>                 asyncInvocation.remove();
>>>>>>>            }
>>>>>>>        }));
>>>>>>>    }
>>>>>>>
>>>>>>>}
>>>>>>>
>>>>>>>
>>>>>>>But I've got a feeling this works just by chance and not because the workaround is so clever.
>>>>>>>
>>>>>>>
>>>>>>>What do you guys think, what would be the best way to support this with the current CDI version? Or would CDI/Interceptors need something like Servlet's async support, where the InvocationContext is put into async mode whereafter it "simply" allows an other thread to continue processing on it?
>>>>>>>
>>>>>>>
>>>>>>>Kind regards,
>>>>>>>Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>cdi-dev mailing list
>>>>>cdi-dev at lists.jboss.org
>>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>
>>>>Antonio Goncalves
>>>>Software architect, Java Champion and Pluralsight author
>>>>
>>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>>
>>>
>>>
>>>_______________________________________________
>>>cdi-dev mailing list
>>>cdi-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>>
>>
>
>
>
>-- 
>
>Antonio Goncalves 
>Software architect, Java Champion and Pluralsight author
>
>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>

From arjan.tijms at gmail.com  Sat Jan 17 11:46:36 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 17 Jan 2015 17:46:36 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CA+ZZq98B9R+udvkcofSM=MF_9Uh+jXDHP6oMB4k8Tcrh7puJ4g@mail.gmail.com>
References: <CAE=-AhAwfy35WkSD5JQPVRNSQtP1nLuHQ9-U8Mt15AjrJ_qnww@mail.gmail.com>
	<1515863897.2700554.1421499184135.JavaMail.yahoo@jws11122.mail.ir2.yahoo.com>
	<CA+ZZq98B9R+udvkcofSM=MF_9Uh+jXDHP6oMB4k8Tcrh7puJ4g@mail.gmail.com>
Message-ID: <CAE=-AhBRT-vSS1iAwtSjJ1o7q6Bfz5XZ_jvXgyxy5ZzyX=S0NQ@mail.gmail.com>

Hi,

On Sat, Jan 17, 2015 at 4:30 PM, Antonio Goncalves
<antonio.goncalves at gmail.com> wrote:
> So I don't know how we could "push" for an MR of the EE Concurrency spec.
> Any idea ? Except harassing Bill to add resources to the EE Concurrency spec
> and taking other resources out somewhere else... I don't know how we could
> do this.

Maybe by doing the work largely ourselves and then contributing it?
E.g. having the RI implementation done, writing a test for it, writing
some spec prose, etc. That way Anthony Lai would mainly have to
formally accept that work. This would all be a lot easier of course if
the code, tck and documentation was all on GitHub, then it would just
be 3 pull requests ;)

Kind regards,
Arjan


>
> @Mark EE Concurreny could also add a @ThreadScoped like the one in Weld (but
> with a EE meaning).
>
> Antonio
>
>
> On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <struberg at yahoo.de> wrote:
>>
>> EE concurrency spec needs an update anyway. It currently doesn't
>> explicitly require @RequestScoped beans to be supported on a new Thread.
>> That breaks tons of frameworks and makes it barely usable in EE7.
>>
>> LieGrue,
>> strub
>>
>> On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>>
>> >
>> >
>> >Hi,
>> >
>> >
>> >
>> >On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves
>> > <antonio.goncalves at gmail.com> wrote:
>> >
>> >@arjan Your example is base on  ManagedExecutorService from the Java EE
>> > Concurrency spec. That's one topic we've been wondering about : should the
>> > @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But it
>> > looks like the spec might not be updated.
>> >
>> >
>> >The example I showed here would IMHO best be placed in the Java EE
>> > Concurrency spec. That would in my opinion be a perfect analogy to
>> > @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
>> > Concurrency, so theoretically it could also be put into a third spec.
>> >
>> >
>> >Personally I would find it strange to put something in spec A, when it
>> > may better belong in spec B, just because spec B is not updated. What's
>> > holding the update of Java EE Concurrency back? If most of the EG members
>> > would be of the opinion that an @Asynchronous interceptor belongs best in
>> > Java EE Concurrency, then we can just update that spec, right?
>> >
>> >
>> >I know that MR releases can be quite fast and agile process wise, while
>> > still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC 1.1
>> > was too. I was somewhat involved with JASPIC 1.1 (as community member) and I
>> > think the setup time was pretty fast. Mid feb 2013 we created the JIRA
>> > issues, the MR draft was published early march 2013 and the release was with
>> > EE 7 end may 2013.
>> >
>> >
>> >If it would just be about putting a few interceptors formally in Java EE
>> > Concurrency, then why not do such small update for it?
>> >
>> >
>> >Kind regards,
>> >Arjan
>> >
>> >
>> >>
>> >>Antonio
>> >>
>> >>
>> >>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
>> >> wrote:
>> >>
>> >>Hi,
>> >>>
>> >>>
>> >>>
>> >>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
>> >>> wrote:
>> >>>
>> >>>Hi Arjan,
>> >>>>
>> >>>>I did some changes recently in Weld interceptors and this usecase
>>     now works smoothly. The code is not part of a release yet. See this
>>     test for a simple implementation of an @Async interceptor (basically
>>     the same as your initial attempt). Note that the chain is repeatable
>>     but at the same time it is not reset after dispatch to a different
>>     thread so you no longer need the ThreadLocal nor any other
>>     workaround.
>> >>>>
>> >>>
>> >>>
>> >>>That's quite a coincidence, it's indeed rather similar ;)
>> >>>
>> >>>
>> >>>I wonder how it now works though, as the InvocationContext "ctx" does
>> >>> not seem to be made aware that it's been dispatched to a different thread
>> >>> from within the code. Does it use an internal thread local to keep state or
>> >>> so?
>> >>>
>> >>>
>> >>>I'll also try to see what this does on OWB. Do you think this is
>> >>> something that should work, or just something that Weld happens to support
>> >>> regardless of the spec?
>> >>>
>> >>>
>> >>>Kind regards,
>> >>>Arjan
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>>
>> >>>> >>>>https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>> >>>>
>> >>>>Jozef
>> >>>>
>> >>>>
>> >>>>
>> >>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
>> >>>>
>> >>>>Hi,
>> >>>>>
>> >>>>>
>> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>> >>>>>
>> >>>>>Originally I had defined my interceptor as follows;
>> >>>>>
>> >>>>>@Interceptor
>> >>>>>@Asynchronous
>> >>>>>@Priority(APPLICATION)
>> >>>>>public class AsynchronousInterceptor implements Serializable {
>> >>>>>
>> >>>>>    private static final long serialVersionUID = 1L;
>> >>>>>
>> >>>>>    @Resource
>> >>>>>    private ManagedExecutorService managedExecutorService;
>> >>>>>
>> >>>>>    @AroundInvoke
>> >>>>>    public Object submitAsync(InvocationContext ctx) throws
>>           Exception {
>> >>>>>        return new
>>           FutureDelegator(managedExecutorService.submit( ()-> {
>>           return ctx.proceed(); } ));
>> >>>>>    }
>> >>>>>
>> >>>>>}
>> >>>>>
>> >>>>>
>> >>>>>With FutureDelegator as follows:
>> >>>>>
>> >>>>>public class FutureDelegator implements Future<Object> {
>> >>>>>
>> >>>>>    private Future<?> future;
>> >>>>>
>> >>>>>    public FutureDelegator(Future<?> future) {
>> >>>>>        this.future = future;
>> >>>>>    }
>> >>>>>
>> >>>>>    @Override
>> >>>>>    public Object get() throws InterruptedException,
>>           ExecutionException {
>> >>>>>        AsyncResult<?> asyncResult =
>>           (AsyncResult<?>) future.get();
>> >>>>>        if (asyncResult == null) {
>> >>>>>            return null;
>> >>>>>        }
>> >>>>>
>> >>>>>        return asyncResult.get();
>> >>>>>    }
>> >>>>>
>> >>>>>    @Override
>> >>>>>    public Object get(long timeout, TimeUnit unit) throws
>>           InterruptedException,    ExecutionException, TimeoutException
>>           {
>> >>>>>        AsyncResult<?> asyncResult =
>>           (AsyncResult<?>) future.get(timeout, unit);
>> >>>>>        if (asyncResult == null) {
>> >>>>>            return null;
>> >>>>>        }
>> >>>>>
>> >>>>>        return asyncResult.get();
>> >>>>>    }
>> >>>>>
>> >>>>>    @Override
>> >>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
>> >>>>>        return future.cancel(mayInterruptIfRunning);
>> >>>>>    }
>> >>>>>
>> >>>>>    @Override
>> >>>>>    public boolean isCancelled() {
>> >>>>>        return future.isCancelled();
>> >>>>>    }
>> >>>>>    @Override
>> >>>>>    public boolean isDone() {
>> >>>>>        return future.isDone();
>> >>>>>    }
>> >>>>>
>> >>>>>}
>> >>>>>
>> >>>>>
>> >>>>>This of course didn't quite work, as the InvocationContext will be
>> >>>>> reset after the @AroundInvoke method returns, and an infinite intercept loop
>> >>>>> results (on Weld).
>> >>>>>
>> >>>>>I got it to work though on Weld by using a thread local check
>>           to break that loop:
>> >>>>>
>> >>>>>@Interceptor
>> >>>>>@Asynchronous
>> >>>>>@Priority(PLATFORM_BEFORE)
>> >>>>>public class AsynchronousInterceptor implements Serializable {
>> >>>>>
>> >>>>>    private static final long serialVersionUID = 1L;
>> >>>>>
>> >>>>>    @Resource
>> >>>>>    private ManagedExecutorService managedExecutorService;
>> >>>>>
>> >>>>>    private static final ThreadLocal<Boolean>
>>           asyncInvocation = new ThreadLocal<Boolean>();
>> >>>>>
>> >>>>>    @AroundInvoke
>> >>>>>    public synchronized Object submitAsync(InvocationContext
>>           ctx) throws Exception {
>> >>>>>
>> >>>>>        if (TRUE.equals(asyncInvocation.get())) {
>> >>>>>            return ctx.proceed();
>> >>>>>        }
>> >>>>>
>> >>>>>        return new
>>           FutureDelegator(managedExecutorService.submit( ()-> {
>> >>>>>            try {
>> >>>>>                asyncInvocation.set(TRUE);
>> >>>>>                return ctx.proceed();
>> >>>>>            } finally {
>> >>>>>                 asyncInvocation.remove();
>> >>>>>            }
>> >>>>>        }));
>> >>>>>    }
>> >>>>>
>> >>>>>}
>> >>>>>
>> >>>>>
>> >>>>>But I've got a feeling this works just by chance and not because the
>> >>>>> workaround is so clever.
>> >>>>>
>> >>>>>
>> >>>>>What do you guys think, what would be the best way to support this
>> >>>>> with the current CDI version? Or would CDI/Interceptors need something like
>> >>>>> Servlet's async support, where the InvocationContext is put into async mode
>> >>>>> whereafter it "simply" allows an other thread to continue processing on it?
>> >>>>>
>> >>>>>
>> >>>>>Kind regards,
>> >>>>>Arjan Tijms
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>_______________________________________________
>> cdi-dev mailing list cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
>> provided on this list, the provider licenses the code under the Apache
>> License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
>> all other ideas provided on this list, the provider waives all patent and
>> other intellectual property rights inherent in such information.
>> >>>>
>> >>>
>> >>>_______________________________________________
>> >>>cdi-dev mailing list
>> >>>cdi-dev at lists.jboss.org
>> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>
>> >>>Note that for all code provided on this list, the provider licenses the
>> >>> code under the Apache License, Version 2
>> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> >>> provided on this list, the provider waives all patent and other intellectual
>> >>> property rights inherent in such information.
>> >>>
>> >>
>> >>
>> >>
>> >>--
>> >>
>> >>Antonio Goncalves
>> >>Software architect, Java Champion and Pluralsight author
>> >>
>> >>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>> >
>> >
>> >
>> >_______________________________________________
>> >cdi-dev mailing list
>> >cdi-dev at lists.jboss.org
>> >https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> >Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other intellectual
>> > property rights inherent in such information.
>> >
>> >
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

From werner.keil at gmail.com  Sat Jan 17 12:35:02 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sat, 17 Jan 2015 18:35:02 +0100
Subject: [cdi-dev] cdi-dev Digest, Vol 50, Issue 37
Message-ID: <CAAGawe3reMLKSR1Ey7AUpdaTc8RPTQ7j2wR6ozacDRXxqzt7QA@mail.gmail.com>

All,

The Java EE 8 EG (which at least Antonio and myself, but also Antoine and
others representing CDI Spec Lead Red Hat are also EG members) has this
paragraph on CDI:

We plan to enhance the managed bean model to make ease of use features that
are currently available only to selected components available to all
managed beans via the mechanisms provided by CDI. In particular, we plan to
consider enhancements for declarative security by means of CDI interceptors
and for notifications for timed events by means of the CDI event and
observer mechanism.


I understand, it mostly aims at using CDI in other JSRs like 375 (somewhere
along the lines of Agorava or its precursor JSR 357;-)

If it's a completely new annotation (at least for CDI) would it be totally
wrong to define this by CDI itself?

Of course it's already in EJB (javax.ejb) and given Java EE 8 plans to
prune some of the EJB Spec, that is most clearly one to be touched in EE 8.

Unless it's something to be pruned of javax.ejb it won't go away from there
either. javax.enterprise.concurrent is so tiny and (unless using others
already;-) doesn't declare a single annotation of its own so far, so why
bother doing so for this one?

If it feels wrong in javax.ejb or should work entirely without EJB then
consider some place where CDI already has annotations (not just under its
main packages)
CDI 2 aims at a "Standard/Desktop" variant and another one like
"Full/Enterprise" depending on which of these benefit from such annotation
that may influence where to put it.

Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
Board Member, Java Track Chair, DWX '15

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | #EclipseUOMo
| #DeviceMap
| #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil

On Sat, Jan 17, 2015 at 4:58 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Building EJB-like @Asynchronous via interceptor in CDI
>       (Antonio Goncalves)
>    2. Re: Building EJB-like @Asynchronous via interceptor in CDI
>       (Mark Struberg)
> ------------------------------
>
> Message: 2
> Date: Sat, 17 Jan 2015 15:58:06 +0000 (UTC)
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
>         in CDI
> To: Antonio Goncalves <antonio.goncalves at gmail.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> 1807377505.2717120.1421510286847.JavaMail.yahoo at jws11147.mail.ir2.yahoo.com
> >
>
> Content-Type: text/plain; charset=UTF-8
>
> @Antonio: and where/how to start this context? Boils down to the exactly
> same issue.
>
> Also remember that @RequestScoped IS already almost the same as it must be
> there for every EJB invocation, @Asynchronous, @Startup @Singleton
> @PostConstruct methods, JMS invocations, etc, etc
>
> LieGrue,
> strub
> On Saturday, 17 January 2015, 16:31, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
>
>
> >
> >
> >@Arjan, remember the email I sent to the EE EG entitled "Status of the
> Java EE 8 specifications". Bill Shannon replied :
> >
> >
> >We agree on the long term vision.  This is almost entirely a resource
> issue.  In order to do this, we have to stop doing something else, or we
> have to delay the release.  Based on the feedback we've gotten from the
> community, the things we've chosen to work on right now are the most
> important.  We'd like to do what you suggest below as well, but it's most
> likely going to have to be done later.
> >
> >
> >
> >So I don't know how we could "push" for an MR of the EE Concurrency spec.
> Any idea ? Except harassing Bill to add resources to the EE Concurrency
> spec and taking other resources out somewhere else... I don't know how we
> could do this.
> >
> >
> >@Mark EE Concurreny could also add a @ThreadScoped like the one in Weld
> (but with a EE meaning).
> >
> >
> >Antonio
> >
> >
> >
> >
> >On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <struberg at yahoo.de> wrote:
> >
> >EE concurrency spec needs an update anyway. It currently doesn't
> explicitly require @RequestScoped beans to be supported on a new Thread.
> That breaks tons of frameworks and makes it barely usable in EE7.
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>On Saturday, 17 January 2015, 13:12, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >>
> >>>
> >>>
> >>>Hi,
> >>>
> >>>
> >>>
> >>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> antonio.goncalves at gmail.com> wrote:
> >>>
> >>>@arjan Your example is base on  ManagedExecutorService from the Java EE
> Concurrency spec. That's one topic we've been wondering about : should the
> @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> it looks like the spec might not be updated.
> >>>
> >>>
> >>>The example I showed here would IMHO best be placed in the Java EE
> Concurrency spec. That would in my opinion be a perfect analogy to
> @Transactional and JTA. As given, the interceptor uses CDI/Interceptors and
> Concurrency, so theoretically it could also be put into a third spec.
> >>>
> >>>
> >>>Personally I would find it strange to put something in spec A, when it
> may better belong in spec B, just because spec B is not updated. What's
> holding the update of Java EE Concurrency back? If most of the EG members
> would be of the opinion that an @Asynchronous interceptor belongs best in
> Java EE Concurrency, then we can just update that spec, right?
> >>>
> >>>
> >>>I know that MR releases can be quite fast and agile process wise, while
> still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community member)
> and I think the setup time was pretty fast. Mid feb 2013 we created the
> JIRA issues, the MR draft was published early march 2013 and the release
> was with EE 7 end may 2013.
> >>>
> >>>
> >>>If it would just be about putting a few interceptors formally in Java
> EE Concurrency, then why not do such small update for it?
> >>>
> >>>
> >>>Kind regards,
> >>>Arjan
> >>>
> >>>
> >>>>
> >>>>Antonio
> >>>>
> >>>>
> >>>>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>>>
> >>>>Hi,
> >>>>>
> >>>>>
> >>>>>
> >>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <
> jharting at redhat.com> wrote:
> >>>>>
> >>>>>Hi Arjan,
> >>>>>>
> >>>>>>I did some changes recently in Weld interceptors and this usecase
> >>    now works smoothly. The code is not part of a release yet. See this
> >>    test for a simple implementation of an @Async interceptor (basically
> >>    the same as your initial attempt). Note that the chain is repeatable
> >>    but at the same time it is not reset after dispatch to a different
> >>    thread so you no longer need the ThreadLocal nor any other
> >>    workaround.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>That's quite a coincidence, it's indeed rather similar ;)
> >>>>>
> >>>>>
> >>>>>I wonder how it now works though, as the InvocationContext "ctx" does
> not seem to be made aware that it's been dispatched to a different thread
> from within the code. Does it use an internal thread local to keep state or
> so?
> >>>>>
> >>>>>
> >>>>>I'll also try to see what this does on OWB. Do you think this is
> something that should work, or just something that Weld happens to support
> regardless of the spec?
> >>>>>
> >>>>>
> >>>>>Kind regards,
> >>>>>Arjan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>>>>>
> >>>>>>Jozef
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>>>>>
> >>>>>>Hi,
> >>>>>>>
> >>>>>>>
> >>I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
> >>>>>>>
> >>>>>>>Originally I had defined my interceptor as follows;
> >>>>>>>
> >>>>>>>@Interceptor
> >>>>>>>@Asynchronous
> >>>>>>>@Priority(APPLICATION)
> >>>>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>>>
> >>>>>>>    private static final long serialVersionUID = 1L;
> >>>>>>>
> >>>>>>>    @Resource
> >>>>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>>>
> >>>>>>>    @AroundInvoke
> >>>>>>>    public Object submitAsync(InvocationContext ctx) throws
> >>          Exception {
> >>>>>>>        return new
> >>          FutureDelegator(managedExecutorService.submit( ()-> {
> >>          return ctx.proceed(); } ));
> >>>>>>>    }
> >>>>>>>
> >>>>>>>}
> >>>>>>>
> >>>>>>>
> >>>>>>>With FutureDelegator as follows:
> >>>>>>>
> >>>>>>>public class FutureDelegator implements Future<Object> {
> >>>>>>>
> >>>>>>>    private Future<?> future;
> >>>>>>>
> >>>>>>>    public FutureDelegator(Future<?> future) {
> >>>>>>>        this.future = future;
> >>>>>>>    }
> >>>>>>>
> >>>>>>>    @Override
> >>>>>>>    public Object get() throws InterruptedException,
> >>          ExecutionException {
> >>>>>>>        AsyncResult<?> asyncResult =
> >>          (AsyncResult<?>) future.get();
> >>>>>>>        if (asyncResult == null) {
> >>>>>>>            return null;
> >>>>>>>        }
> >>>>>>>
> >>>>>>>        return asyncResult.get();
> >>>>>>>    }
> >>>>>>>
> >>>>>>>    @Override
> >>>>>>>    public Object get(long timeout, TimeUnit unit) throws
> >>          InterruptedException,    ExecutionException, TimeoutException
> >>          {
> >>>>>>>        AsyncResult<?> asyncResult =
> >>          (AsyncResult<?>) future.get(timeout, unit);
> >>>>>>>        if (asyncResult == null) {
> >>>>>>>            return null;
> >>>>>>>        }
> >>>>>>>
> >>>>>>>        return asyncResult.get();
> >>>>>>>    }
> >>>>>>>
> >>>>>>>    @Override
> >>>>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
> >>>>>>>        return future.cancel(mayInterruptIfRunning);
> >>>>>>>    }
> >>>>>>>
> >>>>>>>    @Override
> >>>>>>>    public boolean isCancelled() {
> >>>>>>>        return future.isCancelled();
> >>>>>>>    }
> >>>>>>>    @Override
> >>>>>>>    public boolean isDone() {
> >>>>>>>        return future.isDone();
> >>>>>>>    }
> >>>>>>>
> >>>>>>>}
> >>>>>>>
> >>>>>>>
> >>>>>>>This of course didn't quite work, as the InvocationContext will be
> reset after the @AroundInvoke method returns, and an infinite intercept
> loop results (on Weld).
> >>>>>>>
> >>>>>>>I got it to work though on Weld by using a thread local check
> >>          to break that loop:
> >>>>>>>
> >>>>>>>@Interceptor
> >>>>>>>@Asynchronous
> >>>>>>>@Priority(PLATFORM_BEFORE)
> >>>>>>>public class AsynchronousInterceptor implements Serializable {
> >>>>>>>
> >>>>>>>    private static final long serialVersionUID = 1L;
> >>>>>>>
> >>>>>>>    @Resource
> >>>>>>>    private ManagedExecutorService managedExecutorService;
> >>>>>>>
> >>>>>>>    private static final ThreadLocal<Boolean>
> >>          asyncInvocation = new ThreadLocal<Boolean>();
> >>>>>>>
> >>>>>>>    @AroundInvoke
> >>>>>>>    public synchronized Object submitAsync(InvocationContext
> >>          ctx) throws Exception {
> >>>>>>>
> >>>>>>>        if (TRUE.equals(asyncInvocation.get())) {
> >>>>>>>            return ctx.proceed();
> >>>>>>>        }
> >>>>>>>
> >>>>>>>        return new
> >>          FutureDelegator(managedExecutorService.submit( ()-> {
> >>>>>>>            try {
> >>>>>>>                asyncInvocation.set(TRUE);
> >>>>>>>                return ctx.proceed();
> >>>>>>>            } finally {
> >>>>>>>                 asyncInvocation.remove();
> >>>>>>>            }
> >>>>>>>        }));
> >>>>>>>    }
> >>>>>>>
> >>>>>>>}
> >>>>>>>
> >>>>>>>
> >>>>>>>But I've got a feeling this works just by chance and not because
> the workaround is so clever.
> >>>>>>>
> >>>>>>>
> >>>>>>>What do you guys think, what would be the best way to support this
> with the current CDI version? Or would CDI/Interceptors need something like
> Servlet's async support, where the InvocationContext is put into async mode
> whereafter it "simply" allows an other thread to continue processing on it?
> >>>>>>>
> >>>>>>>
> >>>>>>>Kind regards,
> >>>>>>>Arjan Tijms
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>cdi-dev mailing list cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
> provided on this list, the provider licenses the code under the Apache
> License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For
> all other ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >>>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>cdi-dev mailing list
> >>>>>cdi-dev at lists.jboss.org
> >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>>
> >>>>>Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>
> >>>>Antonio Goncalves
> >>>>Software architect, Java Champion and Pluralsight author
> >>>>
> >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>cdi-dev mailing list
> >>>cdi-dev at lists.jboss.org
> >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>>Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>
> >>>
> >>
> >
> >
> >
> >--
> >
> >Antonio Goncalves
> >Software architect, Java Champion and Pluralsight author
> >
> >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 50, Issue 37
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/52d66852/attachment-0001.html 

From werner.keil at gmail.com  Sat Jan 17 12:38:29 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Sat, 17 Jan 2015 18:38:29 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CD
Message-ID: <CAAGawe1Bwb=DvOyFTnrmuyydJ5xpp=Tz5QsGkyjGLq3Bfvmujg@mail.gmail.com>

Sorry, didn't change the topic when simply hitting reply, that's the thread
for it.

Werner


> ------------------------------
>
> Message: 2
> Date: Sat, 17 Jan 2015 18:35:02 +0100
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 50, Issue 37
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAAGawe3reMLKSR1Ey7AUpdaTc8RPTQ7j2wR6ozacDRXxqzt7QA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> All,
>
> The Java EE 8 EG (which at least Antonio and myself, but also Antoine and
> others representing CDI Spec Lead Red Hat are also EG members) has this
> paragraph on CDI:
>
> We plan to enhance the managed bean model to make ease of use features that
> are currently available only to selected components available to all
> managed beans via the mechanisms provided by CDI. In particular, we plan to
> consider enhancements for declarative security by means of CDI interceptors
> and for notifications for timed events by means of the CDI event and
> observer mechanism.
>
>
> I understand, it mostly aims at using CDI in other JSRs like 375 (somewhere
> along the lines of Agorava or its precursor JSR 357;-)
>
> If it's a completely new annotation (at least for CDI) would it be totally
> wrong to define this by CDI itself?
>
> Of course it's already in EJB (javax.ejb) and given Java EE 8 plans to
> prune some of the EJB Spec, that is most clearly one to be touched in EE 8.
>
> Unless it's something to be pruned of javax.ejb it won't go away from there
> either. javax.enterprise.concurrent is so tiny and (unless using others
> already;-) doesn't declare a single annotation of its own so far, so why
> bother doing so for this one?
>
> If it feels wrong in javax.ejb or should work entirely without EJB then
> consider some place where CDI already has annotations (not just under its
> main packages)
> CDI 2 aims at a "Standard/Desktop" variant and another one like
> "Full/Enterprise" depending on which of these benefit from such annotation
> that may influence where to put it.
>
> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
> Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory
> Board Member, Java Track Chair, DWX '15
>
> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | #EclipseUOMo
> | #DeviceMap
> | #DevOps
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
> On Sat, Jan 17, 2015 at 4:58 PM, <cdi-dev-request at lists.jboss.org> wrote:
>
> > Send cdi-dev mailing list submissions to
> >         cdi-dev at lists.jboss.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://lists.jboss.org/mailman/listinfo/cdi-dev
> > or, via email, send a message with subject or body 'help' to
> >         cdi-dev-request at lists.jboss.org
> >
> > You can reach the person managing the list at
> >         cdi-dev-owner at lists.jboss.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cdi-dev digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Building EJB-like @Asynchronous via interceptor in CDI
> >       (Antonio Goncalves)
> >    2. Re: Building EJB-like @Asynchronous via interceptor in CDI
> >       (Mark Struberg)
> > ------------------------------
> >
> > Message: 2
> > Date: Sat, 17 Jan 2015 15:58:06 +0000 (UTC)
> > From: Mark Struberg <struberg at yahoo.de>
> > Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
> >         in CDI
> > To: Antonio Goncalves <antonio.goncalves at gmail.com>
> > Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> > Message-ID:
> >         <
> >
> 1807377505.2717120.1421510286847.JavaMail.yahoo at jws11147.mail.ir2.yahoo.com
> > >
> >
> > Content-Type: text/plain; charset=UTF-8
> >
> > @Antonio: and where/how to start this context? Boils down to the exactly
> > same issue.
> >
> > Also remember that @RequestScoped IS already almost the same as it must
> be
> > there for every EJB invocation, @Asynchronous, @Startup @Singleton
> > @PostConstruct methods, JMS invocations, etc, etc
> >
> > LieGrue,
> > strub
> > On Saturday, 17 January 2015, 16:31, Antonio Goncalves <
> > antonio.goncalves at gmail.com> wrote:
> >
> >
> > >
> > >
> > >@Arjan, remember the email I sent to the EE EG entitled "Status of the
> > Java EE 8 specifications". Bill Shannon replied :
> > >
> > >
> > >We agree on the long term vision.  This is almost entirely a resource
> > issue.  In order to do this, we have to stop doing something else, or we
> > have to delay the release.  Based on the feedback we've gotten from the
> > community, the things we've chosen to work on right now are the most
> > important.  We'd like to do what you suggest below as well, but it's most
> > likely going to have to be done later.
> > >
> > >
> > >
> > >So I don't know how we could "push" for an MR of the EE Concurrency
> spec.
> > Any idea ? Except harassing Bill to add resources to the EE Concurrency
> > spec and taking other resources out somewhere else... I don't know how we
> > could do this.
> > >
> > >
> > >@Mark EE Concurreny could also add a @ThreadScoped like the one in Weld
> > (but with a EE meaning).
> > >
> > >
> > >Antonio
> > >
> > >
> > >
> > >
> > >On Sat, Jan 17, 2015 at 1:53 PM, Mark Struberg <struberg at yahoo.de>
> wrote:
> > >
> > >EE concurrency spec needs an update anyway. It currently doesn't
> > explicitly require @RequestScoped beans to be supported on a new Thread.
> > That breaks tons of frameworks and makes it barely usable in EE7.
> > >>
> > >>LieGrue,
> > >>strub
> > >>
> > >>
> > >>On Saturday, 17 January 2015, 13:12, arjan tijms <
> arjan.tijms at gmail.com>
> > wrote:
> > >>
> > >>
> > >>>
> > >>>
> > >>>Hi,
> > >>>
> > >>>
> > >>>
> > >>>On Sat, Jan 17, 2015 at 11:05 AM, Antonio Goncalves <
> > antonio.goncalves at gmail.com> wrote:
> > >>>
> > >>>@arjan Your example is base on  ManagedExecutorService from the Java
> EE
> > Concurrency spec. That's one topic we've been wondering about : should
> the
> > @Asynchronous interceptor go to the Java EE Concurrency spec or not ? But
> > it looks like the spec might not be updated.
> > >>>
> > >>>
> > >>>The example I showed here would IMHO best be placed in the Java EE
> > Concurrency spec. That would in my opinion be a perfect analogy to
> > @Transactional and JTA. As given, the interceptor uses CDI/Interceptors
> and
> > Concurrency, so theoretically it could also be put into a third spec.
> > >>>
> > >>>
> > >>>Personally I would find it strange to put something in spec A, when it
> > may better belong in spec B, just because spec B is not updated. What's
> > holding the update of Java EE Concurrency back? If most of the EG members
> > would be of the opinion that an @Asynchronous interceptor belongs best in
> > Java EE Concurrency, then we can just update that spec, right?
> > >>>
> > >>>
> > >>>I know that MR releases can be quite fast and agile process wise,
> while
> > still packing some punch. JTA 1.2 itself was just such an MR, and JASPIC
> > 1.1 was too. I was somewhat involved with JASPIC 1.1 (as community
> member)
> > and I think the setup time was pretty fast. Mid feb 2013 we created the
> > JIRA issues, the MR draft was published early march 2013 and the release
> > was with EE 7 end may 2013.
> > >>>
> > >>>
> > >>>If it would just be about putting a few interceptors formally in Java
> > EE Concurrency, then why not do such small update for it?
> > >>>
> > >>>
> > >>>Kind regards,
> > >>>Arjan
> > >>>
> > >>>
> > >>>>
> > >>>>Antonio
> > >>>>
> > >>>>
> > >>>>On Sat, Jan 17, 2015 at 12:32 AM, arjan tijms <arjan.tijms at gmail.com
> >
> > wrote:
> > >>>>
> > >>>>Hi,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <
> > jharting at redhat.com> wrote:
> > >>>>>
> > >>>>>Hi Arjan,
> > >>>>>>
> > >>>>>>I did some changes recently in Weld interceptors and this usecase
> > >>    now works smoothly. The code is not part of a release yet. See this
> > >>    test for a simple implementation of an @Async interceptor
> (basically
> > >>    the same as your initial attempt). Note that the chain is
> repeatable
> > >>    but at the same time it is not reset after dispatch to a different
> > >>    thread so you no longer need the ThreadLocal nor any other
> > >>    workaround.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>That's quite a coincidence, it's indeed rather similar ;)
> > >>>>>
> > >>>>>
> > >>>>>I wonder how it now works though, as the InvocationContext "ctx"
> does
> > not seem to be made aware that it's been dispatched to a different thread
> > from within the code. Does it use an internal thread local to keep state
> or
> > so?
> > >>>>>
> > >>>>>
> > >>>>>I'll also try to see what this does on OWB. Do you think this is
> > something that should work, or just something that Weld happens to
> support
> > regardless of the spec?
> > >>>>>
> > >>>>>
> > >>>>>Kind regards,
> > >>>>>Arjan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>
> >
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> > >>>>>>
> > >>>>>>Jozef
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>On 01/16/2015 06:17 PM, arjan tijms wrote:
> > >>>>>>
> > >>>>>>Hi,
> > >>>>>>>
> > >>>>>>>
> > >>I'm attempting to emulate EJB's @Asynchronous in CDI using
> interceptors.
> > >>>>>>>
> > >>>>>>>Originally I had defined my interceptor as follows;
> > >>>>>>>
> > >>>>>>>@Interceptor
> > >>>>>>>@Asynchronous
> > >>>>>>>@Priority(APPLICATION)
> > >>>>>>>public class AsynchronousInterceptor implements Serializable {
> > >>>>>>>
> > >>>>>>>    private static final long serialVersionUID = 1L;
> > >>>>>>>
> > >>>>>>>    @Resource
> > >>>>>>>    private ManagedExecutorService managedExecutorService;
> > >>>>>>>
> > >>>>>>>    @AroundInvoke
> > >>>>>>>    public Object submitAsync(InvocationContext ctx) throws
> > >>          Exception {
> > >>>>>>>        return new
> > >>          FutureDelegator(managedExecutorService.submit( ()-> {
> > >>          return ctx.proceed(); } ));
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>}
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>With FutureDelegator as follows:
> > >>>>>>>
> > >>>>>>>public class FutureDelegator implements Future<Object> {
> > >>>>>>>
> > >>>>>>>    private Future<?> future;
> > >>>>>>>
> > >>>>>>>    public FutureDelegator(Future<?> future) {
> > >>>>>>>        this.future = future;
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>    @Override
> > >>>>>>>    public Object get() throws InterruptedException,
> > >>          ExecutionException {
> > >>>>>>>        AsyncResult<?> asyncResult =
> > >>          (AsyncResult<?>) future.get();
> > >>>>>>>        if (asyncResult == null) {
> > >>>>>>>            return null;
> > >>>>>>>        }
> > >>>>>>>
> > >>>>>>>        return asyncResult.get();
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>    @Override
> > >>>>>>>    public Object get(long timeout, TimeUnit unit) throws
> > >>          InterruptedException,    ExecutionException, TimeoutException
> > >>          {
> > >>>>>>>        AsyncResult<?> asyncResult =
> > >>          (AsyncResult<?>) future.get(timeout, unit);
> > >>>>>>>        if (asyncResult == null) {
> > >>>>>>>            return null;
> > >>>>>>>        }
> > >>>>>>>
> > >>>>>>>        return asyncResult.get();
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>    @Override
> > >>>>>>>    public boolean cancel(boolean mayInterruptIfRunning) {
> > >>>>>>>        return future.cancel(mayInterruptIfRunning);
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>    @Override
> > >>>>>>>    public boolean isCancelled() {
> > >>>>>>>        return future.isCancelled();
> > >>>>>>>    }
> > >>>>>>>    @Override
> > >>>>>>>    public boolean isDone() {
> > >>>>>>>        return future.isDone();
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>}
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>This of course didn't quite work, as the InvocationContext will be
> > reset after the @AroundInvoke method returns, and an infinite intercept
> > loop results (on Weld).
> > >>>>>>>
> > >>>>>>>I got it to work though on Weld by using a thread local check
> > >>          to break that loop:
> > >>>>>>>
> > >>>>>>>@Interceptor
> > >>>>>>>@Asynchronous
> > >>>>>>>@Priority(PLATFORM_BEFORE)
> > >>>>>>>public class AsynchronousInterceptor implements Serializable {
> > >>>>>>>
> > >>>>>>>    private static final long serialVersionUID = 1L;
> > >>>>>>>
> > >>>>>>>    @Resource
> > >>>>>>>    private ManagedExecutorService managedExecutorService;
> > >>>>>>>
> > >>>>>>>    private static final ThreadLocal<Boolean>
> > >>          asyncInvocation = new ThreadLocal<Boolean>();
> > >>>>>>>
> > >>>>>>>    @AroundInvoke
> > >>>>>>>    public synchronized Object submitAsync(InvocationContext
> > >>          ctx) throws Exception {
> > >>>>>>>
> > >>>>>>>        if (TRUE.equals(asyncInvocation.get())) {
> > >>>>>>>            return ctx.proceed();
> > >>>>>>>        }
> > >>>>>>>
> > >>>>>>>        return new
> > >>          FutureDelegator(managedExecutorService.submit( ()-> {
> > >>>>>>>            try {
> > >>>>>>>                asyncInvocation.set(TRUE);
> > >>>>>>>                return ctx.proceed();
> > >>>>>>>            } finally {
> > >>>>>>>                 asyncInvocation.remove();
> > >>>>>>>            }
> > >>>>>>>        }));
> > >>>>>>>    }
> > >>>>>>>
> > >>>>>>>}
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>But I've got a feeling this works just by chance and not because
> > the workaround is so clever.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>What do you guys think, what would be the best way to support this
> > with the current CDI version? Or would CDI/Interceptors need something
> like
> > Servlet's async support, where the InvocationContext is put into async
> mode
> > whereafter it "simply" allows an other thread to continue processing on
> it?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>Kind regards,
> > >>>>>>>Arjan Tijms
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>_______________________________________________
> > >>cdi-dev mailing list cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code
> > provided on this list, the provider licenses the code under the Apache
> > License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).
> For
> > all other ideas provided on this list, the provider waives all patent and
> > other intellectual property rights inherent in such information.
> > >>>>>>
> > >>>>>
> > >>>>>_______________________________________________
> > >>>>>cdi-dev mailing list
> > >>>>>cdi-dev at lists.jboss.org
> > >>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>>>>
> > >>>>>Note that for all code provided on this list, the provider licenses
> > the code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>--
> > >>>>
> > >>>>Antonio Goncalves
> > >>>>Software architect, Java Champion and Pluralsight author
> > >>>>
> > >>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
> France
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>cdi-dev mailing list
> > >>>cdi-dev at lists.jboss.org
> > >>>https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>>
> > >>>Note that for all code provided on this list, the provider licenses
> the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >--
> > >
> > >Antonio Goncalves
> > >Software architect, Java Champion and Pluralsight author
> > >
> > >Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> > >
> > >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> > End of cdi-dev Digest, Vol 50, Issue 37
> > ***************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/52d66852/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 50, Issue 38
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150117/ede5cf83/attachment-0001.html 

From arjan.tijms at gmail.com  Sun Jan 18 12:38:15 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sun, 18 Jan 2015 18:38:15 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <D0DFF142.4C83C%arne.limburg@openknowledge.de>
References: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
	<D0DFF142.4C83C%arne.limburg@openknowledge.de>
Message-ID: <CAE=-AhBe=y7AaMRjTz646SbqTyAyXPHQYcfTvC7+2edciXwB2Q@mail.gmail.com>

Hi

On Sat, Jan 17, 2015 at 11:05 AM, Arne Limburg <
arne.limburg at openknowledge.de> wrote:
> Since we almost don?t use ThreadLocals in OWB, I guess, this should work
out
> of the box.
> Did a quick check of the interceptor code and see no issues with handling
> over the InvocationContext to another thread. However, the
InvocationContext
> has some internal state that could get confused, if proceed() is called in
> parallel from two different threads, but that?s another thing. Just give
it
> a try and tell us about the result :-)

I tested it on a OWB 1.5.0-SNAPSHOT from a few weeks back as part of
TomEE-2.0-SNAPSHOT and using a simple example with a request scoped bean
and no other interceptors it indeed worked out of the box :) Still have to
test with some more complicated setups, but things look promising.

I wonder, should anything still be spec'ed for this? Perhaps just a mention
somewhere that this is indeed allowed, along with a TCK test?

Kind regards,
Arjan




>
> Cheers,
> Arne
>
> Von: arjan tijms <arjan.tijms at gmail.com>
> Datum: Samstag, 17. Januar 2015 00:32
> An: Jozef Hartinger <jharting at redhat.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Betreff: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in
> CDI
>
> Hi,
>
> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>>
>> Hi Arjan,
>>
>> I did some changes recently in Weld interceptors and this usecase now
>> works smoothly. The code is not part of a release yet. See this test for
a
>> simple implementation of an @Async interceptor (basically the same as
your
>> initial attempt). Note that the chain is repeatable but at the same time
it
>> is not reset after dispatch to a different thread so you no longer need
the
>> ThreadLocal nor any other workaround.
>
>
> That's quite a coincidence, it's indeed rather similar ;)
>
> I wonder how it now works though, as the InvocationContext "ctx" does not
> seem to be made aware that it's been dispatched to a different thread from
> within the code. Does it use an internal thread local to keep state or so?
>
> I'll also try to see what this does on OWB. Do you think this is something
> that should work, or just something that Weld happens to support
regardless
> of the spec?
>
> Kind regards,
> Arjan
>
>
>
>>
>>
>>
>>
https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>>
>> Jozef
>>
>>
>> On 01/16/2015 06:17 PM, arjan tijms wrote:
>>
>> Hi,
>>
>> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
>>
>> Originally I had defined my interceptor as follows;
>>
>> @Interceptor
>> @Asynchronous
>> @Priority(APPLICATION)
>> public class AsynchronousInterceptor implements Serializable {
>>
>>     private static final long serialVersionUID = 1L;
>>
>>     @Resource
>>     private ManagedExecutorService managedExecutorService;
>>
>>     @AroundInvoke
>>     public Object submitAsync(InvocationContext ctx) throws Exception {
>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>> return ctx.proceed(); } ));
>>     }
>>
>> }
>>
>> With FutureDelegator as follows:
>>
>> public class FutureDelegator implements Future<Object> {
>>
>>     private Future<?> future;
>>
>>     public FutureDelegator(Future<?> future) {
>>         this.future = future;
>>     }
>>
>>     @Override
>>     public Object get() throws InterruptedException, ExecutionException {
>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>>         if (asyncResult == null) {
>>             return null;
>>         }
>>
>>         return asyncResult.get();
>>     }
>>
>>     @Override
>>     public Object get(long timeout, TimeUnit unit) throws
>> InterruptedException,    ExecutionException, TimeoutException {
>>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get(timeout,
>> unit);
>>         if (asyncResult == null) {
>>             return null;
>>         }
>>
>>         return asyncResult.get();
>>     }
>>
>>     @Override
>>     public boolean cancel(boolean mayInterruptIfRunning) {
>>         return future.cancel(mayInterruptIfRunning);
>>     }
>>
>>     @Override
>>     public boolean isCancelled() {
>>         return future.isCancelled();
>>     }
>>     @Override
>>     public boolean isDone() {
>>         return future.isDone();
>>     }
>>
>> }
>>
>> This of course didn't quite work, as the InvocationContext will be reset
>> after the @AroundInvoke method returns, and an infinite intercept loop
>> results (on Weld).
>>
>> I got it to work though on Weld by using a thread local check to break
>> that loop:
>>
>> @Interceptor
>> @Asynchronous
>> @Priority(PLATFORM_BEFORE)
>> public class AsynchronousInterceptor implements Serializable {
>>
>>     private static final long serialVersionUID = 1L;
>>
>>     @Resource
>>     private ManagedExecutorService managedExecutorService;
>>
>>     private static final ThreadLocal<Boolean> asyncInvocation = new
>> ThreadLocal<Boolean>();
>>
>>     @AroundInvoke
>>     public synchronized Object submitAsync(InvocationContext ctx) throws
>> Exception {
>>
>>         if (TRUE.equals(asyncInvocation.get())) {
>>             return ctx.proceed();
>>         }
>>
>>         return new FutureDelegator(managedExecutorService.submit( ()-> {
>>             try {
>>                 asyncInvocation.set(TRUE);
>>                 return ctx.proceed();
>>             } finally {
>>                  asyncInvocation.remove();
>>             }
>>         }));
>>     }
>>
>> }
>>
>> But I've got a feeling this works just by chance and not because the
>> workaround is so clever.
>>
>> What do you guys think, what would be the best way to support this with
>> the current CDI version? Or would CDI/Interceptors need something like
>> Servlet's async support, where the InvocationContext is put into async
mode
>> whereafter it "simply" allows an other thread to continue processing on
it?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
intellectual
>> property rights inherent in such information.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150118/9610c3b6/attachment.html 

From rmannibucau at gmail.com  Sun Jan 18 14:46:12 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Sun, 18 Jan 2015 20:46:12 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhBe=y7AaMRjTz646SbqTyAyXPHQYcfTvC7+2edciXwB2Q@mail.gmail.com>
References: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
	<D0DFF142.4C83C%arne.limburg@openknowledge.de>
	<CAE=-AhBe=y7AaMRjTz646SbqTyAyXPHQYcfTvC7+2edciXwB2Q@mail.gmail.com>
Message-ID: <CACLE=7OtnM6VVHjmpHhBpjay9tjMFoq7yGsc23kpcEDSvzSOvg@mail.gmail.com>

+1
Le 18 janv. 2015 18:38, "arjan tijms" <arjan.tijms at gmail.com> a ?crit :

> Hi
>
> On Sat, Jan 17, 2015 at 11:05 AM, Arne Limburg <
> arne.limburg at openknowledge.de> wrote:
> > Since we almost don?t use ThreadLocals in OWB, I guess, this should work
> out
> > of the box.
> > Did a quick check of the interceptor code and see no issues with handling
> > over the InvocationContext to another thread. However, the
> InvocationContext
> > has some internal state that could get confused, if proceed() is called
> in
> > parallel from two different threads, but that?s another thing. Just give
> it
> > a try and tell us about the result :-)
>
> I tested it on a OWB 1.5.0-SNAPSHOT from a few weeks back as part of
> TomEE-2.0-SNAPSHOT and using a simple example with a request scoped bean
> and no other interceptors it indeed worked out of the box :) Still have to
> test with some more complicated setups, but things look promising.
>
> I wonder, should anything still be spec'ed for this? Perhaps just a
> mention somewhere that this is indeed allowed, along with a TCK test?
>
> Kind regards,
> Arjan
>
>
>
>
> >
> > Cheers,
> > Arne
> >
> > Von: arjan tijms <arjan.tijms at gmail.com>
> > Datum: Samstag, 17. Januar 2015 00:32
> > An: Jozef Hartinger <jharting at redhat.com>
> > Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> > Betreff: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor in
> > CDI
> >
> > Hi,
> >
> > On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com>
> > wrote:
> >>
> >> Hi Arjan,
> >>
> >> I did some changes recently in Weld interceptors and this usecase now
> >> works smoothly. The code is not part of a release yet. See this test
> for a
> >> simple implementation of an @Async interceptor (basically the same as
> your
> >> initial attempt). Note that the chain is repeatable but at the same
> time it
> >> is not reset after dispatch to a different thread so you no longer need
> the
> >> ThreadLocal nor any other workaround.
> >
> >
> > That's quite a coincidence, it's indeed rather similar ;)
> >
> > I wonder how it now works though, as the InvocationContext "ctx" does not
> > seem to be made aware that it's been dispatched to a different thread
> from
> > within the code. Does it use an internal thread local to keep state or
> so?
> >
> > I'll also try to see what this does on OWB. Do you think this is
> something
> > that should work, or just something that Weld happens to support
> regardless
> > of the spec?
> >
> > Kind regards,
> > Arjan
> >
> >
> >
> >>
> >>
> >>
> >>
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
> >>
> >> Jozef
> >>
> >>
> >> On 01/16/2015 06:17 PM, arjan tijms wrote:
> >>
> >> Hi,
> >>
> >> I'm attempting to emulate EJB's @Asynchronous in CDI using interceptors.
> >>
> >> Originally I had defined my interceptor as follows;
> >>
> >> @Interceptor
> >> @Asynchronous
> >> @Priority(APPLICATION)
> >> public class AsynchronousInterceptor implements Serializable {
> >>
> >>     private static final long serialVersionUID = 1L;
> >>
> >>     @Resource
> >>     private ManagedExecutorService managedExecutorService;
> >>
> >>     @AroundInvoke
> >>     public Object submitAsync(InvocationContext ctx) throws Exception {
> >>         return new FutureDelegator(managedExecutorService.submit( ()-> {
> >> return ctx.proceed(); } ));
> >>     }
> >>
> >> }
> >>
> >> With FutureDelegator as follows:
> >>
> >> public class FutureDelegator implements Future<Object> {
> >>
> >>     private Future<?> future;
> >>
> >>     public FutureDelegator(Future<?> future) {
> >>         this.future = future;
> >>     }
> >>
> >>     @Override
> >>     public Object get() throws InterruptedException, ExecutionException
> {
> >>         AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
> >>         if (asyncResult == null) {
> >>             return null;
> >>         }
> >>
> >>         return asyncResult.get();
> >>     }
> >>
> >>     @Override
> >>     public Object get(long timeout, TimeUnit unit) throws
> >> InterruptedException,    ExecutionException, TimeoutException {
> >>         AsyncResult<?> asyncResult = (AsyncResult<?>)
> future.get(timeout,
> >> unit);
> >>         if (asyncResult == null) {
> >>             return null;
> >>         }
> >>
> >>         return asyncResult.get();
> >>     }
> >>
> >>     @Override
> >>     public boolean cancel(boolean mayInterruptIfRunning) {
> >>         return future.cancel(mayInterruptIfRunning);
> >>     }
> >>
> >>     @Override
> >>     public boolean isCancelled() {
> >>         return future.isCancelled();
> >>     }
> >>     @Override
> >>     public boolean isDone() {
> >>         return future.isDone();
> >>     }
> >>
> >> }
> >>
> >> This of course didn't quite work, as the InvocationContext will be reset
> >> after the @AroundInvoke method returns, and an infinite intercept loop
> >> results (on Weld).
> >>
> >> I got it to work though on Weld by using a thread local check to break
> >> that loop:
> >>
> >> @Interceptor
> >> @Asynchronous
> >> @Priority(PLATFORM_BEFORE)
> >> public class AsynchronousInterceptor implements Serializable {
> >>
> >>     private static final long serialVersionUID = 1L;
> >>
> >>     @Resource
> >>     private ManagedExecutorService managedExecutorService;
> >>
> >>     private static final ThreadLocal<Boolean> asyncInvocation = new
> >> ThreadLocal<Boolean>();
> >>
> >>     @AroundInvoke
> >>     public synchronized Object submitAsync(InvocationContext ctx) throws
> >> Exception {
> >>
> >>         if (TRUE.equals(asyncInvocation.get())) {
> >>             return ctx.proceed();
> >>         }
> >>
> >>         return new FutureDelegator(managedExecutorService.submit( ()-> {
> >>             try {
> >>                 asyncInvocation.set(TRUE);
> >>                 return ctx.proceed();
> >>             } finally {
> >>                  asyncInvocation.remove();
> >>             }
> >>         }));
> >>     }
> >>
> >> }
> >>
> >> But I've got a feeling this works just by chance and not because the
> >> workaround is so clever.
> >>
> >> What do you guys think, what would be the best way to support this with
> >> the current CDI version? Or would CDI/Interceptors need something like
> >> Servlet's async support, where the InvocationContext is put into async
> mode
> >> whereafter it "simply" allows an other thread to continue processing on
> it?
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2
> >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >> provided on this list, the provider waives all patent and other
> intellectual
> >> property rights inherent in such information.
> >>
> >>
> >
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150118/36f178ec/attachment-0001.html 

From jharting at redhat.com  Mon Jan 19 03:21:59 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 19 Jan 2015 09:21:59 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>	<54B9858D.7010909@redhat.com>
	<CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
Message-ID: <54BCBEA7.5080202@redhat.com>


On 01/17/2015 12:32 AM, arjan tijms wrote:
> Hi,
>
> On Fri, Jan 16, 2015 at 10:41 PM, Jozef Hartinger <jharting at redhat.com 
> <mailto:jharting at redhat.com>> wrote:
>
>     Hi Arjan,
>
>     I did some changes recently in Weld interceptors and this usecase
>     now works smoothly. The code is not part of a release yet. See
>     this test for a simple implementation of an @Async interceptor
>     (basically the same as your initial attempt). Note that the chain
>     is repeatable but at the same time it is not reset after dispatch
>     to a different thread so you no longer need the ThreadLocal nor
>     any other workaround.
>
>
> That's quite a coincidence, it's indeed rather similar ;)
>
> I wonder how it now works though, as the InvocationContext "ctx" does 
> not seem to be made aware that it's been dispatched to a different 
> thread from within the code. Does it use an internal thread local to 
> keep state or so?
The most straightforward implementations use a mutable integer index to 
keep track of which interceptor of the chain is the one to be invoked 
next. This index is incremented after each interceptor invocation and 
once it reaches the size of the interceptor chain, the interceptor 
method is called. In addition, there is a spec requirement that says 
that calls to InvocationContext.proceed() should be repeatable i.e. you 
should be able implement retry such as:

try {
     return invocationContext.proceed();
} catch (Exception ignored) {
     return invocationContext.proceed(); // retry once again
}

In order to implement this requirement, InvocationContext's internal 
mutable index needs to be reset to the initial position for retry to 
work as expected. This clashes with the AsyncInterceptor as it returns 
from the interceptor method before the chain is finished. This causes 
the index to be reset prematurely and things get stuck in an infinite loop.

In order to support AsyncInterceptor we switched to an implementation 
where we use multiple InvocationContext implementations with immutable 
indexes. That way we do not need to reset the index and AsyncInterceptor 
works.
Note that we do not guard access to the state of parameters and context 
data and these are therefore expected to be published safely between 
threads (as your implementation does).


>
> I'll also try to see what this does on OWB. Do you think this is 
> something that should work, or just something that Weld happens to 
> support regardless of the spec?
It's something that is currently not required by the spec but doable. 
Therefore, it is a good idea to implement it this way.
>
> Kind regards,
> Arjan
>
>
>
>     https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java
>
>     Jozef
>
>
>     On 01/16/2015 06:17 PM, arjan tijms wrote:
>>     Hi,
>>
>>     I'm attempting to emulate EJB's @Asynchronous in CDI using
>>     interceptors.
>>
>>     Originally I had defined my interceptor as follows;
>>
>>     @Interceptor
>>     @Asynchronous
>>     @Priority(APPLICATION)
>>     public class AsynchronousInterceptor implements Serializable {
>>
>>         private static final long serialVersionUID = 1L;
>>
>>         @Resource
>>         private ManagedExecutorService managedExecutorService;
>>
>>         @AroundInvoke
>>         public Object submitAsync(InvocationContext ctx) throws
>>     Exception {
>>             return new FutureDelegator(managedExecutorService.submit(
>>     ()-> { return ctx.proceed(); } ));
>>         }
>>
>>     }
>>
>>     With FutureDelegator as follows:
>>
>>     public class FutureDelegator implements Future<Object> {
>>
>>         private Future<?> future;
>>
>>         public FutureDelegator(Future<?> future) {
>>             this.future = future;
>>         }
>>
>>         @Override
>>         public Object get() throws InterruptedException,
>>     ExecutionException {
>>             AsyncResult<?> asyncResult = (AsyncResult<?>) future.get();
>>             if (asyncResult == null) {
>>                 return null;
>>             }
>>
>>             return asyncResult.get();
>>         }
>>
>>         @Override
>>         public Object get(long timeout, TimeUnit unit) throws
>>     InterruptedException, ExecutionException, TimeoutException {
>>             AsyncResult<?> asyncResult = (AsyncResult<?>)
>>     future.get(timeout, unit);
>>             if (asyncResult == null) {
>>                 return null;
>>             }
>>
>>             return asyncResult.get();
>>         }
>>
>>         @Override
>>         public boolean cancel(boolean mayInterruptIfRunning) {
>>             return future.cancel(mayInterruptIfRunning);
>>         }
>>
>>         @Override
>>         public boolean isCancelled() {
>>             return future.isCancelled();
>>         }
>>         @Override
>>         public boolean isDone() {
>>             return future.isDone();
>>         }
>>
>>     }
>>
>>     This of course didn't quite work, as the InvocationContext will
>>     be reset after the @AroundInvoke method returns, and an infinite
>>     intercept loop results (on Weld).
>>
>>     I got it to work though on Weld by using a thread local check to
>>     break that loop:
>>
>>     @Interceptor
>>     @Asynchronous
>>     @Priority(PLATFORM_BEFORE)
>>     public class AsynchronousInterceptor implements Serializable {
>>
>>         private static final long serialVersionUID = 1L;
>>
>>         @Resource
>>         private ManagedExecutorService managedExecutorService;
>>
>>         private static final ThreadLocal<Boolean> asyncInvocation =
>>     new ThreadLocal<Boolean>();
>>
>>         @AroundInvoke
>>         public synchronized Object submitAsync(InvocationContext ctx)
>>     throws Exception {
>>
>>             if (TRUE.equals(asyncInvocation.get())) {
>>                 return ctx.proceed();
>>             }
>>
>>             return new FutureDelegator(managedExecutorService.submit(
>>     ()-> {
>>                 try {
>>                     asyncInvocation.set(TRUE);
>>                     return ctx.proceed();
>>                 } finally {
>>                      asyncInvocation.remove();
>>                 }
>>             }));
>>         }
>>
>>     }
>>
>>     But I've got a feeling this works just by chance and not because
>>     the workaround is so clever.
>>
>>     What do you guys think, what would be the best way to support
>>     this with the current CDI version? Or would CDI/Interceptors need
>>     something like Servlet's async support, where the
>>     InvocationContext is put into async mode whereafter it "simply"
>>     allows an other thread to continue processing on it?
>>
>>     Kind regards,
>>     Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org  <mailto:cdi-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>     Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150119/6007a8d0/attachment.html 

From issues at jboss.org  Wed Jan 21 05:12:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:12:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166969@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.17932.1421835169646@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-499:
----------------------------------------

             Summary: Firing events asynchronously 
                 Key: CDI-499
                 URL: https://issues.jboss.org/browse/CDI-499
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Events
    Affects Versions: 1.2.Final
            Reporter: Antoine Sabot-Durand


We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is: 

h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}

Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}

h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.

h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously

h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).

h2 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 05:18:48 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:18:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.17939.1421835528942@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034041#comment-13034041 ] 

Antoine Sabot-Durand commented on CDI-499:
------------------------------------------

This ticket comes after a lot of discussion around async events in CDI-31 or in the event workshop document. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 05:18:48 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:18:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.17940.1421835528965@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-499:
-------------------------------------
    Description: 
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is: 

h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}

Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}

h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.

h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously

h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).

h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  

  was:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is: 

h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}

Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}

h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.

h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously

h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).

h2 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 05:22:50 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:22:50 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-31) Asynchronous events
In-Reply-To: <JIRA.12427806.1294751586000@Atlassian.JIRA>
References: <JIRA.12427806.1294751586000@Atlassian.JIRA>
	<JIRA.12427806.1294751586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427806.1294751586000.17957.1421835770468@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-31.
-----------------------------------
    Resolution: Duplicate Issue


This ticket has been superseded by CDI-499.

> Asynchronous events
> -------------------
>
>                 Key: CDI-31
>                 URL: https://issues.jboss.org/browse/CDI-31
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.0
>            Reporter: Nicklas Karlsson
>             Fix For: 2.0 (discussion)
>
>
> Consider including asynchronous events as their were specified in one of the previous drafts.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 05:32:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:32:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.17968.1421836369328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034041#comment-13034041 ] 

Antoine Sabot-Durand edited comment on CDI-499 at 1/21/15 5:32 AM:
-------------------------------------------------------------------

This ticket comes after a lot of discussion around async events in CDI-31, in the event workshop document (http://bit.ly/cdi2wsevt) or IRC meeting. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.


was (Author: antoinesabot-durand):
This ticket comes after a lot of discussion around async events in CDI-31 or in the event workshop document. In these discussions there were a lot of more complicated scenario but we wanted to keep CDI event as simple as possible. For advanced asynchronous scenario, JDK8 will provide its new API {{CompletableFuture}} or we could add the support of asynchronous operation in CDI if necessary.

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 05:34:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 05:34:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.17969.1421836489146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-499:
-------------------------------------
    Description: 
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is: 

h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}

Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}

h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.

h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously

h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).

h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  

  was:
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
Our proposal is: 

h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
Signature of the method on {{Event<T>}} would be
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event);
{code}

Signature on {{BeanManager}} would be
{code:java}
<T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
{code}

h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.

h2. 3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously

h2. 4. Event Ordering
Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are amix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).

h2. 5. Event state (payload mutability)
We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 06:37:49 2015
From: issues at jboss.org (=?UTF-8?Q?Jos=C3=A9_Paumard_=28JIRA=29?=)
Date: Wed, 21 Jan 2015 06:37:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18024.1421840269178@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034053#comment-13034053 ] 

Jos? Paumard commented on CDI-499:
----------------------------------

2 things : 
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement. 

- the signature of the fireAsync is <U extends T> CompletionStage<U> fireAsync(U event);
I think we need to add a 2nd method that takes an Executor as a parameter, for 2 reasons : 
- it would stick to the CompletionStage patterns
- in a Java EE world, it would allow one to state that the processing of the event should take place in a ManagedExecutorService, obtained by injection, that the BeanManager might not be aware of. 

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From issues at jboss.org  Wed Jan 21 07:06:49 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18078.1421842009269@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058 ] 

Jozef Hartinger commented on CDI-499:
-------------------------------------

{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?

{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 07:37:50 2015
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 21 Jan 2015 07:37:50 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.18129.1421843870021@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034063#comment-13034063 ] 

John Ament commented on CDI-26:
-------------------------------

We're speaking through this again on the 2.0 EG.

The current proposal is to add a new interface (tentatively called {{CDIContainer}} ) which will handle the creation of the container.

The possible package is {{javax.enterprise.inject.spi}} or {{javax.enterprise.inject.spi.container}} or something else.

It's expected to have 2 or 3 methods in it

{code}
init();

init(Map<?,?> params);

shutdown();
{code}

> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion)
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 07:38:48 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 21 Jan 2015 07:38:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata
 injection for EE components
In-Reply-To: <JIRA.12561340.1421843887000@Atlassian.JIRA>
References: <JIRA.12561340.1421843887000@Atlassian.JIRA>
	<JIRA.12561340.1421843887357@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561340.1421843887000.18130.1421843928912@Atlassian.JIRA>

Martin Kouba created CDI-500:
--------------------------------

             Summary: Clarify @Intercepted Bean metadata injection for EE components
                 Key: CDI-500
                 URL: https://issues.jboss.org/browse/CDI-500
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Interceptors
    Affects Versions: 1.2.Final
            Reporter: Martin Kouba


It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. 

See the CDI spec, "5.5.8. Bean metadata":
{quote}
Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate:
* a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and
* ...
{quote}
However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection":
{quote}
The component classes listed in Table EE.5-1 with support level "Standard"
all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled?which it is by default?these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors.
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From john.d.ament at gmail.com  Wed Jan 21 07:40:12 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 21 Jan 2015 12:40:12 +0000
Subject: [cdi-dev] Today's meeting
Message-ID: <CAOqetn_Z=wG9tffz_j2+OS1aif2sp2nW+68smghppymuEXraaQ@mail.gmail.com>

Hey guys

Was hoping to get to today's meeting, luck's not in my favor and I have
some surgery today :-(  Good news is at least the next six weeks no one
will bother me right before the scheduled meeting so I'll be there.

I just updated the CDI SE ticket based on what we talked about last week.
I can start marking up the doc in google docs this week as well.

- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/e3cf1428/attachment.html 

From issues at jboss.org  Wed Jan 21 07:43:49 2015
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 21 Jan 2015 07:43:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.18147.1421844229674@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament updated CDI-26:
--------------------------
    Affects Version/s: 1.2.Final
                       1.1.PFD


> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0, 1.1.PFD, 1.2.Final
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion)
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From werner.keil at gmail.com  Wed Jan 21 07:52:48 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 21 Jan 2015 13:52:48 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
Message-ID: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>

Antoine/all,

Is it safe to assume any recent discussion about an @Asynchronous
annotation would be covered there unless e.g. EJB itself needs it to be
updated for EE 8?

Werner


On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    2. [JBoss JIRA] (CDI-31) Asynchronous events
>       (Antoine Sabot-Durand (JIRA))
>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Jos? Paumard (JIRA))
>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Jozef Hartinger (JIRA))
>
>
> ----------------------------------------------------------------------
>
>
> Message: 6
> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058
> ]
>
> Jozef Hartinger commented on CDI-499:
> -------------------------------------
>
> {quote}For backward compatibility reason the possibility to invoke an
> observer asynchronously should be let to the observer{quote}
> What exactly are the reasons for this? I can think of one:
> - observer method injecting a @RequestScoped (or similar) bean
> Are there other arguments for this?
>
> {quote}3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but
> asynchronously{quote}
> How's that different from Event.fire()?
>
> > Firing events asynchronously
> > -----------------------------
> >
> >                 Key: CDI-499
> >                 URL: https://issues.jboss.org/browse/CDI-499
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Events
> >    Affects Versions: 1.2.Final
> >            Reporter: Antoine Sabot-Durand
> >
> > We should allow a way to fire event asynchronously. This mechanism
> should leverage new async API in JDK8 especially the {{CompletionStage}}
> interface.
> > Our proposal is:
> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> > Signature of the method on {{Event<T>}} would be
> > {code:java}
> > <U extends T> CompletionStage<U> fireAsync(U event);
> > {code}
> > Signature on {{BeanManager}} would be
> > {code:java}
> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> > {code}
> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> > For backward compatibility reason the possibility to invoke an observer
> asynchronously should be let to the observer (legacy observers should be
> called synchronously). We propose to add the boolean {{asyncSupported()}}
> member with the {{false}} default value to support this backward
> compatibility aspect.
> > So to be notified asynchronously an observer should have
> {{asyncSupported}} member to true. otherwise it will be called
> synchronously.
> > h2. 3. Observer bound to a transaction phase
> > these observer will be invoked in the right transaction phase but
> asynchronously
> > h2. 4. Event Ordering
> > Should we decide to add events ordering in CDI 2.0, the order will be
> keep in asynchronous observer notification. If there are a mix of
> synchronous and asynchronous observer, asynchronous will be called first in
> order, then synchronous in their order (async has priority on sync).
> > h2. 5. Event state (payload mutability)
> > We'll keep payload mutability with async events (but should explicitly
> specify it). That means  that we should guarantee the event state
> consistency between observers and in case of ordered observers the fact
> that observer N+1 get the event state at the end of observer N.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.11#6341)
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 50, Issue 42
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/0a6e70ce/attachment.html 

From issues at jboss.org  Wed Jan 21 09:37:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 09:37:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18381.1421851069661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034108#comment-13034108 ] 

Antoine Sabot-Durand commented on CDI-499:
------------------------------------------

{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
...
{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}

I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.

{quote}
{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?
{quote}

probably none ;). How did you handle that in Weld Alpha [~jharting]?



> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 09:44:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 09:44:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18433.1421851489345@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034108#comment-13034108 ] 

Antoine Sabot-Durand edited comment on CDI-499 at 1/21/15 9:44 AM:
-------------------------------------------------------------------

{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
{quote}
...
{quote}
{color:blue}
For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer
{color}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}

I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.

{quote}
{color:blue}
3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously
{color}
How's that different from Event.fire()?
{quote}

probably none ;). How did you handle that in Weld Alpha [~jharting]?




was (Author: antoinesabot-durand):
{quote}
- So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
I think a call to fireAsync() should be processed asynchronously by all observers. But I have the feeling that it is in contradiction with this statement
...
{quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
What exactly are the reasons for this? I can think of one:
- observer method injecting a @RequestScoped (or similar) bean
Are there other arguments for this?
{quote}

I'm not very happy with this approach as well : It could bring confusion for end user. This possible backward compatibility issue was raised by [~meetoblivion] or [~struberg] during last IRC meeting. I'd be glad to have a better solution here.

{quote}
{quote}3. Observer bound to a transaction phase
these observer will be invoked in the right transaction phase but asynchronously{quote}
How's that different from Event.fire()?
{quote}

probably none ;). How did you handle that in Weld Alpha [~jharting]?



> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From werner.keil at gmail.com  Wed Jan 21 09:58:36 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 21 Jan 2015 15:58:36 +0100
Subject: [cdi-dev] Today's meeting (John D. Ament)
Message-ID: <CAAGawe0NCcS0hhBXXKcM-Fjj24rwKWJzEBA=x40Nkkm52U=+fQ@mail.gmail.com>

Also very busy with 3 parallel tasks here at the moment (the most critical
one heavily related to Java, JNI and some changes in latest builds of both
Java 7 and 8;-) but maybe later today I could join the IRC from the web
interface.

Werner

On Wed, Jan 21, 2015 at 3:37 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. [JBoss JIRA] (CDI-26) Bootstrap API for CDI (John Ament (JIRA))
>    2. [JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata
>       injection for EE components (Martin Kouba (JIRA))
>    3. Today's meeting (John D. Ament)
>    4. [JBoss JIRA] (CDI-26) Bootstrap API for CDI (John Ament (JIRA))
>    5. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Werner Keil)
>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>
>
> ----------------------------------------------------------------------
>
>
>
> Message: 3
> Date: Wed, 21 Jan 2015 12:40:12 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: [cdi-dev] Today's meeting
> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAOqetn_Z=
> wG9tffz_j2+OS1aif2sp2nW+68smghppymuEXraaQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey guys
>
> Was hoping to get to today's meeting, luck's not in my favor and I have
> some surgery today :-(  Good news is at least the next six weeks no one
> will bother me right before the scheduled meeting so I'll be there.
>
> I just updated the CDI SE ticket based on what we talked about last week.
> I can start marking up the doc in google docs this week as well.
>
> - John
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/e3cf1428/attachment-0001.html
>
> ------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/e1d1978d/attachment.html 

From issues at jboss.org  Wed Jan 21 09:58:50 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 21 Jan 2015 09:58:50 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18478.1421852330021@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034170#comment-13034170 ] 

Jozef Hartinger commented on CDI-499:
-------------------------------------

{quote}How did you handle that in Weld Alpha Jozef Hartinger?{quote}
Delivery to transactional observers has always been asynchronous so no special treatment.

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 21 09:59:49 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 21 Jan 2015 09:59:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <JIRA.12561330.1421835166000@Atlassian.JIRA>
References: <JIRA.12561330.1421835166000@Atlassian.JIRA>
	<JIRA.12561330.1421835166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561330.1421835166000.18488.1421852389681@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034171#comment-13034171 ] 

Antoine Sabot-Durand commented on CDI-499:
------------------------------------------

[~josepaumard]
{quote}
- the signature of the fireAsync is <U extends T> CompletionStage<U> fireAsync(U event);
I think we need to add a 2nd method that takes an Executor as a parameter, for 2 reasons : 
- it would stick to the CompletionStage patterns
- in a Java EE world, it would allow one to state that the processing of the event should take place in a ManagedExecutorService, obtained by injection, that the BeanManager might not be aware of. 
{quote}

Discussion is open but I really think we should keep the event system as simple as possible. My feeling is: if someone need a specific executor service he'll manage his own asynchronous call. Event shouldn't be more than notification and basic tasks...

> Firing events asynchronously 
> -----------------------------
>
>                 Key: CDI-499
>                 URL: https://issues.jboss.org/browse/CDI-499
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is: 
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.  



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From antoine at sabot-durand.net  Wed Jan 21 10:01:35 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 21 Jan 2015 16:01:35 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>
References: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>
Message-ID: <EA3E8FE5-445A-4E09-B365-E5AF49BDB024@sabot-durand.net>

Hi Werner,


No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about async operation support in CDI 2.0 is another subject.


> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit :
> 
> Antoine/all,
> 
> Is it safe to assume any recent discussion about an @Asynchronous annotation would be covered there unless e.g. EJB itself needs it to be updated for EE 8?
> 
> Werner
> 
> On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org <mailto:cdi-dev-request at lists.jboss.org>> wrote:
> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org <mailto:cdi-dev-request at lists.jboss.org>
> 
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org <mailto:cdi-dev-owner at lists.jboss.org>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
> 
> 
> Today's Topics:
> 
>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    2. [JBoss JIRA] (CDI-31) Asynchronous events
>       (Antoine Sabot-Durand (JIRA))
>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand (JIRA))
>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Jos? Paumard (JIRA))
>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Jozef Hartinger (JIRA))
> 
> 
> ----------------------------------------------------------------------
> 
> 
> Message: 6
> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> From: "Jozef Hartinger (JIRA)" <issues at jboss.org <mailto:issues at jboss.org>>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> To: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> Message-ID:
>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
> 
> 
>     [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058 <https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058> ]
> 
> Jozef Hartinger commented on CDI-499:
> -------------------------------------
> 
> {quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
> What exactly are the reasons for this? I can think of one:
> - observer method injecting a @RequestScoped (or similar) bean
> Are there other arguments for this?
> 
> {quote}3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously{quote}
> How's that different from Event.fire()?
> 
> > Firing events asynchronously
> > -----------------------------
> >
> >                 Key: CDI-499
> >                 URL: https://issues.jboss.org/browse/CDI-499 <https://issues.jboss.org/browse/CDI-499>
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Events
> >    Affects Versions: 1.2.Final
> >            Reporter: Antoine Sabot-Durand
> >
> > We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> > Our proposal is:
> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> > Signature of the method on {{Event<T>}} would be
> > {code:java}
> > <U extends T> CompletionStage<U> fireAsync(U event);
> > {code}
> > Signature on {{BeanManager}} would be
> > {code:java}
> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> > {code}
> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> > For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> > So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> > h2. 3. Observer bound to a transaction phase
> > these observer will be invoked in the right transaction phase but asynchronously
> > h2. 4. Event Ordering
> > Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> > h2. 5. Event state (payload mutability)
> > We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.11#6341)
> 
> 
> ------------------------------
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html <http://www.apache.org/licenses/LICENSE-2.0.html>).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 
> End of cdi-dev Digest, Vol 50, Issue 42
> ***************************************
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/cbb1c2dc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/cbb1c2dc/attachment-0001.bin 

From antoine at sabot-durand.net  Wed Jan 21 10:04:38 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 21 Jan 2015 16:04:38 +0100
Subject: [cdi-dev] Today's meeting
In-Reply-To: <CAOqetn_Z=wG9tffz_j2+OS1aif2sp2nW+68smghppymuEXraaQ@mail.gmail.com>
References: <CAOqetn_Z=wG9tffz_j2+OS1aif2sp2nW+68smghppymuEXraaQ@mail.gmail.com>
Message-ID: <6CE398B0-3590-4194-99BF-29C6B147148C@sabot-durand.net>

Hi John,

Good luck. I?ll be happy to talk to you next week.

Antoine


> Le 21 janv. 2015 ? 13:40, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> Hey guys
> 
> Was hoping to get to today's meeting, luck's not in my favor and I have some surgery today :-(  Good news is at least the next six weeks no one will bother me right before the scheduled meeting so I'll be there.
> 
> I just updated the CDI SE ticket based on what we talked about last week.  I can start marking up the doc in google docs this week as well.
> 
> - John
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/a6d90af2/attachment.bin 

From werner.keil at gmail.com  Wed Jan 21 10:07:46 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 21 Jan 2015 16:07:46 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <EA3E8FE5-445A-4E09-B365-E5AF49BDB024@sabot-durand.net>
References: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>
	<EA3E8FE5-445A-4E09-B365-E5AF49BDB024@sabot-durand.net>
Message-ID: <CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=xHg@mail.gmail.com>

Hi Antoine,

It seems the exact place for that is still to be found, but even if these
are separate threads in parallel the fact that CDI 2 aims to add support
for async events means anything other JSRs cannot do or don't want to do
(see Bill's remark on resources in other JSRs) would fit into CDI 2 as long
as the resource situation here isn't too critical either of course;-)

That's what I wanted to say.

Werner

On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi Werner,
>
>
> No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about
> async operation support in CDI 2.0 is another subject.
>
>
> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit :
>
> Antoine/all,
>
> Is it safe to assume any recent discussion about an @Asynchronous
> annotation would be covered there unless e.g. EJB itself needs it to be
> updated for EE 8?
>
> Werner
>
> On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         cdi-dev at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         cdi-dev-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>>         cdi-dev-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>       (Antoine Sabot-Durand (JIRA))
>>    2. [JBoss JIRA] (CDI-31) Asynchronous events
>>       (Antoine Sabot-Durand (JIRA))
>>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>       (Antoine Sabot-Durand (JIRA))
>>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>       (Antoine Sabot-Durand (JIRA))
>>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>       (Jos? Paumard (JIRA))
>>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>       (Jozef Hartinger (JIRA))
>>
>>
>> ----------------------------------------------------------------------
>>
>>
>> Message: 6
>> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
>> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
>> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
>> To: cdi-dev at lists.jboss.org
>> Message-ID:
>>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
>> Content-Type: text/plain; charset=UTF-8
>>
>>
>>     [
>> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058
>> ]
>>
>> Jozef Hartinger commented on CDI-499:
>> -------------------------------------
>>
>> {quote}For backward compatibility reason the possibility to invoke an
>> observer asynchronously should be let to the observer{quote}
>> What exactly are the reasons for this? I can think of one:
>> - observer method injecting a @RequestScoped (or similar) bean
>> Are there other arguments for this?
>>
>> {quote}3. Observer bound to a transaction phase
>> these observer will be invoked in the right transaction phase but
>> asynchronously{quote}
>> How's that different from Event.fire()?
>>
>> > Firing events asynchronously
>> > -----------------------------
>> >
>> >                 Key: CDI-499
>> >                 URL: https://issues.jboss.org/browse/CDI-499
>> >             Project: CDI Specification Issues
>> >          Issue Type: Feature Request
>> >          Components: Events
>> >    Affects Versions: 1.2.Final
>> >            Reporter: Antoine Sabot-Durand
>> >
>> > We should allow a way to fire event asynchronously. This mechanism
>> should leverage new async API in JDK8 especially the {{CompletionStage}}
>> interface.
>> > Our proposal is:
>> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
>> > Signature of the method on {{Event<T>}} would be
>> > {code:java}
>> > <U extends T> CompletionStage<U> fireAsync(U event);
>> > {code}
>> > Signature on {{BeanManager}} would be
>> > {code:java}
>> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
>> > {code}
>> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
>> > For backward compatibility reason the possibility to invoke an observer
>> asynchronously should be let to the observer (legacy observers should be
>> called synchronously). We propose to add the boolean {{asyncSupported()}}
>> member with the {{false}} default value to support this backward
>> compatibility aspect.
>> > So to be notified asynchronously an observer should have
>> {{asyncSupported}} member to true. otherwise it will be called
>> synchronously.
>> > h2. 3. Observer bound to a transaction phase
>> > these observer will be invoked in the right transaction phase but
>> asynchronously
>> > h2. 4. Event Ordering
>> > Should we decide to add events ordering in CDI 2.0, the order will be
>> keep in asynchronous observer notification. If there are a mix of
>> synchronous and asynchronous observer, asynchronous will be called first in
>> order, then synchronous in their order (async has priority on sync).
>> > h2. 5. Event state (payload mutability)
>> > We'll keep payload mutability with async events (but should explicitly
>> specify it). That means  that we should guarantee the event state
>> consistency between observers and in case of ordered observers the fact
>> that observer N+1 get the event state at the end of observer N.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.11#6341)
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>> End of cdi-dev Digest, Vol 50, Issue 42
>> ***************************************
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/eb5a3559/attachment.html 

From antoine at sabot-durand.net  Wed Jan 21 10:20:46 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 21 Jan 2015 16:20:46 +0100
Subject: [cdi-dev] Building EJB-like @Asynchronous via interceptor in CDI
In-Reply-To: <54BCBEA7.5080202@redhat.com>
References: <CAE=-AhDAWJX4uf-MsqySTLT+6KX00OKBCFNsoWwjJPcXX-RvrA@mail.gmail.com>
	<54B9858D.7010909@redhat.com>
	<CAE=-AhBUu-MAiM1OmH4uVt4c-EU-1P0Sj-xvB8F3a_BvzPGi0A@mail.gmail.com>
	<54BCBEA7.5080202@redhat.com>
Message-ID: <2D5C8B76-F389-4CE3-92F6-E48EFA0BE8D6@sabot-durand.net>

Hi Guys,

Remember that CDI 2.0 will require JDK8. So user will have very powerful asynchronous feature out of the box with the CompletableFuture class. So I wonder if we should really focus on this @Asynhcronous annotation and it?s right JSR ?
Whatever we decide here, the first point we should work on IMO is specifying how contexts will be propagated (or not) during async operations.

Antoine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/9036a06f/attachment.bin 

From antoine at sabot-durand.net  Wed Jan 21 10:25:44 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 21 Jan 2015 16:25:44 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=xHg@mail.gmail.com>
References: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>
	<EA3E8FE5-445A-4E09-B365-E5AF49BDB024@sabot-durand.net>
	<CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=xHg@mail.gmail.com>
Message-ID: <70D7164E-3C68-46A9-9BCC-F737E5385C85@sabot-durand.net>

My concern is too avoid creating a new EJB spec with CDI 2. Managing async operation is now very simple for end user with java 8, so do we have to add annotation to support it. I wonder. 

Antoine Sabot-Durand

> Le 21 janv. 2015 ? 16:07, Werner Keil <werner.keil at gmail.com> a ?crit :
> 
> Hi Antoine,
> 
> It seems the exact place for that is still to be found, but even if these are separate threads in parallel the fact that CDI 2 aims to add support for async events means anything other JSRs cannot do or don't want to do (see Bill's remark on resources in other JSRs) would fit into CDI 2 as long as the resource situation here isn't too critical either of course;-)
> 
> That's what I wanted to say.
> 
> Werner
> 
>> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> Hi Werner,
>> 
>> 
>> No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about async operation support in CDI 2.0 is another subject.
>> 
>> 
>>> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit :
>>> 
>>> Antoine/all,
>>> 
>>> Is it safe to assume any recent discussion about an @Asynchronous annotation would be covered there unless e.g. EJB itself needs it to be updated for EE 8?
>>> 
>>> Werner
>>> 
>>>> On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org> wrote:
>>>> Send cdi-dev mailing list submissions to
>>>>         cdi-dev at lists.jboss.org
>>>> 
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> or, via email, send a message with subject or body 'help' to
>>>>         cdi-dev-request at lists.jboss.org
>>>> 
>>>> You can reach the person managing the list at
>>>>         cdi-dev-owner at lists.jboss.org
>>>> 
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of cdi-dev digest..."
>>>> 
>>>> 
>>>> Today's Topics:
>>>> 
>>>>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>>       (Antoine Sabot-Durand (JIRA))
>>>>    2. [JBoss JIRA] (CDI-31) Asynchronous events
>>>>       (Antoine Sabot-Durand (JIRA))
>>>>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>>       (Antoine Sabot-Durand (JIRA))
>>>>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>>       (Antoine Sabot-Durand (JIRA))
>>>>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>>       (Jos? Paumard (JIRA))
>>>>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>>       (Jozef Hartinger (JIRA))
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 
>>>> Message: 6
>>>> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
>>>> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
>>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>> To: cdi-dev at lists.jboss.org
>>>> Message-ID:
>>>>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
>>>> Content-Type: text/plain; charset=UTF-8
>>>> 
>>>> 
>>>>     [ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058 ]
>>>> 
>>>> Jozef Hartinger commented on CDI-499:
>>>> -------------------------------------
>>>> 
>>>> {quote}For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer{quote}
>>>> What exactly are the reasons for this? I can think of one:
>>>> - observer method injecting a @RequestScoped (or similar) bean
>>>> Are there other arguments for this?
>>>> 
>>>> {quote}3. Observer bound to a transaction phase
>>>> these observer will be invoked in the right transaction phase but asynchronously{quote}
>>>> How's that different from Event.fire()?
>>>> 
>>>> > Firing events asynchronously
>>>> > -----------------------------
>>>> >
>>>> >                 Key: CDI-499
>>>> >                 URL: https://issues.jboss.org/browse/CDI-499
>>>> >             Project: CDI Specification Issues
>>>> >          Issue Type: Feature Request
>>>> >          Components: Events
>>>> >    Affects Versions: 1.2.Final
>>>> >            Reporter: Antoine Sabot-Durand
>>>> >
>>>> > We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
>>>> > Our proposal is:
>>>> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
>>>> > Signature of the method on {{Event<T>}} would be
>>>> > {code:java}
>>>> > <U extends T> CompletionStage<U> fireAsync(U event);
>>>> > {code}
>>>> > Signature on {{BeanManager}} would be
>>>> > {code:java}
>>>> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
>>>> > {code}
>>>> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
>>>> > For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
>>>> > So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
>>>> > h2. 3. Observer bound to a transaction phase
>>>> > these observer will be invoked in the right transaction phase but asynchronously
>>>> > h2. 4. Event Ordering
>>>> > Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
>>>> > h2. 5. Event state (payload mutability)
>>>> > We'll keep payload mutability with async events (but should explicitly specify it). That means  that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
>>>> 
>>>> 
>>>> 
>>>> --
>>>> This message was sent by Atlassian JIRA
>>>> (v6.3.11#6341)
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>> 
>>>> End of cdi-dev Digest, Vol 50, Issue 42
>>>> ***************************************
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/3ffd155b/attachment-0001.html 

From werner.keil at gmail.com  Wed Jan 21 10:39:37 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 21 Jan 2015 16:39:37 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
In-Reply-To: <70D7164E-3C68-46A9-9BCC-F737E5385C85@sabot-durand.net>
References: <CAAGawe0H6AokvGa0GuRgGBkCTHnbp1c7DgEeMbckDsNP3fgPbQ@mail.gmail.com>
	<EA3E8FE5-445A-4E09-B365-E5AF49BDB024@sabot-durand.net>
	<CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=xHg@mail.gmail.com>
	<70D7164E-3C68-46A9-9BCC-F737E5385C85@sabot-durand.net>
Message-ID: <CAAGawe0_RisjNOR7G1W5BaPvqJxfuYVD2uHyS0GRi7YPzcv7iQ@mail.gmail.com>

I guess also looking a bit beyond SE and EE 8 the "modularity" aspect and
"isolation" of what you need from another JSR like EJB could be
interesting, but not all of it may fully apply to a "pre Jigsaw" EE 8
yet;-) On the long term it could be very relevant to have CDI 2.x (or 3)
without even a single element in other modules like EJB, the question is,
do we and all implementing systems just on the CDI side rely on such
annotations or not?

Werner



On Wed, Jan 21, 2015 at 4:25 PM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> My concern is too avoid creating a new EJB spec with CDI 2. Managing async
> operation is now very simple for end user with java 8, so do we have to add
> annotation to support it. I wonder.
>
> Antoine Sabot-Durand
>
> Le 21 janv. 2015 ? 16:07, Werner Keil <werner.keil at gmail.com> a ?crit :
>
> Hi Antoine,
>
> It seems the exact place for that is still to be found, but even if these
> are separate threads in parallel the fact that CDI 2 aims to add support
> for async events means anything other JSRs cannot do or don't want to do
> (see Bill's remark on resources in other JSRs) would fit into CDI 2 as long
> as the resource situation here isn't too critical either of course;-)
>
> That's what I wanted to say.
>
> Werner
>
> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> Hi Werner,
>>
>>
>> No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about
>> async operation support in CDI 2.0 is another subject.
>>
>>
>> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit :
>>
>> Antoine/all,
>>
>> Is it safe to assume any recent discussion about an @Asynchronous
>> annotation would be covered there unless e.g. EJB itself needs it to be
>> updated for EE 8?
>>
>> Werner
>>
>> On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org> wrote:
>>
>>> Send cdi-dev mailing list submissions to
>>>         cdi-dev at lists.jboss.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> or, via email, send a message with subject or body 'help' to
>>>         cdi-dev-request at lists.jboss.org
>>>
>>> You can reach the person managing the list at
>>>         cdi-dev-owner at lists.jboss.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of cdi-dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>       (Antoine Sabot-Durand (JIRA))
>>>    2. [JBoss JIRA] (CDI-31) Asynchronous events
>>>       (Antoine Sabot-Durand (JIRA))
>>>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>       (Antoine Sabot-Durand (JIRA))
>>>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>       (Antoine Sabot-Durand (JIRA))
>>>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>       (Jos? Paumard (JIRA))
>>>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
>>>       (Jozef Hartinger (JIRA))
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>>
>>> Message: 6
>>> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
>>> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
>>> To: cdi-dev at lists.jboss.org
>>> Message-ID:
>>>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>>
>>>     [
>>> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058
>>> ]
>>>
>>> Jozef Hartinger commented on CDI-499:
>>> -------------------------------------
>>>
>>> {quote}For backward compatibility reason the possibility to invoke an
>>> observer asynchronously should be let to the observer{quote}
>>> What exactly are the reasons for this? I can think of one:
>>> - observer method injecting a @RequestScoped (or similar) bean
>>> Are there other arguments for this?
>>>
>>> {quote}3. Observer bound to a transaction phase
>>> these observer will be invoked in the right transaction phase but
>>> asynchronously{quote}
>>> How's that different from Event.fire()?
>>>
>>> > Firing events asynchronously
>>> > -----------------------------
>>> >
>>> >                 Key: CDI-499
>>> >                 URL: https://issues.jboss.org/browse/CDI-499
>>> >             Project: CDI Specification Issues
>>> >          Issue Type: Feature Request
>>> >          Components: Events
>>> >    Affects Versions: 1.2.Final
>>> >            Reporter: Antoine Sabot-Durand
>>> >
>>> > We should allow a way to fire event asynchronously. This mechanism
>>> should leverage new async API in JDK8 especially the {{CompletionStage}}
>>> interface.
>>> > Our proposal is:
>>> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
>>> > Signature of the method on {{Event<T>}} would be
>>> > {code:java}
>>> > <U extends T> CompletionStage<U> fireAsync(U event);
>>> > {code}
>>> > Signature on {{BeanManager}} would be
>>> > {code:java}
>>> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation...
>>> qualifiers)
>>> > {code}
>>> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
>>> > For backward compatibility reason the possibility to invoke an
>>> observer asynchronously should be let to the observer (legacy observers
>>> should be called synchronously). We propose to add the boolean
>>> {{asyncSupported()}} member with the {{false}} default value to support
>>> this backward compatibility aspect.
>>> > So to be notified asynchronously an observer should have
>>> {{asyncSupported}} member to true. otherwise it will be called
>>> synchronously.
>>> > h2. 3. Observer bound to a transaction phase
>>> > these observer will be invoked in the right transaction phase but
>>> asynchronously
>>> > h2. 4. Event Ordering
>>> > Should we decide to add events ordering in CDI 2.0, the order will be
>>> keep in asynchronous observer notification. If there are a mix of
>>> synchronous and asynchronous observer, asynchronous will be called first in
>>> order, then synchronous in their order (async has priority on sync).
>>> > h2. 5. Event state (payload mutability)
>>> > We'll keep payload mutability with async events (but should explicitly
>>> specify it). That means  that we should guarantee the event state
>>> consistency between observers and in case of ordered observers the fact
>>> that observer N+1 get the event state at the end of observer N.
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.11#6341)
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (
>>> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>
>>> End of cdi-dev Digest, Vol 50, Issue 42
>>> ***************************************
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/d67efe1f/attachment.html 

From werner.keil at gmail.com  Wed Jan 21 11:59:31 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 21 Jan 2015 17:59:31 +0100
Subject: [cdi-dev] Today's meeting
Message-ID: <CAAGawe0xt8SgNFO5qREUOozEWEFuxoMZ3q4tTyZYmO41AP8AYw@mail.gmail.com>

Guys,
Just noticed, I never joined the IRC chat from here in the company (last
time was mostly Christmas in Austria) and both web URLs or ports seem
blocked by our firewall and proxy, so I'm afraid I can't join today either.
If it's a less busy week I try to be at home by then should work there.

+1 for using Java SE 8 where we can btw. Everything that makes CDI 2 less
dependent on other specs that may become optional in future profiles or
won't even be around in a pure SE/desktop environment sounds like a good
idea.

Werner

On Wed, Jan 21, 2015 at 4:25 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Today's meeting (Antoine Sabot-Durand)
>    2. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Werner Keil)
>    3. Re: Building EJB-like @Asynchronous via interceptor in CDI
>       (Antoine Sabot-Durand)
>    4. Re: [JBoss JIRA] (CDI-499) Firing events asynchronously
>       (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Jan 2015 16:04:38 +0100
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] Today's meeting
> To: John Ament <john.d.ament at gmail.com>
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID: <6CE398B0-3590-4194-99BF-29C6B147148C at sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi John,
>
> Good luck. I?ll be happy to talk to you next week.
>
> Antoine
>
>
> > Le 21 janv. 2015 ? 13:40, John D. Ament <john.d.ament at gmail.com> a
> ?crit :
> >
> > Hey guys
> >
> > Was hoping to get to today's meeting, luck's not in my favor and I have
> some surgery today :-(  Good news is at least the next six weeks no one
> will bother me right before the scheduled meeting so I'll be there.
> >
> > I just updated the CDI SE ticket based on what we talked about last
> week.  I can start marking up the doc in google docs this week as well.
> >
> > - John
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/a6d90af2/attachment-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Wed, 21 Jan 2015 16:07:46 +0100
> From: Werner Keil <werner.keil at gmail.com>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events
>         asynchronously
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAAGawe0qe3KvDk7r4Tb2zB-EhSWeV4oH64Gq7Y=P2Zg9-V=
> xHg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antoine,
>
> It seems the exact place for that is still to be found, but even if these
> are separate threads in parallel the fact that CDI 2 aims to add support
> for async events means anything other JSRs cannot do or don't want to do
> (see Bill's remark on resources in other JSRs) would fit into CDI 2 as long
> as the resource situation here isn't too critical either of course;-)
>
> That's what I wanted to say.
>
> Werner
>
> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
> > Hi Werner,
> >
> >
> > No, it doesn?t cover @Asynchronous or @Async annotation. Discussion about
> > async operation support in CDI 2.0 is another subject.
> >
> >
> > Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit :
> >
> > Antoine/all,
> >
> > Is it safe to assume any recent discussion about an @Asynchronous
> > annotation would be covered there unless e.g. EJB itself needs it to be
> > updated for EE 8?
> >
> > Werner
> >
> > On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org>
> wrote:
> >
> >> Send cdi-dev mailing list submissions to
> >>         cdi-dev at lists.jboss.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> or, via email, send a message with subject or body 'help' to
> >>         cdi-dev-request at lists.jboss.org
> >>
> >> You can reach the person managing the list at
> >>         cdi-dev-owner at lists.jboss.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of cdi-dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>       (Antoine Sabot-Durand (JIRA))
> >>    2. [JBoss JIRA] (CDI-31) Asynchronous events
> >>       (Antoine Sabot-Durand (JIRA))
> >>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>       (Antoine Sabot-Durand (JIRA))
> >>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>       (Antoine Sabot-Durand (JIRA))
> >>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>       (Jos? Paumard (JIRA))
> >>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>       (Jozef Hartinger (JIRA))
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> >> Message: 6
> >> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> >> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
> >> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> >> To: cdi-dev at lists.jboss.org
> >> Message-ID:
> >>         <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA
> >
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >>
> >>     [
> >>
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058
> >> ]
> >>
> >> Jozef Hartinger commented on CDI-499:
> >> -------------------------------------
> >>
> >> {quote}For backward compatibility reason the possibility to invoke an
> >> observer asynchronously should be let to the observer{quote}
> >> What exactly are the reasons for this? I can think of one:
> >> - observer method injecting a @RequestScoped (or similar) bean
> >> Are there other arguments for this?
> >>
> >> {quote}3. Observer bound to a transaction phase
> >> these observer will be invoked in the right transaction phase but
> >> asynchronously{quote}
> >> How's that different from Event.fire()?
> >>
> >> > Firing events asynchronously
> >> > -----------------------------
> >> >
> >> >                 Key: CDI-499
> >> >                 URL: https://issues.jboss.org/browse/CDI-499
> >> >             Project: CDI Specification Issues
> >> >          Issue Type: Feature Request
> >> >          Components: Events
> >> >    Affects Versions: 1.2.Final
> >> >            Reporter: Antoine Sabot-Durand
> >> >
> >> > We should allow a way to fire event asynchronously. This mechanism
> >> should leverage new async API in JDK8 especially the {{CompletionStage}}
> >> interface.
> >> > Our proposal is:
> >> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> >> > Signature of the method on {{Event<T>}} would be
> >> > {code:java}
> >> > <U extends T> CompletionStage<U> fireAsync(U event);
> >> > {code}
> >> > Signature on {{BeanManager}} would be
> >> > {code:java}
> >> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation...
> qualifiers)
> >> > {code}
> >> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> >> > For backward compatibility reason the possibility to invoke an
> observer
> >> asynchronously should be let to the observer (legacy observers should be
> >> called synchronously). We propose to add the boolean
> {{asyncSupported()}}
> >> member with the {{false}} default value to support this backward
> >> compatibility aspect.
> >> > So to be notified asynchronously an observer should have
> >> {{asyncSupported}} member to true. otherwise it will be called
> >> synchronously.
> >> > h2. 3. Observer bound to a transaction phase
> >> > these observer will be invoked in the right transaction phase but
> >> asynchronously
> >> > h2. 4. Event Ordering
> >> > Should we decide to add events ordering in CDI 2.0, the order will be
> >> keep in asynchronous observer notification. If there are a mix of
> >> synchronous and asynchronous observer, asynchronous will be called
> first in
> >> order, then synchronous in their order (async has priority on sync).
> >> > h2. 5. Event state (payload mutability)
> >> > We'll keep payload mutability with async events (but should explicitly
> >> specify it). That means  that we should guarantee the event state
> >> consistency between observers and in case of ordered observers the fact
> >> that observer N+1 get the event state at the end of observer N.
> >>
> >>
> >>
> >> --
> >> This message was sent by Atlassian JIRA
> >> (v6.3.11#6341)
> >>
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (
> >> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> >> provided on this list, the provider waives all patent and other
> >> intellectual property rights inherent in such information.
> >>
> >> End of cdi-dev Digest, Vol 50, Issue 42
> >> ***************************************
> >>
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/eb5a3559/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 21 Jan 2015 16:20:46 +0100
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] Building EJB-like @Asynchronous via interceptor
>         in CDI
> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID: <2D5C8B76-F389-4CE3-92F6-E48EFA0BE8D6 at sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
>
> Remember that CDI 2.0 will require JDK8. So user will have very powerful
> asynchronous feature out of the box with the CompletableFuture class. So I
> wonder if we should really focus on this @Asynhcronous annotation and it?s
> right JSR ?
> Whatever we decide here, the first point we should work on IMO is
> specifying how contexts will be propagated (or not) during async operations.
>
> Antoine
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/9036a06f/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Wed, 21 Jan 2015 16:25:44 +0100
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events
>         asynchronously
> To: Werner Keil <werner.keil at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID: <70D7164E-3C68-46A9-9BCC-F737E5385C85 at sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> My concern is too avoid creating a new EJB spec with CDI 2. Managing async
> operation is now very simple for end user with java 8, so do we have to add
> annotation to support it. I wonder.
>
> Antoine Sabot-Durand
>
> > Le 21 janv. 2015 ? 16:07, Werner Keil <werner.keil at gmail.com> a ?crit :
> >
> > Hi Antoine,
> >
> > It seems the exact place for that is still to be found, but even if
> these are separate threads in parallel the fact that CDI 2 aims to add
> support for async events means anything other JSRs cannot do or don't want
> to do (see Bill's remark on resources in other JSRs) would fit into CDI 2
> as long as the resource situation here isn't too critical either of
> course;-)
> >
> > That's what I wanted to say.
> >
> > Werner
> >
> >> On Wed, Jan 21, 2015 at 4:01 PM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
> >> Hi Werner,
> >>
> >>
> >> No, it doesn?t cover @Asynchronous or @Async annotation. Discussion
> about async operation support in CDI 2.0 is another subject.
> >>
> >>
> >>> Le 21 janv. 2015 ? 13:52, Werner Keil <werner.keil at gmail.com> a ?crit
> :
> >>>
> >>> Antoine/all,
> >>>
> >>> Is it safe to assume any recent discussion about an @Asynchronous
> annotation would be covered there unless e.g. EJB itself needs it to be
> updated for EE 8?
> >>>
> >>> Werner
> >>>
> >>>> On Wed, Jan 21, 2015 at 1:06 PM, <cdi-dev-request at lists.jboss.org>
> wrote:
> >>>> Send cdi-dev mailing list submissions to
> >>>>         cdi-dev at lists.jboss.org
> >>>>
> >>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>> or, via email, send a message with subject or body 'help' to
> >>>>         cdi-dev-request at lists.jboss.org
> >>>>
> >>>> You can reach the person managing the list at
> >>>>         cdi-dev-owner at lists.jboss.org
> >>>>
> >>>> When replying, please edit your Subject line so it is more specific
> >>>> than "Re: Contents of cdi-dev digest..."
> >>>>
> >>>>
> >>>> Today's Topics:
> >>>>
> >>>>    1. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>>       (Antoine Sabot-Durand (JIRA))
> >>>>    2. [JBoss JIRA] (CDI-31) Asynchronous events
> >>>>       (Antoine Sabot-Durand (JIRA))
> >>>>    3. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>>       (Antoine Sabot-Durand (JIRA))
> >>>>    4. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>>       (Antoine Sabot-Durand (JIRA))
> >>>>    5. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>>       (Jos? Paumard (JIRA))
> >>>>    6. [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>>       (Jozef Hartinger (JIRA))
> >>>>
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>
> >>>>
> >>>> Message: 6
> >>>> Date: Wed, 21 Jan 2015 07:06:49 -0500 (EST)
> >>>> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
> >>>> Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously
> >>>> To: cdi-dev at lists.jboss.org
> >>>> Message-ID:
> >>>>
>  <JIRA.12561330.1421835166000.18078.1421842009269 at Atlassian.JIRA>
> >>>> Content-Type: text/plain; charset=UTF-8
> >>>>
> >>>>
> >>>>     [
> https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034058#comment-13034058
> ]
> >>>>
> >>>> Jozef Hartinger commented on CDI-499:
> >>>> -------------------------------------
> >>>>
> >>>> {quote}For backward compatibility reason the possibility to invoke an
> observer asynchronously should be let to the observer{quote}
> >>>> What exactly are the reasons for this? I can think of one:
> >>>> - observer method injecting a @RequestScoped (or similar) bean
> >>>> Are there other arguments for this?
> >>>>
> >>>> {quote}3. Observer bound to a transaction phase
> >>>> these observer will be invoked in the right transaction phase but
> asynchronously{quote}
> >>>> How's that different from Event.fire()?
> >>>>
> >>>> > Firing events asynchronously
> >>>> > -----------------------------
> >>>> >
> >>>> >                 Key: CDI-499
> >>>> >                 URL: https://issues.jboss.org/browse/CDI-499
> >>>> >             Project: CDI Specification Issues
> >>>> >          Issue Type: Feature Request
> >>>> >          Components: Events
> >>>> >    Affects Versions: 1.2.Final
> >>>> >            Reporter: Antoine Sabot-Durand
> >>>> >
> >>>> > We should allow a way to fire event asynchronously. This mechanism
> should leverage new async API in JDK8 especially the {{CompletionStage}}
> interface.
> >>>> > Our proposal is:
> >>>> > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> >>>> > Signature of the method on {{Event<T>}} would be
> >>>> > {code:java}
> >>>> > <U extends T> CompletionStage<U> fireAsync(U event);
> >>>> > {code}
> >>>> > Signature on {{BeanManager}} would be
> >>>> > {code:java}
> >>>> > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation...
> qualifiers)
> >>>> > {code}
> >>>> > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> >>>> > For backward compatibility reason the possibility to invoke an
> observer asynchronously should be let to the observer (legacy observers
> should be called synchronously). We propose to add the boolean
> {{asyncSupported()}} member with the {{false}} default value to support
> this backward compatibility aspect.
> >>>> > So to be notified asynchronously an observer should have
> {{asyncSupported}} member to true. otherwise it will be called
> synchronously.
> >>>> > h2. 3. Observer bound to a transaction phase
> >>>> > these observer will be invoked in the right transaction phase but
> asynchronously
> >>>> > h2. 4. Event Ordering
> >>>> > Should we decide to add events ordering in CDI 2.0, the order will
> be keep in asynchronous observer notification. If there are a mix of
> synchronous and asynchronous observer, asynchronous will be called first in
> order, then synchronous in their order (async has priority on sync).
> >>>> > h2. 5. Event state (payload mutability)
> >>>> > We'll keep payload mutability with async events (but should
> explicitly specify it). That means  that we should guarantee the event
> state consistency between observers and in case of ordered observers the
> fact that observer N+1 get the event state at the end of observer N.
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> This message was sent by Atlassian JIRA
> >>>> (v6.3.11#6341)
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> cdi-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>>>
> >>>> End of cdi-dev Digest, Vol 50, Issue 42
> >>>> ***************************************
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/3ffd155b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 50, Issue 45
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150121/ab8ce606/attachment-0001.html 

From issues at jboss.org  Wed Jan 21 16:03:48 2015
From: issues at jboss.org (=?UTF-8?Q?Jos=C3=A9_Paumard_=28JIRA=29?=)
Date: Wed, 21 Jan 2015 16:03:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-501) Firing and consuming events should
 take place in the same thread
In-Reply-To: <JIRA.12561386.1421874221000@Atlassian.JIRA>
References: <JIRA.12561386.1421874221000@Atlassian.JIRA>
	<JIRA.12561386.1421874221461@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561386.1421874221000.18927.1421874228913@Atlassian.JIRA>

Jos? Paumard created CDI-501:
--------------------------------

             Summary: Firing and consuming events should take place in the same thread
                 Key: CDI-501
                 URL: https://issues.jboss.org/browse/CDI-501
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Events
    Affects Versions: 1.2.Final
            Reporter: Jos? Paumard


An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. 

All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state.

The issue is the following : 
- the payload object is not specified, it can then be mutable, non-synchronized etc...
- it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. 

So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. 

Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. 



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


From john.d.ament at gmail.com  Sat Jan 24 09:54:07 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Sat, 24 Jan 2015 09:54:07 -0500
Subject: [cdi-dev] Source code for cdi-spec.org?
Message-ID: <CAOqetn8eFFXNWDp+yb0iBgqRxfW1U-jZBvs7QeoU=7wxux02xw@mail.gmail.com>

Hi all,

Was wondering, where is the source code for the cdi-spec.org site?
Is it this page and someone at redhat publishes it?
https://github.com/cdi-spec/cdi-spec.org

I was thinking maybe we should have a link to the IRC logs somewhere,
easier to find that way.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150124/d661f9e5/attachment.html 

From antoine at sabot-durand.net  Sat Jan 24 11:40:27 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 24 Jan 2015 17:40:27 +0100
Subject: [cdi-dev] Source code for cdi-spec.org?
In-Reply-To: <CAOqetn8eFFXNWDp+yb0iBgqRxfW1U-jZBvs7QeoU=7wxux02xw@mail.gmail.com>
References: <CAOqetn8eFFXNWDp+yb0iBgqRxfW1U-jZBvs7QeoU=7wxux02xw@mail.gmail.com>
Message-ID: <A5A9EF6B-3918-480C-976D-1DE173092572@sabot-durand.net>

Hi John,

Yes it's this repo: an awestruct website. You can push a PR to it if you feel like doing it. 

Antoine Sabot-Durand

> Le 24 janv. 2015 ? 15:54, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> Hi all,
> 
> Was wondering, where is the source code for the cdi-spec.org site?
> Is it this page and someone at redhat publishes it? https://github.com/cdi-spec/cdi-spec.org
> 
> I was thinking maybe we should have a link to the IRC logs somewhere, easier to find that way.
> 
> John
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150124/a4640d3b/attachment.html 

From antoine at sabot-durand.net  Wed Jan 28 03:54:36 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 28 Jan 2015 09:54:36 +0100
Subject: [cdi-dev] Canceling today's meeting
Message-ID: <41106DBB-3EC4-4C5B-AF09-A940BEB4B392@sabot-durand.net>

Hi,

I won't be available for the meeting today. Let's continue our reflexion on SE support and async event for next Wednesday. 

Antoine Sabot-Durand



From issues at jboss.org  Wed Jan 28 05:57:48 2015
From: issues at jboss.org (Tomasz Krakowiak (JIRA))
Date: Wed, 28 Jan 2015 05:57:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632701@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.29072.1422442668915@Atlassian.JIRA>

Tomasz Krakowiak created CDI-502:
------------------------------------

             Summary: Clarify "contains" meaning in "Legal bean types" specification.
                 Key: CDI-502
                 URL: https://issues.jboss.org/browse/CDI-502
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Beans, Inheritance and Specialization
            Reporter: Tomasz Krakowiak


CDI 1.1, section 2.2.1. Legal bean types says:
{quote}
A parameterized type that contains a wildcard type parameter is not a legal bean type.
{quote}

Does it means direct containment or deep/recursive containment?

I understand this is clearly illegal:
{code}
@Produces
List<?> produceList(){
//...
}
{code}

But, are those two bean definitions legal:
{code}
@Produces
List<Optional<?>> produceList(){
//...
}
{code}
{code}
// Bean types: MyList, List<Optional<?>>, Object
// or
// Bean types: MyList, Object
@Dependent
MyList extends List<Optional<?>> {
//...
}
{code}






--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 28 11:40:49 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 28 Jan 2015 11:40:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.30851.1422463249778@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035932#comment-13035932 ] 

Jozef Hartinger commented on CDI-502:
-------------------------------------

"Assignability of raw and parameterized types" rules which do not currently allow this usecase. That indirectly indicates that this scenario is not supported by the spec. If we want to change it we'll need to update the rules also.

> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Wed Jan 28 15:24:49 2015
From: issues at jboss.org (Tomasz Krakowiak (JIRA))
Date: Wed, 28 Jan 2015 15:24:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.31296.1422476689123@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035993#comment-13035993 ] 

Tomasz Krakowiak commented on CDI-502:
--------------------------------------

Thanks for quick reply, [~jozed].

I struggling to understand how. I can't find in "5.2.4. Assignability of raw and parameterized types" anything that would disallow it.
I'm not sure what "actual type". But assuming that it doesn't exclude wildcard types I think that rule
{quote}
the required type parameter is a wildcard, the bean type parameter is an actual type and the actual type is assignable to the upper bound, if any, of the wildcard and assignable from the lower bound, if any, of the wildcard
{quote}
covers it.

h6. A little off the topic - I think I found a bug there
If I understand correctly "5.2.4. Assignability of raw and parameterized types" (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#assignable_parameters) indicates that bean type {{List<Optional<Object>>}} is assignable to required type {{List<Optional<? extends Object>>}} (which are not assignable to each other in Java language and wildcards are allowed in required types).

> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Thu Jan 29 04:25:49 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 29 Jan 2015 04:25:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.32126.1422523549218@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036118#comment-13036118 ] 

Jozef Hartinger commented on CDI-502:
-------------------------------------

{quote}But assuming that it doesn't exclude wildcard types I think that rule{quote}
An actual type is a type that is not a wildcard nor an unresolved type variable. There is therefore no rule in 5.2.4 where a wildcard would be considered on the bean type side.

{quote}If I understand correctly "5.2.4. Assignability of raw and parameterized types" (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#assignable_parameters) indicates that bean type List<Optional<Object>> is assignable to required type List<Optional<? extends Object>> (which are not assignable to each other in Java language and wildcards are allowed in required types).{quote}

Correct. Not sure why it is so.

> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Thu Jan 29 04:39:49 2015
From: issues at jboss.org (Tomasz Krakowiak (JIRA))
Date: Thu, 29 Jan 2015 04:39:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.32165.1422524389108@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036126#comment-13036126 ] 

Tomasz Krakowiak commented on CDI-502:
--------------------------------------

{quote}
An actual type is a type that is not a wildcard nor an unresolved type variable. There is therefore no rule in 5.2.4 where a wildcard would be considered on the bean type side.
{quote}
Thanks, now I understand.

It would be nice if legal bean types would be the types you can instantiate in Java (That doesn't covers all types a variable can have(eg. `List<? extends Optional<?>>`), but covers types, like `List<Optional<?>>`). And assignability to be exactly the same what in Java is with the exception for raw generic types.

I guess I could report feature request.

{quote}
Correct. Not sure why it is so.
{quote}
Should I report it as a clarification or bug?

> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Thu Jan 29 05:10:49 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 29 Jan 2015 05:10:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-502) Clarify "contains" meaning in
 "Legal bean types" specification.
In-Reply-To: <JIRA.12561865.1422442632000@Atlassian.JIRA>
References: <JIRA.12561865.1422442632000@Atlassian.JIRA>
	<JIRA.12561865.1422442632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561865.1422442632000.32226.1422526249194@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036139#comment-13036139 ] 

Jozef Hartinger commented on CDI-502:
-------------------------------------

Yes, clarification probably.

> Clarify "contains" meaning in "Legal bean types" specification.
> ---------------------------------------------------------------
>
>                 Key: CDI-502
>                 URL: https://issues.jboss.org/browse/CDI-502
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Tomasz Krakowiak
>
> CDI 1.1, section 2.2.1. Legal bean types says:
> {quote}
> A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> Does it means direct containment or deep/recursive containment?
> I understand this is clearly illegal:
> {code}
> @Produces
> List<?> produceList(){
> //...
> }
> {code}
> But, are those two bean definitions legal:
> {code}
> @Produces
> List<Optional<?>> produceList(){
> //...
> }
> {code}
> {code}
> // Bean types: MyList, List<Optional<?>>, Object
> // or
> // Bean types: MyList, Object
> @Dependent
> MyList extends List<Optional<?>> {
> //...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Fri Jan 30 08:53:48 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 30 Jan 2015 08:53:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated
In-Reply-To: <JIRA.12538650.1397829419000@Atlassian.JIRA>
References: <JIRA.12538650.1397829419000@Atlassian.JIRA>
	<JIRA.12538650.1397829419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538650.1397829419000.34462.1422626028928@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned CDI-434:
--------------------------------

    Assignee:     (was: Martin Kouba)


> AfterTypeDiscovery javadoc outdated
> -----------------------------------
>
>                 Key: CDI-434
>                 URL: https://issues.jboss.org/browse/CDI-434
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> {quote}
> *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list
> {quote}
> vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29
> The same applies to {{getInterceptors()}} and {{getDecorators()}}.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Fri Jan 30 15:14:48 2015
From: issues at jboss.org (Nikos Ballas (JIRA))
Date: Fri, 30 Jan 2015 15:14:48 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-503) Properties injection from files to
 classes that are valid beans
In-Reply-To: <JIRA.12562127.1422648849000@Atlassian.JIRA>
References: <JIRA.12562127.1422648849000@Atlassian.JIRA>
	<JIRA.12562127.1422648849106@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562127.1422648849000.35340.1422648888912@Atlassian.JIRA>

Nikos Ballas created CDI-503:
--------------------------------

             Summary: Properties injection from files to classes that are valid beans
                 Key: CDI-503
                 URL: https://issues.jboss.org/browse/CDI-503
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Contexts, Packaging and Deployment
            Reporter: Nikos Ballas


I would like to be able to provide under META-INF folder my .properties file and have the the values automatically injected(loaded) into my bean using annotation injection. DeltaSpike offers something similar but with alot of tricky code.I would like to be able to do the following:
case 1:
public MyClass{
 @PropertiesInjection(file = "/path/to/file")
 private Properties properties
}

case 2:
@PropertyPlaceholder(file = "path/to/file")
public MyClass {
   @InjectProperty(name="property.name")
   private String propertyName
   
   @PropertyPlaceholder(file = "path/to/other/file") 
   public void someMethod(){
     @InjectProperty(name = "other.property")
      String propertyName;
      endpoint = propertyName+port;
   }
}


Again it should be stated that would be nice to be able to apply the @PropertyPlaceholder annotation either as classlevel annotation and being able to override the value if it's  in method level with different parameters.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)

From issues at jboss.org  Fri Jan 30 15:20:49 2015
From: issues at jboss.org (Nikos Ballas (JIRA))
Date: Fri, 30 Jan 2015 15:20:49 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-503) Properties injection from files to
	classes
In-Reply-To: <JIRA.12562127.1422648849000@Atlassian.JIRA>
References: <JIRA.12562127.1422648849000@Atlassian.JIRA>
	<JIRA.12562127.1422648849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562127.1422648849000.35342.1422649249103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikos Ballas updated CDI-503:
-----------------------------
    Summary: Properties injection from files to classes  (was: Properties injection from files to classes that are valid beans)


> Properties injection from files to classes
> ------------------------------------------
>
>                 Key: CDI-503
>                 URL: https://issues.jboss.org/browse/CDI-503
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts, Packaging and Deployment
>            Reporter: Nikos Ballas
>
> I would like to be able to provide under META-INF folder my .properties file and have the the values automatically injected(loaded) into my bean using annotation injection. DeltaSpike offers something similar but with alot of tricky code.I would like to be able to do the following:
> case 1:
> public MyClass{
>  @PropertiesInjection(file = "/path/to/file")
>  private Properties properties
> }
> case 2:
> @PropertyPlaceholder(file = "path/to/file")
> public MyClass {
>    @InjectProperty(name="property.name")
>    private String propertyName
>    
>    @PropertyPlaceholder(file = "path/to/other/file") 
>    public void someMethod(){
>      @InjectProperty(name = "other.property")
>       String propertyName;
>       endpoint = propertyName+port;
>    }
> }
> Again it should be stated that would be nice to be able to apply the @PropertyPlaceholder annotation either as classlevel annotation and being able to override the value if it's  in method level with different parameters.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)