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 >
