geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Date Tue, 05 Feb 2008 13:44:45 GMT
Hi,

Indeed, WADI has a lot of dependencies on concurrent. As a matter of  
fact, concurrent was a very handy toolkit to build the asynchronous  
message processing/passing components and distributed locks of WADI  
on top of the JDK 1.4.

I re-implemented the relevant WADI classes to use J2SE5  
j.u.concurrent instead of concurrent:  http://svn.wadi.codehaus.org/ 
changelog/wadi/trunk/wadi?cs=2415

I will cut a new WADI release tomorrow night and move 2.1 and trunk  
to this new revision.

Thanks,
Gianny

On 05/02/2008, at 1:39 PM, Jarek Gawor wrote:

> After quick scan of the WADI code, it looks like it has a lot of
> dependencies on the concurrent library. So we'll definitely need that
> dependency at runtime. And to be more specific, I did not see any
> references to ConcurrentReaderHashMap but a few references to
> CopyOnWriteArrayList.
>
> Jarek
>
> On Feb 3, 2008 10:52 PM, Kevan Miller <kevan.miller@gmail.com> wrote:
>>
>> On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:
>>
>>> Hi Kevan,
>>>
>>> concurrent is a WADI runtime dependency. The server starts fine
>>> because wadi-clustering is not started by default and, assuming this
>>> was the case, this dependency is only used when an invocation is
>>> "contextualized".
>>>
>>> So, could you please rollback this change?
>>
>> A bit more info on the problem with the concurrent library. The doc
>> that I've found on the concurrent library is here -- http:// 
>> g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>>
>> As described there, the concurrent classes have been released to the
>> public domain. However, two classes are copyright Sun and appear  
>> to be
>> covered by the following license agreement:
>>
>> http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun- 
>> u.c.license.pdf
>>
>> The problem with that license is:
>>
>> "You acknowledge that Software is not designed, licensed or intended
>> for use in the design, construction, operation or maintenance of any
>> nuclear facility."
>>
>> This limitation is, I'm pretty sure, going to be against Apache
>> Policy. It would be classified as a category x license (i.e. the
>> licensed artifacts can't be included in an Apache distribution).  
>> See http://people.apache.org/~rubys/3party.html
>>   for more information on 3rd party licensing.
>>
>> So, things we can do:
>>
>> 1) validate the above on legal-discuss. I could always be wrong.
>> 2) leave out concurrent jar, but require users to download the jar if
>> they want to use wadi
>> 3) update wadi to use JSE 5 concurrent support
>> 4) Remove the CopyOnWriteArrayList and ConcurrentReaderHashMap  
>> classes
>> from the concurrent jar. If wadi (and internal concurrent
>> implementation) doesn't use those classes, everything should be OK.
>>
>> We included the library in at least our 1.1.1 release (it's not in  
>> our
>> 2.0.x releases). Unfortunately, that doesn't help us. Just means that
>> we were wrong back then...
>>
>>   If anybody has any additional thoughts or ideas, let us know. We'll
>> have to resolve this issue prior to a 2.1 release.
>>
>> --kevan
>>


Mime
View raw message