Even then, the CDI spec doesn't define any built in session
scoped/conversation scoped beans. It would really be up to the app code on
how to support this as well between the two containers.
On Fri, Oct 9, 2015 at 7:55 AM Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
AFAIK nothing portable in EJB spec and cluster features are
mentionned but
not as explicit as CDI. Back to the original question (CDI ;)): there is
nothing in the spec about clustering so this is 100% up to vendors.
Romain Manni-Bucau
@rmannibucau <
https://twitter.com/rmannibucau> | Blog
<
http://rmannibucau.wordpress.com> | Github
<
https://github.com/rmannibucau> | LinkedIn
<
https://www.linkedin.com/in/rmannibucau> | Tomitriber
<
http://www.tomitribe.com>
2015-10-09 13:53 GMT+02:00 Mark Struberg <struberg(a)yahoo.de>:
> 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>:
> >
> > 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.
>
_______________________________________________
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.