September 2011 - cdi-dev - Jboss List Archives

by Pete Muir

All, I would like to submit EDR 1 next week by Tuesday. I realise this is tight, but as I am speaking about CDI 1.1 at JavaOne, it's an excellent opportunity to present something to the community. I think most people have been keeping up on JIRA/GitHub anyway, so there won't be any surprises. Note that this is only an EDR (an Alpha in software speak) meant to get extra feedback from the somewhat-less-involved community. We can still change stuff after this, and I fully plan to submit a second EDR with all features in. I'll be merging in all the reviewed changes (per standard policy) now, adding a preface to the spec explaining what's changed (and where to look to find more) and send that out for review. As always, speak if you disagree :-) Pete

13 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (CDI-140) improve Serializable requirements for @Dependent scoped beans in 6.6.4

by Mark Struberg (JIRA)

improve Serializable requirements for @Dependent scoped beans in 6.6.4 ---------------------------------------------------------------------- Key: CDI-140 URL: https://issues.jboss.org/browse/CDI-140 Project: CDI Specification Issues Issue Type: Clarification Components: Resolution Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) Currently section 6.6.4 defines that @Dependent scoped beans which get injected into a bean of a passivating scope must be Serializable. "If a producer method or field of scope @Dependent returns an unserializable object for injection into an injection point that requires a passivation capable dependency, the container must throw an Illegal- ProductException" The question is how to interpret "that requires a passivation capable dependency". It would e.g. be perfectly fine if the @Dependent bean is _not_ Serializable *if* the injectionpoint will be serialized via a writeObject or Externalizable#writeExternal. Proposal: to explicitly add a check for Modifier.TRANSIENT and writeObject(ObjectOutputStream) and Externalizable#writeExternal(ObjectOutput) This is very important for @Dependent scoped producers of legacy classes because there is otherwise no way to inject such classes at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (CDI-153) PassivationCapable producer method/field definition is ambiguous

by Mark Struberg (JIRA)

PassivationCapable producer method/field definition is ambiguous ---------------------------------------------------------------- Key: CDI-153 URL: https://issues.jboss.org/browse/CDI-153 Project: CDI Specification Issues Issue Type: Clarification Components: Resolution Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) Currently the spec paragraph 6.6.1 and 6.6.4 contradict themselfs a bit 6.6.1 (which is an overview) defines: • A producer method is passivation capable if and only if it never returns a value which is not passivation capable at runtime. A producer method with a primitive return type or a return type that implements or extends Serializable is passivation capable. A producer method with a return type that is declared final and does not implement Serializable is not passivation capable. • A producer field is passivation capable if and only if it never refers to a value which is not passivation capable at runtime. A producer field with a primitive type or a type that implements or extends Serializable is passivation cap- able. A producer field with a type that is declared final and does not implement Serializable is not passivation cap- able. and 6.6.4: If a producer field declares a passivating scope and: • the container is able to determine that it is not passivation capable by inspecting its type, then the container automatically detects the problem and treats it as a deployment problem. In some cases, the container is not able to determine whether a producer method or field is passivation capable. If a produ- cer method or field which declares a passivating scope returns an unserializable object at runtime, the container must throw an IllegalProductException. If a producer method or field of scope @Dependent returns an unserializable object for injection into an injection point that requires a passivation capable dependency, the container must throw an Illegal- ProductException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
5
0 / 0

[JBoss JIRA] Resolved: (CDI-92) Allow injection of Bean object for a bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-92. -------------------------- Assignee: Pete Muir Resolution: Done > Allow injection of Bean object for a bean > ----------------------------------------- > > Key: CDI-92 > URL: https://issues.jboss.org/browse/CDI-92 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (CDI-118) Standardize deployment-related exception classes

by Dan Allen (JIRA)

Standardize deployment-related exception classes ------------------------------------------------ Key: CDI-118 URL: https://issues.jboss.org/browse/CDI-118 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Affects Versions: 1.0 Reporter: Dan Allen Fix For: 1.1 (Proposed) While it's true that deployment exceptions are not a public API when developing with the CDI programming model, they are a public API for tools and in testing environments. It would be useful to standardize the deployment-related error and exception classes so that these tools don't have to rely on classes from the implementation. One example occurs in the CDI-TCK and it's counterpart, Arquillian. A test may want to verify that the code will result in a deployment error. Currently, to detect this exception, it's necessary to rely on an implementation specific exception class, which makes the test non-portable. Another example is a tool that starts a CDI runtime or server that provides CDI. The tool has to check for the implementation-specific exception to know if the deployment error is caused by CDI (and to capture and report that error). It important both when CDI is used for standalone bootstrap and for a container that provides CDI. Proposed APIs: javax.enterprise.inject.DeploymentException extends RuntimeException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

6
8
0 / 0

[JBoss JIRA] Resolved: (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-50. -------------------------- Assignee: Pete Muir Resolution: Done > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Pete Muir resolved CDI-2. ------------------------- Resolution: Done > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Inheritance and Specialization > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Confirmed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (CDI-145) allow @Disposes methods also for producer fields

by Mark Struberg (JIRA)

allow @Disposes methods also for producer fields ------------------------------------------------ Key: CDI-145 URL: https://issues.jboss.org/browse/CDI-145 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans, Concepts Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) The current wording of 3.3.7 only allowed disposal methods for producer methods. Producer fields are imo not covered by the wording and cannot get @Disposed > 3.3.7. Disposer method resolution > A disposer method is bound to a producer method if: > • the producer method is declared by the same bean class as the > disposer method, and > • the producer method is assignable to the disposed parameter, > according to the rules of typesafe resolution defined in Section 5.2, > "Typesafe resolution" (using Section 5.2.3, "Assignability of raw and > parameterized types"). We should change this and also allow the disposal of producer fields. This is especially needed in the hindsight of 3.5 Resource fields which currently cannot get disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
2
0 / 0

[JBoss JIRA] Resolved: (CDI-14) Add instance() method to BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-14. -------------------------- Resolution: Done > Add instance() method to BeanManager > ------------------------------------ > > Key: CDI-14 > URL: https://issues.jboss.org/browse/CDI-14 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > > Currently obtaining a contextual reference is quite a complex operation, adding a method like: > Instance<Object> instance(); > would make it much easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (CDI-135) Request parameter for terminating cid propagation

by Nicklas Karlsson (JIRA)

Request parameter for terminating cid propagation ------------------------------------------------- Key: CDI-135 URL: https://issues.jboss.org/browse/CDI-135 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.0 Reporter: Nicklas Karlsson The specification says the conversation id of non-transient conversations should be automatically propagated, it would however be handy to be able to stop this propagation on a per-component basis. If the request token (e.g. named "nocid") would be present, CDI would interpret this as if no cid was found in the request. This would enable users to jump from non-transient to non-transient conversations in one step (e.g. by using a commandLink with a f:param named nocid and an action that would start a new non-transient conversation. A further enhancement could be that the parameter value could be "end" and CDI would terminate the propagated non-transient conversation instead of just abandoning it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2011