February 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-413) Update outdated license

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.sy... ] Work on CDI-413 started by Antoine Sabot-Durand. > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license...] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11...] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected'

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-420: ----------------------------------- It's also not clear to me whether a mode 'annotated' should find interfaces and fire a ProcessAnnotatedType for them? > add a bean-discovery-mode 'detected' > ------------------------------------ > > 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 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected'

by Mark Struberg (JIRA)

Mark Struberg created CDI-420: --------------------------------- Summary: add a bean-discovery-mode 'detected' 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 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 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 the (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 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected'

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Mark Struberg updated CDI-420: ------------------------------ Description: 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... was: 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 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 the (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 processing. I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... > add a bean-discovery-mode 'detected' > ------------------------------------ > > 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 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-331: ------------------------------------- Fix Version/s: 1.2 Proposed (was: TBD) > Instance.iterator() shouldn't include non-alternatives that haven't been replaced > --------------------------------------------------------------------------------- > > Key: CDI-331 > URL: https://issues.jboss.org/browse/CDI-331 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.2 Proposed > > > The specification currently says that: > {quote} > The iterator() method must: > • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into > which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1. > {quote} > The ambiguity resolution algorithm as defined in 5.2.2 should be applied. > This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency: > Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative. > Assume further the following > {noformat} > @Inject @Any Instance<Common> instance > {noformat} > injection point. > It is clear that instance.get() returns Bar. > It is however not clear whether instance.iterator() iterates over: > a) Bar > b) Foo, Bar > and whether instance.isAmbiguous() returns: > a) true > b) false -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-419) Clarify whether custom beans need to declare the qualifier "Any"

by Gunnar Morling (JIRA)

Gunnar Morling created CDI-419: ---------------------------------- Summary: Clarify whether custom beans need to declare the qualifier "Any" Key: CDI-419 URL: https://issues.jboss.org/browse/CDI-419 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Reporter: Gunnar Morling It's not obvious whether custom beans contributed through a portable extension need to return the {{Any}} qualifier from there {{getQualifier()}} methods or not (the CDI implementation would be required to add it if missing then). Concerned spec sections are: Section 2.3.1: {quote} Every bean has the built-in qualifier @Any, even if it does not explicitly declare this qualifier ... {quote} And section 11.1 which says: {quote} getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() must return the bean types, qualifiers, scope type, bean name and stereotypes of the bean, as defined in Chapter 2 {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

Is it required to explicitly add @Any for custom beans?

by Gunnar Morling

Hi, I'm registering a custom Bean implementation using a portable extension. Injection of this bean using the @Any qualifier fails unless I explicitly add this qualifier in the getQualifiers() implementation of my bean. Now the spec says in 2.3.1: "Every bean has the built-in qualifier @Any, even if it does not explicitly declare this qualifier [...]" Based on that, I had expected that I'm not required to add this qualifier to my custom bean implementation. Or am I misinterpreting the spec here? Thanks, --Gunnar

10 years, 2 months

3
4
0 / 0

exclude rules questions

by Mark Struberg

Hi! A few questions regarding exclude rules 1.) does .* mean only the package, but no sub-packages. Whereas .** also includes sub-packages? Marek brought up another interesting note: com.foo.** would according to the wording also exclude com.foobar... Is that intended? 2.) Are multiple children allowed in an exclude rule in beans.xml? There is a funny example in the spec: <exclude name="com.acme.ejb.**"> <if-class-available name="javax.enterprise.inject.Model"/> <if-system-property name="exclude-ejbs"/> </exclude> But I could not find the explanation what should happen. The if-class-available is nowhere stated. Or did I overlook it? txs and LieGrue, strub

10 years, 2 months

4
6
0 / 0

[JBoss JIRA] (CDI-234) behavior of arrays without @Nonbinding

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-234?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-234: ------------------------------- My PR had problems, that's why it wasn't merged. > behavior of arrays without @Nonbinding > -------------------------------------- > > Key: CDI-234 > URL: https://issues.jboss.org/browse/CDI-234 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Romain Manni-Bucau > Assignee: Pete Muir > Priority: Minor > Fix For: TBD > > > The spec says: > "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. > If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior > results." > The case of arrays without this annotation should be managed to get a better portability. The equality of arrays is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotat...) so i don't think there is any technical issue to consider arrays as a field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm (Perso)

by antoine.sabotdurand＠gmail.com

This event has been changed. Title: CDI 1.2 MR meeting Proposed agenda : - Ready to fix review and assignation - Discussion on other ticket - Progess and obstacles View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJi.... (changed) When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm Paris Where: IRC #jsr346 Channel on Freenode Calendar: Perso Who: (Guest list has been hidden at organizer's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJ... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2014