Hi Gerhard,
My suggestion is that if there is an abstract class here, it be
public abstract class AbstraceResourceInjectionService implements
ResourceInjectionService
{
/**
* delegation of serialization behavior
*/
public <T> void writeExternal(Bean<T> bean, T actualResource, ObjectOutput
out) throws IOException
{
//do nothing
}
}
public <T> T readExternal(Bean<T> bean, ObjectInput in) throws IOException,
ClassNotFoundException
{
return (T) ((ResourceBean)bean).getActualInstance();
}
This is much simpler and likely faster (at most one deserialization from jndi
in readExternal rather than serialization on write and deserialization on read)
than the implementations in StandaloneResourceInjectionService and
OpenEjbResourceInjectionService. I think it is likely to work in many more
scenarios than the current OWB code. I don't think the
OpenEjbResourceInjectionService is used anywhere, certainly not in the openejb
integration in openejb. The code above works in geronimo and the existing OWB
code does not.
My original idea at the start of this thread was to just use this method always
without delegating to ResourceinjectionService, but Mark didn't like that idea.
I still do not understand any circumstance in which the existing code would be
useful compared with the above.
thanks
david jencks
On Jan 11, 2011, at 2:42 PM, Gerhard wrote:
> hi david,
>
> please provide more details btw. a more concrete suggestion.
> currently StandaloneResourceInjectionService
> and OpenEjbResourceInjectionService are the only classes which have an
> implementation of the new methods (the same implementation).
> -> we have c&p + new methods which break backward compatibility (we should
> avoid both - if it is possible).
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
> 2011/1/10 David Jencks <david_jen...@yahoo.com>
>
>> He Gerhard,
>>
>> I'm not entirely sure what you have in mind..... is it to introduce an
>>
>> public abstract class AbstraceResourceInjectionService implements
>> ResourceInjectionService
>> {
>> public <T> void writeExternal(Bean<T> bean, T actualResource,
>> ObjectOutput out) throws IOException
>> {
>> ...
>> }
>>
>> }
>>
>> /**
>> * delegation of serialization behavior
>> */
>> public <T> T readExternal(Bean<T> bean, ObjectInput in) throws
>> IOException,
>> ClassNotFoundException
>> {
>> ...
>> }
>>
>> ?
>>
>> I'm OK with this if the implementations here are the ones in geronimo, not
>> the ones in StandaloneResourceInjectionService which I think are unlikely to
>> be useful in most environments and are a lot more complicated.
>>
>> public <T> void writeExternal(Bean<T> bean, T actualResource,
>> ObjectOutput out) throws IOException {
>> //do nothing
>> }
>>
>> /**
>> * delegation of serialization behavior
>> */
>> public <T> T readExternal(Bean<T> bean, ObjectInput out) throws
>> IOException,
>> ClassNotFoundException {
>> return (T) ((ResourceBean)bean).getActualInstance();
>> }
>>
>>
>> I would need to understand why the implementations in the
>> StandaloneResourceInjectionService are ever useful to support their use as a
>> default implementation.
>>
>> thanks
>> david jencks
>>
>>
>> On Jan 10, 2011, at 4:43 AM, Gerhard wrote:
>>
>>> hi,
>>>
>>> @ResourceInjectionService:
>>> the current trunk breaks backward compatibility with existing owb
>> plugins.
>>> instead of c&p the default implementation of the new methods we should
>>> introduce an abstract class.
>>>
>>> regards,
>>> gerhard
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>>
>>> 2010/12/31 David Jencks <david_jen...@yahoo.com>
>>>
>>>> I put an implementation of the delegation idea in
>>>> https://issues.apache.org/jira/browse/OWB-511 along with a proposal for
>>>> making WebBeansContext more useful (IMO).
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 29, 2010, at 4:12 PM, David Jencks wrote:
>>>>
>>>>>
>>>>> On Dec 29, 2010, at 12:24 AM, Mark Struberg wrote:
>>>>>
>>>>>>> My current idea is that we should assume that _all_
>>>>>>> resource objects are stateless and _always_ deserialize
>>>>>>> these ResourceProxyHandlers by obtaining the actual resource
>>>>>>> from the ResourceInjectionService.
>>>>>>
>>>>>> Now I am confused ;) This means to _not_ deserialize those Resources
>> at
>>>> all, but instead always re-attach by getting it fro JNDI again?
>>>>>
>>>>> s/jndi/ResourceInjectionService
>>>>> yes, that's what I'd like.
>>>>>
>>>>>>
>>>>>> What I meant in my long flame: JNDI objects were supposed to be stored
>>>> in serialised form, but that in the mean time JNDI got used as a big fat
>>>> toilette where lots of objects got flushed down in the various EE specs
>>>> without thinking about it. Take the QueueConnectionFactory [1] for JMS.
>> The
>>>> spec says that the impls _should_ be Serializable, but quite a few impls
>> are
>>>> not.
>>>>>
>>>>> I won't argue against the claim that JNDI is a garbage pit of
>>>> underspecified bad ideas and bizarre implementations. However, it's
>> also an
>>>> ee requirement at the moment.
>>>>>
>>>>>>
>>>>>> In fact: a few resources we get from JNDI are Serializable, others are
>>>> not.
>>>>>>
>>>>>> My opinion: The ones which implement Serializable should manage
>>>> themself, the others should be re-attached from JNDI via a 'proxy'
>>>>>>
>>>>>> But maybe I still miss the 'one' important point ;)
>>>>>
>>>>> My experience is that EE stuff bound to jndi that implements
>> serializable
>>>> usually doesn't actually serialize/deserialize properly. So I'm very
>>>> reluctant to delegate to implementations that are likely to be broken.
>> In
>>>> particular I'm having problems serializing/deserializing an openjpa EMF.
>>>>>
>>>>> AFAIK none of the ee objects you can specify as a @Resource and get
>> from
>>>> jndi are supposed to have user modifiable state. Therefore getting a
>> new
>>>> one from jndi on deserialization should work fine.
>>>>>
>>>>> If you find this argument less than compelling, could we simply
>> delegate
>>>> _all_ of the serialization/deserialization of the actual resource to the
>>>> ResourceInjectionService? Then I can do the "always lookup in jndi"
>>>> approach in geronimo and you can avoid it in OWB.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> --- On Tue, 12/28/10, David Jencks <david_jen...@yahoo.com> wrote:
>>>>>>
>>>>>>> From: David Jencks <david_jen...@yahoo.com>
>>>>>>> Subject: Re: Problem with serializing ResourceProxyHandler
>>>>>>> To: dev@openwebbeans.apache.org
>>>>>>> Date: Tuesday, December 28, 2010, 11:31 PM
>>>>>>> I'm afraid I don't understand your
>>>>>>> response very well.
>>>>>>>
>>>>>>> On Dec 27, 2010, at 3:13 AM, Mark Struberg wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I think this is really theoretical. Serializing /
>>>>>>> Deserializing will most probably only happen in a cluster
>>>>>>> between the same applications. If they have different
>>>>>>> configurations activated on different cluster nodes, well
>>>>>>> ... ;)
>>>>>>>>
>>>>>>>> Can you think of any other scenario?
>>>>>>>>
>>>>>>>
>>>>>>> such scenarios might be unlikely but since they are easy to
>>>>>>> guard against I don't really see why not to do so. On
>>>>>>> the other hand if we decide to delegate all the content
>>>>>>> serialization (see below) then we can delegate this checking
>>>>>>> as well.
>>>>>>>
>>>>>>>>
>>>>>>>> For the general serialisation question:
>>>>>>>> JNDI usage in EE servers is in general (and thus also
>>>>>>> the EMF handling in this area also) pretty sick. Originally
>>>>>>> EMFs have been Serializable because they are bound to JNDI.
>>>>>>> JNDI is typically bound to directory services in serialized
>>>>>>> form. But in EE they are now used completely different. They
>>>>>>> should now all be javax.naming.Referencable and not
>>>>>>> Serializable anymore...
>>>>>>>>
>>>>>>>> If we get other things from JNDI which are
>>>>>>> Serializable, then we must serialize them to get back this
>>>>>>> exact state because any intermediate JNDI rebind would
>>>>>>> probably crash our application.
>>>>>>>>
>>>>>>>> I personally try to avoid JNDI wherever possible. They
>>>>>>> are perfectly over-specced and still behave very different
>>>>>>> on different EE servers when it comes to gory details ;)
>>>>>>>
>>>>>>> I don't understand any of your argument here, nor what
>>>>>>> conclusion you have reached. You are free to write a
>>>>>>> ResourceInjectionService backed by something other than
>>>>>>> jndi, although I don't see how it would relate to how
>>>>>>> @Resource annotations are supposed to work in cdi.
>>>>>>>
>>>>>>> My current idea is that we should assume that _all_
>>>>>>> resource objects are stateless and _always_ deserialize
>>>>>>> these ResourceProxyHandlers by obtaining the actual resource
>>>>>>> from the ResourceInjectionService. This means leaving
>>>>>>> out the FailoverService here. We could have a
>>>>>>> ResourceSerializationService which if supplied does the
>>>>>>> serialization. Or we could delegate all the
>>>>>>> serialization to a ResourceSerializationService so I can
>>>>>>> implement something that works for geronimo without
>>>>>>> disturbing the current special-casing of corba stubs.
>>>>>>>
>>>>>>> Hoping you can clarify in a way I can understand :-)
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --- On Mon, 12/27/10, David Jencks <david_jen...@yahoo.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From: David Jencks <david_jen...@yahoo.com>
>>>>>>>>> Subject: Re: Problem with serializing
>>>>>>> ResourceProxyHandler
>>>>>>>>> To: dev@openwebbeans.apache.org
>>>>>>>>> Date: Monday, December 27, 2010, 7:43 AM
>>>>>>>>> And another thing...
>>>>>>>>>
>>>>>>>>> ResourceProxyHandler will have problems if the
>>>>>>> serializing
>>>>>>>>> and deserializing OWB instances differ on whether
>>>>>>>>> FailoverService is present. We should write
>>>>>>> a token to
>>>>>>>>> indicate whether FailoverService was used to
>>>>>>> serialize and
>>>>>>>>> use it in deserialization.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Dec 26, 2010, at 11:21 PM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>>> There's some asymetric logic in
>>>>>>>>> serializing/deserializing ResourceProxyHandler.
>>>>>>>>>>
>>>>>>>>>> Serializing: any serialized actual
>>>>>>> resource is
>>>>>>>>> written to the object output stream, whereas
>>>>>>>>> non-serializable objects have a marker
>>>>>>> serialized.
>>>>>>>>>>
>>>>>>>>>> Deserializing: The object is read from the
>>>>>>> object
>>>>>>>>> input stream, but only the marker object and CORBA
>>>>>>> stubs
>>>>>>>>> result in the actualResource field being set.
>>>>>>>>>>
>>>>>>>>>> Finding the marker object results in getting
>>>>>>> the
>>>>>>>>> resource again from the ResourceInjectionService,
>>>>>>> typically
>>>>>>>>> by looking something up in jndi.
>>>>>>>>>>
>>>>>>>>>> I would prefer to always get the actual
>>>>>>> resource from
>>>>>>>>> the ResourceInjectionService. Is there a
>>>>>>> strong reason
>>>>>>>>> not to do this?
>>>>>>>>>>
>>>>>>>>>> If anyone wants to keep the current approach,
>>>>>>> I think
>>>>>>>>> the logic currently in place to reconnect a CORBA
>>>>>>> stub uses
>>>>>>>>> the wrong ORB, I think it needs to look up the orb
>>>>>>> in jndi.
>>>>>>>>>>
>>>>>>>>>> I'm going to fix the current hole in the logic
>>>>>>> (rev
>>>>>>>>> 1053011) but IMO serializing random objects rather
>>>>>>> than
>>>>>>>>> getting them from the bean is a bad idea.
>>>>>>> Even with
>>>>>>>>> this I get a tck failure trying to deserialze an
>>>>>>>>> EntityManagerFactory.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
