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 >
