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

John D. Ament john.d.ament at gmail.com
Fri Oct 9 08:05:37 EDT 2015


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 at 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 at 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 at 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 at apache.org <mailto:ejiang at apache.org>
>> >>
>> >>
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >> cdi-dev at 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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151009/d3400ada/attachment.html 


More information about the cdi-dev mailing list