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>:
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.