I put an implementation of the delegation idea in https://issues.apache.org/jira/browse/OWB-511 along with a proposal for making WebBeansContext more useful (IMO).
thanks david jencks On Dec 29, 2010, at 4:12 PM, David Jencks wrote: > > 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >
