February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-44: ------------------------------ Please review https://github.com/jboss/cdi/pull/175 > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PFD > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-139) Support for unmanaged instances

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-139: ------------------------------- Please review https://github.com/jboss/cdi/pull/174 which is based on the long standing Weld FAQ - http://www.seamframework.org/Documentation/HowDoIDoNoncontextualInjection... > Support for unmanaged instances > ------------------------------- > > Key: CDI-139 > URL: https://issues.jboss.org/browse/CDI-139 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Joshua Davis > Assignee: Pete Muir > Fix For: 1.1.PFD > > > Allow the creation of unmanaged instances. The CDI context will not keep track of these instances and the application will be responsible for cleaning them up. This is a fairly typical usage of other DI frameworks such as Guice and PicoContainer. > Currently, if an ApplicationScoped object injects an {{Instance<T>}} interface, CDI will manage all instances returned by the {{get()}} method as dependents of the application scoped object. Those instances will be kept in memory by the CDI implementation and will only be GC'd when the application scoped object is destroyed (at the end of the application). This may look like a memory leak to the user (see WELD-920). > From P. Muir on WELD-920 > {quote} > We can describe instances which are attached (as the CDI 1.0 spec requires) as "managed" instances, and those which the user takes responsibility for cleaning up themselves as "unmanaged" instances. In CDI 1.1 I would like to add support for unmanaged instances (the impl will just hand these over and forget about them) and also to allow the app to request an unmanaged instance is cleaned up. Please can someone file a CDI issue for this? > Weld could certainly be more friendly and more proactively discard instances. Ideas: > 1) Analyse the dependent instance graph, and if there are no @PreDestroy/@Disposer callbacks on in the graph, do not store the dependent instance for cleanup (this would be a good general optimization > (2) Add a config option to allow instances created from Instance to be held only as long as the app holds a reference, and if the app doesn't hold a reference for it's lifetime, then Weld would not do any cleanup (Weld would hold a weak ref). > {quote} -- 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, 6 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 Joe Bergmark (JIRA)

[ https://issues.jboss.org/browse/CDI-223?page=com.atlassian.jira.plugin.sy... ] Joe Bergmark commented on CDI-223: ---------------------------------- I think this may have been covered by the CDI-180 change which clarified that scope only ends if it was created for this ejb invocation. Hopefully that also makes it clear that it will end if it was created for this remote invocation. For reference that pull request was here: https://github.com/jboss/cdi/pull/92 > 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: Pete Muir > > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-271: ------------------------------- Please review https://github.com/jboss/cdi/pull/173 - I just extended where we cover Instance to cover Event as well. > Provide a way to inject Event metadata into an observer method > -------------------------------------------------------------- > > Key: CDI-271 > URL: https://issues.jboss.org/browse/CDI-271 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Arne Limburg > Assignee: Arne Limburg > Fix For: 1.1.PFD > > > Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members). > Consider the following example: > {code} > @Inject @MyQualifier > Event<MyObject> event; > public void fireEvent(MyObject object, MyTypeValue type) { > event.select(new MyTypeAnnotationLiteral(type)).fire(object); > } > {code} > Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this: > {code} > public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) { > MyType annotation = ip.getAnnotated().getAnnotation(MyType.class); > MyTypeValue value = annotation.value(); > ... > } > {code} -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-304. --------------------------- Resolution: Done Good find Jozef. As we have precedent elsewhere in the spec, we should definitely follow it rather than invent something new! I've updated beans to follow delegates > Clarify Producers for injection into generic types > -------------------------------------------------- > > Key: CDI-304 > URL: https://issues.jboss.org/browse/CDI-304 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.1.PRD > Reporter: Mark Struberg > Assignee: Pete Muir > Fix For: 1.1.PFD > > > There is a discussion over in DeltaSpike whether an injection point > {code} > @Inject > private JsfMessage<SomeMessageClass>; > {code} > with a producer method > {code} > @Produces @Dependent > JsfMessage createMessage(InjectionPoint ip) > {code} > 5.2 imo only defines the other way around. Having a raw type at the injection point and a parameterized producer method. > We should define how this is intended to work. > Please note that the producer above works in all existing containers so far but not in Weld2-beta1. > Here is the link to the DS issue: https://issues.apache.org/jira/browse/DELTASPIKE-295 -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-227: ------------------------------- I've removed the bullet about not being available in the module. The reference in the section is to "ambiguous and unsatisfied dependencies", which isn't to do with the module resolution, which happens in the previous section. As Jozef points out, getBeans() is responsible for sorting this bit out. This is backed up by the javadoc for resolve {quote} Apply the ambiguous dependency resolution rules to a set of {@linkplain Bean beans}. {quote} Again only discussing ambiguous dependencies, not module resolution. > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Labels: patch > Fix For: 1.1.PFD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable 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, 6 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 resolved CDI-223. --------------------------- Assignee: Pete Muir (was: Joe Bergmark) Fix Version/s: (was: 1.1.PFD) Resolution: Rejected No longer think this is an issue. > 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: Pete Muir > > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-305) Reflect the new EJB passivation-capable flag in CDI

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-305?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-305: ------------------------------- Please review https://github.com/jboss/cdi/pull/171 > Reflect the new EJB passivation-capable flag in CDI > --------------------------------------------------- > > Key: CDI-305 > URL: https://issues.jboss.org/browse/CDI-305 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.1.PRD > Reporter: Pete Muir > Fix For: 1.1.PFD > > > EJB 3.2 adds the ability to disable passivation of SFSB by either using @Stateful(passivationCapable=false) or setting it in the DD. > We should update the CDI spec to cover 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-142) Clarify behaviour of specializing beans across bean archive boundaries

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-142?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-142: ------------------------------- Defer visibility issues. > Clarify behaviour of specializing beans across bean archive boundaries > ---------------------------------------------------------------------- > > Key: CDI-142 > URL: https://issues.jboss.org/browse/CDI-142 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it? -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-142) Clarify behaviour of specializing beans across bean archive boundaries

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-142?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-142: -------------------------- Fix Version/s: TBD (was: 1.1.PFD) > Clarify behaviour of specializing beans across bean archive boundaries > ---------------------------------------------------------------------- > > Key: CDI-142 > URL: https://issues.jboss.org/browse/CDI-142 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: TBD > > > For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it? -- 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, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013