Hi I have checked the problem and the patch provided. I think we can apply it with some small modifications, just because it does not harm anything. But checking EJB 3.1 spec I only found this reference about it (EJB 3.1 spec section 4.2.1):
"... The container must be able to properly save and restore the reference to the business interfaces and home and component interfaces of the enterprise beans stored in the instance’s state even if the classes that implement the object references are not serializable. ..." In this case, the @EJB annotation injects an object that is serializable, but that works as a reference to the real bean instance. The EJB spec does not enforce java serialization, but it seems in this case, the reference object is serializable and once is deserialized, it can find the right instance. But note the EJB spec is not enforcing this behavior in a explicit way. The bug happens because the internal Class.forName() from java.io.ObjectInputStream cannot found the right instance. Use the context class loader and fallback to the class classloader like we do to support OSGi containers sounds reasonable. regards, Leonardo Uribe 2012/7/18 David Blevins <[email protected]>: > Thanks for the tip, Gerhard! It's not my app, so I can't say if that > functionality is needed, but I'll pass that link along. > > Did you have any thoughts on the patch itself? > > > -David > > On Tue, Jul 17, 2012 at 12:27 AM, Gerhard Petracek > <[email protected]> wrote: >> hi david, >> >> thx for the patch! >> if you don't need a serialized state, you can disable it with >> org.apache.myfaces.SERIALIZE_STATE_IN_SESSION (see [1]). >> >> regards, >> gerhard >> >> [1] http://wiki.apache.org/myfaces/Performance >> >> http://www.irian.at >> >> Your JSF/JavaEE powerhouse - >> JavaEE Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> >> 2012/7/16 David Blevins <[email protected]> >>> >>> Hey all, >>> >>> My first MyFaces patch: >>> >>> https://issues.apache.org/jira/browse/MYFACES-3581 >>> >>> Small issue on deserialization. JDK proxies need similar workaround code >>> in the deserialization part. Likely went unneeded, but when the >>> ManagedBeans hold an EJB ref from OpenEJB then you run into it. Not sure >>> why this never surfaced in Geronimo, but patch adds in the code we use on >>> the OpenEJB side to do deserialization that is JDK proxy-aware. >>> >>> Does sort of break the intended architecture. Added some comments on that >>> in the JIRA. >>> >>> We could go a couple different ways on that. Probably the only way that >>> matches the current approach is to add the method to the classloading >>> abstraction. Downside is it would break all existing implementations. >>> >>> Maybe we could commit as-is with it wired up to >>> Thread.currentThread().getClassLoader() and abstract it out later. >>> >>> >>> -David >>> >>
