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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >>