hi david, please provide more details btw. a more concrete suggestion. currently StandaloneResourceInjectionService and OpenEjbResourceInjectionService are the only classes which have an implementation of the new methods (the same implementation). -> we have c&p + new methods which break backward compatibility (we should avoid both - if it is possible).
regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/10 David Jencks <david_jen...@yahoo.com> > He Gerhard, > > I'm not entirely sure what you have in mind..... is it to introduce an > > public abstract class AbstraceResourceInjectionService implements > ResourceInjectionService > { > public <T> void writeExternal(Bean<T> bean, T actualResource, > ObjectOutput out) throws IOException > { > ... > } > > } > > /** > * delegation of serialization behavior > */ > public <T> T readExternal(Bean<T> bean, ObjectInput in) throws > IOException, > ClassNotFoundException > { > ... > } > > ? > > I'm OK with this if the implementations here are the ones in geronimo, not > the ones in StandaloneResourceInjectionService which I think are unlikely to > be useful in most environments and are a lot more complicated. > > public <T> void writeExternal(Bean<T> bean, T actualResource, > ObjectOutput out) throws IOException { > //do nothing > } > > /** > * delegation of serialization behavior > */ > public <T> T readExternal(Bean<T> bean, ObjectInput out) throws > IOException, > ClassNotFoundException { > return (T) ((ResourceBean)bean).getActualInstance(); > } > > > I would need to understand why the implementations in the > StandaloneResourceInjectionService are ever useful to support their use as a > default implementation. > > thanks > david jencks > > > On Jan 10, 2011, at 4:43 AM, Gerhard wrote: > > > 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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >
