Re: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl

Wonder the same. I’m 100% sure that it is NOT portable for NIV. Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don’t remember whether this was only specified for remoting or also for clustering. Nor do I remember if the spec said anything about clustering at all). I guess there often is ‚additional‘ wrapper stuff handed over in addition to the normal beans for EJB3 style EJBs. I know for sure that we do exactly that in OpenEJB. We have additional wrappers e.g. for transported Exceptions when doing remoting. We hand over the ’string representation’ and the original Exception stack data separately. In case we cannot de-serialize the Exception on the other side. Think about sending some OptimisticLockException (or even some internal Hibernate Exception) over to an EJB client which doesn’t have any Hibernate jars and not even the jaa-spec jar on it’s classpath… Similar additional information might be stored in any EJB proxy. Or think about Extended Persistence Contexts. How should that ever work to be serialized between e.g. WildFly and Glassfish? How would you replicate over some Hibernate Exception if the other node is running Glassfish with EclipseLink? :) LieGrue, strub > Am 09.10.2015 um 12:54 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > I wonder whether this behavior is defined somewhere, i.e. if all EJB > implementations must support "failover" between minor versions (e.g. EJB > 3.0 and 3.2), in other words the passivation mechanism may not change. > This would mean that an EJB app might be deployed to a "cluster" of > mixed Java EE 6 and Java EE 7 app servers - seems to me like an > extremely risky experiment. > > Martin > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a): >> I am investigating the HttpSession failover for SessionScoped or >> ConversationScoped beans. I think it is not easy to failover from the >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean >> was serialised and the proxies are different between cdi 1.0 and cdi >> 1.2. Has anyone have any thoughts on this? If not possible, this is a >> big limitation for CDI as EJB container has no such limitation. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang(a)apache.org <mailto:ejiang@apache.org> >> >> >> _______________________________________________ >> 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. >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > 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.