On Dec 29, 2010, at 12:24 AM, Mark Struberg wrote: >> 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?
s/jndi/ResourceInjectionService yes, that's what I'd like. > > 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. I won't argue against the claim that JNDI is a garbage pit of underspecified bad ideas and bizarre implementations. However, it's also an ee requirement at the moment. > > 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 ;) My experience is that EE stuff bound to jndi that implements serializable usually doesn't actually serialize/deserialize properly. So I'm very reluctant to delegate to implementations that are likely to be broken. In particular I'm having problems serializing/deserializing an openjpa EMF. AFAIK none of the ee objects you can specify as a @Resource and get from jndi are supposed to have user modifiable state. Therefore getting a new one from jndi on deserialization should work fine. If you find this argument less than compelling, could we simply delegate _all_ of the serialization/deserialization of the actual resource to the ResourceInjectionService? Then I can do the "always lookup in jndi" approach in geronimo and you can avoid it in OWB. thanks david jencks > > 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 >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
