Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml

[Gianny Damour]

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 <[EMAIL PROTECTED]> 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