September 2016 - cdi-dev - Jboss List Archives

Passed: cdi-spec/cdi#54 (EDR2-with-assertions - ab444df)

by Travis CI

Build Update for cdi-spec/cdi ------------------------------------- Build: #54 Status: Passed Duration: 4 minutes and 18 seconds Commit: ab444df (EDR2-with-assertions) Author: Tomas Remes Message: Update paths to latest master. View the changeset: https://github.com/cdi-spec/cdi/compare/f7a2e81075d9^...ab444df7447f View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/158375957 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

7 years, 9 months

1
0
0 / 0

Proposal for CDI-580 (intercepors for producers and custom beans)

by Antoine Sabot-Durand

Hi all, Please review this proposal we made during F2F meeting regarding CDI-580: https://github.com/cdi-spec/cdi/tree/CDI-580 New spi interface is: https://github.com/antoinesd/cdi-spec/blob/c68730d294e614eee127288d7daa89... usage is here: https://github.com/antoinesd/cdi-spec/tree/c68730d294e614eee127288d7daa89... Antoine

7 years, 9 months

3
2
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-626 at 9/7/16 12:49 PM: ------------------------------------------------------------------- F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. Javadoc needs to be clarified on that point. was (Author: antoinesabot-durand): F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Work on CDI-626 started by Antoine Sabot-Durand. ------------------------------------------------ > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-626: ---------------------------------------- Assignee: Antoine Sabot-Durand > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-626: ------------------------------------------ F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

EDR2 officially launched

by Antoine Sabot-Durand

Hi all, In case you didn't notice, JCP has finally published our EDR2 last week-end ;). I'm preparing a blog post for that. Regarding our work, I've now put the master branch as the default one in the repo. All the (numerous ;) ) PRs will be done against master from now. Antoine

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-224) Support Decoration of no interface beans

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-224: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

Errored: cdi-spec/cdi#51 (CDI-580 - 8dfb614)

by Travis CI

Build Update for cdi-spec/cdi ------------------------------------- Build: #51 Status: Errored Duration: 6 minutes and 58 seconds Commit: 8dfb614 (CDI-580) Author: Antoine Sabot-Durand Message: Proposal for CDI-580 : Allow interceptors and decorators to be applied to the return value of a producer method Also works for custom beans create() View the changeset: https://github.com/cdi-spec/cdi/compare/c68730d294e6...8dfb6148da87 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/158169982 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-220. ------------------------------------ Resolution: Rejected Already specified (look at 1st comment) > behaviour of CDI bean @Specializes session bean is undefined > ------------------------------------------------------------ > > Key: CDI-220 > URL: https://issues.jboss.org/browse/CDI-220 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, F2F2016 > Fix For: 2.0 (discussion) > > > The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. > @Stateless > public class Horse {..} > @ApplicationScoped @Specializes > public class Trakehner extends Horse {..} > Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. > Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2016