December 2016 - cdi-dev - Jboss List Archives

by John Ament

Hi, Just want to check if the meeting for today is still on? ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

8 years

2
1
0 / 0

[JBoss JIRA] (CDI-667) Session beans in trimmed bean archive

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-667?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-667: ---------------------------------------- what about removing it from CDI spec and only referencing EJB spec for this scanning? > Session beans in trimmed bean archive > ------------------------------------- > > Key: CDI-667 > URL: https://issues.jboss.org/browse/CDI-667 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? > IMO we should state that there are discovered as beans, but it's questionable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-667) Session beans in trimmed bean archive

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-667?page=com.atlassian.jira.plugin.sy... ] Tomas Remes edited comment on CDI-667 at 12/19/16 2:12 AM: ----------------------------------------------------------- I would suggest to introduce new chapter in 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. was (Author: tremes): I would suggest to introduce new chapter 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. > Session beans in trimmed bean archive > ------------------------------------- > > Key: CDI-667 > URL: https://issues.jboss.org/browse/CDI-667 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? > IMO we should state that there are discovered as beans, but it's questionable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-667) Session beans in trimmed bean archive

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-667?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-667: --------------------------------- I would suggest to introduce new chapter 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. > Session beans in trimmed bean archive > ------------------------------------- > > Key: CDI-667 > URL: https://issues.jboss.org/browse/CDI-667 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? > IMO we should state that there are discovered as beans, but it's questionable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-673?page=com.atlassian.jira.plugin.sy... ] Matej Novotny updated CDI-673: ------------------------------ Fix Version/s: 2.0 .Final > Revisit manipulation with InjectionPoint(s) in ProducerConfigurator > ------------------------------------------------------------------- > > Key: CDI-673 > URL: https://issues.jboss.org/browse/CDI-673 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0.Beta1 > Reporter: Matej Novotny > Fix For: 2.0 .Final > > > Currently, {{ProducerConfigurator}} allows to add or replace injection points. > Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway. > Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer: > {code} > @Produces public Foo produceIt (@Default Bar) { //do stuff} > {code} > and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}. > The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following: > bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject(). > However, spec says nothing about what should happen when you change implementation's set on IPs later. > Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-673) Revisit manipulation with InjectionPoint(s) in ProducerConfigurator

by Matej Novotny (JIRA)

Matej Novotny created CDI-673: --------------------------------- Summary: Revisit manipulation with InjectionPoint(s) in ProducerConfigurator Key: CDI-673 URL: https://issues.jboss.org/browse/CDI-673 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0.Beta1 Reporter: Matej Novotny Currently, {{ProducerConfigurator}} allows to add or replace injection points. Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway. Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer: {code} @Produces public Foo produceIt (@Default Bar) { //do stuff} {code} and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}. The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following: bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject(). However, spec says nothing about what should happen when you change implementation's set on IPs later. Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-672: ------------------------------------------ Yes, we agree: remove read from BAC and keep them in BC. > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-672: ---------------------------------- But you can't use {{BeanAttributesConfigurator}} during {{AfterBeanDiscovery}} notification, or? > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-672) Purpose of BeanAttributesConfigurator read methods

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-672?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-672: ------------------------------------------ I agree, but they are useful in {{BeanConfigurator}} to be used in {{AfterBeanDiscovery}} > Purpose of BeanAttributesConfigurator read methods > --------------------------------------------------- > > Key: CDI-672 > URL: https://issues.jboss.org/browse/CDI-672 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0.Beta1 > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.sy... ] Martin Kouba edited comment on CDI-671 at 12/16/16 3:13 AM: ------------------------------------------------------------ The other approach would be to simulate injection of {{Instance}} (this is what Weld does): ||Injection point||Required type||Required qualifier||{{CDI}} equivalent|| |{{@Inject Instance<Object>}}|Object|(a)Default|CDI.current()| |{{@Inject @Any Instance<Object>}}|Object|(a)Any|CDI.current().select(Any.Literal.INSTANCE)| |{{@Inject Instance<Foo>}}|Foo|(a)Default|CDI.current().select(Foo.class)| |{{@Inject @Any Instance<Foo>}}|Foo|(a)Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)| |{{@Inject @MyQualifier Instance<Foo>}}|Foo|(a)MyQualifier|CDI.current().select(Foo.class,MyQualifier.Literal.INSTANCE)| In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected. was (Author: mkouba): The other approach would be to simulate injection of {{Instance}} (this is what Weld does): ||Injection point||Required type||Required qualifier||{{CDI}} equivalent|| |{{@Inject Instance<Object>}}|Object|(a)Default|CDI.current()| |{{@Inject @Any Instance<Object>}}|Object|(a)Any|CDI.current().select(Any.Literal.INSTANCE)| |{{@Inject Instance<Foo>}}|Foo|(a)Default|CDI.current().select(Foo.class)| |{{@Inject @Any Instance<Foo>}}|Foo|(a)Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)| In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected. > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2016