From radim.hanus at gmail.com  Fri Jan  3 08:21:30 2014
From: radim.hanus at gmail.com (=?UTF-8?B?UmFkaW0gSGFudcWh?=)
Date: Fri, 3 Jan 2014 14:21:30 +0100
Subject: [cdi-dev] Having an official CDI tutorial and user forum
In-Reply-To: <AAD11A23-0B79-4868-9C88-95DFBF28585C@sabot-durand.net>
References: <50045616-948F-4D3F-A56A-9E7F31AF7059@sabot-durand.net>
	<CAFrbYmMmz6RavyXrA3yTTs0oG+7iRvps-nTaf9rqUSfDNSsipg@mail.gmail.com>
	<AAD11A23-0B79-4868-9C88-95DFBF28585C@sabot-durand.net>
Message-ID: <CAFrbYmPdkJyDmnc_p9nU5MMohJFPAeGd6Zp6yGU0RfRboFe55Q@mail.gmail.com>

Hi Antoine,

meantime I've started to contribute CDI samples to javaee7-samples on
github [1] as Arun Gupta encouraged me [2]

I've got a plenty of usefull still simple examples of several CDI features
based on junit/arquillian tests so that I may contribute them immediatelly
to javaee7-samples with only some simple modifications

If somebody wants to add a sample of a missing CDI feature here [1] please
let me know

Sincerely,
Radim Hanus

[1] https://github.com/javaee-samples/javaee7-samples
[2]
http://blog.arungupta.me/2013/11/javaee-samples-github-organization-javaee7-samples-and-hands-on-lab-already-moved/

2013/11/18 Antoine Sabot-Durand <antoine at sabot-durand.net>

> Hi Radim,
>
> Allow me to post my answer on the list so every body will benefit of your
> contribution.
>
> first of all I would like to let you know that I very appreciate your
> effort to promote my favourite technology :)
>
>
> Thanks. I hope we?ll achieve to pursue this promotion effort. It?s always
> hard to mix highly conceptual technical activity like a spec and promotion
> / communication at the same time. My feeling is CDI is very overlooked and
> deserve a bigger community. Community that could help us making it better.
> Note that I?m not very objective on that topic ;).
>
> >> I think it would be useful to provide an official CDI 1.1 tutorial on
> cdi-spec site
> I agree with you a cdi tutorial with a plenty of quickstarts
> is desperately missing
> something like jboss way quickstarts would be a great addition to
> cdi-spec.org site
>
>
> Yes JDF quick starts are nice (and also deal with Deltaspike) but need
> documentation to introduced them. [1]
> Apache team have nice example for CDI as well on TomEE examples [2]
>
> I also remember seeing interesting content on IBM developerworks. I can
> find them right now.
>
> >> I have the feeling such content is already nearly written by people in
> this ML
> recently I tried to find some details on how to properly use @ThreadScoped
> in java se environment and the only place where I found a working sample
> was this ML (
> http://lists.jboss.org/pipermail/weld-dev/2009-December/002016.html)
>
>
> You may know threadscope is not in the spec, Its specific to Weld, I don?t
> know if OWB has something like that. Anyway, writing a tutorial on building
> a thread scope for all imll, could be interesting. Great to show how to add
> a new scope and promote CDI for SE at the same time.
>
>
> >> so if you have written introduction tutorial to CDI and agree to be
> reused on official site it would be great and time saving for me
> I have already written some CDI samples for my colleagues including the
> one mentioned above
> I would be pleased to supply these samples?
>
>
> Great. We surely could benefit from them
>
>
> Sincerely,
> Radim Hanus
>
>
> Thanks again for your commitment
>
> Antoine
>
> [1] http://www.jboss.org/jdf/quickstarts/get-started/
> [2] http://tomee.apache.org/examples-trunk/index.html
>
>
>
>
>
> 2013/11/18 Antoine Sabot-Durand <antoine at sabot-durand.net>
>
>> Hi all,
>>
>> First excuse my french in previous meeting invites. Obviously Google can
>> speak english to you and keep sending french invitation ;).
>>
>> I launch this thread in reaction to the  FUD or inaccuracies about CDI
>> one can find on the web like this post [1]).
>>
>> As the spec is quite long to read and very theoretic, I think it would be
>> useful to provide an official CDI 1.1 tutorial on cdi-spec site. It could
>> allows us to be sure that people have an official overview of the spec and
>> could be enhanced with use cases we would encounter on the web (stack
>> overflow or other).
>> I have the feeling such content is already nearly written by people in
>> this ML, so if you have written introduction tutorial to CDI and agree to
>> be reused on official site it would be great and time saving for me.
>>
>> In the same idea of community federation, I think it could be useful to
>> launch a forum (Google group or other) to allow people to ask informal
>> question about CDI and its eco system. People starting using CDI or casual
>> users won?t use this mailing list and all of them think to use site like
>> Stack Overflow. It would also a good mean to enhance our FAQ.
>>
>> What do you think ?
>>
>>
>> Antoine
>>
>>
>>
>> [1] http://blog.frankel.ch/my-case-against-autowiring
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140103/7c7082ff/attachment.html 

From issues at jboss.org  Sat Jan  4 15:16:33 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Sat, 4 Jan 2014 15:16:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection
In-Reply-To: <JIRA.12528622.1388866578280@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528622.1388866578280@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528622.1388866578280.29787.1388866593854@jira02.app.mwc.hst.phx2.redhat.com>

arjan tijms created CDI-414:
-------------------------------

             Summary: Support for "self" injection
                 Key: CDI-414
                 URL: https://issues.jboss.org/browse/CDI-414
             Project: CDI Specification Issues
          Issue Type: Bug
          Components: Resolution
            Reporter: arjan tijms


Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.

This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.

{code}
@Stateless
public class Foo {

    @EJB
    private Foo self;

    // ...
}
{code}

Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb

Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:

{noformat}
WELD-001443 Pseudo scoped bean has circular dependencies.
{noformat}

See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb

Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.

With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan  6 10:17:33 2014
From: issues at jboss.org (Arne Limburg (JIRA))
Date: Mon, 6 Jan 2014 10:17:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection
In-Reply-To: <JIRA.12528622.1388866578000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528622.1388866578000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528622.1388866578000.30928.1389021453759@jira02.app.mwc.hst.phx2.redhat.com>


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

Arne Limburg commented on CDI-414:
----------------------------------

This works with normal-scoped beans (@ApplicationScoped, @SessionScoped, ...)
Which scope are you using?
                
> Support for "self" injection
> ----------------------------
>
>                 Key: CDI-414
>                 URL: https://issues.jboss.org/browse/CDI-414
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Resolution
>            Reporter: arjan tijms
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
>     @EJB
>     private Foo self;
>     // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan  7 03:49:32 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 7 Jan 2014 03:49:32 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.32181.1389084572862@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-411:
-------------------------------------

    Labels:   (was: Investigate)

    
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> 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.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Jan  7 03:50:03 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 7 Jan 2014 09:50:03 +0100
Subject: [cdi-dev] CDI 1.1 MR official launch on the 13th
Message-ID: <6CA455E0-279F-41BC-971F-C8E64175072F@sabot-durand.net>

Hi all,

Happy new year guys ! I wish to all of you the best in your personal and professional life in 2014.
So I did the JCP ? paperwork ?  and the the MR will be officially launched next monday (the 13th) and should be closed on march 11th.

The last point that was to be decided was about CDI-411: CDI conversation activation conflicts with the Servlet spec [1]. After exchanging with Jozef on the subject we decided to definitely include this in the MR.

I also included a last ticket : CDI-413 : Update outdated license. To propose different license according the site where spec is downloaded.

Antoine


[1] : https://issues.jboss.org/browse/CDI-411
[2] : https://issues.jboss.org/browse/CDI-413




From j.j.snyder at oracle.com  Tue Jan  7 15:00:34 2014
From: j.j.snyder at oracle.com (JJ Snyder)
Date: Tue, 07 Jan 2014 15:00:34 -0500
Subject: [cdi-dev] CDI 1.1 MR official launch on the 13th
In-Reply-To: <6CA455E0-279F-41BC-971F-C8E64175072F@sabot-durand.net>
References: <6CA455E0-279F-41BC-971F-C8E64175072F@sabot-durand.net>
Message-ID: <52CC5CE2.2000600@oracle.com>

Antoine,
Does March 11 include completion of Weld and TCK?

JJ
On 01/07/2014 03:50 AM, Antoine Sabot-Durand wrote:
> Hi all,
>
> Happy new year guys ! I wish to all of you the best in your personal and professional life in 2014.
> So I did the JCP ? paperwork ?  and the the MR will be officially launched next monday (the 13th) and should be closed on march 11th.
>
> The last point that was to be decided was about CDI-411: CDI conversation activation conflicts with the Servlet spec [1]. After exchanging with Jozef on the subject we decided to definitely include this in the MR.
>
> I also included a last ticket : CDI-413 : Update outdated license. To propose different license according the site where spec is downloaded.
>
> Antoine
>
>
> [1] : https://issues.jboss.org/browse/CDI-411
> [2] : https://issues.jboss.org/browse/CDI-413
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev


From antoine at sabot-durand.net  Tue Jan  7 16:44:34 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 7 Jan 2014 22:44:34 +0100
Subject: [cdi-dev] CDI 1.1 MR official launch on the 13th
In-Reply-To: <52CC5CE2.2000600@oracle.com>
References: <6CA455E0-279F-41BC-971F-C8E64175072F@sabot-durand.net>
	<52CC5CE2.2000600@oracle.com>
Message-ID: <54DA95AB-3E58-4B2E-9BFB-5B27DE28F63E@sabot-durand.net>

According to section 5.2 and 5.3 of JCP 2.9 procedures [1] we should provide all the elements for march 11th, including revised RI and TCK.
Now to be totally accurate what will be launch next week is a ballot (for 7 days) to review our proposal. If the ballot result is positive we?ll officially start the week after.

Antoine 


[1] https://jcp.org/en/procedures/jcp2_9#5.2


Le 7 janv. 2014 ? 21:00, JJ Snyder <j.j.snyder at oracle.com> a ?crit :

> Antoine,
> Does March 11 include completion of Weld and TCK?
> 
> JJ
> On 01/07/2014 03:50 AM, Antoine Sabot-Durand wrote:
>> Hi all,
>> 
>> Happy new year guys ! I wish to all of you the best in your personal and professional life in 2014.
>> So I did the JCP ? paperwork ?  and the the MR will be officially launched next monday (the 13th) and should be closed on march 11th.
>> 
>> The last point that was to be decided was about CDI-411: CDI conversation activation conflicts with the Servlet spec [1]. After exchanging with Jozef on the subject we decided to definitely include this in the MR.
>> 
>> I also included a last ticket : CDI-413 : Update outdated license. To propose different license according the site where spec is downloaded.
>> 
>> Antoine
>> 
>> 
>> [1] : https://issues.jboss.org/browse/CDI-411
>> [2] : https://issues.jboss.org/browse/CDI-413
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From gunnar at hibernate.org  Wed Jan 15 04:56:06 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Jan 2014 10:56:06 +0100
Subject: [cdi-dev] How to specify priority of interceptor registered as
	custom bean?
Message-ID: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>

Hi,

Using a CDI portable extension, I'm registering a custom bean which
represents an interceptor (by implementing the
javax.enterprise.inject.spi.Interceptor interface).

My question now is how to specify the priority of that interceptor.
Intuitively I had expected a method such as Interceptor#getPriority(), but
there isn't such method.

In section 9 the spec says extensions could "override the interceptor order
defined by the @Priority annotation" and refers to section 11.5.2 which
introduces AfterTypeDiscovery#getInterceptors(). So I could use this to add
my interceptor, but I don't see how I could specify the priority while
doing so.

How can this be achieved?

Many thanks,

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

From jharting at redhat.com  Wed Jan 15 05:52:57 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 15 Jan 2014 11:52:57 +0100
Subject: [cdi-dev] How to specify priority of interceptor registered as
 custom bean?
In-Reply-To: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>
References: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>
Message-ID: <52D66889.3060001@redhat.com>

Hi Gunnar,

this is not possible. You can only enable the interceptor by adding it 
to AfterTypeDiscovery#getInterceptors() relatively to other interceptors.

Jozef

On 01/15/2014 10:56 AM, Gunnar Morling wrote:
> Hi,
>
> Using a CDI portable extension, I'm registering a custom bean which 
> represents an interceptor (by implementing the 
> javax.enterprise.inject.spi.Interceptor interface).
>
> My question now is how to specify the priority of that interceptor. 
> Intuitively I had expected a method such as Interceptor#getPriority(), 
> but there isn't such method.
>
> In section 9 the spec says extensions could "override the interceptor 
> order defined by the @Priority annotation" and refers to section 
> 11.5.2 which introduces AfterTypeDiscovery#getInterceptors(). So I 
> could use this to add my interceptor, but I don't see how I could 
> specify the priority while doing so.
>
> How can this be achieved?
>
> Many thanks,
>
> --Gunnar
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

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

From gunnar at hibernate.org  Wed Jan 15 06:17:01 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Jan 2014 12:17:01 +0100
Subject: [cdi-dev] How to specify priority of interceptor registered as
 custom bean?
In-Reply-To: <52D66889.3060001@redhat.com>
References: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>
	<52D66889.3060001@redhat.com>
Message-ID: <CADGJaX8LHw+E2=jZ6MKPf_pAS-B7zG7mi8tXs3H3ti6YF1ZNHg@mail.gmail.com>

Hi Jozef,

Thanks for the clarification.

Would it make sense to add Interceptor#getPriority() in a future spec
revision and handle such a custom interceptor bean as if there was an
equivalent annotated interceptor type? As it seems its currently not
possible to achieve the semantics of an annotated interceptor type using a
portable extension.

--Gunnar






2014/1/15 Jozef Hartinger <jharting at redhat.com>

>  Hi Gunnar,
>
> this is not possible. You can only enable the interceptor by adding it to
> AfterTypeDiscovery#getInterceptors() relatively to other interceptors.
>
> Jozef
>
>
> On 01/15/2014 10:56 AM, Gunnar Morling wrote:
>
> Hi,
>
>  Using a CDI portable extension, I'm registering a custom bean which
> represents an interceptor (by implementing the
> javax.enterprise.inject.spi.Interceptor interface).
>
>  My question now is how to specify the priority of that interceptor.
> Intuitively I had expected a method such as Interceptor#getPriority(), but
> there isn't such method.
>
>  In section 9 the spec says extensions could "override the interceptor
> order defined by the @Priority annotation" and refers to section 11.5.2
> which introduces AfterTypeDiscovery#getInterceptors(). So I could use this
> to add my interceptor, but I don't see how I could specify the priority
> while doing so.
>
>  How can this be achieved?
>
>  Many thanks,
>
>  --Gunnar
>
>
>
> _______________________________________________
> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140115/0c66fad3/attachment-0001.html 

From jharting at redhat.com  Wed Jan 15 06:22:39 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 15 Jan 2014 12:22:39 +0100
Subject: [cdi-dev] How to specify priority of interceptor registered as
 custom bean?
In-Reply-To: <CADGJaX8LHw+E2=jZ6MKPf_pAS-B7zG7mi8tXs3H3ti6YF1ZNHg@mail.gmail.com>
References: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>
	<52D66889.3060001@redhat.com>
	<CADGJaX8LHw+E2=jZ6MKPf_pAS-B7zG7mi8tXs3H3ti6YF1ZNHg@mail.gmail.com>
Message-ID: <52D66F7F.7050305@redhat.com>

Yes,

the problem with this is that currently we cannot add a new method to 
the interface - otherwise we break existing implementations of the 
interface. We can either wait for Java 8 or find some other way of 
specifying the priority.

Jozef

On 01/15/2014 12:17 PM, Gunnar Morling wrote:
> Hi Jozef,
>
> Thanks for the clarification.
>
> Would it make sense to add Interceptor#getPriority() in a future spec 
> revision and handle such a custom interceptor bean as if there was an 
> equivalent annotated interceptor type? As it seems its currently not 
> possible to achieve the semantics of an annotated interceptor type 
> using a portable extension.
>
> --Gunnar
>
>
>
>
>
>
> 2014/1/15 Jozef Hartinger <jharting at redhat.com 
> <mailto:jharting at redhat.com>>
>
>     Hi Gunnar,
>
>     this is not possible. You can only enable the interceptor by
>     adding it to AfterTypeDiscovery#getInterceptors() relatively to
>     other interceptors.
>
>     Jozef
>
>
>     On 01/15/2014 10:56 AM, Gunnar Morling wrote:
>>     Hi,
>>
>>     Using a CDI portable extension, I'm registering a custom bean
>>     which represents an interceptor (by implementing the
>>     javax.enterprise.inject.spi.Interceptor interface).
>>
>>     My question now is how to specify the priority of that
>>     interceptor. Intuitively I had expected a method such as
>>     Interceptor#getPriority(), but there isn't such method.
>>
>>     In section 9 the spec says extensions could "override the
>>     interceptor order defined by the @Priority annotation" and refers
>>     to section 11.5.2 which introduces
>>     AfterTypeDiscovery#getInterceptors(). So I could use this to add
>>     my interceptor, but I don't see how I could specify the priority
>>     while doing so.
>>
>>     How can this be achieved?
>>
>>     Many thanks,
>>
>>     --Gunnar
>>
>>
>>
>>     _______________________________________________
>>     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
>
>

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

From gunnar at hibernate.org  Wed Jan 15 06:29:04 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Jan 2014 12:29:04 +0100
Subject: [cdi-dev] How to specify priority of interceptor registered as
 custom bean?
In-Reply-To: <52D66F7F.7050305@redhat.com>
References: <CADGJaX_UddOFBgpc8-dvW1TBQihN6sg1imyo3PSNz59QMBoFGw@mail.gmail.com>
	<52D66889.3060001@redhat.com>
	<CADGJaX8LHw+E2=jZ6MKPf_pAS-B7zG7mi8tXs3H3ti6YF1ZNHg@mail.gmail.com>
	<52D66F7F.7050305@redhat.com>
Message-ID: <CADGJaX98TW7yF7OinLBB55Z3eD4CdQu4+dsVuQPVvy=sz6Ymdg@mail.gmail.com>

2014/1/15 Jozef Hartinger <jharting at redhat.com>

>  Yes,
>
> the problem with this is that currently we cannot add a new method to the
> interface - otherwise we break existing implementations of the interface.
> We can either wait for Java 8 or find some other way of specifying the
> priority.
>

One could think about supporting the @Priority annotation on
implementations of j.e.i.s.Interceptor or have a derived interface
PrioritizedInterceptor which adds the new method.

--Gunnar



> Jozef
>
>
> On 01/15/2014 12:17 PM, Gunnar Morling wrote:
>
> Hi Jozef,
>
>  Thanks for the clarification.
>
>  Would it make sense to add Interceptor#getPriority() in a future spec
> revision and handle such a custom interceptor bean as if there was an
> equivalent annotated interceptor type? As it seems its currently not
> possible to achieve the semantics of an annotated interceptor type using a
> portable extension.
>
>  --Gunnar
>
>
>
>
>
>
> 2014/1/15 Jozef Hartinger <jharting at redhat.com>
>
>>  Hi Gunnar,
>>
>> this is not possible. You can only enable the interceptor by adding it to
>> AfterTypeDiscovery#getInterceptors() relatively to other interceptors.
>>
>> Jozef
>>
>>
>> On 01/15/2014 10:56 AM, Gunnar Morling wrote:
>>
>>  Hi,
>>
>>  Using a CDI portable extension, I'm registering a custom bean which
>> represents an interceptor (by implementing the
>> javax.enterprise.inject.spi.Interceptor interface).
>>
>>  My question now is how to specify the priority of that interceptor.
>> Intuitively I had expected a method such as Interceptor#getPriority(), but
>> there isn't such method.
>>
>>  In section 9 the spec says extensions could "override the interceptor
>> order defined by the @Priority annotation" and refers to section 11.5.2
>> which introduces AfterTypeDiscovery#getInterceptors(). So I could use this
>> to add my interceptor, but I don't see how I could specify the priority
>> while doing so.
>>
>>  How can this be achieved?
>>
>>  Many thanks,
>>
>>  --Gunnar
>>
>>
>>
>>  _______________________________________________
>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140115/ae83507c/attachment.html 

From issues at jboss.org  Wed Jan 22 04:48:28 2014
From: issues at jboss.org (Michael Kotten (JIRA))
Date: Wed, 22 Jan 2014 04:48:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't
 specify handling of null parameter values
In-Reply-To: <JIRA.12530069.1390384029588@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530069.1390384029588@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530069.1390384029588.6273.1390384108921@jira02.app.mwc.hst.phx2.redhat.com>

Michael Kotten created CDI-415:
----------------------------------

             Summary: Observer resolution doesn't specify handling of null parameter values
                 Key: CDI-415
                 URL: https://issues.jboss.org/browse/CDI-415
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Events
            Reporter: Michael Kotten
            Priority: Minor


There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:46:28 2014
From: issues at jboss.org (yangju (JIRA))
Date: Wed, 22 Jan 2014 17:46:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-102) Support Injection of Servlet
	Contexts
In-Reply-To: <JIRA.12429058.1296087589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12429058.1296087589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12429058.1296087589000.7951.1390430788882@jira02.app.mwc.hst.phx2.redhat.com>


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

yangju commented on CDI-102:
----------------------------

Any solution to this issue?
I got error when deploy application with Solder-impl.3.2.0.Final:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.jboss.solder.servlet.http.CookieParamProducer.request
  at org.jboss.solder.servlet.http.CookieParamProducer.request(CookieParamProducer.java:0)
  Possible dependencies: 
  - WELD|AbstractSyntheticBean|epen-login-1.4.30-SNAPSHOT.war/WEB-INF/lib/solder-impl-3.2.0.Final.jar|HttpServletRequest,
  - Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()]

	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:369)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
                
> Support Injection of Servlet Contexts
> -------------------------------------
>
>                 Key: CDI-102
>                 URL: https://issues.jboss.org/browse/CDI-102
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Minor
>             Fix For: 1.1.EDR
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:46:29 2014
From: issues at jboss.org (yangju (JIRA))
Date: Wed, 22 Jan 2014 17:46:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-102) Support Injection of Servlet
	Contexts
In-Reply-To: <JIRA.12429058.1296087589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12429058.1296087589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12429058.1296087589000.7963.1390430789397@jira02.app.mwc.hst.phx2.redhat.com>


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

yangju commented on CDI-102:
----------------------------

Sorry, forgot to mention the jboss version is Wildfly CR1
                
> Support Injection of Servlet Contexts
> -------------------------------------
>
>                 Key: CDI-102
>                 URL: https://issues.jboss.org/browse/CDI-102
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Minor
>             Fix For: 1.1.EDR
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Thu Jan 23 10:24:17 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 23 Jan 2014 16:24:17 +0100
Subject: [cdi-dev] Time to start the MR
Message-ID: <E30805A4-A53E-4AEF-B0E7-F207ED8F78AD@sabot-durand.net>

Hi all,


After resolving some misunderstanding with JCP we?re now ready to start the MR. So we can start to fix the issue list for CDI 1.2  [1] 

To be as efficient as possible in our asynchronous working mode I propose the following rules :

1. I propose that we favorite IRC over Hangout to organize our work (I lost too much time by typing meeting minutes from my hangout notes when we could have them directly from IRC meeting bot). Off course JIRA and the ML are also place to discuss about this MR content.

2. We should have an IRC meeting once a week (at the same time that we use to have the Hangout). Starting the coming monday (jan 27th) at 6:00pm CET. Off course I?ll try to be reachable on IRC as often as possible during my workday.

3. Proposed workflow on issues
- To be able to start work on an issue, Jira discussion should be closed.
- Spec leads propose a discussion closing on an issue by applying the label ? Ready To Fix ? and sum up the resolution choice in the comment of the issue
- Other EG member have 48 hours (2 working days) or until the next weekly meeting (whichever is shorter) to disagree  (should the spec lead missed something or made a mistake in this closing). 
- After this delay one of the spec leads will replace the label by a ? to be assigned label ?
- Issue picking is based on volunteering, so each EG member can decide to pick an issue to fix it. Assignation discussion will also take place on weekly meetings
- When the assignee start work on the issue he puts it in ? in progress ?  state
- As usual when the work is finish a PR is sent to the spec repo for review
- PR should be added to Jira as well
- When the PR is accepted, the assigned put the issue is resolved state.

I hope this way of proceeding is ok for you all. If it?s not the case let me know.
To be efficient, I?ll start to put some issues in ? Ready To Fix ? state tomorrow and we will discuss about their adoption and assignation on monday meeting

[1] https://issues.jboss.org/browse/CDI-413?jql=fixVersion%20%3D%20"1.2%20Proposed"%20AND%20project%20%3D%20CDI.

Antoine



From issues at jboss.org  Fri Jan 24 09:58:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 09:58:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license
In-Reply-To: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528255.1387475028000.11287.1390575508484@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-413:
-------------------------------------

    Labels: Ready_to_fix  (was: )

    
> Update outdated license
> -----------------------
>
>                 Key: CDI-413
>                 URL: https://issues.jboss.org/browse/CDI-413
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.1.FD
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated.
> As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download.
> Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 10:36:31 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 10:36:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license
In-Reply-To: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528255.1387475028000.11398.1390577791435@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Should provide a way to generate two different licence at build time.
*Fixing Leads*
Could be fixed by adding option in the [doc generation script|https://github.com/cdi-spec/cdi/blob/master/spec/generate.sh] or by introducing a generation thru Maven [Asciidoctor plugin|http://asciidoctor.org/news/2013/04/16/introducing-the-asciidoctor-maven-plugin/] and profiles.
                
> Update outdated license
> -----------------------
>
>                 Key: CDI-413
>                 URL: https://issues.jboss.org/browse/CDI-413
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.1.FD
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated.
> As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download.
> Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 10:38:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 10:38:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated
In-Reply-To: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526692.1386061731000.11403.1390577909225@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-410:
-------------------------------------

    Labels: Ready_to_fix  (was: )

    
> @RequestScoped Javadoc outdated
> -------------------------------
>
>                 Key: CDI-410
>                 URL: https://issues.jboss.org/browse/CDI-410
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 10:46:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 10:46:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-406) Make stereotypes bean defining
	annotations
In-Reply-To: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508779.1382693645000.11434.1390578389502@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-406:
-------------------------------------

    Labels: Ready_to_fix  (was: )

    
> Make stereotypes bean defining annotations
> ------------------------------------------
>
>                 Key: CDI-406
>                 URL: https://issues.jboss.org/browse/CDI-406
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> For example @Model

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 10:52:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 10:52:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license
In-Reply-To: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528255.1387475028000.11443.1390578748889@jira02.app.mwc.hst.phx2.redhat.com>


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

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

*Fixing Lead*
Correct spec [section 2.5|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations]
                
> Update outdated license
> -----------------------
>
>                 Key: CDI-413
>                 URL: https://issues.jboss.org/browse/CDI-413
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.1.FD
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated.
> As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download.
> Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 10:52:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 10:52:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-406) Make stereotypes bean defining
	annotations
In-Reply-To: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508779.1382693645000.11442.1390578748832@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-406:
-------------------------------------

    Labels: CDI_impl_chge CDI_spec_chge CDI_tck_chge Ready_to_fix  (was: Ready_to_fix)

    
> Make stereotypes bean defining annotations
> ------------------------------------------
>
>                 Key: CDI-406
>                 URL: https://issues.jboss.org/browse/CDI-406
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_impl_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> For example @Model

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine.sabotdurand at gmail.com  Fri Jan 24 11:07:29 2014
From: antoine.sabotdurand at gmail.com (Antoine Sabot-Durand)
Date: Fri, 24 Jan 2014 16:07:29 +0000
Subject: [cdi-dev] Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm
 on Monday from Mon Jan 27 to Mon Mar 31 (Perso)
Message-ID: <001a11c3e9b60a6bd304f0b98ecb@google.com>

You have been invited to the following event.

Title: CDI 1.2 MR meeting
Proposed agenda :
- Ready to fix review and assignation
- Discussion on other ticket
- Progess and obstacles
When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris
Where: IRC #jsr346 Channel on Freenode
Calendar: Perso
Who:
     (Guest list has been hidden at organizer's request)

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
cdi-dev at lists.jboss.org because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140124/0b1f2fff/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1544 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140124/0b1f2fff/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1591 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140124/0b1f2fff/attachment-0003.bin 

From issues at jboss.org  Fri Jan 24 11:16:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:16:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license
In-Reply-To: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528255.1387475028000.11508.1390580190195@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-413:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: Ready_to_fix)

    
> Update outdated license
> -----------------------
>
>                 Key: CDI-413
>                 URL: https://issues.jboss.org/browse/CDI-413
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.1.FD
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated.
> As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download.
> Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:18:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:18:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license
In-Reply-To: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528255.1387475028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528255.1387475028000.11518.1390580308953@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-413:
-------------------------------------

    Comment: was deleted

(was: *Fixing Lead*
Correct spec [section 2.5|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations])

    
> Update outdated license
> -----------------------
>
>                 Key: CDI-413
>                 URL: https://issues.jboss.org/browse/CDI-413
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 1.1.FD
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated.
> As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download.
> Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:18:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:18:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-406) Make stereotypes bean defining
	annotations
In-Reply-To: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508779.1382693645000.11517.1390580308890@jira02.app.mwc.hst.phx2.redhat.com>


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

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

*Fixing Lead*
Correct spec [section 2.5|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations]
                
> Make stereotypes bean defining annotations
> ------------------------------------------
>
>                 Key: CDI-406
>                 URL: https://issues.jboss.org/browse/CDI-406
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_impl_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> For example @Model

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:18:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:18:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated
In-Reply-To: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526692.1386061731000.11520.1390580309010@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-410:
-------------------------------------

    Labels: CDI_api_change Ready_to_fix  (was: Ready_to_fix)

    
> @RequestScoped Javadoc outdated
> -------------------------------
>
>                 Key: CDI-410
>                 URL: https://issues.jboss.org/browse/CDI-410
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_api_change, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:22:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:22:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated
In-Reply-To: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526692.1386061731000.11538.1390580549778@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-410:
-------------------------------------

    Labels: CDI_api Ready_to_fix  (was: CDI_api_change Ready_to_fix)

    
> @RequestScoped Javadoc outdated
> -------------------------------
>
>                 Key: CDI-410
>                 URL: https://issues.jboss.org/browse/CDI-410
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_api, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:24:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:24:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated
In-Reply-To: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526692.1386061731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526692.1386061731000.11542.1390580668603@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-410:
-------------------------------------

    Labels: CDI_api_chge Ready_to_fix  (was: CDI_api Ready_to_fix)

    
> @RequestScoped Javadoc outdated
> -------------------------------
>
>                 Key: CDI-410
>                 URL: https://issues.jboss.org/browse/CDI-410
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Fri Jan 24 11:25:46 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 24 Jan 2014 17:25:46 +0100
Subject: [cdi-dev] Adding new label to ticket ready for fix
Message-ID: <E5ED45B7-5700-4048-9CEA-50FFF66F3673@sabot-durand.net>

Hi all,

Just to inform you that when I label a ticket with ? Ready_to_fix ?, I also try to add label regarding impact on different part of CDI :
CDI_api_chge : fix will change API and/or Javadoc
CDI_spec_chge : fix will change specification document
CDI_tck_chge : fix will change TCK and Implementation

I may missed some impact but it?s an indication for people that will work on these points.

Antoine Sabot-Durand
???????????????
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead

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

From issues at jboss.org  Fri Jan 24 11:26:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:26:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-406) Make stereotypes bean defining
	annotations
In-Reply-To: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508779.1382693645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508779.1382693645000.11557.1390580788736@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-406:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix  (was: CDI_impl_chge CDI_spec_chge CDI_tck_chge Ready_to_fix)

    
> Make stereotypes bean defining annotations
> ------------------------------------------
>
>                 Key: CDI-406
>                 URL: https://issues.jboss.org/browse/CDI-406
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> For example @Model

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:38:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 24 Jan 2014 11:38:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of
 @RequestScoped and @ApplicationScoped in section 2.4.1
In-Reply-To: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503242.1381927095000.11600.1390581508626@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-405:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1
> --------------------------------------------------------------------------------
>
>                 Key: CDI-405
>                 URL: https://issues.jboss.org/browse/CDI-405
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 06:04:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 25 Jan 2014 06:04:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of
 @RequestScoped and @ApplicationScoped in section 2.4.1
In-Reply-To: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503242.1381927095000.13237.1390647868539@jira02.app.mwc.hst.phx2.redhat.com>


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

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

These issue are all related to what should be told about scope in CDI and what should be left to other spec. 
                
> Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1
> --------------------------------------------------------------------------------
>
>                 Key: CDI-405
>                 URL: https://issues.jboss.org/browse/CDI-405
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 04:37:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 04:37:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.13933.1390815448640@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-411:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge  (was: )

    
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> 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.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 04:41:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 04:41:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.13940.1390815689394@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-408:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:29:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:29:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations
 for Interceptor while setting bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501385.1380026051000.14028.1390818569310@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I think Option 1 in [~arnelim] comment should be chosen : {{@Interceptor}} and {{@Decorator}} should become bean defining annotation. We'll propbably extend the annotations list for bean defining annotation with CDI-406, so why not add these 2 as well ?
                
> adding  bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"
> -----------------------------------------------------------------------------------------------
>
>                 Key: CDI-404
>                 URL: https://issues.jboss.org/browse/CDI-404
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Tang Yong
>             Fix For: 1.2 Proposed
>
>
> [1] and [2] has reported an issue about
> bean-discovery-mode="annotated". Although there are some workarounds for
> the issue, I think that in the future, we should support interceptor
> implict scanning while an user uses bean-discovery-mode="annotated".
> Apparently, just as bean-discovery-mode="annotated", CDI Spec and
> Interceptor Spec are disconnected.
> [1]:https://java.net/jira/browse/GLASSFISH-20667
> [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7
> About detailed discussion, please seeing the following,
> https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:29:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:29:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations
 for Interceptor while setting bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501385.1380026051000.14032.1390818569630@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-404:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge  (was: )

    
> adding  bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"
> -----------------------------------------------------------------------------------------------
>
>                 Key: CDI-404
>                 URL: https://issues.jboss.org/browse/CDI-404
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Tang Yong
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> [1] and [2] has reported an issue about
> bean-discovery-mode="annotated". Although there are some workarounds for
> the issue, I think that in the future, we should support interceptor
> implict scanning while an user uses bean-discovery-mode="annotated".
> Apparently, just as bean-discovery-mode="annotated", CDI Spec and
> Interceptor Spec are disconnected.
> [1]:https://java.net/jira/browse/GLASSFISH-20667
> [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7
> About detailed discussion, please seeing the following,
> https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:33:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:33:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-401) Clarify the meaning of "bean class
 local view"
In-Reply-To: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500801.1379363355000.14049.1390818808550@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-401:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify the meaning of "bean class local view"
> ----------------------------------------------
>
>                 Key: CDI-401
>                 URL: https://issues.jboss.org/browse/CDI-401
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> 3.2.2 Bean types of a session bean:
> {quote}
> The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a *bean class local view*, the unrestricted set of bean types contains the bean class and all superclasses.
> ...
> {quote}
> AFAIK the EJB spec does not define anything like "bean class local view". I believe the CDI spec is referencing *No-Interface View* here (a variation of the local view that exposes the non-static public methods of the bean class without the use of a separate business interface).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:39:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:39:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.14062.1390819168614@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-398:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 05:43:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:43:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-397) Clarify Section 6.6.3 regarding
	singletons
In-Reply-To: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499414.1377587184000.14074.1390819408961@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-397:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify Section 6.6.3 regarding singletons
> ------------------------------------------
>
>                 Key: CDI-397
>                 URL: https://issues.jboss.org/browse/CDI-397
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Priority: Minor
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The section 6.6.3 Passivation capable dependencies states:
> {quote}
> all singleton beans are passivation capable dependencies
> {quote}
> Clearly the specification intents to address *singleton session beans* but the current wording does not make that explicit and users confuse this line and consider javax.inject.Singleton-scoped beans also to be passivation capable dependencies.
> The spec should instead say that:
> {quote}
> all singleton *session* beans are passivation capable dependencies
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:43:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:43:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.14080.1390819409220@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-392:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:47:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:47:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.14086.1390819648516@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-389:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 05:55:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:55:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-388) Session bean specialization
 example is not valid
In-Reply-To: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496123.1373466177000.14135.1390820128826@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-388:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> Session bean specialization example is not valid
> ------------------------------------------------
>
>                 Key: CDI-388
>                 URL: https://issues.jboss.org/browse/CDI-388
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:59:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 05:59:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-388) Session bean specialization
 example is not valid
In-Reply-To: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496123.1373466177000.14149.1390820368753@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-388:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: CDI_spec_chge)

    
> Session bean specialization example is not valid
> ------------------------------------------------
>
>                 Key: CDI-388
>                 URL: https://issues.jboss.org/browse/CDI-388
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 06:09:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 06:09:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-386) Two examples in section 5.2.4
 contradict the rules of the same section
In-Reply-To: <JIRA.12495865.1373240408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495865.1373240408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495865.1373240408000.14160.1390820968570@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Resolve with CDI-389
                
> Two examples in section 5.2.4 contradict the rules of the same section
> ----------------------------------------------------------------------
>
>                 Key: CDI-386
>                 URL: https://issues.jboss.org/browse/CDI-386
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Marko Luk?a
>             Fix For: 1.2 Proposed
>
>
> The examples in section 5.2.4 state that bean {{Dao<T extends Persistent>}} is eligible for injection into both {{Dao<Order>}} and {{Dao<User>}}, but according to the rules stated in the same section this isn't true.
> Also note that the spec doesn't state explicitly that {{Order extends Persistent}} and {{User extends Persistent}}. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 06:09:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 06:09:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-386) Two examples in section 5.2.4
 contradict the rules of the same section
In-Reply-To: <JIRA.12495865.1373240408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495865.1373240408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495865.1373240408000.14163.1390820968773@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-386:
-------------------------------------

    Labels: Ready_to_fix  (was: )

    
> Two examples in section 5.2.4 contradict the rules of the same section
> ----------------------------------------------------------------------
>
>                 Key: CDI-386
>                 URL: https://issues.jboss.org/browse/CDI-386
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Marko Luk?a
>              Labels: Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The examples in section 5.2.4 state that bean {{Dao<T extends Persistent>}} is eligible for injection into both {{Dao<Order>}} and {{Dao<User>}}, but according to the rules stated in the same section this isn't true.
> Also note that the spec doesn't state explicitly that {{Order extends Persistent}} and {{User extends Persistent}}. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 08:15:31 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 08:15:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not
 associated with the result of a producer method/field
In-Reply-To: <JIRA.12495301.1372409107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495301.1372409107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495301.1372409107000.14661.1390828531651@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-382:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify interceptors are not associated with the result of a producer method/field
> ----------------------------------------------------------------------------------
>
>                 Key: CDI-382
>                 URL: https://issues.jboss.org/browse/CDI-382
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.1.PFD
>            Reporter: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec.
> [1] https://github.com/cdi-spec/cdi/pull/110
> "Interceptors are not associated with the return value of a producer method or the current value of a producer field."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 08:19:32 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 08:19:32 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of
 Request Context
In-Reply-To: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494579.1371584449000.14740.1390828772180@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Javadoc should be updated to be more open
                
> Additional implementations of Request Context
> ---------------------------------------------
>
>                 Key: CDI-381
>                 URL: https://issues.jboss.org/browse/CDI-381
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Priority: Minor
>             Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that?  The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes.  It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 08:19:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 08:19:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of
 Request Context
In-Reply-To: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494579.1371584449000.14761.1390828773635@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-381:
-------------------------------------

    Labels: CDI_api_chge Ready_to_fix  (was: )

    
> Additional implementations of Request Context
> ---------------------------------------------
>
>                 Key: CDI-381
>                 URL: https://issues.jboss.org/browse/CDI-381
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that?  The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes.  It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:07:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:07:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-380) Clarify SessionScoped
In-Reply-To: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494577.1371584170000.15046.1390831649006@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-380:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify SessionScoped
> ---------------------
>
>                 Key: CDI-380
>                 URL: https://issues.jboss.org/browse/CDI-380
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Priority: Minor
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
>    - at the end of the servlet request, after the service() method, all
>      doFilter() methods, and all requestDestroyed() and onComplete()
>      notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items.  It's difficult to parse.  It would be clearer
> if it was written as a list.  And, like request scoped, it would be clearer
> if it described when the session scope/context is created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:09:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:09:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation
 processing problematic
In-Reply-To: <JIRA.12494334.1371230850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494334.1371230850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494334.1371230850000.15063.1390831769405@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-377:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge  (was: )

    
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
>                 Key: CDI-377
>                 URL: https://issues.jboss.org/browse/CDI-377
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.PFD
>         Environment: glassfish-4
>            Reporter: Reuben Pasquini
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container 
> results in CDI processing annotated classes intended for 
> app-managed injection.  See this ticket filed with guava for a concrete example:
>     https://code.google.com/p/guava-libraries/issues/detail?id=1433

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:11:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:11:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.15076.1390831888594@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-376:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge  (was: )

    
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> 1st is API git, 2nd is spec version:
> public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> They differ in the return type:
> ProducerFactory<X> vs
> ProducerFactory<? super X>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:17:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:17:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.15143.1390832250468@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-376:
-------------------------------------

    Description: 
return type differs between API and spec wording for both BeanManager#getProducerFactory methods.

In API we have
{{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}

While in spec (section 11.3.22 )we have 
{{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}

They differ in the return type:
{{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}


  was:
return type differs between API and spec wording for both BeanManager#getProducerFactory methods.

1st is API git, 2nd is spec version:

public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);

They differ in the return type:
ProducerFactory<X> vs
ProducerFactory<? super X>



    
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have 
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:19:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:19:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.15149.1390832368775@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I propose to correct the Spec to conform API. It should have less impact.
                
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have 
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:19:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:19:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.15152.1390832368832@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-376:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge Ready_to_fix  (was: CDI_api_chge CDI_spec_chge)

    
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have 
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:23:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:23:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.15157.1390832608887@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-372:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 09:27:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:27:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.15171.1390832848508@jira02.app.mwc.hst.phx2.redhat.com>


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

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

The notion of Bean Archive is introduce in Chapter 12, we should do an introduction before.In section 2.5 we introduce the notion of bean defining annotation, we should more clearly explain what is the purpose of this concept. Now we only have a link to section 12.1.
                
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 09:29:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:29:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.15177.1390832969241@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-320:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: )

    
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 09:37:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:37:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.15235.1390833448955@jira02.app.mwc.hst.phx2.redhat.com>


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

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

We have to change the wording to avoid this confusion.
                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 09:51:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:51:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear
 on any supertype
In-Reply-To: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483212.1358931161000.15369.1390834289937@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-318:
-------------------------------------

    Labels: CDI_api_chge  (was: )

    
> @WithAnnotations types can appear on any supertype
> --------------------------------------------------
>
>                 Key: CDI-318
>                 URL: https://issues.jboss.org/browse/CDI-318
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: CDI_api_chge
>             Fix For: 1.2 Proposed
>
>
> Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only.
> Is there any special use-case for this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:51:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:51:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear
 on any supertype
In-Reply-To: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483212.1358931161000.15373.1390834290200@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Javadoc in API should be corrected to day the same than spec
                
> @WithAnnotations types can appear on any supertype
> --------------------------------------------------
>
>                 Key: CDI-318
>                 URL: https://issues.jboss.org/browse/CDI-318
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: CDI_api_chge
>             Fix For: 1.2 Proposed
>
>
> Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only.
> Is there any special use-case for this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:51:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:51:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear
 on any supertype
In-Reply-To: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483212.1358931161000.15375.1390834290272@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-318:
-------------------------------------

    Labels: CDI_api_chge Ready_to_fix  (was: CDI_api_chge)

    
> @WithAnnotations types can appear on any supertype
> --------------------------------------------------
>
>                 Key: CDI-318
>                 URL: https://issues.jboss.org/browse/CDI-318
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only.
> Is there any special use-case for this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:53:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:53:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.15379.1390834408610@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-280:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:55:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 09:55:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.15381.1390834528624@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Don't forget references to EJB Bean which should be indicated as Session Bean
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:19:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 27 Jan 2014 10:19: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@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.15515.1390835969901@jira02.app.mwc.hst.phx2.redhat.com>


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

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

This should be clarified with resolution of CD-280.
Regarding Specialization how does this code behave today in Weld and OWB. I hope it's not accepted
                
> 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
>             Fix For: 1.2 Proposed
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Antoine Sabot-Durand updated CDI-220:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> 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
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Jan 28 03:31:07 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 28 Jan 2014 09:31:07 +0100
Subject: [cdi-dev] yesterday meeting
Message-ID: <2DE5AFDE-5E3A-4413-A1E6-8B10E16C71BA@sabot-durand.net>

Hi all,

For those who weren?t at the meeting yesterday. You??l find the transcript here [1] and a sumup of different topic here : [2].

My proposed list of issue ready to be assigned is here [3]. You'll have until tomorrow 5:00pm GMT to send me objections.

In the meantime you can start choosing tasks you?d like to fulfill and ask or assignment on the ML.

I?ll be reachable on IRC or here if you have questions.

Antoine 



[1] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-01-27-16.54.log.html
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-01-27-16.54.html

From issues at jboss.org  Tue Jan 28 05:01:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 05:01:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.17296.1390903288526@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-398:
-------------------------------------

The CDI_tck_chge flag should be added - tests for this assertion will need to be added to the TCK.
                
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 28 05:09:28 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 28 Jan 2014 05:09:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.17311.1390903768909@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-398:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix  (was: CDI_spec_chge Ready_to_fix)

    
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 28 05:09:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 28 Jan 2014 05:09:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.17313.1390903769004@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Done [~jharting], but don't be shy : you're the TCK specialist her ;).
                
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 28 05:23:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 28 Jan 2014 05:23:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.17371.1390904609566@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-398 at 1/28/14 5:22 AM:
-------------------------------------------------------------------

Done [~jharting], but don't be shy : you're the TCK specialist here ;).
                
      was (Author: antoinesabot-durand):
    Done [~jharting], but don't be shy : you're the TCK specialist her ;).
                  
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jharting at redhat.com  Tue Jan 28 06:13:13 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 28 Jan 2014 12:13:13 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
Message-ID: <52E790C9.5030001@redhat.com>

Hi all,

as many of you know already, Weld 2.2 is going to be the reference 
implementation of the upcoming maintenance release of the CDI specification.

CDI is an EE specification. That implies that the CDI TCK which 
validates a CDI implementation has to be run against an EE container not 
just the CDI implementation itself (e.g. Weld Core).

So far, both existing releases of CDI (1.0 and 1.1) were always part of 
a major Java EE release (6 and 7). It therefore made sense to require 
the CDI RI to run as part of the GlassFish application server since 
GlassFish is the RI for each recent Java EE version.

However, with CDI 1.2 the situation is different. Since CDI 1.2 is not 
part of a major Java EE release, we see no reason to require the CDI 1.2 
RI to run specifically on GlassFish at the end of the maintenance 
release window. Instead, any Java EE 7 certified application server 
should be suitable. Therefore, we are going to use WildFly 
(http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.

Note that this by no means defines which Java EE servers will or will 
not support CDI 1.2. This proposal only defines which Java EE server 
will be used at the end of the CDI 1.2 MR effort to validate the RI and 
the TCK.

Regards,

Jozef

From rmannibucau at gmail.com  Tue Jan 28 07:36:15 2014
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 28 Jan 2014 13:36:15 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <52E790C9.5030001@redhat.com>
References: <52E790C9.5030001@redhat.com>
Message-ID: <CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>

Hi

I think it should still run on GlassFish to try to ensure
compatibility with previous version (at least). We all know
integration is where the most issues are.

wdyt?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-01-28 Jozef Hartinger <jharting at redhat.com>:
> Hi all,
>
> as many of you know already, Weld 2.2 is going to be the reference
> implementation of the upcoming maintenance release of the CDI specification.
>
> CDI is an EE specification. That implies that the CDI TCK which
> validates a CDI implementation has to be run against an EE container not
> just the CDI implementation itself (e.g. Weld Core).
>
> So far, both existing releases of CDI (1.0 and 1.1) were always part of
> a major Java EE release (6 and 7). It therefore made sense to require
> the CDI RI to run as part of the GlassFish application server since
> GlassFish is the RI for each recent Java EE version.
>
> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not
> part of a major Java EE release, we see no reason to require the CDI 1.2
> RI to run specifically on GlassFish at the end of the maintenance
> release window. Instead, any Java EE 7 certified application server
> should be suitable. Therefore, we are going to use WildFly
> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.
>
> Note that this by no means defines which Java EE servers will or will
> not support CDI 1.2. This proposal only defines which Java EE server
> will be used at the end of the CDI 1.2 MR effort to validate the RI and
> the TCK.
>
> Regards,
>
> Jozef
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

From antoine at sabot-durand.net  Tue Jan 28 08:28:31 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 28 Jan 2014 14:28:31 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
Message-ID: <74200111-D672-4FF9-BDC3-F1BCC1CD0F72@sabot-durand.net>

Romain,

I think what Jozef meant is that JCP MR process doesn?t force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that.
So there are too many parameters we don?t control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that?s why Jozef made this proposal.
Off course we?ll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky.
Now that can be discussed if a GF developer is reading this message and raise the Hand?

Antoine


[1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey


Le 28 janv. 2014 ? 13:36, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :

> Hi
> 
> I think it should still run on GlassFish to try to ensure
> compatibility with previous version (at least). We all know
> integration is where the most issues are.
> 
> wdyt?
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 
> 2014-01-28 Jozef Hartinger <jharting at redhat.com>:
>> Hi all,
>> 
>> as many of you know already, Weld 2.2 is going to be the reference
>> implementation of the upcoming maintenance release of the CDI specification.
>> 
>> CDI is an EE specification. That implies that the CDI TCK which
>> validates a CDI implementation has to be run against an EE container not
>> just the CDI implementation itself (e.g. Weld Core).
>> 
>> So far, both existing releases of CDI (1.0 and 1.1) were always part of
>> a major Java EE release (6 and 7). It therefore made sense to require
>> the CDI RI to run as part of the GlassFish application server since
>> GlassFish is the RI for each recent Java EE version.
>> 
>> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not
>> part of a major Java EE release, we see no reason to require the CDI 1.2
>> RI to run specifically on GlassFish at the end of the maintenance
>> release window. Instead, any Java EE 7 certified application server
>> should be suitable. Therefore, we are going to use WildFly
>> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.
>> 
>> Note that this by no means defines which Java EE servers will or will
>> not support CDI 1.2. This proposal only defines which Java EE server
>> will be used at the end of the CDI 1.2 MR effort to validate the RI and
>> the TCK.
>> 
>> Regards,
>> 
>> Jozef
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From rmannibucau at gmail.com  Tue Jan 28 08:34:27 2014
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 28 Jan 2014 14:34:27 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <74200111-D672-4FF9-BDC3-F1BCC1CD0F72@sabot-durand.net>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
	<74200111-D672-4FF9-BDC3-F1BCC1CD0F72@sabot-durand.net>
Message-ID: <CACLE=7MR+BmA7GGeqXQNjBGpmwA5tD61g9knB-28oL2AWOMgeg@mail.gmail.com>

I got the point but I really think we shoudln't change the RI default
Integration before 2.0. That said you are right if GF doesn't care and
is not able to follow the release just forget my comment.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-01-28 Antoine Sabot-Durand <antoine at sabot-durand.net>:
> Romain,
>
> I think what Jozef meant is that JCP MR process doesn't force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that.
> So there are too many parameters we don't control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that's why Jozef made this proposal.
> Off course we'll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky.
> Now that can be discussed if a GF developer is reading this message and raise the Hand...
>
> Antoine
>
>
> [1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey
>
>
> Le 28 janv. 2014 ? 13:36, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :
>
>> Hi
>>
>> I think it should still run on GlassFish to try to ensure
>> compatibility with previous version (at least). We all know
>> integration is where the most issues are.
>>
>> wdyt?
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-01-28 Jozef Hartinger <jharting at redhat.com>:
>>> Hi all,
>>>
>>> as many of you know already, Weld 2.2 is going to be the reference
>>> implementation of the upcoming maintenance release of the CDI specification.
>>>
>>> CDI is an EE specification. That implies that the CDI TCK which
>>> validates a CDI implementation has to be run against an EE container not
>>> just the CDI implementation itself (e.g. Weld Core).
>>>
>>> So far, both existing releases of CDI (1.0 and 1.1) were always part of
>>> a major Java EE release (6 and 7). It therefore made sense to require
>>> the CDI RI to run as part of the GlassFish application server since
>>> GlassFish is the RI for each recent Java EE version.
>>>
>>> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not
>>> part of a major Java EE release, we see no reason to require the CDI 1.2
>>> RI to run specifically on GlassFish at the end of the maintenance
>>> release window. Instead, any Java EE 7 certified application server
>>> should be suitable. Therefore, we are going to use WildFly
>>> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.
>>>
>>> Note that this by no means defines which Java EE servers will or will
>>> not support CDI 1.2. This proposal only defines which Java EE server
>>> will be used at the end of the CDI 1.2 MR effort to validate the RI and
>>> the TCK.
>>>
>>> Regards,
>>>
>>> Jozef
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>


From issues at jboss.org  Tue Jan 28 08:39:28 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 28 Jan 2014 08:39:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations
 for Interceptor while setting bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501385.1380026051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501385.1380026051000.17882.1390916368963@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-404:
-------------------------------

+1 for Option 1
                
> adding  bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"
> -----------------------------------------------------------------------------------------------
>
>                 Key: CDI-404
>                 URL: https://issues.jboss.org/browse/CDI-404
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Tang Yong
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> [1] and [2] has reported an issue about
> bean-discovery-mode="annotated". Although there are some workarounds for
> the issue, I think that in the future, we should support interceptor
> implict scanning while an user uses bean-discovery-mode="annotated".
> Apparently, just as bean-discovery-mode="annotated", CDI Spec and
> Interceptor Spec are disconnected.
> [1]:https://java.net/jira/browse/GLASSFISH-20667
> [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7
> About detailed discussion, please seeing the following,
> https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Jan 28 08:43:51 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 28 Jan 2014 14:43:51 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <CACLE=7MR+BmA7GGeqXQNjBGpmwA5tD61g9knB-28oL2AWOMgeg@mail.gmail.com>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
	<74200111-D672-4FF9-BDC3-F1BCC1CD0F72@sabot-durand.net>
	<CACLE=7MR+BmA7GGeqXQNjBGpmwA5tD61g9knB-28oL2AWOMgeg@mail.gmail.com>
Message-ID: <B28B0BD6-0AF6-4E94-8D26-BD08A3BC0C8F@sabot-durand.net>

No problem Romain,

To be honest I?m far more interested by putting work effort on having the TCK running on your coming OWB release in TomEE than validating twice Weld on WF and GF. Off course this comment is totally outside MR scope ;).

Antoine 


Le 28 janv. 2014 ? 14:34, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :

> I got the point but I really think we shoudln't change the RI default
> Integration before 2.0. That said you are right if GF doesn't care and
> is not able to follow the release just forget my comment.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
> 
> 
> 
> 2014-01-28 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>> Romain,
>> 
>> I think what Jozef meant is that JCP MR process doesn't force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that.
>> So there are too many parameters we don't control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that's why Jozef made this proposal.
>> Off course we'll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky.
>> Now that can be discussed if a GF developer is reading this message and raise the Hand...
>> 
>> Antoine
>> 
>> 
>> [1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey
>> 
>> 
>> Le 28 janv. 2014 ? 13:36, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :
>> 
>>> Hi
>>> 
>>> I think it should still run on GlassFish to try to ensure
>>> compatibility with previous version (at least). We all know
>>> integration is where the most issues are.
>>> 
>>> wdyt?
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>> 
>>> 
>>> 
>>> 2014-01-28 Jozef Hartinger <jharting at redhat.com>:
>>>> Hi all,
>>>> 
>>>> as many of you know already, Weld 2.2 is going to be the reference
>>>> implementation of the upcoming maintenance release of the CDI specification.
>>>> 
>>>> CDI is an EE specification. That implies that the CDI TCK which
>>>> validates a CDI implementation has to be run against an EE container not
>>>> just the CDI implementation itself (e.g. Weld Core).
>>>> 
>>>> So far, both existing releases of CDI (1.0 and 1.1) were always part of
>>>> a major Java EE release (6 and 7). It therefore made sense to require
>>>> the CDI RI to run as part of the GlassFish application server since
>>>> GlassFish is the RI for each recent Java EE version.
>>>> 
>>>> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not
>>>> part of a major Java EE release, we see no reason to require the CDI 1.2
>>>> RI to run specifically on GlassFish at the end of the maintenance
>>>> release window. Instead, any Java EE 7 certified application server
>>>> should be suitable. Therefore, we are going to use WildFly
>>>> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.
>>>> 
>>>> Note that this by no means defines which Java EE servers will or will
>>>> not support CDI 1.2. This proposal only defines which Java EE server
>>>> will be used at the end of the CDI 1.2 MR effort to validate the RI and
>>>> the TCK.
>>>> 
>>>> Regards,
>>>> 
>>>> Jozef
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 



From rmannibucau at gmail.com  Tue Jan 28 08:49:18 2014
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 28 Jan 2014 14:49:18 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <B28B0BD6-0AF6-4E94-8D26-BD08A3BC0C8F@sabot-durand.net>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
	<74200111-D672-4FF9-BDC3-F1BCC1CD0F72@sabot-durand.net>
	<CACLE=7MR+BmA7GGeqXQNjBGpmwA5tD61g9knB-28oL2AWOMgeg@mail.gmail.com>
	<B28B0BD6-0AF6-4E94-8D26-BD08A3BC0C8F@sabot-durand.net>
Message-ID: <CACLE=7M08-m=pKVZCvSdqJ+c8Ruo-gW-F4unGnrpo6bcbn5V-Q@mail.gmail.com>

Me too but i'm concernend getting EE stack as stable as possible to
avoid bad comments for nothing
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-01-28 Antoine Sabot-Durand <antoine at sabot-durand.net>:
> No problem Romain,
>
> To be honest I'm far more interested by putting work effort on having the TCK running on your coming OWB release in TomEE than validating twice Weld on WF and GF. Off course this comment is totally outside MR scope ;).
>
> Antoine
>
>
> Le 28 janv. 2014 ? 14:34, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :
>
>> I got the point but I really think we shoudln't change the RI default
>> Integration before 2.0. That said you are right if GF doesn't care and
>> is not able to follow the release just forget my comment.
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-01-28 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>>> Romain,
>>>
>>> I think what Jozef meant is that JCP MR process doesn't force us to provide Glassfish integration on the scope of the MR. Right now Glassfish integrates Weld 2.0.0.SP1 and Oracle has a nightly build with Weld 2.0.5 [1]. Working on Weld 2.1 and 2.2 integration could be quite time consuming especially if Glassfish people are not available to help us on that.
>>> So there are too many parameters we don't control to take the risk of adding this constraint in our 60 days MR. What we control on JBoss side is Wildfly integration so that's why Jozef made this proposal.
>>> Off course we'll do the necessary and help GF developers to integrates Weld 2.2 in GF but taking it in our agenda is quite risky.
>>> Now that can be discussed if a GF developer is reading this message and raise the Hand...
>>>
>>> Antoine
>>>
>>>
>>> [1] https://blogs.oracle.com/theaquarium/entry/using_updated_release_of_jersey
>>>
>>>
>>> Le 28 janv. 2014 ? 13:36, Romain Manni-Bucau <rmannibucau at gmail.com> a ?crit :
>>>
>>>> Hi
>>>>
>>>> I think it should still run on GlassFish to try to ensure
>>>> compatibility with previous version (at least). We all know
>>>> integration is where the most issues are.
>>>>
>>>> wdyt?
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2014-01-28 Jozef Hartinger <jharting at redhat.com>:
>>>>> Hi all,
>>>>>
>>>>> as many of you know already, Weld 2.2 is going to be the reference
>>>>> implementation of the upcoming maintenance release of the CDI specification.
>>>>>
>>>>> CDI is an EE specification. That implies that the CDI TCK which
>>>>> validates a CDI implementation has to be run against an EE container not
>>>>> just the CDI implementation itself (e.g. Weld Core).
>>>>>
>>>>> So far, both existing releases of CDI (1.0 and 1.1) were always part of
>>>>> a major Java EE release (6 and 7). It therefore made sense to require
>>>>> the CDI RI to run as part of the GlassFish application server since
>>>>> GlassFish is the RI for each recent Java EE version.
>>>>>
>>>>> However, with CDI 1.2 the situation is different. Since CDI 1.2 is not
>>>>> part of a major Java EE release, we see no reason to require the CDI 1.2
>>>>> RI to run specifically on GlassFish at the end of the maintenance
>>>>> release window. Instead, any Java EE 7 certified application server
>>>>> should be suitable. Therefore, we are going to use WildFly
>>>>> (http://wildfly.org/) as the runtime for CDI 1.2 RI and TCK.
>>>>>
>>>>> Note that this by no means defines which Java EE servers will or will
>>>>> not support CDI 1.2. This proposal only defines which Java EE server
>>>>> will be used at the end of the CDI 1.2 MR effort to validate the RI and
>>>>> the TCK.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jozef
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>


From jharting at redhat.com  Wed Jan 29 04:00:30 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 29 Jan 2014 10:00:30 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
Message-ID: <52E8C32E.9050400@redhat.com>

It's not a question of whether we run or GlassFish or not but rather when.

On 01/28/2014 01:36 PM, Romain Manni-Bucau wrote:
> Hi
>
> I think it should still run on GlassFish to try to ensure
> compatibility with previous version (at least). We all know
> integration is where the most issues are.
>
> wdyt?
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>

From antoine at sabot-durand.net  Wed Jan 29 04:05:26 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 29 Jan 2014 10:05:26 +0100
Subject: [cdi-dev] CDI 1.2 Implementation
In-Reply-To: <52E8C32E.9050400@redhat.com>
References: <52E790C9.5030001@redhat.com>
	<CACLE=7M+kjErv3PwxBb_wD46YFovqY9gc-xFF4bmBndTv__DhQ@mail.gmail.com>
	<52E8C32E.9050400@redhat.com>
Message-ID: <E06199B4-7F82-452D-BD44-FA27492414B3@sabot-durand.net>

I couldn?t have summarized this better ;)

Antoine

Le 29 janv. 2014 ? 10:00, Jozef Hartinger <jharting at redhat.com> a ?crit :

> It's not a question of whether we run or GlassFish or not but rather when.
> 
> On 01/28/2014 01:36 PM, Romain Manni-Bucau wrote:
>> Hi
>> 
>> I think it should still run on GlassFish to try to ensure
>> compatibility with previous version (at least). We all know
>> integration is where the most issues are.
>> 
>> wdyt?
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>> 
>> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From issues at jboss.org  Wed Jan 29 11:29:28 2014
From: issues at jboss.org (Michel Graciano (JIRA))
Date: Wed, 29 Jan 2014 11:29:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-416) Typo for @PersistencContext at
	section 7.3.6
In-Reply-To: <JIRA.12530657.1391012887995@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530657.1391012887995@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530657.1391012887995.21186.1391012968425@jira02.app.mwc.hst.phx2.redhat.com>

Michel Graciano created CDI-416:
-----------------------------------

             Summary: Typo for @PersistencContext at section 7.3.6
                 Key: CDI-416
                 URL: https://issues.jboss.org/browse/CDI-416
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 1.1.PFD
            Reporter: Michel Graciano
            Priority: Minor


At section 7.3.6 [1] there is a type for @PersistencContext where it should be @PersistenceContext.

[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 11:33:29 2014
From: issues at jboss.org (Michel Graciano (JIRA))
Date: Wed, 29 Jan 2014 11:33:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-416) Typo for @PersistencContext at
	section 7.3.6
In-Reply-To: <JIRA.12530657.1391012887000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530657.1391012887000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530657.1391012887000.21204.1391013209316@jira02.app.mwc.hst.phx2.redhat.com>


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

Michel Graciano updated CDI-416:
--------------------------------

    Description: 
At section 7.3.6 [1] there is a typo for @PersistencContext where it should be @PersistenceContext.

[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle

  was:
At section 7.3.6 [1] there is a type for @PersistencContext where it should be @PersistenceContext.

[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle


    
> Typo for @PersistencContext at section 7.3.6
> --------------------------------------------
>
>                 Key: CDI-416
>                 URL: https://issues.jboss.org/browse/CDI-416
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Michel Graciano
>            Priority: Minor
>
> At section 7.3.6 [1] there is a typo for @PersistencContext where it should be @PersistenceContext.
> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Thu Jan 30 08:20:08 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 30 Jan 2014 14:20:08 +0100
Subject: [cdi-dev] Time for homework picking
Message-ID: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net>

Hi guys,

We've got a bunch of task ready to be fixed. So if you can/want, it?s time to pick a ticket. I?ve built a list of unassigned task ready to be fixed [1].
So make your choice by assigning the ticket to you or by asking me.
Don?t forget the workflow we approved on monday

Regards,

Antoine



[1] : https://issues.jboss.org/browse/CDI-410?filter=12320805

From mkouba at redhat.com  Thu Jan 30 08:49:10 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 30 Jan 2014 14:49:10 +0100
Subject: [cdi-dev] Time for homework picking
In-Reply-To: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net>
References: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net>
Message-ID: <52EA5856.7030405@redhat.com>

Hi,

I've taken CDI-382 and CDI-318.

M

Dne 30.1.2014 14:20, Antoine Sabot-Durand napsal(a):
> Hi guys,
> 
> We've got a bunch of task ready to be fixed. So if you can/want, it?s time to pick a ticket. I?ve built a list of unassigned task ready to be fixed [1].
> So make your choice by assigning the ticket to you or by asking me.
> Don?t forget the workflow we approved on monday
> 
> Regards,
> 
> Antoine
> 
> 
> 
> [1] : https://issues.jboss.org/browse/CDI-410?filter=12320805
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

From issues at jboss.org  Thu Jan 30 08:49:28 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 30 Jan 2014 08:49:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not
 associated with the result of a producer method/field
In-Reply-To: <JIRA.12495301.1372409107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495301.1372409107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495301.1372409107000.22979.1391089768565@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba reassigned CDI-382:
--------------------------------

    Assignee: Martin Kouba

    
> Clarify interceptors are not associated with the result of a producer method/field
> ----------------------------------------------------------------------------------
>
>                 Key: CDI-382
>                 URL: https://issues.jboss.org/browse/CDI-382
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Interceptors
>    Affects Versions: 1.1.PFD
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec.
> [1] https://github.com/cdi-spec/cdi/pull/110
> "Interceptors are not associated with the return value of a producer method or the current value of a producer field."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 08:49:28 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 30 Jan 2014 08:49:28 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear
 on any supertype
In-Reply-To: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483212.1358931161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483212.1358931161000.22978.1391089768529@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba reassigned CDI-318:
--------------------------------

    Assignee: Martin Kouba

    
> @WithAnnotations types can appear on any supertype
> --------------------------------------------------
>
>                 Key: CDI-318
>                 URL: https://issues.jboss.org/browse/CDI-318
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only.
> Is there any special use-case for this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Thu Jan 30 09:25:00 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 30 Jan 2014 15:25:00 +0100
Subject: [cdi-dev] Time for homework picking
In-Reply-To: <52EA5856.7030405@redhat.com>
References: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net>
	<52EA5856.7030405@redhat.com>
Message-ID: <F5C66A5B-CC02-4743-92E1-86E2F9862A05@sabot-durand.net>

Great Martin.

Taking CDI-413 and CDI-389

Antoine


Le 30 janv. 2014 ? 14:49, Martin Kouba <mkouba at redhat.com> a ?crit :

> Hi,
> 
> I've taken CDI-382 and CDI-318.
> 
> M
> 
> Dne 30.1.2014 14:20, Antoine Sabot-Durand napsal(a):
>> Hi guys,
>> 
>> We've got a bunch of task ready to be fixed. So if you can/want, it?s time to pick a ticket. I?ve built a list of unassigned task ready to be fixed [1].
>> So make your choice by assigning the ticket to you or by asking me.
>> Don?t forget the workflow we approved on monday
>> 
>> Regards,
>> 
>> Antoine
>> 
>> 
>> 
>> [1] : https://issues.jboss.org/browse/CDI-410?filter=12320805
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 



From issues at jboss.org  Thu Jan 30 09:25:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 09:25:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23087.1391091930116@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-389:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:25:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:25:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23445.1391099129064@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-389 started by Antoine Sabot-Durand.

> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:37:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:37:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23470.1391099849213@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand closed CDI-389.
------------------------------------

    Resolution: Unresolved

    
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:37:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:37:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23472.1391099849310@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Made change in asciidoc file
                
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:51:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:51:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23543.1391100689978@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reopened CDI-389:
--------------------------------------


    
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:51:30 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:51:30 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23549.1391100690541@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-389 started by Antoine Sabot-Durand.

> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 11:53:29 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 30 Jan 2014 11:53:29 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85
In-Reply-To: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496664.1374053576000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496664.1374053576000.23564.1391100809256@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-389:
-------------------------------------

    Git Pull Request: https://github.com/cdi-spec/cdi/pull/198

    
> Revert CDI-85
> -------------
>
>                 Key: CDI-389
>                 URL: https://issues.jboss.org/browse/CDI-389
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to 
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From antoine at sabot-durand.net  Thu Jan 30 11:56:26 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 30 Jan 2014 17:56:26 +0100
Subject: [cdi-dev] PR for CDI-389 resolution
Message-ID: <1F6CA3A3-6414-4DBA-9932-9BEB5119EFF4@sabot-durand.net>


Please review PR https://github.com/cdi-spec/cdi/pull/198 for CD-389 [1] resolution

Antoine

[1] https://issues.jboss.org/browse/CDI-389

From issues at jboss.org  Fri Jan 31 09:15:31 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 31 Jan 2014 09:15:31 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-417) SessionContext active during
 HttpSessionActivationListener events
In-Reply-To: <JIRA.12530899.1391177693579@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530899.1391177693579@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530899.1391177693579.25775.1391177731021@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Remes created CDI-417:
-------------------------------

             Summary: SessionContext active during HttpSessionActivationListener events
                 Key: CDI-417
                 URL: https://issues.jboss.org/browse/CDI-417
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


I'd expect SessionScoped to be active also during javax.servlet.http.HttpSessionActivationListener (and there could be likely some more candidates) events. Reproducer is available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/servlet/session-activation-listener. Does it make sense?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From struberg at yahoo.de  Fri Jan 31 15:07:49 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 31 Jan 2014 20:07:49 +0000 (GMT)
Subject: [cdi-dev] exclude rules questions
Message-ID: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com>



Hi!

A few questions regarding exclude rules

1.) does .* mean only the package, but no sub-packages. Whereas .** also includes sub-packages?
Marek brought up another interesting note: com.foo.** would according to the wording also exclude com.foobar... Is that intended?


2.) Are multiple children allowed in an exclude rule in beans.xml?
There is a funny example in the spec:

<exclude name="com.acme.ejb.**"> 

? <if-class-available name="javax.enterprise.inject.Model"/> 

? <if-system-property name="exclude-ejbs"/> 
</exclude> 


But I could not find the explanation what should happen. The if-class-available is nowhere stated. Or did I overlook it?

txs and LieGrue,
strub