From issues at jboss.org  Mon Jan  4 03:38:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 03:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.4971.1451896680429@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

Happy new year!

I think there is an agreement that we shall not remove the non-proxyable rules in general (Option B). 
Option A. is purely an educational thing. 
We might write some blog about it but we should not pollute the spec with long explanations.
Those should go into a side letter instead.


But I also grok Emilys statement and have a possible solution for it. 
We could enhance the beans.xml.

{code}
<beans>
  <allowProxying>
    <class>com.acme.MyClassWithFinalMethods</class>
  </allowProxying>
</beans>
{code}

It would be in the chapter 5 sense of BDA of course. 
Otherwise it would make no sense at all as y'ou would have to re-package the jar again.
Means having a jar with the above in an EARs /lib folder would allow it for the whole EAR.
If it's just in an WAR WEB-INF/lib/ jar inside an EAR then it would only allow it for this very WAR in the EAR.

The container could log out a WARNING if it finds such entries.
Something like "Class XxxYyyy explicitly declared as proxyable despite having final methods!"


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 03:41:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 03:41:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.4991.1451896860450@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

Oh and if you like this solution then we might also think about introducing a new allowProxying(String classname) or Class to BeforeBeanDiscovery

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 03:49:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 4 Jan 2016 03:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.5014.1451897340575@Atlassian.JIRA>


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

Martin Kouba commented on CDI-527:
----------------------------------

Hi Mark, I don't like this solution. beans.xml *is* per bean archive and _"chapter 5 sense of BDA"_ is just an OWB interpretation (and wrong imho) - so nothing we can build other solutions on.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 04:07:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 04:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.5064.1451898420396@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

as I already said many weeks ago: give us a better solution and we will think about it. But blocking all solutions for a REAL issue is contraproductive...

And no, as discussed and agreed many times (also by JBoss), both interpretations of the term BDA are perfectly covered by the spec.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 05:15:01 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 4 Jan 2016 05:15:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-577) Non-Dependent scope specified on
	Decorator
In-Reply-To: <JIRA.12598020.1451902488000@Atlassian.JIRA>
References: <JIRA.12598020.1451902488000@Atlassian.JIRA>
	<JIRA.12598020.1451902488168@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12598020.1451902488000.5417.1451902501557@Atlassian.JIRA>

Emily Jiang created CDI-577:
-------------------------------

             Summary: Non-Dependent scope specified on Decorator
                 Key: CDI-577
                 URL: https://issues.jboss.org/browse/CDI-577
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Decorators
    Affects Versions: 1.2.Final, 1.0
            Reporter: Emily Jiang
            Priority: Minor


In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors. 

At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.

Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:

If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error. 




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 05:52:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 05:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-577) Non-Dependent scope specified on
	Decorator
In-Reply-To: <JIRA.12598020.1451902488000@Atlassian.JIRA>
References: <JIRA.12598020.1451902488000@Atlassian.JIRA>
	<JIRA.12598020.1451902488000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12598020.1451902488000.5625.1451904720349@Atlassian.JIRA>


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

Mark Struberg commented on CDI-577:
-----------------------------------

+1 for detecting this user error at startup .

> Non-Dependent scope specified on Decorator
> ------------------------------------------
>
>                 Key: CDI-577
>                 URL: https://issues.jboss.org/browse/CDI-577
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0, 1.2.Final
>            Reporter: Emily Jiang
>            Priority: Minor
>
> In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors. 
> At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.
> Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:
> If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 08:56:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 4 Jan 2016 08:56:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.7232.1451915760482@Atlassian.JIRA>


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

Martin Kouba commented on CDI-527:
----------------------------------

bq. as I already said many weeks ago...
Sometimes there is no good solution. Also for legacy applications this beans.xml approach wouldn't help either - if it is possible to change the app, then in most cases the "interface workaround" mentioned in A. might be used.
bq. And no, as discussed and agreed many times...
Not agreed. However, this issue is not a good place to discuss the problem. One of the things which is not "perfectly covered" is merging of {{beans.xml}} within an existing EE module.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 09:34:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 09:34:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.7528.1451918040441@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

This has exactly NOTHING to do with merging info from beans.xml. Nor has @Alternative any problems with merging beans.xml btw. The ONLY case where this might make problems is for decorators and interceptors!

Any other arguments? Because this is not a valid argument so far.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Jan  4 15:31:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 4 Jan 2016 15:31:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.9671.1451939460406@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

Martin, to come back to your argument that it won't help for legacy apps. It would not help if you have a sealed WAR/EAR anymore which you cannot change. But you can add a simple small jar to them which contains just the beans.xml with those additional settings almost always. You can even put this into the shared classpath without changing your EAR/WAR...
So I think it is the closest we can get. Again: happy for any other good solution. But doing nothing is not an option in my opinion.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Tue Jan  5 10:32:02 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 05 Jan 2016 15:32:02 +0000
Subject: [cdi-dev] Review needed for PR 270 (CDI 558)
Message-ID: <CABu-YBSpTeje+si84cCUdNX6bCs898KdhF2SHN3akRbqBsEX0A@mail.gmail.com>

Hi guys,

I just finish the first api version for CDI-558 (
https://issues.jboss.org/browse/CDI-558).
The spec part is not yet here, since I wanted to discuss the API with you
before.

We probably should discuss the following point:

- Package and class name
- Access to AnnotatedTypeBuilder (the only builder accessible while no CDI
container is running)
- Specification of exception in unauthorized called in these builder.

Your feedback is most welcome.

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

From pbenedict at apache.org  Tue Jan  5 17:13:20 2016
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 5 Jan 2016 16:13:20 -0600
Subject: [cdi-dev] CDI + 3rd party DI frameworks
Message-ID: <CABLGb9x+m_5ysb_nrcZzSpZcTiYspK6in4MqVLqHk9O909ersw@mail.gmail.com>

Hello EG members. I have a question regarding this statement from the
"Parts CDI Workshop doc". The line is: "Allow 3rd parties to implement
easily this subpart of CDI"

One thing, which has constantly frustrated me when using CDI 1.x, is the
lack of seamless integration with popular/proprietary DI frameworks (like
Spring). Regarding my experience with CDI+Spring in one app, I annotate CDI
injection points one way, and Spring injection points another way. I do not
like this schism and always seek to resolve it the best I can, but it's
never satisfactory to me.

It's my hope that, one day, custom DI frameworks that boot-up inside an app
can join themselves to the CDI engine and be able offer up their beans
through a CDI SPI. When the app tears down, so does the 3rd party framework
and those beans are no longer available. Thus, I would like CDI to offer
integration service points so that bean contexts/archive are, in a sense,
federated.

Is anything like this planned for 2.0? Or, if this idea is brand new, what
do you think of it?

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160105/7a9cb241/attachment.html 

From antoine at sabot-durand.net  Tue Jan 12 09:05:30 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 12 Jan 2016 14:05:30 +0000
Subject: [cdi-dev] Canceling today's meeting
Message-ID: <CABu-YBTJvNJMoyWTiXGrxDyqkKNDD3YvLS_E5j=6cn_mDct9NQ@mail.gmail.com>

Hi,

I have personal issue tonight and won't be able to make it for the meeting.
Sorry. In the meantime you can continue contributing to
https://github.com/cdi-spec/cdi/pull/270

Regards,

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

From arjan.tijms at gmail.com  Tue Jan 12 11:43:23 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 12 Jan 2016 17:43:23 +0100
Subject: [cdi-dev] Interceptors and JDK 8 default methods
Message-ID: <CAE=-AhCQ6sxhBmHnnuU=rf8dh_+RSGuutZ_RVOhMsBjQ5USXmQ@mail.gmail.com>

Hi,

I've got a CDI bean implementing an interface with several default methods.
The bean implements one of those methods.

When I place an interceptor on said bean, and call the different methods
via the CDI proxy, only the method that the bean implemented is
intercepted. The defaulted methods go straight to the implementation
provided by the interface.

Tested with Weld 2.3.2 on WildFly 10cr5.

Is this supposed to work?

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160112/64300da9/attachment.html 

From mkouba at redhat.com  Wed Jan 13 02:57:27 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 13 Jan 2016 08:57:27 +0100
Subject: [cdi-dev] Interceptors and JDK 8 default methods
In-Reply-To: <CAE=-AhCQ6sxhBmHnnuU=rf8dh_+RSGuutZ_RVOhMsBjQ5USXmQ@mail.gmail.com>
References: <CAE=-AhCQ6sxhBmHnnuU=rf8dh_+RSGuutZ_RVOhMsBjQ5USXmQ@mail.gmail.com>
Message-ID: <56960367.4050300@redhat.com>

Hi Arjan,

that's a good question. I think it should work, i.e. an invocation of a 
default method should be intercepted, see also the spec "7.2. Container 
invocations and interception". However, I'm not so sure about possible 
implementation problems. I've created WELD-2093 [1] to track this issue.

Martin

[1]
https://issues.jboss.org/browse/WELD-2093

Dne 12.1.2016 v 17:43 arjan tijms napsal(a):
> Hi,
>
> I've got a CDI bean implementing an interface with several default
> methods. The bean implements one of those methods.
>
> When I place an interceptor on said bean, and call the different methods
> via the CDI proxy, only the method that the bean implemented is
> intercepted. The defaulted methods go straight to the implementation
> provided by the interface.
>
> Tested with Weld 2.3.2 on WildFly 10cr5.
>
> Is this supposed to work?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From arjan.tijms at gmail.com  Wed Jan 13 03:18:30 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 13 Jan 2016 09:18:30 +0100
Subject: [cdi-dev] Interceptors and JDK 8 default methods
In-Reply-To: <56960367.4050300@redhat.com>
References: <CAE=-AhCQ6sxhBmHnnuU=rf8dh_+RSGuutZ_RVOhMsBjQ5USXmQ@mail.gmail.com>
	<56960367.4050300@redhat.com>
Message-ID: <CAE=-AhDbMnZ2EfDb21c4YGdABEHyL+1mbqOOcHbp1AjKUdiuLQ@mail.gmail.com>

Hi Martin,

Thanks, I'll keep an eye on that issue. If time permits I'll check what OWB
does here.

Kind regards,
Arjan Tijms



On Wed, Jan 13, 2016 at 8:57 AM, Martin Kouba <mkouba at redhat.com> wrote:

> Hi Arjan,
>
> that's a good question. I think it should work, i.e. an invocation of a
> default method should be intercepted, see also the spec "7.2. Container
> invocations and interception". However, I'm not so sure about possible
> implementation problems. I've created WELD-2093 [1] to track this issue.
>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-2093
>
> Dne 12.1.2016 v 17:43 arjan tijms napsal(a):
>
>> Hi,
>>
>> I've got a CDI bean implementing an interface with several default
>> methods. The bean implements one of those methods.
>>
>> When I place an interceptor on said bean, and call the different methods
>> via the CDI proxy, only the method that the bean implemented is
>> intercepted. The defaulted methods go straight to the implementation
>> provided by the interface.
>>
>> Tested with Weld 2.3.2 on WildFly 10cr5.
>>
>> Is this supposed to work?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160113/ac5b4631/attachment.html 

From mkouba at redhat.com  Wed Jan 13 05:16:28 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 13 Jan 2016 11:16:28 +0100
Subject: [cdi-dev] @WithAnnotations and meta-annotations
Message-ID: <569623FC.4090803@redhat.com>

Hi all,

suppose the following use-case:

* a class Foo annotated with a stereotype @Alpha which declares another 
stereotype @Bravo with meta-annotation @Baz
* a PAT observer annotated with @WithAnnotations({ Baz.class })

The question is: should this observer method be called for Foo? In other 
words, how should we interpret "11.5.6. ProcessAnnotatedType event"? The 
current spec wording seems ambiguous.

Weld currently does not perform the check "recursively", i.e. the 
observer method will not be called as Weld only considers annotations on 
the annotated type, on any member/parameter of the annotated type, or 
meta-annotations of such annotations (i.e. goes one level down).

I'm not sure about OWB.

Also note that there is no TCK test for this special use-case.

Thanks,

Martin

From struberg at yahoo.de  Wed Jan 13 06:19:08 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 13 Jan 2016 12:19:08 +0100
Subject: [cdi-dev] @WithAnnotations and meta-annotations
In-Reply-To: <569623FC.4090803@redhat.com>
References: <569623FC.4090803@redhat.com>
Message-ID: <4E697417-848D-452E-A9AF-35DE218C0850@yahoo.de>

I think we don?t check for the meta-annotations neither. But would need to look at the code in detail.

LieGrue,
strub

> Am 13.01.2016 um 11:16 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Hi all,
> 
> suppose the following use-case:
> 
> * a class Foo annotated with a stereotype @Alpha which declares another 
> stereotype @Bravo with meta-annotation @Baz
> * a PAT observer annotated with @WithAnnotations({ Baz.class })
> 
> The question is: should this observer method be called for Foo? In other 
> words, how should we interpret "11.5.6. ProcessAnnotatedType event"? The 
> current spec wording seems ambiguous.
> 
> Weld currently does not perform the check "recursively", i.e. the 
> observer method will not be called as Weld only considers annotations on 
> the annotated type, on any member/parameter of the annotated type, or 
> meta-annotations of such annotations (i.e. goes one level down).
> 
> I'm not sure about OWB.
> 
> Also note that there is no TCK test for this special use-case.
> 
> Thanks,
> 
> Martin
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From struberg at yahoo.de  Sat Jan 16 04:50:27 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 16 Jan 2016 10:50:27 +0100
Subject: [cdi-dev] pull requests broken?
Message-ID: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>

hi folks!

I cannot send a pull-request anymore. Only got pete and ales in the fork upstream network list. The official cdi-spec repo is gone from my list. The sha1 chain is fine though. 
Got this broken by some tinkering with the official repo or is github broken?

LieGrue,
strub

From issues at jboss.org  Sat Jan 16 04:53:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 16 Jan 2016 04:53:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.63712.1452937980527@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

first draft https://github.com/struberg/cdi/tree/CDI-527
Github pull requests to the official repo is broken currently. Not sure why. See mail on the list.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Sat Jan 16 05:28:00 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 16 Jan 2016 10:28:00 +0000
Subject: [cdi-dev] pull requests broken?
In-Reply-To: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
References: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
Message-ID: <CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>

Hi Mark,

There was nothing done recently on the repo. The last big change was my
request to make it the main repo (it was mark as a fork of Ales before
that), but it was 2 years ago.
You should add the remote again on your local repo.
Don't forget to make your PR on 2.0-EDR2 branch.

Antoine

Le sam. 16 janv. 2016 ? 10:51, Mark Struberg <struberg at yahoo.de> a ?crit :

> hi folks!
>
> I cannot send a pull-request anymore. Only got pete and ales in the fork
> upstream network list. The official cdi-spec repo is gone from my list. The
> sha1 chain is fine though.
> Got this broken by some tinkering with the official repo or is github
> broken?
>
> LieGrue,
> strub
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160116/a75d3ce7/attachment.html 

From antoine at sabot-durand.net  Sat Jan 16 05:38:23 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 16 Jan 2016 10:38:23 +0000
Subject: [cdi-dev] pull requests broken?
In-Reply-To: <CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
References: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
	<CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
Message-ID: <CABu-YBRsXcjysPJdG3fywzv+19Ms6Cwbe4C3CyCFBhki9o_eww@mail.gmail.com>

I meant "no recent changes"
Le sam. 16 janv. 2016 ? 11:27, Antoine Sabot-Durand <
antoine at sabot-durand.net> a ?crit :

> Hi Mark,
>
> There was nothing done recently on the repo. The last big change was my
> request to make it the main repo (it was mark as a fork of Ales before
> that), but it was 2 years ago.
> You should add the remote again on your local repo.
> Don't forget to make your PR on 2.0-EDR2 branch.
>
> Antoine
>
> Le sam. 16 janv. 2016 ? 10:51, Mark Struberg <struberg at yahoo.de> a ?crit :
>
>> hi folks!
>>
>> I cannot send a pull-request anymore. Only got pete and ales in the fork
>> upstream network list. The official cdi-spec repo is gone from my list. The
>> sha1 chain is fine though.
>> Got this broken by some tinkering with the official repo or is github
>> broken?
>>
>> LieGrue,
>> strub
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160116/62b8fb2e/attachment.html 

From struberg at yahoo.de  Sat Jan 16 05:50:51 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 16 Jan 2016 11:50:51 +0100
Subject: [cdi-dev] pull requests broken?
In-Reply-To: <CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
References: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
	<CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
Message-ID: <2D26E18C-5DD2-4C38-B4B4-C135246D31C0@yahoo.de>

Oki txs.

Is 2.0-EDR2 now the official work branch for time time coming? 
I cannot find any mail nor log where this got discussed or announced. Did I miss something?

How does it look like for the CDI-TCK? Which branch to use for it?

txs and LieGrue,
strub 


> Am 16.01.2016 um 11:28 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
> 
> Hi Mark,
> 
> There was nothing done recently on the repo. The last big change was my request to make it the main repo (it was mark as a fork of Ales before that), but it was 2 years ago.
> You should add the remote again on your local repo.
> Don't forget to make your PR on 2.0-EDR2 branch.
> 
> Antoine 
> 
> Le sam. 16 janv. 2016 ? 10:51, Mark Struberg <struberg at yahoo.de> a ?crit :
> hi folks!
> 
> I cannot send a pull-request anymore. Only got pete and ales in the fork upstream network list. The official cdi-spec repo is gone from my list. The sha1 chain is fine though.
> Got this broken by some tinkering with the official repo or is github broken?
> 
> LieGrue,
> strub
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From antoine at sabot-durand.net  Sat Jan 16 05:59:52 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 16 Jan 2016 10:59:52 +0000
Subject: [cdi-dev] pull requests broken?
In-Reply-To: <2D26E18C-5DD2-4C38-B4B4-C135246D31C0@yahoo.de>
References: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
	<CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
	<2D26E18C-5DD2-4C38-B4B4-C135246D31C0@yahoo.de>
Message-ID: <CABu-YBQ5kWiQ9tt1kNjY+CFgTBg03rs8T4VkoEw-YbQh-W53RA@mail.gmail.com>

It's been the default branch on Github since the end of EDR1. There's a 2
branch for the TCK as well.

Le sam. 16 janv. 2016 ? 11:50, Mark Struberg <struberg at yahoo.de> a ?crit :

> Oki txs.
>
> Is 2.0-EDR2 now the official work branch for time time coming?
> I cannot find any mail nor log where this got discussed or announced. Did
> I miss something?
>
> How does it look like for the CDI-TCK? Which branch to use for it?
>
> txs and LieGrue,
> strub
>
>
> > Am 16.01.2016 um 11:28 schrieb Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> >
> > Hi Mark,
> >
> > There was nothing done recently on the repo. The last big change was my
> request to make it the main repo (it was mark as a fork of Ales before
> that), but it was 2 years ago.
> > You should add the remote again on your local repo.
> > Don't forget to make your PR on 2.0-EDR2 branch.
> >
> > Antoine
> >
> > Le sam. 16 janv. 2016 ? 10:51, Mark Struberg <struberg at yahoo.de> a
> ?crit :
> > hi folks!
> >
> > I cannot send a pull-request anymore. Only got pete and ales in the fork
> upstream network list. The official cdi-spec repo is gone from my list. The
> sha1 chain is fine though.
> > Got this broken by some tinkering with the official repo or is github
> broken?
> >
> > LieGrue,
> > strub
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160116/711168c5/attachment-0001.html 

From tremes at redhat.com  Mon Jan 18 01:36:29 2016
From: tremes at redhat.com (Tomas Remes)
Date: Mon, 18 Jan 2016 01:36:29 -0500 (EST)
Subject: [cdi-dev] pull requests broken?
In-Reply-To: <CABu-YBQ5kWiQ9tt1kNjY+CFgTBg03rs8T4VkoEw-YbQh-W53RA@mail.gmail.com>
References: <AFE0D256-31CD-4B41-A737-154A160BF0D2@yahoo.de>
	<CABu-YBQE_WksU+H4SmJSdwfWkJ9iaAp=c5T3Ovd5+bRK84bhjA@mail.gmail.com>
	<2D26E18C-5DD2-4C38-B4B4-C135246D31C0@yahoo.de>
	<CABu-YBQ5kWiQ9tt1kNjY+CFgTBg03rs8T4VkoEw-YbQh-W53RA@mail.gmail.com>
Message-ID: <757403070.14089320.1453098989892.JavaMail.zimbra@redhat.com>


Hi,

For TCK the master is for upcoming CDI 2.0 and then there are branches 1.2, 1.1, 1.O. Pretty clear I would say. 

Thank's
Tom

----- Original Message -----
From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
To: "Mark Struberg" <struberg at yahoo.de>
Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
Sent: Saturday, January 16, 2016 11:59:52 AM
Subject: Re: [cdi-dev] pull requests broken?

It's been the default branch on Github since the end of EDR1. There's a 2 branch for the TCK as well. 

Le sam. 16 janv. 2016 ? 11:50, Mark Struberg < struberg at yahoo.de > a ?crit : 


Oki txs. 

Is 2.0-EDR2 now the official work branch for time time coming? 
I cannot find any mail nor log where this got discussed or announced. Did I miss something? 

How does it look like for the CDI-TCK? Which branch to use for it? 

txs and LieGrue, 
strub 


> Am 16.01.2016 um 11:28 schrieb Antoine Sabot-Durand < antoine at sabot-durand.net >: 
> 
> Hi Mark, 
> 
> There was nothing done recently on the repo. The last big change was my request to make it the main repo (it was mark as a fork of Ales before that), but it was 2 years ago. 
> You should add the remote again on your local repo. 
> Don't forget to make your PR on 2.0-EDR2 branch. 
> 
> Antoine 
> 
> Le sam. 16 janv. 2016 ? 10:51, Mark Struberg < struberg at yahoo.de > a ?crit : 
> hi folks! 
> 
> I cannot send a pull-request anymore. Only got pete and ales in the fork upstream network list. The official cdi-spec repo is gone from my list. The sha1 chain is fine though. 
> Got this broken by some tinkering with the official repo or is github broken? 
> 
> LieGrue, 
> strub 
> _______________________________________________ 
> cdi-dev mailing list 
> cdi-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/cdi-dev 
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. 


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

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




From issues at jboss.org  Tue Jan 19 09:36:01 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 19 Jan 2016 09:36:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.72990.1453214161015@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

beans_2_0.xsd added and pull request pushed.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jan 19 11:51:02 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 19 Jan 2016 11:51:02 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API
In-Reply-To: <JIRA.12591193.1446478318000@Atlassian.JIRA>
References: <JIRA.12591193.1446478318000@Atlassian.JIRA>
	<JIRA.12591193.1446478318000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12591193.1446478318000.74541.1453222262186@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-568:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Enhancing Java SE bootstrap API
> -------------------------------
>
>                 Key: CDI-568
>                 URL: https://issues.jboss.org/browse/CDI-568
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>
> As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1.
> The current version has the following flaws:
> * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API.
> * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration.
> * Don't provide a nice way to programmatically configure the container behavior.
> That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting 
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jan 19 11:52:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 19 Jan 2016 11:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API
In-Reply-To: <JIRA.12591193.1446478318000@Atlassian.JIRA>
References: <JIRA.12591193.1446478318000@Atlassian.JIRA>
	<JIRA.12591193.1446478318000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12591193.1446478318000.74547.1453222320306@Atlassian.JIRA>


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

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

Starting work based on [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java]


> Enhancing Java SE bootstrap API
> -------------------------------
>
>                 Key: CDI-568
>                 URL: https://issues.jboss.org/browse/CDI-568
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>
> As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1.
> The current version has the following flaws:
> * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API.
> * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration.
> * Don't provide a nice way to programmatically configure the container behavior.
> That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting 
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jan 19 12:11:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 19 Jan 2016 12:11:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-577) Non-Dependent scope specified on
	Decorator
In-Reply-To: <JIRA.12598020.1451902488000@Atlassian.JIRA>
References: <JIRA.12598020.1451902488000@Atlassian.JIRA>
	<JIRA.12598020.1451902488000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12598020.1451902488000.74677.1453223460526@Atlassian.JIRA>


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

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


> Non-Dependent scope specified on Decorator
> ------------------------------------------
>
>                 Key: CDI-577
>                 URL: https://issues.jboss.org/browse/CDI-577
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0, 1.2.Final
>            Reporter: Emily Jiang
>            Priority: Minor
>             Fix For: 2.0 (proposed)
>
>
> In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors. 
> At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.
> Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:
> If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Jan 19 12:25:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 19 Jan 2016 12:25:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-578) define behaviour of firing an
 event for an observer with transaction if the transaction is not open or
 marked rollback
In-Reply-To: <JIRA.12600129.1453224271000@Atlassian.JIRA>
References: <JIRA.12600129.1453224271000@Atlassian.JIRA>
	<JIRA.12600129.1453224271770@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600129.1453224271000.74800.1453224300249@Atlassian.JIRA>

Mark Struberg created CDI-578:
---------------------------------

             Summary: define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
                 Key: CDI-578
                 URL: https://issues.jboss.org/browse/CDI-578
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 1.2.Final
            Reporter: Mark Struberg


The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111

If you have an observer 

{code}
public void clearCacheAfterTx(@Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...}
{code}

and you fire the event

{code}
clearCacheEvent.fire(new ClearCacheEvent());
{code}

In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server.

The problem is that you cannot enlisten a Synchronisation at the tx anymore. 

I think we should define/clarify how it should behave in the various phases.

E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine.
At the end we need a matrix of the the event phases + possible Exceptions



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Jan 23 04:13:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 23 Jan 2016 04:13:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-578) define behaviour of firing an
 event for an observer with transaction if the transaction is not open or
 marked rollback
In-Reply-To: <JIRA.12600129.1453224272000@Atlassian.JIRA>
References: <JIRA.12600129.1453224272000@Atlassian.JIRA>
	<JIRA.12600129.1453224272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600129.1453224272000.8675.1453540380101@Atlassian.JIRA>


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

Mark Struberg commented on CDI-578:
-----------------------------------

added error handling for rollback and illegal state. 
The only technical thing which is missing is SystemException. But this indicates that there is some really low-level setup or container problem. Thus I think we should leave this out of the spec and the containers should just blow up with the Exception.

> define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-578
>                 URL: https://issues.jboss.org/browse/CDI-578
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>
> The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111
> If you have an observer 
> {code}
> public void clearCacheAfterTx(@Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...}
> {code}
> and you fire the event
> {code}
> clearCacheEvent.fire(new ClearCacheEvent());
> {code}
> In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server.
> The problem is that you cannot enlisten a Synchronisation at the tx anymore. 
> I think we should define/clarify how it should behave in the various phases.
> E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine.
> At the end we need a matrix of the the event phases + possible Exceptions



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Jan 24 16:52:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sun, 24 Jan 2016 16:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672306000@Atlassian.JIRA>
References: <JIRA.12600902.1453672306000@Atlassian.JIRA>
	<JIRA.12600902.1453672306772@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672306000.9006.1453672320053@Atlassian.JIRA>

Mark Struberg created CDI-579:
---------------------------------

             Summary: Extension disqualifies a jar as 'implicit bean archive'?
                 Key: CDI-579
                 URL: https://issues.jboss.org/browse/CDI-579
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: Mark Struberg
            Priority: Minor


The bean-discovery-wording is a bit odd. 
This has been in since CDI-1.1
{code}
An archive which:
? contains a beans.xml file with the bean-discovery-mode of none, or,
? contains an extension and no beans.xml file is not a bean archive.
is not a bean archive.
{code}

That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.

I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 02:44:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 25 Jan 2016 02:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.9397.1453707840080@Atlassian.JIRA>


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

Martin Kouba commented on CDI-579:
----------------------------------

Weld must follow the spec (i.e. it's not recognized as a bean archive), otherwise it wouldn't pass the relevant TCK test:
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/deployment/discovery/BeanDiscoveryTest.java#L187

[Weld SE|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support_2] and [Weld Servlet|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support] have a limited implicit bean archive support - bean archives without beans.xml descriptor are completely ignored.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 02:48:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 25 Jan 2016 02:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.9404.1453708080127@Atlassian.JIRA>


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

Tomas Remes commented on CDI-579:
---------------------------------

I have to agree that's not really straightforward but it's the way it is... There is TCK test for this {{org.jboss.cdi.tck.tests.deployment.discovery.BeanDiscoveryTest#testNotBeanArchiveExtension}}. Extension is called, but beans are not discovered. 

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 02:49:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 25 Jan 2016 02:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.9412.1453708140429@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-579 at 1/25/16 2:48 AM:
-----------------------------------------------------------

Well, Weld must follow the spec (i.e. it's not recognized as a bean archive), otherwise it wouldn't pass the relevant TCK test:
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/deployment/discovery/BeanDiscoveryTest.java#L187

[Weld SE|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support_2] and [Weld Servlet|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support] have a limited implicit bean archive support - bean archives without beans.xml descriptor are completely ignored.

But I agree it sounds weird.


was (Author: mkouba):
Weld must follow the spec (i.e. it's not recognized as a bean archive), otherwise it wouldn't pass the relevant TCK test:
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/deployment/discovery/BeanDiscoveryTest.java#L187

[Weld SE|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support_2] and [Weld Servlet|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support] have a limited implicit bean archive support - bean archives without beans.xml descriptor are completely ignored.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 02:51:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 25 Jan 2016 02:51:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.9417.1453708260250@Atlassian.JIRA>


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

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

I nkow we made TomEE supporting it but this is very unatural and error prone for users (you dev without a beans.xml then you add an extension to do X and finally nothing work anymore). I know it has been added for backward compatibility but not sure it is that relevant.

Since it is not that used I think it is still time to correct it in the spec and TCKs.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 02:51:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 25 Jan 2016 02:51:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.9419.1453708260297@Atlassian.JIRA>


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

Romain Manni-Bucau edited comment on CDI-579 at 1/25/16 2:50 AM:
-----------------------------------------------------------------

We made TomEE supporting it but this is very unatural and error prone for users (you dev without a beans.xml then you add an extension to do X and finally nothing work anymore). I know it has been added for backward compatibility but not sure it is that relevant.

Since it is not that used I think it is still time to correct it in the spec and TCKs.


was (Author: rmannibucau):
I nkow we made TomEE supporting it but this is very unatural and error prone for users (you dev without a beans.xml then you add an extension to do X and finally nothing work anymore). I know it has been added for backward compatibility but not sure it is that relevant.

Since it is not that used I think it is still time to correct it in the spec and TCKs.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:19:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 25 Jan 2016 11:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13368.1453738740435@Atlassian.JIRA>


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

Emily Jiang commented on CDI-579:
---------------------------------

If we fix it, there is still chance to break the existing customers. Introducing a system property is an option if we decide to fix it.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:31:01 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 25 Jan 2016 11:31:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13488.1453739461103@Atlassian.JIRA>


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

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

[~emilyj] supposing it is used but if you hit it you add a beans.xml so this "feature" is not that used IMO so it is ok to change it now

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:36:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 25 Jan 2016 11:36:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13541.1453739760718@Atlassian.JIRA>


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

Emily Jiang commented on CDI-579:
---------------------------------

well. An application may not starte if suddenly new beans are discovered by removing this sentence (AmbiguousResolutionException might be one of the causes)

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:38:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 25 Jan 2016 11:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13547.1453739880250@Atlassian.JIRA>


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

Mark Struberg commented on CDI-579:
-----------------------------------

Emily not sure if it is really a problem in real life. 
The only situation I can come up is if someone has an @ApplicationScoped bean or similar which is *not* getting used right now but has a deployment problem in it. So theoretically possible, but still would be really weird.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:39:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 25 Jan 2016 11:39:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13575.1453739940912@Atlassian.JIRA>


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

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

Agree but strongly think it is not used at all cause of the user experience it provides and the easiest way to fix this issue which is to go back on beans.xml structure - alternative is to add code to the extension which is not a real gain for users.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:42:02 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 25 Jan 2016 11:42:02 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13628.1453740122448@Atlassian.JIRA>


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

Emily Jiang commented on CDI-579:
---------------------------------

disagree on just removing the sentence without any way to revert back to the old behavior.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Jan 25 11:45:01 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 25 Jan 2016 11:45:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.13652.1453740301155@Atlassian.JIRA>


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

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

[~emilyj] how many users application did you see relying on this? Encountered this issue 4 times and each time the fix has been the same whoever lead it. Changing something not used or wrong is fine, even for specs, it is done in most new versions actually.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jan 26 02:31:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 26 Jan 2016 02:31:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.15602.1453793460288@Atlassian.JIRA>


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

Martin Kouba commented on CDI-579:
----------------------------------

bq. Emily Jiang how many users application did you see relying on this?  Encountered this issue 4 times...
We should definitely not rely on similar estimates. [~rmannibucau] do you really believe your experience is representing the whole CDI community and all use cases? I think we should find out why it was written this way (probably some compatibility issue) and then consider changing this and adding a config property to switch back to the old behaviour. This reminds me that maybe we should also consider some "unification" of configuration on the spec level (might be useful for other parts of the spec).


> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jan 26 02:47:00 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 26 Jan 2016 02:47:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.15671.1453794420341@Atlassian.JIRA>


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

Matej Novotny commented on CDI-579:
-----------------------------------

To toss my two cents in...
With implicit bean archives you can just play around and add beans with no beans.xml and it will work. Then you add an extension and suddenly it stops being an archive. This I consider weird. I believe we should change it, nevertheless Emily made a good point here. We do not want to make a change and lose the backward compatibility, and there should be a way to revert to original behavior.

Martin also hit the nerve here imo - the sentence is so weird it seems to be there on purpose (e.g. the aforementioned compatibility issues?) and we should investigate it.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jan 26 02:54:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 26 Jan 2016 02:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.15697.1453794840284@Atlassian.JIRA>


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

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

>From my understanding when I impl-ed it in TomEE it was for existing extension registering beans from jars without beans.xml. If these jars are now auto discovered the app can be broken.

That said I still think it is rare enough - [~mkouba] I don't think my experience represents the whole CDi community but 1. nobody said me I was wrong cause they met another case until now , 2. we can get a polling as we did for @New.

Just passively thinking it can be used and add a mess in the spec for that is not the best default IMO (feature flag are a headache most of the time for deployers/users so if we can avoid it it would be better. If we cant then fine to add a flag or a new API in extensions to activate annotated mode).

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jan 26 03:42:00 2016
From: issues at jboss.org (arjan tijms (JIRA))
Date: Tue, 26 Jan 2016 03:42:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.15879.1453797720273@Atlassian.JIRA>


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

arjan tijms commented on CDI-579:
---------------------------------

{quote}This reminds me that maybe we should also consider some "unification" of configuration on the spec level (might be useful for other parts of the spec).{quote}

Do you mean CDI specific configuration or platform wide configuration?

The Java EE configuration spec was supposed to handle that latter concern, but as we know this effort was largely aborted.

Unification would absolutely be welcome still, as would be some guidance at the platform level. E.g. here it's proposed to change behaviour and then provide a switch to restore the old behaviour.

JSF 2.3 however takes the opposite way. Out of the box it's JSF 2.2, and you need to set a series of switches to incrementally turn it into a JSF 2.3. 

IMHO this is confusing. For some specs you need to set switches to go back to old behaviour while for others you need to set switches to get new behaviour. 

And as for the location of said switches, {{web.xml}} is the closest we have to a universal location, but CDI extensions can't read that one. Some specs have a programmatic API (like Servlet and JASPIC), but the API is totally different between specs. And then some specs have a service loader based mechanism to provide raw deployment descriptors programmatically (see e.g. http://jdevelopment.nl/jsf-22/#533).
Finally there's a bunch of annotations, spread all throughout the specs with many their own usage patterns.

If CDI adds its own configuration then, though very welcome, it would be yet another location and method where and how things are configured.


> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From antoine at sabot-durand.net  Tue Jan 26 03:58:06 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 26 Jan 2016 08:58:06 +0000
Subject: [cdi-dev] Cancelling today's meeting
Message-ID: <CABu-YBSBVjJEyqJ37PexicXqsyc-eazMh4UMBDzfbstjoFVTWg@mail.gmail.com>

Hi guys,

I'm sick today and I don't think I'll be able to attend our meeting.

Sorry,

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

From werner.keil at gmail.com  Tue Jan 26 05:26:16 2016
From: werner.keil at gmail.com (Werner Keil)
Date: Tue, 26 Jan 2016 11:26:16 +0100
Subject: [cdi-dev] Cancelling today's meeting
Message-ID: <CAAGawe24Wc661MSUvd5byE6E+TKPGEcbneuxG8PTXnmJ8dQujg@mail.gmail.com>

Sorry to hear, get well soon,

Werner

On Tue, Jan 26, 2016 at 9:58 AM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Romain Manni-Bucau (JIRA))
>    2. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Emily Jiang (JIRA))
>    3. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Romain Manni-Bucau (JIRA))
>    4. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Martin Kouba (JIRA))
>    5. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Matej Novotny (JIRA))
>    6. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (Romain Manni-Bucau (JIRA))
>    7. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
>       'implicit bean archive'? (arjan tijms (JIRA))
>    8. Cancelling today's meeting (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Jan 2016 11:39:00 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.13575.1453739940912 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153253#comment-13153253
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> Agree but strongly think it is not used at all cause of the user
> experience it provides and the easiest way to fix this issue which is to go
> back on beans.xml structure - alternative is to add code to the extension
> which is not a real gain for users.
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 25 Jan 2016 11:42:02 -0500 (EST)
> From: "Emily Jiang (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.13628.1453740122448 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153258#comment-13153258
> ]
>
> Emily Jiang commented on CDI-579:
> ---------------------------------
>
> disagree on just removing the sentence without any way to revert back to
> the old behavior.
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 25 Jan 2016 11:45:01 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.13652.1453740301155 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153262#comment-13153262
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> [~emilyj] how many users application did you see relying on this?
> Encountered this issue 4 times and each time the fix has been the same
> whoever lead it. Changing something not used or wrong is fine, even for
> specs, it is done in most new versions actually.
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Jan 2016 02:31:00 -0500 (EST)
> From: "Martin Kouba (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.15602.1453793460288 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153442#comment-13153442
> ]
>
> Martin Kouba commented on CDI-579:
> ----------------------------------
>
> bq. Emily Jiang how many users application did you see relying on this?
> Encountered this issue 4 times...
> We should definitely not rely on similar estimates. [~rmannibucau] do you
> really believe your experience is representing the whole CDI community and
> all use cases? I think we should find out why it was written this way
> (probably some compatibility issue) and then consider changing this and
> adding a config property to switch back to the old behaviour. This reminds
> me that maybe we should also consider some "unification" of configuration
> on the spec level (might be useful for other parts of the spec).
>
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 26 Jan 2016 02:47:00 -0500 (EST)
> From: "Matej Novotny (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.15671.1453794420341 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153451#comment-13153451
> ]
>
> Matej Novotny commented on CDI-579:
> -----------------------------------
>
> To toss my two cents in...
> With implicit bean archives you can just play around and add beans with no
> beans.xml and it will work. Then you add an extension and suddenly it stops
> being an archive. This I consider weird. I believe we should change it,
> nevertheless Emily made a good point here. We do not want to make a change
> and lose the backward compatibility, and there should be a way to revert to
> original behavior.
>
> Martin also hit the nerve here imo - the sentence is so weird it seems to
> be there on purpose (e.g. the aforementioned compatibility issues?) and we
> should investigate it.
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 26 Jan 2016 02:54:00 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.15697.1453794840284 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153455#comment-13153455
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> >From my understanding when I impl-ed it in TomEE it was for existing
> extension registering beans from jars without beans.xml. If these jars are
> now auto discovered the app can be broken.
>
> That said I still think it is rare enough - [~mkouba] I don't think my
> experience represents the whole CDi community but 1. nobody said me I was
> wrong cause they met another case until now , 2. we can get a polling as we
> did for @New.
>
> Just passively thinking it can be used and add a mess in the spec for that
> is not the best default IMO (feature flag are a headache most of the time
> for deployers/users so if we can avoid it it would be better. If we cant
> then fine to add a flag or a new API in extensions to activate annotated
> mode).
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 26 Jan 2016 03:42:00 -0500 (EST)
> From: "arjan tijms (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
>         as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12600902.1453672307000.15879.1453797720273 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153477#comment-13153477
> ]
>
> arjan tijms commented on CDI-579:
> ---------------------------------
>
> {quote}This reminds me that maybe we should also consider some
> "unification" of configuration on the spec level (might be useful for other
> parts of the spec).{quote}
>
> Do you mean CDI specific configuration or platform wide configuration?
>
> The Java EE configuration spec was supposed to handle that latter concern,
> but as we know this effort was largely aborted.
>
> Unification would absolutely be welcome still, as would be some guidance
> at the platform level. E.g. here it's proposed to change behaviour and then
> provide a switch to restore the old behaviour.
>
> JSF 2.3 however takes the opposite way. Out of the box it's JSF 2.2, and
> you need to set a series of switches to incrementally turn it into a JSF
> 2.3.
>
> IMHO this is confusing. For some specs you need to set switches to go back
> to old behaviour while for others you need to set switches to get new
> behaviour.
>
> And as for the location of said switches, {{web.xml}} is the closest we
> have to a universal location, but CDI extensions can't read that one. Some
> specs have a programmatic API (like Servlet and JASPIC), but the API is
> totally different between specs. And then some specs have a service loader
> based mechanism to provide raw deployment descriptors programmatically (see
> e.g. http://jdevelopment.nl/jsf-22/#533).
> Finally there's a bunch of annotations, spread all throughout the specs
> with many their own usage patterns.
>
> If CDI adds its own configuration then, though very welcome, it would be
> yet another location and method where and how things are configured.
>
>
> > Extension disqualifies a jar as 'implicit bean archive'?
> > --------------------------------------------------------
> >
> >                 Key: CDI-579
> >                 URL: https://issues.jboss.org/browse/CDI-579
> >             Project: CDI Specification Issues
> >          Issue Type: Bug
> >            Reporter: Mark Struberg
> >            Priority: Minor
> >
> > The bean-discovery-wording is a bit odd.
> > This has been in since CDI-1.1
> > {code}
> > An archive which:
> > ? contains a beans.xml file with the bean-discovery-mode of none, or,
> > ? contains an extension and no beans.xml file is not a bean archive.
> > is not a bean archive.
> > {code}
> > That means even if you have an @ApplicationScoped MyService class in a
> jar which has a single CDI Extension then this MyServices will *not* get
> picked up as CDI bean? At least according to this wording?
> > Feels mega-weird to me and might conflict with the implicit beans
> archive definition a few lines below.
> > I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.11#64026)
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 26 Jan 2016 08:58:06 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] Cancelling today's meeting
> To: CDI Java EE Specification <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CABu-YBSBVjJEyqJ37PexicXqsyc-eazMh4UMBDzfbstjoFVTWg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> I'm sick today and I don't think I'll be able to attend our meeting.
>
> Sorry,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160126/a012cf18/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 62, Issue 6
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160126/a2532346/attachment-0001.html 

From issues at jboss.org  Tue Jan 26 07:09:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 26 Jan 2016 07:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.17182.1453810140537@Atlassian.JIRA>


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

Mark Struberg commented on CDI-579:
-----------------------------------

[~rmannibucau] the explanation with the Extension manually registering beans rings a bell. Maybe we should let it as is. 
It's easy enough to just add a beans.xml. 

And to be honest: making beans.xml optional was imo a bit of a mistake as it will be required to indicate a version="2.0" anyway ;)


> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Jan 26 07:14:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 26 Jan 2016 07:14:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.17219.1453810440453@Atlassian.JIRA>


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

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

[~struberg] removing the descriptor would work if extensions can be discovered thanks to that and activate CDI:

{code}
@CdiMeta // mark it as an extension used to define the module containing it, no need of META-INF/services/...
public class MyModuleMeta {
   void init(@Observes MetaRegistration reg) {
     reg.discoveryMode(...); // if conflict => fail, but it is unlikely respecting modulesMy
   }
}
{code}

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Jan 27 01:53:00 2016
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 27 Jan 2016 01:53:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.21505.1453877580357@Atlassian.JIRA>


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

Jozef Hartinger commented on CDI-579:
-------------------------------------

bq. Changing something not used or wrong is fine, even for specs, it is done in most new versions actually.

https://java.net/projects/javaee-spec/pages/CompatibilityRequirements

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Jan 27 01:55:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 27 Jan 2016 01:55:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.21507.1453877700124@Atlassian.JIRA>


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

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

[~jharting] yep, that's theory and practise. Servlet spec broke it largely between 3.0 and 3.1 for instance.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From arjan.tijms at gmail.com  Wed Jan 27 08:42:00 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 27 Jan 2016 14:42:00 +0100
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <546E522B.3090509@redhat.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
Message-ID: <CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>

Hi

On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger <jharting at redhat.com>
wrote:

> The simplest thing you can do is:
>
> Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
> manager.resolve(manager.getBeans(InjectionPoint.class));
> InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
> InjectionPoint.class, manager.createCreationalContext(bean));


I just tried this again, and unfortunately it now fails on Weld.

I quickly tried a series of Weld versions and this is the result:

Weld
2.2.6 works
2.2.8 works
2.2.9 fails
2.2.13 fails
2.2.14 fails
2.2.16 fails
2.3.0 fails
2.3.2 fails

So apparently it broke between 2.2.8 and 2.2.9.

Would it be possible to add a TCK test for this? This would be really
helpful as we'd like to use this for the JSF 2.3 RI.

Kind regards,
Arjan Tijms







>
>
> On 11/19/2014 05:06 PM, arjan tijms wrote:
>
>> Hi,
>>
>> In a producer method it's trivial to get access to an InjectionPoint
>> instance representing the point where the value produced by the
>> producer will be injected.
>>
>> When registering a Bean manually from an extension using
>> AfterBeanDiscovery#addBean, this is not immediately obvious.
>>
>> After some fumbling with the CDI APIs I came up with the following
>> code that seems to work on both Weld and OWB (didn't test CanDI yet).
>>
>> It uses a small "dummy" class, which is used to grab an InjectionPoint
>> off:
>>
>> In a Bean:
>>
>> public Object create(CreationalContext<Object> creationalContext) {
>>
>> InjectionPoint injectionPoint = (InjectionPoint)
>> beanManager.getInjectableReference(
>>              resolve(beanManager,
>> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>> creationalContext
>> );
>>
>> With InjectionPointGenerator being the following class:
>>
>> public class InjectionPointGenerator {
>>      @Inject
>>      private InjectionPoint injectionPoint;
>> }
>>
>> And resolve being the following method:
>>
>> public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
>> beanClass) {
>>          Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>
>>          for (Bean<?> bean : beans) {
>>              if (bean.getBeanClass() == beanClass) {
>>                  return (Bean<T>)
>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>>              }
>>          }
>>
>>          return (Bean<T>) beanManager.resolve(beans);
>>      }
>>
>> As mentioned, while this seems to work, I wonder if it's the best
>> approach.
>>
>> Kind regards,
>> Arjan
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160127/57a4c212/attachment.html 

From issues at jboss.org  Wed Jan 27 08:49:00 2016
From: issues at jboss.org (Arjan t (JIRA))
Date: Wed, 27 Jan 2016 08:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.24187.1453902540790@Atlassian.JIRA>


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

Arjan t commented on CDI-579:
-----------------------------

Was thinking about the following:

Mojarra is normally a container jar. Since it uses CDI there's a CDI extension. Since container jars are not automatically scanned, annotated classes can be added via {{BeforeBeanDiscovery.addAnnotatedType}}.

But Mojarra can also be used from an application archive and put into WEB-INF/lib.

Now it helps that it's not an implicit bean archive, otherwise the same class would be added twice; by the extension and via the scanning process. Probably it would be better to have a beans.xml file with bean-discovery-mode of none, but perhaps this was the use case for the "Extension disqualifies a jar as 'implicit bean archive'" was added?

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From tremes at redhat.com  Wed Jan 27 09:20:21 2016
From: tremes at redhat.com (Tomas Remes)
Date: Wed, 27 Jan 2016 09:20:21 -0500 (EST)
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
	<CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
Message-ID: <1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>


Hi Arjan,

Ok I am going to check this. Wrt TCK I am not sure it's suitable to some spec assertion so I wouldn't add it to TCK but we can definitely include this to Weld internal testsuite. 

Thank's

Tom

----- Original Message -----
From: "arjan tijms" <arjan.tijms at gmail.com>
To: "Jozef Hartinger" <jharting at redhat.com>
Cc: cdi-dev at lists.jboss.org
Sent: Wednesday, January 27, 2016 2:42:00 PM
Subject: Re: [cdi-dev] Getting injection point from Bean#create

Hi 

On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger < jharting at redhat.com > wrote: 


The simplest thing you can do is: 

Bean<InjectionPoint> bean = (Bean<InjectionPoint>) manager.resolve(manager.getBeans(InjectionPoint.class)); 
InjectionPoint ip = (InjectionPoint) manager.getReference(bean, InjectionPoint.class, manager.createCreationalContext(bean)); 

I just tried this again, and unfortunately it now fails on Weld. 

I quickly tried a series of Weld versions and this is the result: 

Weld 
2.2.6 works 
2.2.8 works 
2.2.9 fails 
2.2.13 fails 
2.2.14 fails 
2.2.16 fails 
2.3.0 fails 
2.3.2 fails 

So apparently it broke between 2.2.8 and 2.2.9. 

Would it be possible to add a TCK test for this? This would be really helpful as we'd like to use this for the JSF 2.3 RI. 

Kind regards, 
Arjan Tijms 










On 11/19/2014 05:06 PM, arjan tijms wrote: 



Hi, 

In a producer method it's trivial to get access to an InjectionPoint 
instance representing the point where the value produced by the 
producer will be injected. 

When registering a Bean manually from an extension using 
AfterBeanDiscovery#addBean, this is not immediately obvious. 

After some fumbling with the CDI APIs I came up with the following 
code that seems to work on both Weld and OWB (didn't test CanDI yet). 

It uses a small "dummy" class, which is used to grab an InjectionPoint off: 

In a Bean: 

public Object create(CreationalContext<Object> creationalContext) { 

InjectionPoint injectionPoint = (InjectionPoint) 
beanManager.getInjectableReference( 
resolve(beanManager, 
InjectionPointGenerator.class).getInjectionPoints().iterator().next(), 
creationalContext 
); 

With InjectionPointGenerator being the following class: 

public class InjectionPointGenerator { 
@Inject 
private InjectionPoint injectionPoint; 
} 

And resolve being the following method: 

public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) { 
Set<Bean<?>> beans = beanManager.getBeans(beanClass); 

for (Bean<?> bean : beans) { 
if (bean.getBeanClass() == beanClass) { 
return (Bean<T>) 
beanManager.resolve(Collections.<Bean<?>>singleton(bean)); 
} 
} 

return (Bean<T>) beanManager.resolve(beans); 
} 

As mentioned, while this seems to work, I wonder if it's the best approach. 

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

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



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

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



From issues at jboss.org  Wed Jan 27 10:19:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 27 Jan 2016 10:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.25353.1453907940810@Atlassian.JIRA>


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

Emily Jiang commented on CDI-579:
---------------------------------

I am kind of leaning towards not to change anything. In practice, extension is a special archive. If someone wants beans to be discovered, just explicitly add a beans.xml quite easily, as mentioned by Mark. In this way, it is nice and clear. An extension is normally big as well. If someone wants it to be excluded for bean discovery, people have to add a beans.xml with bean-discovery-mode="none". 

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Jan 28 08:08:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 28 Jan 2016 08:08:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.29815.1453986480561@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-579 at 1/28/16 8:07 AM:
-----------------------------------------------------------

Well, Weld must follow the spec (i.e. it's not recognized as a bean archive), otherwise it wouldn't pass the relevant TCK test:
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/deployment/discovery/BeanDiscoveryTest.java#L187

Weld 2.3 [SE|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support_2] and [Servlet|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support] have a limited implicit bean archive support - bean archives without beans.xml descriptor are completely ignored. Weld 3 has an experimental support for implicit bean archives without beans.xml, see also WELD-1962.

But I agree it sounds weird.


was (Author: mkouba):
Well, Weld must follow the spec (i.e. it's not recognized as a bean archive), otherwise it wouldn't pass the relevant TCK test:
https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss/cdi/tck/tests/deployment/discovery/BeanDiscoveryTest.java#L187

[Weld SE|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support_2] and [Weld Servlet|http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_implicit_bean_archive_support] have a limited implicit bean archive support - bean archives without beans.xml descriptor are completely ignored.

But I agree it sounds weird.

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From mkouba at redhat.com  Thu Jan 28 10:43:39 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 28 Jan 2016 16:43:39 +0100
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
	<CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
	<1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>
Message-ID: <56AA372B.3080509@redhat.com>

Hi Arjan,

yep, the behavior changed because of fix for WELD-1823 [1]. The spec 
(6.5.3. Contextual reference for a bean) requires to inject a null value 
if a dependent object is not being injected into any injection point. 
I'm not sure we can distinguish these different types of usage of 
BeanManager.getReference().

By the way, Tomas tested the original way using 
BeanManager.getInjectableReference() and it works fine. For the purpose 
of this use case a custom IP with InjectionPoint as a requested type, 
@Default as a qualifier and "this" as a declaring bean should be enough 
(no need for InjectionPointGenerator).

We're going to add a test in the Weld test suite. I don't think we 
should add this into TCK as it's rather corner case not clearly defined 
in the spec.

Martin

[1]
https://issues.jboss.org/browse/WELD-1823

Dne 27.1.2016 v 15:20 Tomas Remes napsal(a):
>
> Hi Arjan,
>
> Ok I am going to check this. Wrt TCK I am not sure it's suitable to some spec assertion so I wouldn't add it to TCK but we can definitely include this to Weld internal testsuite.
>
> Thank's
>
> Tom
>
> ----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Jozef Hartinger" <jharting at redhat.com>
> Cc: cdi-dev at lists.jboss.org
> Sent: Wednesday, January 27, 2016 2:42:00 PM
> Subject: Re: [cdi-dev] Getting injection point from Bean#create
>
> Hi
>
> On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger < jharting at redhat.com > wrote:
>
>
> The simplest thing you can do is:
>
> Bean<InjectionPoint> bean = (Bean<InjectionPoint>) manager.resolve(manager.getBeans(InjectionPoint.class));
> InjectionPoint ip = (InjectionPoint) manager.getReference(bean, InjectionPoint.class, manager.createCreationalContext(bean));
>
> I just tried this again, and unfortunately it now fails on Weld.
>
> I quickly tried a series of Weld versions and this is the result:
>
> Weld
> 2.2.6 works
> 2.2.8 works
> 2.2.9 fails
> 2.2.13 fails
> 2.2.14 fails
> 2.2.16 fails
> 2.3.0 fails
> 2.3.2 fails
>
> So apparently it broke between 2.2.8 and 2.2.9.
>
> Would it be possible to add a TCK test for this? This would be really helpful as we'd like to use this for the JSF 2.3 RI.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
> On 11/19/2014 05:06 PM, arjan tijms wrote:
>
>
>
> Hi,
>
> In a producer method it's trivial to get access to an InjectionPoint
> instance representing the point where the value produced by the
> producer will be injected.
>
> When registering a Bean manually from an extension using
> AfterBeanDiscovery#addBean, this is not immediately obvious.
>
> After some fumbling with the CDI APIs I came up with the following
> code that seems to work on both Weld and OWB (didn't test CanDI yet).
>
> It uses a small "dummy" class, which is used to grab an InjectionPoint off:
>
> In a Bean:
>
> public Object create(CreationalContext<Object> creationalContext) {
>
> InjectionPoint injectionPoint = (InjectionPoint)
> beanManager.getInjectableReference(
> resolve(beanManager,
> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
> creationalContext
> );
>
> With InjectionPointGenerator being the following class:
>
> public class InjectionPointGenerator {
> @Inject
> private InjectionPoint injectionPoint;
> }
>
> And resolve being the following method:
>
> public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>
> for (Bean<?> bean : beans) {
> if (bean.getBeanClass() == beanClass) {
> return (Bean<T>)
> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
> }
> }
>
> return (Bean<T>) beanManager.resolve(beans);
> }
>
> As mentioned, while this seems to work, I wonder if it's the best approach.
>
> Kind regards,
> Arjan
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From arjan.tijms at gmail.com  Thu Jan 28 14:57:15 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 28 Jan 2016 20:57:15 +0100
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <56AA372B.3080509@redhat.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
	<CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
	<1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>
	<56AA372B.3080509@redhat.com>
Message-ID: <CAE=-AhAYx4zLB=YLUZWW8MxGUGfj8jK0mLXF0nPziCWvuQu8oQ@mail.gmail.com>

On Thu, Jan 28, 2016 at 4:43 PM, Martin Kouba <mkouba at redhat.com> wrote:

> By the way, Tomas tested the original way using
> BeanManager.getInjectableReference() and it works fine. For the purpose of
> this use case a custom IP with InjectionPoint as a requested type, @Default
> as a qualifier and "this" as a declaring bean should be enough (no need for
> InjectionPointGenerator).
>

Okay, so you mean this code:

InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
     resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
     creationalContext
);

To what does that has to be changed exactly?



>
> We're going to add a test in the Weld test suite.


Great! That test will be for this method?

Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
manager.resolve(manager.getBeans(InjectionPoint.class));
InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
InjectionPoint.class, manager.createCreationalContext(bean));



> I don't think we should add this into TCK as it's rather corner case not
> clearly defined in the spec.
>

Would that be something that's beneficial to add to the 2.0 spec?

Kind regards,
Arjan Tijms





>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-1823
>
> Dne 27.1.2016 v 15:20 Tomas Remes napsal(a):
>
>
>> Hi Arjan,
>>
>> Ok I am going to check this. Wrt TCK I am not sure it's suitable to some
>> spec assertion so I wouldn't add it to TCK but we can definitely include
>> this to Weld internal testsuite.
>>
>> Thank's
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms at gmail.com>
>> To: "Jozef Hartinger" <jharting at redhat.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Wednesday, January 27, 2016 2:42:00 PM
>> Subject: Re: [cdi-dev] Getting injection point from Bean#create
>>
>> Hi
>>
>> On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger < jharting at redhat.com >
>> wrote:
>>
>>
>> The simplest thing you can do is:
>>
>> Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
>> manager.resolve(manager.getBeans(InjectionPoint.class));
>> InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
>> InjectionPoint.class, manager.createCreationalContext(bean));
>>
>> I just tried this again, and unfortunately it now fails on Weld.
>>
>> I quickly tried a series of Weld versions and this is the result:
>>
>> Weld
>> 2.2.6 works
>> 2.2.8 works
>> 2.2.9 fails
>> 2.2.13 fails
>> 2.2.14 fails
>> 2.2.16 fails
>> 2.3.0 fails
>> 2.3.2 fails
>>
>> So apparently it broke between 2.2.8 and 2.2.9.
>>
>> Would it be possible to add a TCK test for this? This would be really
>> helpful as we'd like to use this for the JSF 2.3 RI.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11/19/2014 05:06 PM, arjan tijms wrote:
>>
>>
>>
>> Hi,
>>
>> In a producer method it's trivial to get access to an InjectionPoint
>> instance representing the point where the value produced by the
>> producer will be injected.
>>
>> When registering a Bean manually from an extension using
>> AfterBeanDiscovery#addBean, this is not immediately obvious.
>>
>> After some fumbling with the CDI APIs I came up with the following
>> code that seems to work on both Weld and OWB (didn't test CanDI yet).
>>
>> It uses a small "dummy" class, which is used to grab an InjectionPoint
>> off:
>>
>> In a Bean:
>>
>> public Object create(CreationalContext<Object> creationalContext) {
>>
>> InjectionPoint injectionPoint = (InjectionPoint)
>> beanManager.getInjectableReference(
>> resolve(beanManager,
>> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>> creationalContext
>> );
>>
>> With InjectionPointGenerator being the following class:
>>
>> public class InjectionPointGenerator {
>> @Inject
>> private InjectionPoint injectionPoint;
>> }
>>
>> And resolve being the following method:
>>
>> public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
>> beanClass) {
>> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>
>> for (Bean<?> bean : beans) {
>> if (bean.getBeanClass() == beanClass) {
>> return (Bean<T>)
>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>> }
>> }
>>
>> return (Bean<T>) beanManager.resolve(beans);
>> }
>>
>> As mentioned, while this seems to work, I wonder if it's the best
>> approach.
>>
>> Kind regards,
>> Arjan
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160128/4e09f1e9/attachment-0001.html 

From issues at jboss.org  Thu Jan 28 15:22:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 28 Jan 2016 15:22:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
 'implicit bean archive'?
In-Reply-To: <JIRA.12600902.1453672307000@Atlassian.JIRA>
References: <JIRA.12600902.1453672307000@Atlassian.JIRA>
	<JIRA.12600902.1453672307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600902.1453672307000.32723.1454012520367@Atlassian.JIRA>


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

Mark Struberg commented on CDI-579:
-----------------------------------

[~atijms] It is really a subtle problem. By adding a beans.xml with bd 'none' it would get picked up by CDI-1.0 containers...

> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
>                 Key: CDI-579
>                 URL: https://issues.jboss.org/browse/CDI-579
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Mark Struberg
>            Priority: Minor
>
> The bean-discovery-wording is a bit odd. 
> This has been in since CDI-1.1
> {code}
> An archive which:
> ? contains a beans.xml file with the bean-discovery-mode of none, or,
> ? contains an extension and no beans.xml file is not a bean archive.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From tremes at redhat.com  Fri Jan 29 02:41:30 2016
From: tremes at redhat.com (Tomas Remes)
Date: Fri, 29 Jan 2016 02:41:30 -0500 (EST)
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <CAE=-AhAYx4zLB=YLUZWW8MxGUGfj8jK0mLXF0nPziCWvuQu8oQ@mail.gmail.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
	<CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
	<1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>
	<56AA372B.3080509@redhat.com>
	<CAE=-AhAYx4zLB=YLUZWW8MxGUGfj8jK0mLXF0nPziCWvuQu8oQ@mail.gmail.com>
Message-ID: <1187568045.21863490.1454053290353.JavaMail.zimbra@redhat.com>


Hi,

Actually the test verifies both methods. It is available here https://github.com/weld/core/pull/1275. I am not sure it's 100% correct but hopefully it is. 

Tom

----- Original Message -----
From: "arjan tijms" <arjan.tijms at gmail.com>
To: "Martin Kouba" <mkouba at redhat.com>
Cc: "Tomas Remes" <tremes at redhat.com>, cdi-dev at lists.jboss.org
Sent: Thursday, January 28, 2016 8:57:15 PM
Subject: Re: [cdi-dev] Getting injection point from Bean#create

On Thu, Jan 28, 2016 at 4:43 PM, Martin Kouba <mkouba at redhat.com> wrote:

> By the way, Tomas tested the original way using
> BeanManager.getInjectableReference() and it works fine. For the purpose of
> this use case a custom IP with InjectionPoint as a requested type, @Default
> as a qualifier and "this" as a declaring bean should be enough (no need for
> InjectionPointGenerator).
>

Okay, so you mean this code:

InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
     resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
     creationalContext
);

To what does that has to be changed exactly?



>
> We're going to add a test in the Weld test suite.


Great! That test will be for this method?

Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
manager.resolve(manager.getBeans(InjectionPoint.class));
InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
InjectionPoint.class, manager.createCreationalContext(bean));



> I don't think we should add this into TCK as it's rather corner case not
> clearly defined in the spec.
>

Would that be something that's beneficial to add to the 2.0 spec?

Kind regards,
Arjan Tijms





>
> Martin
>
> [1]
> https://issues.jboss.org/browse/WELD-1823
>
> Dne 27.1.2016 v 15:20 Tomas Remes napsal(a):
>
>
>> Hi Arjan,
>>
>> Ok I am going to check this. Wrt TCK I am not sure it's suitable to some
>> spec assertion so I wouldn't add it to TCK but we can definitely include
>> this to Weld internal testsuite.
>>
>> Thank's
>>
>> Tom
>>
>> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms at gmail.com>
>> To: "Jozef Hartinger" <jharting at redhat.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Wednesday, January 27, 2016 2:42:00 PM
>> Subject: Re: [cdi-dev] Getting injection point from Bean#create
>>
>> Hi
>>
>> On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger < jharting at redhat.com >
>> wrote:
>>
>>
>> The simplest thing you can do is:
>>
>> Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
>> manager.resolve(manager.getBeans(InjectionPoint.class));
>> InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
>> InjectionPoint.class, manager.createCreationalContext(bean));
>>
>> I just tried this again, and unfortunately it now fails on Weld.
>>
>> I quickly tried a series of Weld versions and this is the result:
>>
>> Weld
>> 2.2.6 works
>> 2.2.8 works
>> 2.2.9 fails
>> 2.2.13 fails
>> 2.2.14 fails
>> 2.2.16 fails
>> 2.3.0 fails
>> 2.3.2 fails
>>
>> So apparently it broke between 2.2.8 and 2.2.9.
>>
>> Would it be possible to add a TCK test for this? This would be really
>> helpful as we'd like to use this for the JSF 2.3 RI.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11/19/2014 05:06 PM, arjan tijms wrote:
>>
>>
>>
>> Hi,
>>
>> In a producer method it's trivial to get access to an InjectionPoint
>> instance representing the point where the value produced by the
>> producer will be injected.
>>
>> When registering a Bean manually from an extension using
>> AfterBeanDiscovery#addBean, this is not immediately obvious.
>>
>> After some fumbling with the CDI APIs I came up with the following
>> code that seems to work on both Weld and OWB (didn't test CanDI yet).
>>
>> It uses a small "dummy" class, which is used to grab an InjectionPoint
>> off:
>>
>> In a Bean:
>>
>> public Object create(CreationalContext<Object> creationalContext) {
>>
>> InjectionPoint injectionPoint = (InjectionPoint)
>> beanManager.getInjectableReference(
>> resolve(beanManager,
>> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>> creationalContext
>> );
>>
>> With InjectionPointGenerator being the following class:
>>
>> public class InjectionPointGenerator {
>> @Inject
>> private InjectionPoint injectionPoint;
>> }
>>
>> And resolve being the following method:
>>
>> public static <T> Bean<T> resolve(BeanManager beanManager, Class<T>
>> beanClass) {
>> Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>>
>> for (Bean<?> bean : beans) {
>> if (bean.getBeanClass() == beanClass) {
>> return (Bean<T>)
>> beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>> }
>> }
>>
>> return (Bean<T>) beanManager.resolve(beans);
>> }
>>
>> As mentioned, while this seems to work, I wonder if it's the best
>> approach.
>>
>> Kind regards,
>> Arjan
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>


From issues at jboss.org  Fri Jan 29 04:14:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 29 Jan 2016 04:14:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from
 javax.enterprise.inject.Instance
In-Reply-To: <JIRA.12564784.1425452571000@Atlassian.JIRA>
References: <JIRA.12564784.1425452571000@Atlassian.JIRA>
	<JIRA.12564784.1425452571000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564784.1425452571000.34135.1454058841838@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-515:
--------------------------------

    Assignee: Martin Kouba


> Allow to obtain Bean metadata from javax.enterprise.inject.Instance
> -------------------------------------------------------------------
>
>                 Key: CDI-515
>                 URL: https://issues.jboss.org/browse/CDI-515
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 (proposed)
>
>
> Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From mkouba at redhat.com  Fri Jan 29 04:40:39 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 29 Jan 2016 10:40:39 +0100
Subject: [cdi-dev] Getting injection point from Bean#create
In-Reply-To: <CAE=-AhAYx4zLB=YLUZWW8MxGUGfj8jK0mLXF0nPziCWvuQu8oQ@mail.gmail.com>
References: <CAE=-AhDouaqWh+3vDzpBgKs3-B-RY6kS7WxF=Jj8cLnSkYhD9g@mail.gmail.com>
	<546E522B.3090509@redhat.com>
	<CAE=-AhCfyAA9BgxTXHr_z=1A3b+O12GPL1oHpnG7SiyUL4R6zQ@mail.gmail.com>
	<1437953557.20861132.1453904421529.JavaMail.zimbra@redhat.com>
	<56AA372B.3080509@redhat.com>
	<CAE=-AhAYx4zLB=YLUZWW8MxGUGfj8jK0mLXF0nPziCWvuQu8oQ@mail.gmail.com>
Message-ID: <56AB3397.7090407@redhat.com>

Dne 28.1.2016 v 20:57 arjan tijms napsal(a):
> On Thu, Jan 28, 2016 at 4:43 PM, Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> wrote:
>
>     By the way, Tomas tested the original way using
>     BeanManager.getInjectableReference() and it works fine. For the
>     purpose of this use case a custom IP with InjectionPoint as a
>     requested type, @Default as a qualifier and "this" as a declaring
>     bean should be enough (no need for InjectionPointGenerator).
>
>
> Okay, so you mean this code:
>
> InjectionPoint injectionPoint = (InjectionPoint)
> beanManager.getInjectableReference(
>       resolve(beanManager,
> InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>       creationalContext
> );
>
> To what does that has to be changed exactly?

This code should just work. But you could use a "synthetic" injection 
point instead of InjectionPointGenerator (e.g. something like 
https://github.com/mkouba/core/blob/custom-bean-ip/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/BarBean.java#L115).

>
>
>
>     We're going to add a test in the Weld test suite.
>
>
> Great! That test will be for this method?

No. For BeanManager.getInjectableReference() - as I said:  I'm not sure 
we can make the "BeanManager.getReference()" way work again without 
breaking other stuff.

>
> Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
> manager.resolve(manager.getBeans(InjectionPoint.class));
> InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
> InjectionPoint.class, manager.createCreationalContext(bean));
>
>
>     I don't think we should add this into TCK as it's rather corner case
>     not clearly defined in the spec.
>
>
> Would that be something that's beneficial to add to the 2.0 spec?

Yep, I think it would deserve some discussion. On the other hand, I 
cannot imagine how to specify this properly.

>
> Kind regards,
> Arjan Tijms
>
>
>
>
>     Martin
>
>     [1]
>     https://issues.jboss.org/browse/WELD-1823
>
>     Dne 27.1.2016 v 15:20 Tomas Remes napsal(a):
>
>
>         Hi Arjan,
>
>         Ok I am going to check this. Wrt TCK I am not sure it's suitable
>         to some spec assertion so I wouldn't add it to TCK but we can
>         definitely include this to Weld internal testsuite.
>
>         Thank's
>
>         Tom
>
>         ----- Original Message -----
>         From: "arjan tijms" <arjan.tijms at gmail.com
>         <mailto:arjan.tijms at gmail.com>>
>         To: "Jozef Hartinger" <jharting at redhat.com
>         <mailto:jharting at redhat.com>>
>         Cc: cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>         Sent: Wednesday, January 27, 2016 2:42:00 PM
>         Subject: Re: [cdi-dev] Getting injection point from Bean#create
>
>         Hi
>
>         On Thu, Nov 20, 2014 at 9:42 PM, Jozef Hartinger <
>         jharting at redhat.com <mailto:jharting at redhat.com> > wrote:
>
>
>         The simplest thing you can do is:
>
>         Bean<InjectionPoint> bean = (Bean<InjectionPoint>)
>         manager.resolve(manager.getBeans(InjectionPoint.class));
>         InjectionPoint ip = (InjectionPoint) manager.getReference(bean,
>         InjectionPoint.class, manager.createCreationalContext(bean));
>
>         I just tried this again, and unfortunately it now fails on Weld.
>
>         I quickly tried a series of Weld versions and this is the result:
>
>         Weld
>         2.2.6 works
>         2.2.8 works
>         2.2.9 fails
>         2.2.13 fails
>         2.2.14 fails
>         2.2.16 fails
>         2.3.0 fails
>         2.3.2 fails
>
>         So apparently it broke between 2.2.8 and 2.2.9.
>
>         Would it be possible to add a TCK test for this? This would be
>         really helpful as we'd like to use this for the JSF 2.3 RI.
>
>         Kind regards,
>         Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>         On 11/19/2014 05:06 PM, arjan tijms wrote:
>
>
>
>         Hi,
>
>         In a producer method it's trivial to get access to an InjectionPoint
>         instance representing the point where the value produced by the
>         producer will be injected.
>
>         When registering a Bean manually from an extension using
>         AfterBeanDiscovery#addBean, this is not immediately obvious.
>
>         After some fumbling with the CDI APIs I came up with the following
>         code that seems to work on both Weld and OWB (didn't test CanDI
>         yet).
>
>         It uses a small "dummy" class, which is used to grab an
>         InjectionPoint off:
>
>         In a Bean:
>
>         public Object create(CreationalContext<Object> creationalContext) {
>
>         InjectionPoint injectionPoint = (InjectionPoint)
>         beanManager.getInjectableReference(
>         resolve(beanManager,
>         InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
>         creationalContext
>         );
>
>         With InjectionPointGenerator being the following class:
>
>         public class InjectionPointGenerator {
>         @Inject
>         private InjectionPoint injectionPoint;
>         }
>
>         And resolve being the following method:
>
>         public static <T> Bean<T> resolve(BeanManager beanManager,
>         Class<T> beanClass) {
>         Set<Bean<?>> beans = beanManager.getBeans(beanClass);
>
>         for (Bean<?> bean : beans) {
>         if (bean.getBeanClass() == beanClass) {
>         return (Bean<T>)
>         beanManager.resolve(Collections.<Bean<?>>singleton(bean));
>         }
>         }
>
>         return (Bean<T>) beanManager.resolve(beans);
>         }
>
>         As mentioned, while this seems to work, I wonder if it's the
>         best approach.
>
>         Kind regards,
>         Arjan
>         _______________________________________________
>         cdi-dev mailing list
>         cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>         Note that for all code provided on this list, the provider
>         licenses the code under the Apache License, Version 2 (
>         http://www.apache.org/licenses/LICENSE-2.0.html ). For all other
>         ideas provided on this list, the provider waives all patent and
>         other intellectual property rights inherent in such information.
>
>
>
>         _______________________________________________
>         cdi-dev mailing list
>         cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>         Note that for all code provided on this list, the provider
>         licenses the code under the Apache License, Version 2
>         (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>         ideas provided on this list, the provider waives all patent and
>         other intellectual property rights inherent in such information.
>
>
>         _______________________________________________
>         cdi-dev mailing list
>         cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>         Note that for all code provided on this list, the provider
>         licenses the code under the Apache License, Version 2
>         (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>         ideas provided on this list, the provider waives all patent and
>         other intellectual property rights inherent in such information.
>
>
>     --
>     Martin Kouba
>     Software Engineer
>     Red Hat, Czech Republic
>
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From issues at jboss.org  Sun Jan 31 04:55:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sun, 31 Jan 2016 04:55:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
In-Reply-To: <JIRA.12531258.1391619072000@Atlassian.JIRA>
References: <JIRA.12531258.1391619072000@Atlassian.JIRA>
	<JIRA.12531258.1391619072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531258.1391619072000.39544.1454234100179@Atlassian.JIRA>


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

Mark Struberg updated CDI-420:
------------------------------
    Summary: add a bean-discovery-mode 'scoped'  (was: add a bean-discovery-mode 'detected')


> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
>                 Key: CDI-420
>                 URL: https://issues.jboss.org/browse/CDI-420
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Packaging and Deployment
>    Affects Versions: TBD
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for 
> ? each Java class, interface or enum deployed in an explicit bean archive, and 
> ? each Java class with a bean defining annotation in an implicit bean archive. 
> ? each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. 
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sun Jan 31 05:02:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sun, 31 Jan 2016 05:02:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
In-Reply-To: <JIRA.12531258.1391619072000@Atlassian.JIRA>
References: <JIRA.12531258.1391619072000@Atlassian.JIRA>
	<JIRA.12531258.1391619072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531258.1391619072000.39548.1454234520166@Atlassian.JIRA>


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

Mark Struberg commented on CDI-420:
-----------------------------------

With getting more and more feedback for cdi-1.1 and 1.2 in the last 2 years it became clear that the bean-discovery-mode 'annotated' is not or less not used by developers! Simply by the fact that not picking up interfaces and stuff create way too many problems with Extensions. That's why I'm pushing this idea again. I just like to rename the new bean-discovery-mode to 'scoped'.

The behaviour is the following:
1.) Scan all interfaces and classes etc just like with 'all'
2.) Fire the ProcessAnnotatedType event for all of them (just like with 'all')
3.) But for all classes in a jar or classpath entry with bean-diescovery-mode=
scoped' _only_ create Bean<T> of those AnnotatedTypes which either
 * have an explicit CDI scope annotation, or
 * are an Interceptor or a Decorator, or
 * are a JavaEE bean, or
 * have a StereoType

This will 
* improve boot times 
* reduce the memory footprint by not storing away tons of useless Bean<T> instances

> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
>                 Key: CDI-420
>                 URL: https://issues.jboss.org/browse/CDI-420
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Packaging and Deployment
>    Affects Versions: TBD
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for 
> ? each Java class, interface or enum deployed in an explicit bean archive, and 
> ? each Java class with a bean defining annotation in an implicit bean archive. 
> ? each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. 
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)