geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: JBoss Non-exhibit E: org.apache.geronimo.ejb.SynchronizationRegistry
Date Thu, 13 Nov 2003 17:03:52 GMT
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


Mime
View raw message