Hi +1 to clarify it. All normal scope dont need Serializable constraint - even session scope - and it makes sense to not respect it in a lot of apps without preventing these beans to be serializable thans their proxies. Best IMO is to either remove it or to allow a scope serializer service to be specified to keep it portable. Wdyt? Le 1 févr. 2015 13:36, "Antonio Goncalves" <antonio.goncalves(a)gmail.com <mailto:antonio.goncalves@gmail.com>> a écrit : Hi all, I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : /1.3.1. JSF example/ /The @SessionScoped annotation defined in Section 2.4.1, “Built-in scope types” is a scope / /type that specifies the lifecycle of instances of Login. *Managed beans with this scope must be*/ /*serializable.*/ The Weld documentation is a bit more explicit : /5.2. Built-in scopes/ /*Managed beans with scope @SessionScoped or @ConversationScoped must be serializable*, since the container passivates the HTTP session from time to time./ And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : *Beans that use session, application, or conversation scope must be serializable*, but beans that use request scope do not have to be serializable. This even made be doubt about the application scope ?!? Any way, could we clarify this in the CDI spec ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Can you elaborate? If a bean has a normal scope (passivating), it may need to be passivated. Are you talking about using a serialization tool that does not require objects to implement Serializable and using such tool to passivate a context? Jozef On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: Hi +1 to clarify it. All normal scope dont need Serializable constraint - even session scope - and it makes sense to not respect it in a lot of apps without preventing these beans to be serializable thans their proxies. Best IMO is to either remove it or to allow a scope serializer service to be specified to keep it portable. Wdyt? Le 1 févr. 2015 13:36, "Antonio Goncalves" <antonio.goncalves(a)gmail.com&gt; a écrit : > > Hi all, > > I was reading the CDI 1.2 spec and couldn't clearly find the way > serialization and scopes work. The only explicit sentence I found was : > > > 1.3.1. JSF example > The @SessionScoped annotation defined in Section 2.4.1, “Built-in scope > types” is a scope > type that specifies the lifecycle of instances of Login. Managed beans > with this scope must be > serializable. > > > The Weld documentation is a bit more explicit : > > 5.2. Built-in scopes > Managed beans with scope @SessionScoped or @ConversationScoped must be > serializable, since the container passivates the HTTP session from time to > time. > > > And in the Java EE Tutorial we find > (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > Beans that use session, application, or conversation scope must be > serializable, but beans that use request scope do not have to be > serializable. > > > This even made be doubt about the application scope ?!? > > > Any way, could we clarify this in the CDI spec ? > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Romain, that's not true. Tomcat by default ALWAYS serializes the session at shutdown! Even if you don't have a cluster set up. This is also required by the Servlets spec... LieGrue, strub > On Monday, 2 February 2015, 16:23, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > > @Jozef: yes or no but supposing it it leads to the same result. > Typically the case I care here is default tomcat one (+ embedded > tomcat* ones) where session is never serialized so this constraint is > not needed at all. That said having a SPI to add a serializer by bean > (or default one) to avoid this constraint is awesome as well. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-02-02 16:10 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: >> Can you elaborate? If a bean has a normal scope (passivating), it may need >> to be passivated. Are you talking about using a serialization tool that > does >> not require objects to implement Serializable and using such tool to >> passivate a context? >> >> Jozef >> >> >> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >> >> Hi >> >> +1 to clarify it. All normal scope dont need Serializable constraint - even >> session scope - and it makes sense to not respect it in a lot of apps >> without preventing these beans to be serializable thans their proxies. >> >> Best IMO is to either remove it or to allow a scope serializer service to > be >> specified to keep it portable. >> >> Wdyt? >> >> Le 1 févr. 2015 13:36, "Antonio Goncalves" > <antonio.goncalves(a)gmail.com&gt; a >> écrit : >>> >>> Hi all, >>> >>> I was reading the CDI 1.2 spec and couldn't clearly find the way >>> serialization and scopes work. The only explicit sentence I found was : >>> >>> >>> 1.3.1. JSF example >>> The @SessionScoped annotation defined in Section 2.4.1, “Built-in scope >>> types” is a scope >>> type that specifies the lifecycle of instances of Login. Managed beans >>> with this scope must be >>> serializable. >>> >>> >>> The Weld documentation is a bit more explicit : >>> >>> 5.2. Built-in scopes >>> Managed beans with scope @SessionScoped or @ConversationScoped must be >>> serializable, since the container passivates the HTTP session from time > to >>> time. >>> >>> >>> And in the Java EE Tutorial we find >>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>> >>> Beans that use session, application, or conversation scope must be >>> serializable, but beans that use request scope do not have to be >>> serializable. >>> >>> >>> This even made be doubt about the application scope ?!? >>> >>> >>> Any way, could we clarify this in the CDI spec ? >>> >>> >>> -- >>> Antonio Goncalves >>> Software architect, Java Champion and Pluralsight author >>> >>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other > intellectual >>> property rights inherent in such information. >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the > code >> under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other > intellectual >> property rights inherent in such information. >> >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided > on this list, the provider waives all patent and other intellectual property > rights inherent in such information. >

but you HAVE to manually switch it off. By _default_ the serialization is on... LieGrue, strub > On Monday, 2 February 2015, 16:42, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: > > @Mark: that's not true. 1) you can switch it off + I mainly spoke of > embedded case where it is true in 80% of cases > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > > 2015-02-02 16:38 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >> Romain, that's not true. Tomcat by default ALWAYS serializes the > session at shutdown! Even if you don't have a cluster set up. This is also > required by the Servlets spec... >> >> LieGrue, >> strub >> >> >> >> >> >>> On Monday, 2 February 2015, 16:23, Romain Manni-Bucau > <rmannibucau(a)gmail.com&gt; wrote: >>> > @Jozef: yes or no but supposing it it leads to the same result. >>> Typically the case I care here is default tomcat one (+ embedded >>> tomcat* ones) where session is never serialized so this constraint is >>> not needed at all. That said having a SPI to add a serializer by bean >>> (or default one) to avoid this constraint is awesome as well. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> >>> 2015-02-02 16:10 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: >>>> Can you elaborate? If a bean has a normal scope (passivating), it > may need >>>> to be passivated. Are you talking about using a serialization tool > that >>> does >>>> not require objects to implement Serializable and using such tool > to >>>> passivate a context? >>>> >>>> Jozef >>>> >>>> >>>> On 02/01/2015 04:44 PM, Romain Manni-Bucau wrote: >>>> >>>> Hi >>>> >>>> +1 to clarify it. All normal scope dont need Serializable > constraint - even >>>> session scope - and it makes sense to not respect it in a lot of > apps >>>> without preventing these beans to be serializable thans their > proxies. >>>> >>>> Best IMO is to either remove it or to allow a scope serializer > service to >>> be >>>> specified to keep it portable. >>>> >>>> Wdyt? >>>> >>>> Le 1 févr. 2015 13:36, "Antonio Goncalves" >>> <antonio.goncalves(a)gmail.com&gt; a >>>> écrit : >>>>> >>>>> Hi all, >>>>> >>>>> I was reading the CDI 1.2 spec and couldn't clearly find > the way >>>>> serialization and scopes work. The only explicit sentence I > found was : >>>>> >>>>> >>>>> 1.3.1. JSF example >>>>> The @SessionScoped annotation defined in Section 2.4.1, > “Built-in scope >>>>> types” is a scope >>>>> type that specifies the lifecycle of instances of Login. > Managed beans >>>>> with this scope must be >>>>> serializable. >>>>> >>>>> >>>>> The Weld documentation is a bit more explicit : >>>>> >>>>> 5.2. Built-in scopes >>>>> Managed beans with scope @SessionScoped or @ConversationScoped > must be >>>>> serializable, since the container passivates the HTTP session > from time >>> to >>>>> time. >>>>> >>>>> >>>>> And in the Java EE Tutorial we find >>>>> (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : >>>>> >>>>> Beans that use session, application, or conversation scope > must be >>>>> serializable, but beans that use request scope do not have to > be >>>>> serializable. >>>>> >>>>> >>>>> This even made be doubt about the application scope ?!? >>>>> >>>>> >>>>> Any way, could we clarify this in the CDI spec ? >>>>> >>>>> >>>>> -- >>>>> Antonio Goncalves >>>>> Software architect, Java Champion and Pluralsight author >>>>> >>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | > Devoxx France >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider > licenses the >>>>> code under the Apache License, Version 2 >>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all > other ideas >>>>> provided on this list, the provider waives all patent and > other >>> intellectual >>>>> property rights inherent in such information. >>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider > licenses the >>> code >>>> under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas >>>> provided on this list, the provider waives all patent and other >>> intellectual >>>> property rights inherent in such information. >>>> >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the > code >>> under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided >>> on this list, the provider waives all patent and other intellectual > property >>> rights inherent in such information. >>> >

Look instead for passivation, you will find plenty. On 1 Feb 2015, at 12:36, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: Hi all, I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : *1.3.1. JSF example* *The @SessionScoped annotation defined in Section 2.4.1, “Built-in scope types” is a scope* *type that specifies the lifecycle of instances of Login. Managed beans with this scope must be* *serializable.* The Weld documentation is a bit more explicit : *5.2. Built-in scopes* *Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time.* And in the Java EE Tutorial we find ( http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : *Beans that use session, application, or conversation scope must be serializable*, but beans that use request scope do not have to be serializable. This even made be doubt about the application scope ?!? Any way, could we clarify this in the CDI spec ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Le 1 févr. 2015 à 17:49, Mark Struberg <struberg(a)yahoo.de&gt; a écrit : See 6.6.5 of the Spec. Serializable all over the place. The important point is also the difference between the requirement for Bean<T> instances to be PassivationCapable and the Contextual Instances to be Serializable. E.g. for @ApplicationScoped the ContextualInstance doesn't need to be Serializable, but the Bean<T> for it needs to be PassivationCapable. The reason is that the Bean<T> instance gets stored in the Proxy. And this Proxy needs to be Serializable because otherwise you would not be able to inject it into a @SessionScoped bean (or any other bean with passivating scope). LieGrue, strub On Sunday, 1 February 2015, 13:37, Antonio Goncalves <antonio.goncalves(a)gmail.com&gt; wrote: > > > Hi all, > > > I was reading the CDI 1.2 spec and couldn't clearly find the way serialization and scopes work. The only explicit sentence I found was : > > > > > 1.3.1. JSF example > The @SessionScoped annotation defined in Section 2.4.1, “Built-in scope types” is a scope > > type that specifies the lifecycle of instances of Login. Managed beans with this scope must be > serializable. > > > > > The Weld documentation is a bit more explicit : > > > 5.2. Built-in scopes > Managed beans with scope @SessionScoped or @ConversationScoped must be serializable, since the container passivates the HTTP session from time to time. > > > > > And in the Java EE Tutorial we find (http://docs.oracle.com/javaee/6/tutorial/doc/gjbbk.html) : > > > Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. > > > > > > This even made be doubt about the application scope ?!? > > > > > Any way, could we clarify this in the CDI spec ? > > > > -- > > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.