geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Date Tue, 05 Feb 2008 02:39:27 GMT
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


On Feb 3, 2008 10:52 PM, Kevan Miller <> 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 --
> 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:
> 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
>   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

View raw message