<div dir="ltr"><div><div><div>Martin,<br><br></div>Thanks for pointing that out. Have to try it on GitHub, e.g. issues or elsewhere. I used quoting individual users before on many cases.<br><br></div>However, CDI uses JIRA at JBoss, so not sure, if this would work there, too?<br></div>It does in the GitHub issue tracker. PRs if there's more discussion there might work, but maybe not the issue tracker, or do we have an EG group there, too?<br><div><div><div><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0px;border-collapse:collapse"><font size="1" face="arial, helvetica, sans-serif"><span lang="EN-US">Werner </span></font><br></p><span lang="EN-GB"><div style="font-family:arial,helvetica,sans-serif"><br></div></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Oct 19, 2016 at 10:22 AM, <span dir="ltr"><<a href="mailto:cdi-dev-request@lists.jboss.org" target="_blank">cdi-dev-request@lists.jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cdi-dev mailing list submissions to<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cdi-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Spliting SE package in an independent jar (Werner Keil)<br>
2. Team mentions on github (Martin Kouba)<br>
3. [JBoss JIRA] (CDI-625) When exactly are events with<br>
@Initialized(X.class) and @Destroyed(X.class) qualifiers fired<br>
(Martin Kouba (JIRA))<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 18 Oct 2016 15:29:39 +0200<br>
From: Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
Subject: Re: [cdi-dev] Spliting SE package in an independent jar<br>
To: John Ament <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a>><br>
Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID:<br>
<<a href="mailto:CAAGawe1UavyR9qv0iOLCBHpXpuVzMcrBfDL_-bcu2deA9MZNGQ@mail.gmail.com">CAAGawe1UavyR9qv0iOLCBHpXpuVz<wbr>McrBfDL_-bcu2deA9MZNGQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Meaning SE API adds stuff to what EE already needs not sub-setting it, so<br>
you end up with more interfaces on SE than EE.<br>
<br>
If the additional SE JAR is simply for bootstrapping on SE, that's<br>
understandable, but it does not meet the idea of<br>
<br>
>5. Define a lightweight container, which takes the annotations specified<br>
by the @Inject specification, defines the behaviour of the container (which<br>
@Inject failed to do), and adds a couple of popular features from CDI such<br>
as producer >methods. This will allow much wider adoption of CDI in the<br>
Java world, and provide a great stepping stone between Java SE, a servlet<br>
container, OSGi and a full Java EE server.<br>
from the proposal.<br>
<br>
Was that found out of scope or not doable in CDI 2?<br>
<br>
Having 2 JARs where EE only nees one is not what I would consider<br>
"lightweight".<br>
<br>
Werner<br>
<br>
<br>
On Tue, Oct 18, 2016 at 3:23 PM, John Ament <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a>><br>
wrote:<br>
<br>
> Thats why cdi-se-api depends on cdi-api.<br>
><br>
><br>
> ------------------------------<br>
> *From:* Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
> *Sent:* Tuesday, October 18, 2016 6:37 AM<br>
> *To:* John Ament<br>
> *Cc:* cdi-dev<br>
><br>
> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar<br>
><br>
> Yes, but on SE you can't just use the "cdi-se-api" on its own.<br>
><br>
> So SE on the API level needs 2 JARs not just one. That's what I mean.<br>
> I trust the sum of all JARs for an implementation would be somewhat<br>
> smaller on SE, otherwise the "Micro" idea of using a self-executable or<br>
> "Fat" JAR in those places would be ad-absurdum, if you end up with a "Fat<br>
> JAR" that's bigger than most existing app servers;-)<br>
><br>
> I would have expected a<br>
> core-api<br>
> se-api<br>
> ee-api<br>
><br>
> kind of setup, but if it won't blow implementations on the SE side, I also<br>
> understand that.<br>
><br>
> Werner<br>
><br>
><br>
> On Tue, Oct 18, 2016 at 12:19 PM, John Ament <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a><br>
> > wrote:<br>
><br>
>> Opposite Werner, EE API is larger and has the bulk of the content. SE<br>
>> API at this point has two classes.<br>
>><br>
>><br>
>> ------------------------------<br>
>> *From:* <a href="mailto:cdi-dev-bounces@lists.jboss.org">cdi-dev-bounces@lists.jboss.<wbr>org</a> <<a href="mailto:cdi-dev-bounces@lists.jboss.org">cdi-dev-bounces@lists.jboss.<wbr>org</a>><br>
>> on behalf of Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
>> *Sent:* Tuesday, October 18, 2016 5:27 AM<br>
>> *To:* cdi-dev<br>
>><br>
>> *Subject:* Re: [cdi-dev] Spliting SE package in an independent jar<br>
>><br>
>> So cdi-se-api is larger than the (core) EE API?<br>
>><br>
>> An SE implementation should hopefully have a smaller footprint than<br>
>> current EE ones (e.g. Weld)?<br>
>><br>
>> Werner<br>
>><br>
>><br>
>> On Tue, Oct 18, 2016 at 11:09 AM, <<a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.<wbr>org</a>><br>
>> wrote:<br>
>><br>
>>> Send cdi-dev mailing list submissions to<br>
>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>><br>
>>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
>>> or, via email, send a message with subject or body 'help' to<br>
>>> <a href="mailto:cdi-dev-request@lists.jboss.org">cdi-dev-request@lists.jboss.<wbr>org</a><br>
>>><br>
>>> You can reach the person managing the list at<br>
>>> <a href="mailto:cdi-dev-owner@lists.jboss.org">cdi-dev-owner@lists.jboss.org</a><br>
>>><br>
>>> When replying, please edit your Subject line so it is more specific<br>
>>> than "Re: Contents of cdi-dev digest..."<br>
>>><br>
>>><br>
>>> Today's Topics:<br>
>>><br>
>>> 1. Re: Spliting SE package in an independent jar (Martin Kouba)<br>
>>> 2. [JBoss JIRA] (CDI-45) Optional Injection Points<br>
>>> (Martin Kouba (JIRA))<br>
>>> 3. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0<br>
>>> (Antoine Sabot-Durand (JIRA))<br>
>>> 4. [JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0<br>
>>> (Antoine Sabot-Durand (JIRA))<br>
>>> 5. No meeting tomorrow (Antoine Sabot-Durand)<br>
>>> 6. Re: Spliting SE package in an independent jar (Emily Jiang)<br>
>>><br>
>>><br>
>>> ------------------------------<wbr>------------------------------<wbr>----------<br>
>>><br>
>>> Message: 1<br>
>>> Date: Thu, 13 Oct 2016 09:56:24 +0200<br>
>>> From: Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
>>> Subject: Re: [cdi-dev] Spliting SE package in an independent jar<br>
>>> To: John Ament <<a href="mailto:john.ament@spartasystems.com">john.ament@spartasystems.com</a>><wbr>, Antoine Sabot-Durand<br>
>>> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>, cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> ><br>
>>> Message-ID: <<a href="mailto:616fdc4e-26f6-a8d7-16d3-fdceb71faa1f@redhat.com">616fdc4e-26f6-a8d7-16d3-<wbr>fdceb71faa1f@redhat.com</a>><br>
>>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>
>>><br>
>>> +1 for John's proposal.<br>
>>><br>
>>> So there will be two API artifacts:<br>
>>> * cdi-api<br>
>>> * cdi-se-api (depends on cdi-api)<br>
>>><br>
>>> Martin<br>
>>><br>
>>> Dne 12.10.2016 v 12:40 John Ament napsal(a):<br>
>>> > the way I've envisioned it:<br>
>>> ><br>
>>> ><br>
>>> > - There is no dedicated EE API (none that I could find that is EE only,<br>
>>> > except for perhaps session scoped)t<br>
>>> ><br>
>>> > - There is SE specific API and the current API could be considered<br>
>>> "core"<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Take the current API module and create two submodules, one for core and<br>
>>> > one for SE. SE depends on core. EE still refers to core as the same<br>
>>> > existing coordinates (create new coordinates for the parent).<br>
>>> ><br>
>>> > ------------------------------<wbr>------------------------------<br>
>>> ------------<br>
>>> > *From:* <a href="mailto:cdi-dev-bounces@lists.jboss.org">cdi-dev-bounces@lists.jboss.<wbr>org</a><br>
>>> > <<a href="mailto:cdi-dev-bounces@lists.jboss.org">cdi-dev-bounces@lists.jboss.<wbr>org</a>> on behalf of Antoine Sabot-Durand<br>
>>> > <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>><br>
>>> > *Sent:* Wednesday, October 12, 2016 5:18 AM<br>
>>> > *To:* cdi-dev<br>
>>> > *Subject:* [cdi-dev] Spliting SE package in an independent jar<br>
>>> ><br>
>>> > to avoid including CDI SE features in Java EE, we already talk about<br>
>>> > creating a specific SE jar.<br>
>>> ><br>
>>> > Any thought on this approach?<br>
>>> ><br>
>>> > Antoine<br>
>>> > ------------------------------<wbr>------------------------------<br>
>>> ------------<br>
>>> > NOTICE: This e-mail message and any attachments may contain<br>
>>> > confidential, proprietary, and/or privileged information which should<br>
>>> be<br>
>>> > treated accordingly. If you are not the intended recipient, please<br>
>>> > notify the sender immediately by return e-mail, delete this message,<br>
>>> and<br>
>>> > destroy all physical and electronic copies. Thank you.<br>
>>> ><br>
>>> ><br>
>>> > ______________________________<wbr>_________________<br>
>>> > cdi-dev mailing list<br>
>>> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
>>> ><br>
>>> > Note that for all code provided on this list, the provider licenses<br>
>>> the code under the Apache License, Version 2 (<br>
>>> <a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>>> provided on this list, the provider waives all patent and other<br>
>>> intellectual property rights inherent in such information.<br>
>>> ><br>
>>><br>
>>> --<br>
>>> Martin Kouba<br>
>>> Software Engineer<br>
>>> Red Hat, Czech Republic<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> cdi-dev mailing list<br>
>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
>>><br>
>>> Note that for all code provided on this list, the provider licenses the<br>
>>> code under the Apache License, Version 2 (<a href="http://www.apache.org/license" rel="noreferrer" target="_blank">http://www.apache.org/license</a><br>
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the<br>
>>> provider waives all patent and other intellectual property rights inherent<br>
>>> in such information.<br>
>>><br>
>>> End of cdi-dev Digest, Vol 71, Issue 29<br>
>>> ******************************<wbr>*********<br>
>>><br>
>><br>
>> ------------------------------<br>
>> NOTICE: This e-mail message and any attachments may contain confidential,<br>
>> proprietary, and/or privileged information which should be treated<br>
>> accordingly. If you are not the intended recipient, please notify the<br>
>> sender immediately by return e-mail, delete this message, and destroy all<br>
>> physical and electronic copies. Thank you.<br>
>><br>
><br>
> ------------------------------<br>
> NOTICE: This e-mail message and any attachments may contain confidential,<br>
> proprietary, and/or privileged information which should be treated<br>
> accordingly. If you are not the intended recipient, please notify the<br>
> sender immediately by return e-mail, delete this message, and destroy all<br>
> physical and electronic copies. Thank you.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.jboss.org/pipermail/cdi-dev/attachments/20161018/2a46a64a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.jboss.org/<wbr>pipermail/cdi-dev/attachments/<wbr>20161018/2a46a64a/attachment-<wbr>0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 19 Oct 2016 10:13:38 +0200<br>
From: Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
Subject: [cdi-dev] Team mentions on github<br>
To: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Message-ID: <<a href="mailto:0ab85968-f073-9cec-7a31-c84c4c540d42@redhat.com">0ab85968-f073-9cec-7a31-<wbr>c84c4c540d42@redhat.com</a>><br>
Content-Type: text/plain; charset=iso-8859-2; format=flowed<br>
<br>
Dear EG,<br>
<br>
I've just found a github feature called "team mentions" [1]. It allows<br>
to reference (send notifications to) every member of a team. The syntax<br>
is: @orgname/teamname.<br>
<br>
In cdi-spec organization there is a team called EG [2]. Sometimes it<br>
might be useful to reference this team e.g. when a PR is changed/needs<br>
review of EG.<br>
<br>
I've added several active members and invited few others. Feel free to<br>
accept/reject invitation or send request to join the team.<br>
<br>
To reference the EG team in comments/issues: @cdi-spec/eg<br>
<br>
Thanks,<br>
<br>
Martin<br>
<br>
[1]<br>
<a href="https://guides.github.com/features/issues/#mentions" rel="noreferrer" target="_blank">https://guides.github.com/<wbr>features/issues/#mentions</a><br>
<br>
[2]<br>
<a href="https://github.com/orgs/cdi-spec/teams/eg" rel="noreferrer" target="_blank">https://github.com/orgs/cdi-<wbr>spec/teams/eg</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT)<br>
From: "Martin Kouba (JIRA)" <<a href="mailto:issues@jboss.org">issues@jboss.org</a>><br>
Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with<br>
@Initialized(X.class) and @Destroyed(X.class) qualifiers fired<br>
To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
Message-ID:<br>
<JIRA.12644548.1472028968000.<wbr>16322.1476865320549@Atlassian.<wbr>JIRA><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
[ <a href="https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/CDI-625?page=com.<wbr>atlassian.jira.plugin.system.<wbr>issuetabpanels:all-tabpanel</a> ]<br>
<br>
Martin Kouba reassigned CDI-625:<br>
------------------------------<wbr>--<br>
<br>
Assignee: Martin Kouba<br>
<br>
<br>
> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired<br>
> ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>-<br>
><br>
> Key: CDI-625<br>
> URL: <a href="https://issues.jboss.org/browse/CDI-625" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/CDI-625</a><br>
> Project: CDI Specification Issues<br>
> Issue Type: Clarification<br>
> Components: Events<br>
> Reporter: Martin Kouba<br>
> Assignee: Martin Kouba<br>
> Labels: F2F2016<br>
> Fix For: 2.0 .Final<br>
><br>
><br>
> The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_).<br>
> Does it mean that:<br>
> * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?<br>
> * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?<br>
> I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.<br>
> In RI/Weld, the behaivour of {{@Destroyed(<wbr>ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.<br>
> I believe this should be more clear.<br>
<br>
<br>
<br>
--<br>
This message was sent by Atlassian JIRA<br>
(v6.4.11#64026)<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/<wbr>licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
End of cdi-dev Digest, Vol 71, Issue 32<br>
******************************<wbr>*********<br>
</blockquote></div><br></div></div></div></div></div></div>