June 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-435?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-435: ------------------------------------- Fix Version/s: 2.0 (proposed) > cdi-spec.org/faq outdated > ------------------------- > > Key: CDI-435 > URL: https://issues.jboss.org/browse/CDI-435 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-414: ------------------------------------- Fix Version/s: 2.0 (discussion) > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected'

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-420: ------------------------------------- Fix Version/s: 2.0 (discussion) > add a bean-discovery-mode 'detected' > ------------------------------------ > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class with a bean defining annotation in an implicit bean archive. > • each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-409) Having @Alternatives for resource definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-409?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-409: ------------------------------------- Issue Type: Feature Request (was: Bug) > Having @Alternatives for resource definition > -------------------------------------------- > > Key: CDI-409 > URL: https://issues.jboss.org/browse/CDI-409 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: TBD > Reporter: Antonio Goncalves > > Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of defining other resources (JMS factory/destination, Mail factory, JCA connectors....). > It would be interesting to have @Alternatives working with these resource definitions. For example you could have a default DS for development : > {code} > @DataSourceDefinition( > className = "org.apache.derby.jdbc.EmbeddedDataSource", > name = "java:global/jdbc/devDS", > user = "dev", > password = "dev", > databaseName = "dev", > properties = {"connectionAttributes=;create=true"} > ) > public class DevResources {...} > {code} > And another DS that would be used, let say, in production as an alternative : > {code} > @Alternative > @DataSourceDefinition( > className = "org.apache.derby.jdbc.EmbeddedDataSource", > name = "java:global/jdbc/prodDS", > user = "prod", > password = "prod", > databaseName = "prod", > properties = {"connectionAttributes=;create=true"} > ) > public class ProdResources {...} > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-416) Typo for @PersistencContext at section 7.3.6

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-416?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-416. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done > Typo for @PersistencContext at section 7.3.6 > -------------------------------------------- > > Key: CDI-416 > URL: https://issues.jboss.org/browse/CDI-416 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Michel Graciano > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 2.0-EDR1 > > > At section 7.3.6 [1] there is a typo for @PersistencContext where it should be @PersistenceContext. > [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#resource_lifecycle -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-438: ------------------------------------------ Spec was corrected with CDI-538. I removed the comment in API. I'm afraid we have to keep this "wrong order" in API. therefore it becomes the "right order". With this change done, is there still any reason to prevent delivering of {{ProcessProducerMethod<Foo,Producer>}} to observer of {{ProcessBean<Foo>}}? I think it could make sense in certain use cases... > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>. > {quote} > API: > {code:java} > /** > * @param <T> The return type of the producer method > * @param <X> The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod<T, X> extends ProcessBean<X> { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-438: ---------------------------------------- Assignee: Antoine Sabot-Durand > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>. > {quote} > API: > {code:java} > /** > * @param <T> The return type of the producer method > * @param <X> The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod<T, X> extends ProcessBean<X> { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-438: ------------------------------------- Fix Version/s: 2.0 (discussion) > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>. > {quote} > API: > {code:java} > /** > * @param <T> The return type of the producer method > * @param <X> The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod<T, X> extends ProcessBean<X> { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-523: ------------------------------------- Fix Version/s: 2.0 (discussion) > CDI spec tries to dispose a container-managed entity manager. > ------------------------------------------------------------- > > Key: CDI-523 > URL: https://issues.jboss.org/browse/CDI-523 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final, 1.1.Final > Reporter: Martin Andersson > Fix For: 2.0 (discussion) > > > Section "3.5.2. Declaring a disposer method" has this example: > {code:java} > public class Resources { > @PersistenceContext > @Produces @UserDatabase > private EntityManager em; > > public void close(@Disposes @UserDatabase EntityManager em) { > em.close(); > } > } > {code} > The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says: > {quote} > The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager. > {quote} > This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-449) beans.xml examples are not valid

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-449: ------------------------------------- Fix Version/s: 2.0 (discussion) > beans.xml examples are not valid > -------------------------------- > > Key: CDI-449 > URL: https://issues.jboss.org/browse/CDI-449 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well. > The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2015