> 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.
Now I am confused ;) This means to _not_ deserialize those Resources at all, but instead always re-attach by getting it fro JNDI again? What I meant in my long flame: JNDI objects were supposed to be stored in serialised form, but that in the mean time JNDI got used as a big fat toilette where lots of objects got flushed down in the various EE specs without thinking about it. Take the QueueConnectionFactory [1] for JMS. The spec says that the impls _should_ be Serializable, but quite a few impls are not. In fact: a few resources we get from JNDI are Serializable, others are not. My opinion: The ones which implement Serializable should manage themself, the others should be re-attached from JNDI via a 'proxy' But maybe I still miss the 'one' important point ;) LieGrue, strub [1] --- On Tue, 12/28/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: Tuesday, December 28, 2010, 11:31 PM > 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 > >>> > >> > >> > > > > > > > >
