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 <[email protected]>
>
>> 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 <[email protected]> wrote:
>>>>
>>>>> From: David Jencks <[email protected]>
>>>>> Subject: Re: Problem with serializing ResourceProxyHandler
>>>>> To: [email protected]
>>>>> 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 <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>>> From: David Jencks <[email protected]>
>>>>>>> Subject: Re: Problem with serializing
>>>>> ResourceProxyHandler
>>>>>>> To: [email protected]
>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
