August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-230) Clarify that some Scope constellations for producer fields result in non portable behaviour

by Mark Struberg (JIRA)

Mark Struberg created CDI-230: --------------------------------- Summary: Clarify that some Scope constellations for producer fields result in non portable behaviour Key: CDI-230 URL: https://issues.jboss.org/browse/CDI-230 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.1.EDR1 Reporter: Mark Struberg Fix For: 1.1 (Proposed) We should add something like the following to the producer-field paragraph: "When a producer field produces a bean with a 'shorter' Lifecycle than the scope of the class the producer field is defined in, non-portable behaviour results." An example: {code} @ApplicationScoped public class ContainerBean { @Produces @RequestScoped Something something = new Something(1, 2, 3); void throwAway(@Disposes Something sthg) { sthg.destroyMe(); } } {code} The problem is that each request will take 'something' from the @ApplicationScoped ContainerBean. Thus all requests share the same contextual instance! Afer the first request ends, the disposal method 'throwAway' will destroy the information inside the variable 'something' and leaves it in a broken state for all other requests -> bang... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
4
0 / 0

[JBoss JIRA] (CDI-62) Clarify @Resource/@PersistenceContext/etc. on disabled alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-62?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-62: ------------------------- Issue Type: Tracker (was: Clarification) This is governed by the Java EE spec > Clarify @Resource/@PersistenceContext/etc. on disabled alternatives > ------------------------------------------------------------------- > > Key: CDI-62 > URL: https://issues.jboss.org/browse/CDI-62 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Is it expected that the container validates these dependencies and fails deployment if they don't exist? I think it is, right? At least, I think some containers behave this way. Then we should say that this validation should *not* happen if the annotation appears in a class annotated @Alternative. I have no idea what the right language would be... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-55) Bean declaration at constructor level

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-55?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-55: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) I've never seen a community request for this > Bean declaration at constructor level > ------------------------------------- > > Key: CDI-55 > URL: https://issues.jboss.org/browse/CDI-55 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > http://www.seamframework.org/Weld/DependencyInjectionWishlist#H-ProducerC... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-55) Bean declaration at constructor level

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-55?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-55: ------------------------- Description: http://www.seamframework.org/Weld/DependencyInjectionWishlist#H-ProducerC... > Bean declaration at constructor level > ------------------------------------- > > Key: CDI-55 > URL: https://issues.jboss.org/browse/CDI-55 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > http://www.seamframework.org/Weld/DependencyInjectionWishlist#H-ProducerC... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-53) Datasources and other resources defined on alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-53?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-53: ------------------------- Issue Type: Tracker (was: Feature Request) Forum Reference: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-TtDataSourc... (was: http://www.seamframework.org/Weld/JavaEEIntegrationWishlist#H-TtDataSourc...) This is governed by the Java EE spec. > Datasources and other resources defined on alternatives > ------------------------------------------------------- > > Key: CDI-53 > URL: https://issues.jboss.org/browse/CDI-53 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Priority: Minor > Fix For: 1.1 (Proposed) > > > http://download.oracle.com/javaee/6/api/javax/annotation/sql/DataSourceDe... -- if this is used on an alternative class, only enable it if the alternative is enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-43: ------------------------- Assignee: Pete Muir Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-43: ------------------------------ First draft, only for ProcessAnnotatedType, at https://github.com/jboss/cdi/pull/88 I'm not sure this makes sense more generally. I think for ProcessBean and ProcessBeanAttributes, ProcessObserverMethod and ProcessInjectionPoint I would prefer to be able to use qualifiers to restrict the beans processed. For producers, it would probably make sense to use only annotations on the annotated member and it's parameters. For InjectionTarget's probably only type level annotations. For observer methods, I guess event qualifiers make sense. I would prefer to start with just ProcessAnnotatedType, and go from there. Maybe we should loosen it to non-portable to use @WithAnnotations elsewhere, making it possible for implementations to experiment. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1.PRD > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-94) Producer field initializers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-94?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-94. -------------------------- Assignee: Pete Muir Fix Version/s: 1.1.EDR (was: 1.1 (Proposed)) Resolution: Done Gavin had already done this. > Producer field initializers > --------------------------- > > Key: CDI-94 > URL: https://issues.jboss.org/browse/CDI-94 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

Removed commented out sections

by Pete Muir

All A left over from the CDI 1.0 days, when the spec wasn't in public VCS, was the extensive amount of commented out sections and notes. I've removed all of these, as they just make editing the spec harder. If you notice any oddities with the spec since this, please shout! Pete

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-195) Clarify serializability requirements for extension-provided metadata

by Jozef Hartinger (Created) (JIRA)

Clarify serializability requirements for extension-provided metadata -------------------------------------------------------------------- Key: CDI-195 URL: https://issues.jboss.org/browse/CDI-195 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The spec never requires an extension-provided implementation of the Bean, Interceptor, Decorator or InjectionPoint to be serializable. The implementation indicates, whether the underlying bean is passivation capable by implementing PassivationCapable, but the implementation itself does not have to be serializable. For both the InjectionPoint bean and Bean metadata bean the spec says: "The built-in implementation must be a passivation capable dependency". However, this is hard to guarantee if an extension provides a non-serializable implementation of a Bean/InjectionPoint interface, e.g. the following code would cause problems at passivation: public class Bar implements Serializable { @Inject private InjectionPoint ip; } If the metadata of the Bar bean (Bean<Bar>) is not serializable, Bar cannot be passivated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

7
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012