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

Reply via email to