May 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in API JAR

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-509: ------------------------------------- Affects Version/s: 1.2.Final > Upgrade to latest felix plugin in API JAR > ----------------------------------------- > > Key: CDI-509 > URL: https://issues.jboss.org/browse/CDI-509 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: John Ament > Assignee: John Ament > > Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

Successfully using @Priority

by Michael Remijan

I wanted to let te team know that I've successfully incorporated the new @Priority annotation into my application and it seems to be working great. My application needs to startup in a particular order and prior to the @Priority annotation I had to create a class whose only job was this prioritization. I never liked this solution. The @Priority annotation is a lot nicer. Something I'd like to see in the documentation. The event the application is observing is my StartupConfigurationEvent class. Along side this class I created a StartupConfigurationPriorty class with a public static final int values in it which define the priority of the event processing. It's then very easy to find not only the classes observing that event but it also self documents the priorty without having to dig into each class.

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-526) Include filters

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-526: ---------------------------------- Maybe we should be more explicit that exclude filters (and possibly include filters) are *only applied to the types found in a specific bean archive*. E.g. users might be tempted to use include filters to "add" types from the classpath. > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > <exclude name="com.acme.rest.*" /> > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > <include name="my.application.*" /> > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-526) Include filters

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ] Emily Jiang updated CDI-526: ---------------------------- +1. I was going to raise a jira myself for this. On Mon, May 11, 2015 at 11:49 AM, Romain Manni-Bucau (JIRA) < -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > <exclude name="com.acme.rest.*" /> > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > <include name="my.application.*" /> > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-526) Include filters

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-526: ---------------------------------------- +1, would be far easier than excluding all the container and breaking the app each time you add a not CDi friendly dependency. > Include filters > --------------- > > Key: CDI-526 > URL: https://issues.jboss.org/browse/CDI-526 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > > CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: > {code:XML} > <exclude name="com.acme.rest.*" /> > {code} > With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: > {code:XML} > <include name="my.application.*" /> > {code} > Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

2
1
0 / 0

[JBoss JIRA] (CDI-526) Include filters

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-526: ----------------------------------- Summary: Include filters Key: CDI-526 URL: https://issues.jboss.org/browse/CDI-526 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Affects Versions: 1.2.Final Reporter: Jozef Hartinger CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g: {code:XML} <exclude name="com.acme.rest.*" /> {code} With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.: {code:XML} <include name="my.application.*" /> {code} Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-521) Create a Prioritized Interface for SPI element that have a priority

by Mark Paluch (JIRA)

[ https://issues.jboss.org/browse/CDI-521?page=com.atlassian.jira.plugin.sy... ] Mark Paluch commented on CDI-521: --------------------------------- Submitted code proposal together with PR https://github.com/cdi-spec/cdi/pull/242 > Create a Prioritized Interface for SPI element that have a priority > -------------------------------------------------------------------- > > Key: CDI-521 > URL: https://issues.jboss.org/browse/CDI-521 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > With the addition of ordering in Observer (CDI-4), we have a collection of element in SPI that could benefit having a {{getPriority()}} method: > * {{ObserverMethod}} > * {{Bean}} to be able to read alternative priority and give priority for {{Decorator}} and {{Interceptor}} > Any other place? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

Injecting classes with final package private methods

by ant elder

Hi CDI spec people, I've an application that uses CDI which breaks when moving from Java 1.6 to Java 1.7. The problem is that the application injects a java.util.Hashtable, and in Java 1.7 a new method, initHashSeedAsNeeded, was added to Hashtable and its a final method, so now the inject fails with: javax.enterprise.inject.UnproxyableResolutionException: WebBeans with api type with normal scope must be proxiable to inject. java.util.Hashtable has final method final boolean java.util.Hashtable.initHashSeedAsNeeded(int) CDI doesn't allow that. Why i'm asking about this here is because initHashSeedAsNeeded has default (package private) visibility, so i wondered if there was any chance that the change in CDI-159 could be interpreted as also allowing injecting classes with final package private visibility methods into classes in a different package? ...ant

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Emily Jiang updated CDI-525: ---------------------------- Agreed! I think Weld should be changed to comply with what CDI Spec says. On Tue, May 5, 2015 at 12:30 PM, Martin Kouba (JIRA) <issues(a)jboss.org> -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-525: ---------------------------------- It seems that OWB follows the current spec wording - see also [WebBeansUtil.getManagedBeanDefaultName()|http://grepcode.com/file/repo1.m...]. Given that the change would be backwards incompatible and not all implementations behave in the same way I'm not so sure it's a good idea anymore. > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2015