Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: 1.0
-
Fix Version/s: 1.1.PFD
-
Component/s: Beans, Resolution
-
Labels:None
Description
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.
Gliffy Diagrams
Issue Links
- is related to
-
CDI-140
improve passivation capable bean validation for @Dependent scoped beans in 6.6.4
-
- Resolved
-
-
CDI-153
PassivationCapable producer method/field definition is ambiguous
-
- Resolved
-
- relates to
-
CDI-329
@TransientReference not reflected within passivation capability validation rules for producer methods
-
- Resolved
-
Mark, do you fancy taking this issue - should be pretty straightforward but we need to make sure we clear any references to this in the spec up.