geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@optonline.net>
Subject Re: JBoss Non-exhibit E: org.apache.geronimo.ejb.SynchronizationRegistry
Date Thu, 13 Nov 2003 18:08:44 GMT
I think that puts this one to bed.

Thanks

On Thursday, November 13, 2003, at 12:03 PM, Dain Sundstrom wrote:

> On Thursday, November 13, 2003, at 07:24 AM, Geir Magnusson Jr. wrote:
>
>>> Be cautious about this assumption as according to
>>> http://theserverside.com/home/thread.jsp?thread_id=22337#101159
>>> and
>>> http://cvs.sourceforge.net/viewcvs.py/*checkout*/jboss/jboss/src/ 
>>> main/org/jboss/ejb/entity/Attic/EntityInvocationRegistry.java
>>> the commit log for the initial import is
>>>
>>> "Tracks the entities and contexts associated with a transaction.   
>>> This
>>> functionality was merged from GlobalTxMap, TxEntityMap, and
>>> EntitySynchronizationInterceptor."
>>>
>>> Which to my mind suggests that at best Dain commited not his own IP  
>>> but a
>>> "derivative work" of IP already owned by JBOSS commiters, and thus  
>>> already
>>> covered by the LGPL, and that therefore this file should indeed be  
>>> licenced
>>> under the LGPL unless Dain was the sole author of all of the code  
>>> from
>>> which this was merged, or unless the it is apparent that the "merge"  
>>> was a
>>> new work which merged the ideas, but not the code itself.
>>>
>>
>> My conclusion was only analyzing the file mentioned in the specific  
>> claim.  Do we start a new thread for this ?
>
> (Yes, moved to new thread)
>
> The key word in the commit message is "functionality", not "merge".   
> This was a completely new algorithm and implementation for handling  
> synchronization of entity beans with the backend datastore.  All  
> previous synchronization implementations in JBoss (of which there were  
> at least 2) had been plagued by various subtle problems.  The new  
> system used a completely different scheme which divides entities into  
> dirty and clean sets but keeps record of the entities in the  
> invocation stack.  It did take me almost a week to figure out the  
> rules for determining which entities are dirty and this work reflects  
> that research.  I do believe that the code represents the only way to  
> determine dirty entities (short of byte code engineering) but there  
> are many ways that idea could be realized.
>
> In the end, the commit message was simply notice to the other  
> developers that the reason I was deleting those critical files was  
> that they were no longer needed (and a kick for them to go take a look  
> at the new code).
>
> -dain
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geirm@optonline.net


Mime
View raw message