|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 4405 | major | always | 02-24-11 10:36 | 03-03-11 15:29 | |
|
|
|||||
| Reporter: | rickHigh | Platform: | |||
| Assigned To: | ferg | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | closed | Product Version: | 4.0.16 | ||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in 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. |
||||
| Steps To Reproduce: | |||||
| 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.) """ |
||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||