You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by David Jencks <da...@yahoo.com> on 2010/12/27 08:21:31 UTC
Problem with serializing ResourceProxyHandler
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
Re: Problem with serializing ResourceProxyHandler
Posted by Gerhard <ge...@gmail.com>.
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 <da...@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 <da...@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 <da...@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 <da...@yahoo.com> wrote:
> >>>>>>
> >>>>>>> From: David Jencks <da...@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 <da...@yahoo.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> From: David Jencks <da...@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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@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 <da...@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 <da...@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 <da...@yahoo.com> wrote:
>>>>>>
>>>>>>> From: David Jencks <da...@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 <da...@yahoo.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From: David Jencks <da...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Problem with serializing ResourceProxyHandler
Posted by Gerhard <ge...@gmail.com>.
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 <da...@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 <da...@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 <da...@yahoo.com> wrote:
> >>>>
> >>>>> From: David Jencks <da...@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 <da...@yahoo.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> From: David Jencks <da...@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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@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 <da...@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 <da...@yahoo.com> wrote:
>>>>
>>>>> From: David Jencks <da...@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 <da...@yahoo.com>
>>>>> wrote:
>>>>>>
>>>>>>> From: David Jencks <da...@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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
Re: Problem with serializing ResourceProxyHandler
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
+1;
--Gurkan
----- Original Message ----
From: Gerhard <ge...@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 <da...@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 <da...@yahoo.com> wrote:
> >>
> >>> From: David Jencks <da...@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 <da...@yahoo.com>
> >>> wrote:
> >>>>
> >>>>> From: David Jencks <da...@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
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by Gerhard <ge...@gmail.com>.
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 <da...@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 <da...@yahoo.com> wrote:
> >>
> >>> From: David Jencks <da...@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 <da...@yahoo.com>
> >>> wrote:
> >>>>
> >>>>> From: David Jencks <da...@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
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@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 <da...@yahoo.com> wrote:
>>
>>> From: David Jencks <da...@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 <da...@yahoo.com>
>>> wrote:
>>>>
>>>>> From: David Jencks <da...@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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> wrote:
>
>> From: David Jencks <da...@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 <da...@yahoo.com>
>> wrote:
>>>
>>>> From: David Jencks <da...@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
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by Mark Struberg <st...@yahoo.de>.
> 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?
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.
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 ;)
LieGrue,
strub
[1]
--- On Tue, 12/28/10, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@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 <da...@yahoo.com>
> wrote:
> >
> >> From: David Jencks <da...@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
> >>>
> >>
> >>
> >
> >
> >
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> wrote:
>
>> From: David Jencks <da...@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
>>>
>>
>>
>
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by Mark Struberg <st...@yahoo.de>.
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?
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 ;)
LieGrue,
strub
--- On Mon, 12/27/10, David Jencks <da...@yahoo.com> wrote:
> From: David Jencks <da...@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
> >
>
>
Re: Problem with serializing ResourceProxyHandler
Posted by David Jencks <da...@yahoo.com>.
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
>