0004405: @Inject fails for not serializable objects (needs investigation)

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0004405

[Resin]

major

always

02-24-11 10:36

03-03-11 15:29

Reporter

rickHigh

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Status

closed

Product Version

4.0.16

Summary

0004405: @Inject fails for not serializable objects (needs investigation)

Description

weld-jsf-pastecode fails with @Inject failures due to not being able to inject non-serializable beans.

Since WELD is the RI and this example works with WELD, this needs further investigation.

Additional Information

The error message is :

[23:26:56.420] {http://*:8080-2} [^] 'hashComputer' is an invalid injection point of type class org.jboss.weld.examples.pastecode.session.HashComputer because it's not serializable for ManagedBeanImpl[CodeFragmentManagerImpl, {@Default(), @Any()}]

The injection point looks like:

@Stateful
public class CodeFragmentManagerImpl implements CodeFragmentManager {

  ...

   @Inject

   private HashComputer hashComputer;

The weld-jsf-pastecode example seems to run after changing all classes that need serializable to implement Serializable.

Note: This weld-jsf-pastecode example would be a good app to test out the functionality of our container b/c it has a good mix of CDI and EJB.

We could issue a warning but I think we should allow it to work. I am not sure of the ramifications of this down the line.

Perhaps if Weld is the RI, then its runtime behavior should be emulated where possible even if it is direct violation of the specification.

Otherwise, we may need to add test to the CDI TCK that ensures failure of this non-standard behavior of Weld.

We could issue a warning but I think we should allow it to work. I am not sure of the ramifications of this down the line.

Dominick remembers that there was a discussion on the GF-Mailinglist about
injection and serializability. It ended that beans don't have to be serializable to be injectable,
but need to be serializable if they take part in a conversation and may be persisted/replicated.

Note that they are trying to inject into an @Stateful EJB.

It may be that the problem is that the injection point that fails is on an EJB Stateful session bean so its behavior will be governed by the EJB 3.1 Light Specification not CDI.

It appears that since the bean is stateful, then it may be serialized over the cluster therefore its injection members should be stateful/serializable. I think we have the right behavior.... but Weld allows it.

This may really depends on what EJB 3.1 Light Specification says about injection into a stateful session bean.

Scott wrote about this issue:

"""
Any bean with a @NormalScope and passivating=true must be serializable (@SessionScope and @ConversationScope in the spec). And all the decorators and interceptors must be serializable. (Tested by the TCK.)
"""

Attached Files

Relationships

Notes
(0005083) rickHigh 02-25-11 11:49	ioc/05e2.qa is the test case for this issue

Issue History
Date Modified	Username	Field	Change
02-24-11 10:36	rickHigh	New Issue
02-24-11 10:37	rickHigh	Status	new => assigned
02-24-11 10:37	rickHigh	Assigned To	=> ferg
02-24-11 10:41	rickHigh	Assigned To	ferg =>
02-24-11 10:41	rickHigh	Status	assigned => new
02-24-11 10:54	rickHigh	View Status	private => public
02-25-11 11:49	rickHigh	Note Added: 0005083
03-03-11 15:29	ferg	Assigned To	=> ferg
03-03-11 15:29	ferg	Status	new => closed
03-03-11 15:29	ferg	Resolution	open => fixed
03-03-11 15:29	ferg	Fixed in Version	=> 4.0.16

Mantis 1.0.0rc3[^]

29 total queries executed.
26 unique queries executed.