<div dir="ltr">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.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-10-09 13:53 GMT+02:00 Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
<br>
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? :)<br>
<br>
LieGrue,<br>
strub<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Am 09.10.2015 um 12:54 schrieb Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>>:<br>
><br>
> I wonder whether this behavior is defined somewhere, i.e. if all EJB<br>
> implementations must support "failover" between minor versions (e.g. EJB<br>
> 3.0 and 3.2), in other words the passivation mechanism may not change.<br>
> This would mean that an EJB app might be deployed to a "cluster" of<br>
> mixed Java EE 6 and Java EE 7 app servers - seems to me like an<br>
> extremely risky experiment.<br>
><br>
> Martin<br>
><br>
> Dne 9.10.2015 v 11:42 Emily Jiang napsal(a):<br>
>> I am investigating the HttpSession failover for SessionScoped or<br>
>> ConversationScoped beans. I think it is not easy to failover from the<br>
>> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw bean<br>
>> was serialised and the proxies are different between cdi 1.0 and cdi<br>
>> 1.2. Has anyone have any thoughts on this? If not possible, this is a<br>
>> big limitation for CDI as EJB container has no such limitation.<br>
>><br>
>> --<br>
>> Thanks<br>
>> Emily<br>
>> =================<br>
>> Emily Jiang<br>
>> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a> <mailto:<a href="mailto:ejiang@apache.org">ejiang@apache.org</a>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
>><br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</div></div></blockquote></div><br></div>