+1;
--Gurkan ----- Original Message ---- From: Gerhard <gerhard.petra...@gmail.com> To: dev@openwebbeans.apache.org Sent: Mon, January 10, 2011 2:43:34 PM Subject: Re: Problem with serializing ResourceProxyHandler hi, @ResourceInjectionService: the current trunk breaks backward compatibility with existing owb plugins. instead of c&p the default implementation of the new methods we should introduce an abstract class. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/12/31 David Jencks <david_jen...@yahoo.com> > 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 > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > >
