Early Draft Review 1
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
[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
[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
[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
[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
[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
[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