Canceling meeting today
by Antoine Sabot-Durand
Hi guys,
I'm sick and won't be able to attend our meeting today.
See you,
Antoine
8 years, 10 months
[JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-554 at 2/22/16 9:48 AM:
-----------------------------------------------------------
Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available when the request scope is active (servlet {{service()}} invocation, {{@PostConstruct}} callback, etc.).
was (Author: mkouba):
Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available during HTTP request processing.
> Additional built-in beans do not have a scope defined
> -----------------------------------------------------
>
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Martin Kouba
>
> See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything.
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-554:
----------------------------------
Yes, John {{@ApplicationScoped}} could be a better match for ServletContext. AFAIR there some problems with EAR deployments in Weld (see also WELD-1621). But it should be possible to identify the correct ServletContext by means of TCCL. In any case, it's not defined at the moment and in Weld the ServletContext is only available during HTTP request processing.
> Additional built-in beans do not have a scope defined
> -----------------------------------------------------
>
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Martin Kouba
>
> See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything.
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-554:
----------------------------------
I'm not so sure this clarification is needed any longer. From the user point of view, it doesn't seem to be necessary.
> Additional built-in beans do not have a scope defined
> -----------------------------------------------------
>
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Martin Kouba
>
> See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything.
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-584:
------------------------------------------
Good catch. Error was on purpose to check your attention ;)... Ok, bad version pasted.
We should have
{code}
Set<InjectionPoint> ips = bean.getInjectionPoints();
{code}
I create the ticket for addition to {{ProcessBean}}
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-584 at 2/19/16 9:45 AM:
-----------------------------------------------------------
I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful. By the way, the example wouldn't work because {{ips}} is not a reference to the original set of injection points (it only contains all the elements from the original set ;-).
was (Author: mkouba):
I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful.
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-584:
----------------------------------
I see, that's a good example. So something like {{ProcessBean#setInjectionPoints()}} might be useful.
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-584 at 2/19/16 9:42 AM:
-----------------------------------------------------------
I see, that's a good example. So something like {{ProcessBean#setBeanInjectionPoints()}} might be useful.
was (Author: mkouba):
I see, that's a good example. So something like {{ProcessBean#setInjectionPoints()}} might be useful.
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-584 at 2/19/16 9:23 AM:
-------------------------------------------------------------------
To that I could answer, "what's the use of ProcessBean if you can't do anything about the bean tied to the event" ;) ?
But I have an example. I was asked to build a prototype extension to create an injection point when a given annotation ({{@CacheContext}}) is found on a field. Here's the portable code I had to wrote to create the feature :
* An AnnotatedType [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab9...]
* An AnnotatedField [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab9...]
* and the [Extension|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68d...]
Extension code is small but {{AnnotatedType}} and {{AnnotatedField}} impls are verbose and the whole is cumbersome to read and maintain (3 classes and 178 lines of code)
If we only target OWB, the extension code is:
{code}
package org.cdisandbox.autoinject.Extension;
import org.cdisandbox.autoinject.CacheContext;
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.*;
import java.util.HashSet;
import java.util.Set;
/**
* Extension looking for the @CacheContext annotation to transform it in an InjectionPoint
*/
public class AutoInjectExtension implements Extension {
private Set<AnnotatedType<?>> atWithCacheContext = new HashSet<>();
/**
* This Observer captures all AnnotatedType containing @CacheContext
*/
public void CreateInjectionPoint(@Observes @WithAnnotations(CacheContext.class) ProcessAnnotatedType<?> pat) {
atWithCacheContext.add(pat.getAnnotatedType());
}
/**
* This observer add an injection point in all bean having @Cachecontext annotaion on some field
*/
public <T> void CheckBeansForCacheContext(@Observes ProcessManagedBean<T> pmb, BeanManager bm) {
AnnotatedType<T> beanAT = pmb.getAnnotatedBeanClass();
if(atWithCacheContext.contains(beanAT)) {
Bean<T> bean = pmb.getBean();
Set<InjectionPoint> ips = new HashSet(bean.getInjectionPoints());
for (AnnotatedField<? super T> f : beanAT.getFields()) {
if(f.isAnnotationPresent(CacheContext.class)) {
ips.add(bm.createInjectionPoint(f));
}
}
}
}
}
{code}
One class, 42 lines.
was (Author: antoinesabot-durand):
To that I could answer, "what's the use of ProcessBean if you can't do anything about the bean tied to the event" ;) ?
But I have an example. I was asked to build a prototype extension to create an injection point when a given annotation ({{@CacheContext}}) is found on a field. Here's the portable code I had to wrote to create the feature :
* An AnnotatedType [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab9...]
* An AnnotatedField [implementation|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab9...]
* and the [Extension|https://github.com/antoinesd/CDI-Sandbox/blob/fb18eb718ab93f68d...]
Extension code is small but {{AnnotatedType}} and {{AnnotatedField }} are verbose and the whole is cumbersome to read and maintain (3 classes and 178 lines of code)
If we only target OWB, the extension code is:
{code}
package org.cdisandbox.autoinject.Extension;
import org.cdisandbox.autoinject.CacheContext;
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.*;
import java.util.HashSet;
import java.util.Set;
/**
* Extension looking for the @CacheContext annotation to transform it in an InjectionPoint
*/
public class AutoInjectExtension implements Extension {
private Set<AnnotatedType<?>> atWithCacheContext = new HashSet<>();
/**
* This Observer captures all AnnotatedType containing @CacheContext
*/
public void CreateInjectionPoint(@Observes @WithAnnotations(CacheContext.class) ProcessAnnotatedType<?> pat) {
atWithCacheContext.add(pat.getAnnotatedType());
}
/**
* This observer add an injection point in all bean having @Cachecontext annotaion on some field
*/
public <T> void CheckBeansForCacheContext(@Observes ProcessManagedBean<T> pmb, BeanManager bm) {
AnnotatedType<T> beanAT = pmb.getAnnotatedBeanClass();
if(atWithCacheContext.contains(beanAT)) {
Bean<T> bean = pmb.getBean();
Set<InjectionPoint> ips = new HashSet(bean.getInjectionPoints());
for (AnnotatedField<? super T> f : beanAT.getFields()) {
if(f.isAnnotationPresent(CacheContext.class)) {
ips.add(bm.createInjectionPoint(f));
}
}
}
}
}
{code}
One class, 42 lines.
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
