March 2017 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-689) Typo or unclear message in 24.1.2

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-689?page=com.atlassian.jira.plugin.sy... ] John Ament updated CDI-689: --------------------------- Issue Type: Bug (was: Feature Request) > Typo or unclear message in 24.1.2 > --------------------------------- > > Key: CDI-689 > URL: https://issues.jboss.org/browse/CDI-689 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > > Section 24.1.2 includes the following text: > {quote} > When Running in Java EE, the container must extend the rules defined in Observer method invocation context and must also ensure that > All kinds of observers are called in the same client security context as the invocation of Event.fire() or Event.fireAsync() or BeanManager.fireEvent(). > {quote} > The break after "that" in the first line seems weird, its not clear if its supposed to continue into the second line, or if the sentence is intended to continue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-688) Contextual bean stores

by John Ament (JIRA)

John Ament created CDI-688: ------------------------------ Summary: Contextual bean stores Key: CDI-688 URL: https://issues.jboss.org/browse/CDI-688 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Right now, the notion of how beans are stored are ambiguous. The implementations back them by maps. This may work well, but there's some amount of plugability required to make passivation capable beans work right. A single request makes sense to store in a map. Sessions are stored in the HTTPSession. We should allow these bean stores to be more pluggable, allowing users or implementations to override how their beans are stored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-687) Programmatic activation of an existing conversation by conversation id

by John Ament (JIRA)

John Ament created CDI-687: ------------------------------ Summary: Programmatic activation of an existing conversation by conversation id Key: CDI-687 URL: https://issues.jboss.org/browse/CDI-687 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, conversation activation can only work if you have an HTTP request with cid query param passed in. We should expand this to allow any arbitrary lookup of conversation by id. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

JSR365(CDI2.0)Public Review Comment

by hiromi_18_takahashi＠mufg.jp

CDI developer all Hi, I'm Hiromi Takahashi. I work for Mitsubishi UFJ Information Technology. Our company is in charge of Mitsubishi UFJ financial group system development, operation and maintenance. And then , I'm in charge of in-house Java framework. Our Java framework depends heavily on Java SE and Java EE technologies. I reviewed JSR365 (CDI2.0) Public Review . I think it's great. On the other hand, to make things even better, I would like to suggest the following: ・About CDI's goal in Java SE What I think is great about CDI is its ability to inject to Java object "transparently". However, with the current spec of CDI, it requires some coding each time to get the injected objects. For example, in getNewInstance() method, I think it would be great if CDI could judge if there was an injected field or not (ie. if there is an injected field then CDI injects, and if not CDI just makes a new instance.) How we code would be even simpler and more beautiful. This way, users can always generate instances in such standard method. Also, it could be even better if CDI could act like below when using "new" descriptor: - If the class has injected field, then get the injected instances - If the class has no injected field, then just simply get a new instance In Java EE, these functions are the container's role and CDI may not have to be in charge of them. However, considering CDI may be used in Java SE, I think CDI needs to act like above in the future. Best regards. ############################################################## Mitsubishi UFJ Information Technology,Ltd. 　Management Information Systems Platforms Department. Hiromi Takahashi tel：+81-3-5859-1525 mail：hiromi_18_takahashi(a)mufg.jp ##############################################################

7 years, 10 months

2
1
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: ------------------------------------- Fix 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 > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > 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... ] Work on CDI-686 started by Antoine Sabot-Durand. ------------------------------------------------ > 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 > Assignee: 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 reassigned CDI-686: ---------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Assignee: 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-684) Should portable extension support static observer method

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.sy... ] Work on CDI-684 started by Antoine Sabot-Durand. ------------------------------------------------ > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-684) Should portable extension support static observer method

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-684: ------------------------------------------ EG agreed to explicitly make this feature non-portable > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-684) Should portable extension support static observer method

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-684: ---------------------------------------- Assignee: Antoine Sabot-Durand > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- 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 March 2017