February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-141) remove overly strict Serialization requirements for @Inject method and ct parameters

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-141?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-141: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > remove overly strict Serialization requirements for @Inject method and ct parameters > ------------------------------------------------------------------------------------ > > Key: CDI-141 > URL: https://issues.jboss.org/browse/CDI-141 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Mark Struberg > Priority: Minor > Fix For: 1.1.PFD > > > Section 6.6.4 declares that: > > If a producer method declares a passivating scope and: > > .. > > * has a parameter that does not resolve to a passivation capable > > dependency, > > then the container automatically detects the problem and > > treats it as a deployment problem. > Something like > @Produces @SessionScoped @AutoAuthenticated > public User getCurrentUser(MyConfig mc) { > return ... > (MyConfig is not Serializable and gets produced as @ApplicationScoped) would not be allowed. > The same restriction currently applies to parameters of @Inject methods and constructors: > >If a managed bean which declares a passivating scope: > > has a ... , bean constructor parameter or initializer method parameter > > that does not resolve to a passivation capable dependency, ... > This maybe comes from simple @Inject setters which set the given method parameters 1:1 into class members. But for all other cases this restriction is just way too rigid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-70: ------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-306) Clarify that MDBs don't need to support injected constructors

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-306?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-306: -------------------------------- In what cases wouldn't you want to support an injected constructor here? > Clarify that MDBs don't need to support injected constructors > ------------------------------------------------------------- > > Key: CDI-306 > URL: https://issues.jboss.org/browse/CDI-306 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1.PFD > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-223) Verify that it's 100% clear that any EJB "remote" invocation which doesn't occur when an existing request context is active, starts/ends it's own request context

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-223: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Verify that it's 100% clear that any EJB "remote" invocation which doesn't occur when an existing request context is active, starts/ends it's own request context > ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-223 > URL: https://issues.jboss.org/browse/CDI-223 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Reporter: Pete Muir > Assignee: Joe Bergmark > Fix For: 1.1.PFD > > > This should apply to JVM-local or JVM-remote remote invocations -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-75: ------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Clarify what happens to a bean which belongs to inactive when it observes an event > ---------------------------------------------------------------------------------- > > Key: CDI-75 > URL: https://issues.jboss.org/browse/CDI-75 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-280: -------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Fix For: TBD > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-52: ------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PFD > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-87) Declarative control over classes including in bean archive scanning

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-87: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: TBD > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-229) introduce @OverridesAttribute for @StereoType

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-229?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-229: -------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > introduce @OverridesAttribute for @StereoType > --------------------------------------------- > > Key: CDI-229 > URL: https://issues.jboss.org/browse/CDI-229 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Fix For: TBD > > > We recently had a thread on the DeltaSpike list about using StereoTypes in real world applications: http://markmail.org/thread/ntqwnsyukjvdwspm > ------ > Imagine the following Stereotype for my Services (I spare out the standard > stuff) > @StereoType @Secured @Transactional @ApplicationScoped > public @interface @Service {} > The problem here is that there is no way to 'propagate' any rolesAllowed from > @Service to @Secured, etc. > What I'd like to have is something like ... > public @interface @Service { > String[] rolesAllowed(); > TransactionAttributeType transactionType(); > } > where the rolesAllowed() would get propagated to the @Secured meta-annotation > and transactionType() to the @Transactional > ----------- > Gerhard Petracek now pointed me to a cool feature which is used in JSR-303 BVAL: @OverridesAttribute > http://docs.oracle.com/javaee/6/api/javax/validation/OverridesAttribute.html > We should ping the BVAL EG for the details. There are quite a few little tricks and side effects to consider. > On the implementation side, we could e.g. pick the @StereoType annotation and automatically propagate those values to the AnnotatedType which get's passed to the Extensions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-268: -------------------------- Fix Version/s: 1.1.PFD (was: 1.1 (Proposed)) > Limitations in the SPI for creating beans > ----------------------------------------- > > Key: CDI-268 > URL: https://issues.jboss.org/browse/CDI-268 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PFD > > > The CDI SPI provides an SPI that helps extension developers to build Bean implementations. > An example follows: > {code:JAVA} > AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class); > BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType); > InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType); > Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget); > {code} > This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior. > However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI. > A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean() > On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed: > *1.) InjectionPoint.getBean() always returns null* > InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean. > This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata). > There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance: > {code:JAVA} > void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) { > final InjectionPoint delegate = event.getInjectionPoint(); > if (delegate.getBean() == null) { > event.setInjectionPoint(new ForwardingInjectionPoint() { > @Override > public Bean<?> getBean() { > return bean; > } > @Override > protected InjectionPoint delegate() { > return delegate; > } > }); > } > } > {code} > *2.) Decorators cannot be applied* > Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not. > To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013