I'm afraid I don't understand your response very well. On Dec 27, 2010, at 3:13 AM, Mark Struberg wrote:
> 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? > such scenarios might be unlikely but since they are easy to guard against I don't really see why not to do so. On the other hand if we decide to delegate all the content serialization (see below) then we can delegate this checking as well. > > 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 ;) I don't understand any of your argument here, nor what conclusion you have reached. You are free to write a ResourceInjectionService backed by something other than jndi, although I don't see how it would relate to how @Resource annotations are supposed to work in cdi. My current idea is that we should assume that _all_ resource objects are stateless and _always_ deserialize these ResourceProxyHandlers by obtaining the actual resource from the ResourceInjectionService. This means leaving out the FailoverService here. We could have a ResourceSerializationService which if supplied does the serialization. Or we could delegate all the serialization to a ResourceSerializationService so I can implement something that works for geronimo without disturbing the current special-casing of corba stubs. Hoping you can clarify in a way I can understand :-) thanks david jencks > > 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 >>> >> >> > > >