Hi! I think this is really theoretical. Serializing / Deserializing will most probably only happen in a cluster between the same applications. If they have different configurations activated on different cluster nodes, well ... ;)
Can you think of any other scenario? For the general serialisation question: JNDI usage in EE servers is in general (and thus also the EMF handling in this area also) pretty sick. Originally EMFs have been Serializable because they are bound to JNDI. JNDI is typically bound to directory services in serialized form. But in EE they are now used completely different. They should now all be javax.naming.Referencable and not Serializable anymore... If we get other things from JNDI which are Serializable, then we must serialize them to get back this exact state because any intermediate JNDI rebind would probably crash our application. I personally try to avoid JNDI wherever possible. They are perfectly over-specced and still behave very different on different EE servers when it comes to gory details ;) LieGrue, strub --- On Mon, 12/27/10, David Jencks <david_jen...@yahoo.com> wrote: > From: David Jencks <david_jen...@yahoo.com> > Subject: Re: Problem with serializing ResourceProxyHandler > To: dev@openwebbeans.apache.org > Date: Monday, December 27, 2010, 7:43 AM > And another thing... > > ResourceProxyHandler will have problems if the serializing > and deserializing OWB instances differ on whether > FailoverService is present. We should write a token to > indicate whether FailoverService was used to serialize and > use it in deserialization. > > thanks > david jencks > > On Dec 26, 2010, at 11:21 PM, David Jencks wrote: > > > There's some asymetric logic in > serializing/deserializing ResourceProxyHandler. > > > > Serializing: any serialized actual resource is > written to the object output stream, whereas > non-serializable objects have a marker serialized. > > > > Deserializing: The object is read from the object > input stream, but only the marker object and CORBA stubs > result in the actualResource field being set. > > > > Finding the marker object results in getting the > resource again from the ResourceInjectionService, typically > by looking something up in jndi. > > > > I would prefer to always get the actual resource from > the ResourceInjectionService. Is there a strong reason > not to do this? > > > > If anyone wants to keep the current approach, I think > the logic currently in place to reconnect a CORBA stub uses > the wrong ORB, I think it needs to look up the orb in jndi. > > > > I'm going to fix the current hole in the logic (rev > 1053011) but IMO serializing random objects rather than > getting them from the bean is a bad idea. Even with > this I get a tck failure trying to deserialze an > EntityManagerFactory. > > > > thanks > > david jencks > > > >
