September 2017 - cdi-dev - Jboss List Archives

Interceptor bindings from interceptor when using 2.0 interception factory

by arjan tijms

Hi, Normally a workaround to get the interceptor bindings from within an Interceptor is to inspect the target and/or the injected intercepted bean. However, when adding an interceptor via the new CDI 2.0 interception factory, things become a bit more muddy. See e.g. https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/interce... Weld has the following method to get the bindings from the InvocationContext: Set<Annotation> bindings = (Set<Annotation>) invocationContext.getContextData().get("org.jboss.weld.interceptor.bindings"); But this is obviously non-standard. Is there a standard way to get the bindings? Perhaps getting hold of the Bean<T> that represents the current Interceptor? Kind regards, Arjan Tijms

7 years, 2 months

2
7
0 / 0

Moving build-in bean for Principal to Java EE Security?

by arjan tijms

Hi, I wonder, wouldn't it be a good idea to let JSR 375 take ownership of the build-in bean in the Java EE part of CDI for Principal? The CDI spec proposed to the servlet spec to take ownership of the build-in beans for the Servlet owned artefacts (such as HttpServletRequest) before. Kind regards Arjan Tijms

7 years, 2 months

2
2
0 / 0

[JBoss JIRA] (CDI-718) Bean creation and dependency injection should not be performed before AfterDeploymentValidation

by Martin Kouba (JIRA)

Martin Kouba created CDI-718: -------------------------------- Summary: Bean creation and dependency injection should not be performed before AfterDeploymentValidation Key: CDI-718 URL: https://issues.jboss.org/browse/CDI-718 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Fix For: 2.1 (Discussion) The spec is clear that it is not allowed to invoke {{BeanManager.getReference()}}, {{BeanManager.getInjectableReference()}} and {{BeanManager.createInstance()}} before {{AfterDeploymentValidation}}. I.e. it could be safely used during {{AfterDeploymentValidation}} and after the application initialization finished. The reason is that before ADV the set of beans/interceptors/decorators may not be complete and extensions can still affect the resolution. However, using {{InjectionTarget}}, {{UnmanagedInstance}} and {{Contextual.create()}} has the same risks. I think we should clarify the usage so that the spec is consistent. WRT backward compatibility - note that the container is permitted to define a non-portable mode to overcome problems with legacy applications not using CDI SPI properly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-717) Element mistakenly removed from beans_2_0.xsd

by Matej Novotny (JIRA)

Matej Novotny created CDI-717: --------------------------------- Summary: Element mistakenly removed from beans_2_0.xsd Key: CDI-717 URL: https://issues.jboss.org/browse/CDI-717 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0 .Final Reporter: Matej Novotny While creating and editing {{beans_2_0.xsd}} there was one line removed as part of [this PR|https://github.com/cdi-spec/cdi/pull/348]. This line is present in {{beans_1_1.xsd}} -> [see the code|https://github.com/cdi-spec/cdi/blob/master/api/src/main/resources/b...]. To sum up the meaning of this line, it allows presence of any other non-defined element from _other namespace (than target namespace)_ and further on enforces validation of such element against corresponding XSD. As a consequence of this change, following {{beans.xml}} is valid with CDI 1.2 ({{beans_1_1.xsd}}) but no longer against CDI 2.0 ({{beans_2_0.xsd}}): {code} <?xml version="1.0" encoding="UTF-8"?> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:weld="http://jboss.org/schema/weld/beans" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" bean-discovery-mode="all"> <weld:scan> <weld:include name="my.package.*"/> </weld:scan> </beans> {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-455) Allow building of TypeLiteral's with dynamic types

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-455: ---------------------------------- I think we should add {{Event.select()}} and {{Instance.select()}} variants which also accept {{java.lang.reflect.Type}}. The argument should be checked at runtime and {{IllegalArgumentException}} should be thrown if the type is not a subtype of the event/required type. Also the trick with {{ChocolateEater}} described above would only work for simple parameterized types and not for more complex use cases. > Allow building of TypeLiteral's with dynamic types > -------------------------------------------------- > > Key: CDI-455 > URL: https://issues.jboss.org/browse/CDI-455 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Lucas Ventura Carro > Fix For: 2.1 (Discussion) > > > It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-wi...]. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-455) Allow building of TypeLiteral's with dynamic types

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-455: ----------------------------- Fix Version/s: 2.1 (Discussion) > Allow building of TypeLiteral's with dynamic types > -------------------------------------------------- > > Key: CDI-455 > URL: https://issues.jboss.org/browse/CDI-455 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Lucas Ventura Carro > Fix For: 2.1 (Discussion) > > > It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-wi...]. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

Ожених се

by Todor Boev

*______________________* *Todor Boev* OSGi Platform *Software AG* *From:* Yakub, Esin *Sent:* Monday, September 18, 2017 8:20 AM *To:* Z_Country_Bulgaria *Subject:* Ожених се Бонбоните са в кухнята J Ето <https://scontent-sof1-1.xx.fbcdn.net/v/t31.0-8/21273381_812588565589027_5...> я щастливата булка, а аз съм си… аз <https://scontent-sof1-1.xx.fbcdn.net/v/t31.0-8/21457502_814606792053871_1...> . Успешна седмица!

7 years, 3 months

1
1
0 / 0

[JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.sy... ] Martin Kouba edited comment on CDI-610 at 9/20/17 2:58 AM: ----------------------------------------------------------- Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using [BeanManager.createInstance().select(InjectionPoint.class).get()|https://g...]) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (e.g. https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o...). Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail) was (Author: mkouba): Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using {{BeanManager.createInstance().select(InjectionPoint.class).get()}}) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o...). Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail) > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean<T>#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean<? extends Object> bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean<T>}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injecti... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-610: ---------------------------------- Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using {{BeanManager.createInstance().select(InjectionPoint.class).get()}}) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/o...). Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail) > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean<T>#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean<? extends Object> bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean<T>}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injecti... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.sy... ] arjan tijms commented on CDI-610: --------------------------------- Just wondering, any updates for this? Would this be in scope for CDI 2.1 perhaps? > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean<T>#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean<? extends Object> bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean<T>}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injecti... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2017