Thank for your answer, but your don't answer the question Of course, there is only one producer of List<TestObjectWhichIsSerialisable> so it is correct. Replacing List<..> by ArrayList<..> in both producer and IP make it to work (because ArrayList<..> implements Serializable. The producer is in another class and the list is produced in @Dependent scope
The question is still open.. 2013/7/30 Luc <[email protected]>: > In fact, you can't inject a list, because there are multiple implementations > of list interface. Which one should select the container to be instanciated? > But I think is more important to know is: how this list will be > "constructed" and used later? > If TestBean2 is a bean inyected somewhere else that will populate the list, > you don't need any @Inject. > -- > Lucas > > > 2013/7/30 titou10 titou10 <[email protected]> >> >> Given the fact that, per the specs >> (http://docs.jboss.com/cdi/spec/1.0/html/contexts.html section 6.6), >> "For every bean which declares a passivating scope, and for every >> stateful session bean, the container must validate that the bean truly >> is passivation capable and that, in addition, its dependencies are >> passivation capable.." "..the container automatically detects the >> problem and treats it as a deployment problem." >> >> Wit the following class, OWB fails to start as per the specs : >> >> @ConversationScoped >> public class TestBean2 implements Serializable { >> private static final long serialVersionUID = 1L; >> @Inject private List<TestObjectWhichIsSerialisable> listTestObject; >> } >> >> Because List<> is not serializable >> >> How do you people, handle this situation? >> - Replace all declaration of List<> by the concrete implementation >> class (it seems that all implementation of List<> are serializable) ? >> - Declare those fields as transient and manage manually the passivation? >> - "deactivate the container passivation feature" if possible in the >> application server and tell OWB to not enforce this (how?) ? >> >> We can not find a good solution for this and this appear to be a real >> problem for us. > >
