February 2017 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-686: ------------------------------------------ [~rmannibucau]I'm not sure to understand your point. {{InterceptionFactory.createInterceptedInstance()}} requires an object instance to be intercepted. This proposal doesn't prevent its usage in a custom {{Bean<T>}} since in {{InterceptionFactory<U>}}, {{U}} is related to instances class and not to beans types (even if they are linked of course). > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- Hmm, isnt one of the goals of this factory to make custom beans (Bean<>) easily integrated with CDI interceptors? If so it is common to have java.lang.reflect based proxies there (see deltaspike ones for instance) and it is very nice and smooth to be able to reuse cdi there. Here a trivial but obvious example: take a repository like proxy based implementation, don't you want to integrate it with jcache which has its own interceptor without coding more than the factory itself? Today it requires to either be bound to a jcache implementation or reimplement the interceptor chain logic from the container which is a pain. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-686: ---------------------------------- +1 for non-portable behavior. I don't think it makes much sense to support interfaces here. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-686: ------------------------------------------ I suggest that we make this usage non portable to let implementation decide and let the door open for a future specification. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Description: If you take this code: {code:java} @Produces public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { if (m.getJavaMember().getName().equals("add") && m.getJavaMember().getParameterCount() == 1) { return true; } return false; }).findFirst().get().add(Monitor.Literal.INSTANCE); return interceptionFactory.createInterceptedInstance(new ArrayList<>()); } {code} Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. was:It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List<Object> produceList(InterceptionFactory<List<Object>> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List<Object>}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Summary: Could InterceptionFactory accept an interface as type parameter (was: InterceptionFactory parameter type vs type of instance to intercept) > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Affects Version/s: 2.0 .Final > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-686) InterceptionFactory parameter type vs type of instance to intercept

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-686: ---------------------------------------- Summary: InterceptionFactory parameter type vs type of instance to intercept Key: CDI-686 URL: https://issues.jboss.org/browse/CDI-686 Project: CDI Specification Issues Issue Type: Clarification Reporter: Antoine Sabot-Durand It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-114) Allow registration of beans at runtime

by Vincent Massol (JIRA)

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Vincent Massol commented on CDI-114: ------------------------------------ {quote}Hmm, does it means xwiki is leaking cause previously injected values can be unregistered ("remove extension")?{quote} Actually I don't know how we would behave if you remove at runtime a component that's been previously injected in another component. In theory yes there should be a problem.In practice in 12 years of XWiki I've never seen this happen. {quote}Or did you mean you never inject the component by type but always Provider<X> everywhere? {quote} No we don't do that systematically, although we recommend it. It's done mostly at places where it's important to be able to use the latest registered component for a given role. {quote}If so you also do lazy validation which means you accept to start a not functional app cause of a missing component - CDI prevents it. Is that right?{quote} Yes we do allow this. Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-114) Allow registration of beans at runtime

by Vincent Massol (JIRA)

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Vincent Massol commented on CDI-114: ------------------------------------ Hi [~ljnelson]. Thanks for mentioning HK2, I didn't know about it. I'll check it out. At first glance, it look very similar to what we have implemented in XWiki. I'll read more about it. However I'm not sure it would justify the effort to switch to it. We don't have any problem with our custom Component Manager and it's low cost maintenance now. What would improve the XWiki technology stack would be to move to a "standard" DI framework. CDI would probably have been the most standard option if it had supported runtime addition of beans. Guice would be another possibility but I'd need to check how dynamicity could be implemented (I remember reading that it was possible). Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2017