July 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-448) Clarify autoboxing of arrays

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-448: ----------------------------------- Summary: Clarify autoboxing of arrays Key: CDI-448 URL: https://issues.jboss.org/browse/CDI-448 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Jozef Hartinger Section 2.2.1: {quote} • A bean type may be an array type. Two array types are considered identical only if the element type is identical. • A bean type may be a primitive type. Primitive types are considered to be identical to their corresponding wrapper types in java.lang. {quote} When these two rules are combined, autoboxing of arrays is implied. For example, having type A defined as int[] and type B defined as Integer[] then: 1) these two array types are considered identical as long as their element types (int and Integer) are identical 2) int and Integer are considered identical (as primitive types are considered identical to java.lang wrapper types) Thus, A and B are considered identical. This is however in contrast to JLS where array autoboxing is not supported - you cannot do int[] foo = new Integer[0]; It should therefore be clarified if array autoboxing is also unsupported in CDI or whether a CDI implementation should do the extra work to support this (e.g. allocating a new array and copying autboxed values over before injecting) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

CDI 2.0 JSR proposal needs supporters

by Antoine Sabot-Durand

Hi all, Pete and I just finished the draft of CDI 2.0 JSR proposal. It’s there : https://docs.google.com/document/d/1al1rdAs3CN34a9zTe3cXsLL4LBfHhzP8EbuDJ... The proposal now needs supporter to be ready for submission, so if you or your company is member of the JCP or play a visible role in Java community and willing to support officially this JSR, please let us know. The document is open for comments but please use this only if you have an important point that couldn’t be discussed after JSR launch. Don’t forget to check the companion doc of this JSR regarding introduction of « parts » in CDI : https://docs.google.com/document/d/1jzCuFQjtCSrnZGRAHjn0oknWvEaP3h0KizW1m... The information in the document is not part of the JSR proposal, just a first idea of what parts could be. The only thing that we’d want to make official in the JSR proposal is this concept of parts. Their granularity, number or included features will be discussed by the futur EG. Thank you for your commitment and feedback, Antoine

10 years, 5 months

3
3
0 / 0

Renaming the Spec for CDI 2.0 ?

by Antoine Sabot-Durand

Hi, As we intend to include Java SE support, Martin propose to rename the complete name of the spec « Contexts and Dependency Injection for Java EE » by removing the EE. New name would be « Contexts and Dependency Injection for Java ». On the principle I’m ok with that except if it brings issue with the JCP or Java EE 8 EC. What do you think ? Antoine

10 years, 5 months

3
3
0 / 0

[JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-447: ---------------------------------- Well yes, this section could be split into several subsections. Right now it contains five lists and is not very easy to read. > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > • Library jars, EJB jars or application client jars > • The WEB-INF/classes directory of a war > • Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification

by Phil Zampino (JIRA)

[ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.sy... ] Phil Zampino commented on CDI-447: ---------------------------------- Thanks for the clarification. Do you agree that it's not clear in the spec that this only applies to embeddable EJB containers? > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > • Library jars, EJB jars or application client jars > • The WEB-INF/classes directory of a war > • Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-447?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-447: ---------------------------------- I think this only applies to an embeddable EJB container, see paragraph below: {quote} The container searches for beans in all bean archives in the application classpath: * In an application deployed as an ear, ... {quote} And in fact, an embeddable EJB container is not even covered by the TCK. > Section 12.1 specifies that JVM classpath must be included in bean archive identification > ----------------------------------------------------------------------------------------- > > Key: CDI-447 > URL: https://issues.jboss.org/browse/CDI-447 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Phil Zampino > > Section 12.1 of the spec states: > When determining which archives are bean archives, the container must consider: > • Library jars, EJB jars or application client jars > • The WEB-INF/classes directory of a war > • Directories in the JVM classpath > For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-447) Section 12.1 specifies that JVM classpath must be included in bean archive identification

by Phil Zampino (JIRA)

Phil Zampino created CDI-447: -------------------------------- Summary: Section 12.1 specifies that JVM classpath must be included in bean archive identification Key: CDI-447 URL: https://issues.jboss.org/browse/CDI-447 Project: CDI Specification Issues Issue Type: Clarification Components: Packaging and Deployment Affects Versions: 1.2.Final Reporter: Phil Zampino Section 12.1 of the spec states: When determining which archives are bean archives, the container must consider: • Library jars, EJB jars or application client jars • The WEB-INF/classes directory of a war • Directories in the JVM classpath For CDI 1.0, I think the inclusion of "directories in the JVM classpath" would not be a big deal. However, since the introduction of implicit bean archives, I'm wondering if implementations are required to scan the JVM classpath for classes annotated with bean-defining annotations. This seems like it has the potential to be an expensive requirement, and it should not be required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-446) Clarify validity/invalidity of using direct access to public fields

by Tomas Remes (JIRA)

Tomas Remes created CDI-446: ------------------------------- Summary: Clarify validity/invalidity of using direct access to public fields Key: CDI-446 URL: https://issues.jboss.org/browse/CDI-446 Project: CDI Specification Issues Issue Type: Clarification Reporter: Tomas Remes The spec could clarify validity/invalidity of using direct access to public fields. Accessing public fields directly could cause potential problems, when testing/using various implementations - see linked issue. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2014