hi, if it isn't used, we should remove it.
imo we should think about a general strategy how we preserve backward compatibility of our spi (as long as it makes sense). 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/12 David Jencks <david_jen...@yahoo.com> > Hi Gerhard, > > My suggestion is that if there is an abstract class here, it be > > public abstract class AbstraceResourceInjectionService implements > ResourceInjectionService > { > /** > * delegation of serialization behavior > */ > public <T> void writeExternal(Bean<T> bean, T actualResource, > ObjectOutput out) throws IOException > { > //do nothing > } > > } > > public <T> T readExternal(Bean<T> bean, ObjectInput in) throws > IOException, > ClassNotFoundException > { > return (T) ((ResourceBean)bean).getActualInstance(); > } > > This is much simpler and likely faster (at most one deserialization from > jndi in readExternal rather than serialization on write and deserialization > on read) than the implementations in StandaloneResourceInjectionService and > OpenEjbResourceInjectionService. I think it is likely to work in many more > scenarios than the current OWB code. I don't think the > OpenEjbResourceInjectionService is used anywhere, certainly not in the > openejb integration in openejb. The code above works in geronimo and the > existing OWB code does not. > > My original idea at the start of this thread was to just use this method > always without delegating to ResourceinjectionService, but Mark didn't like > that idea. I still do not understand any circumstance in which the existing > code would be useful compared with the above. > > thanks > david jencks > > On Jan 11, 2011, at 2:42 PM, Gerhard wrote: > > > 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >> > >> > >
