Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
On Feb 5, 2008, at 8:44 AM, Gianny Damour wrote: 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. Great! Thanks a lot Gianny. FYI, just got a pointer on legal-discuss@ to a CopyOnWriteArrayList implementation in Harmony. Seems that Harmony is using the concurrent library minus the two classes, plus their CopyOnWriteArray. Since ConcurrentReaderHashMap isn't part of the SE 5 api, they didn't need it. So, looks like we might have had another option. --kevan 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. Thanks for looking at this Jarek. --kevan
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
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
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
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 >
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
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
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
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? Hi Gianny, I thought i had checked to be sure the module had been started. Checking... OK. So, I had searched for wadi-clustering... But first hit was as a child of "clustering" (which was running). The licensing for the concurrent library is problematic. It would be best to drop this dependency. Is it possible to use jse 5 concurrent support, instead? --kevan
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
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? Thanks, Gianny On 04/02/2008, at 9:04 AM, [EMAIL PROTECTED] wrote: Author: kevan Date: Sun Feb 3 14:04:38 2008 New Revision: 618102 URL: http://svn.apache.org/viewvc?rev=618102&view=rev Log: Remove concurrent dependency. I haven't tested wadi clustering, with this change. But server starts fine Modified: geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/ pom.xml Modified: geronimo/server/branches/2.1/plugins/clustering/wadi- clustering/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.1/ plugins/clustering/wadi-clustering/pom.xml? rev=618102&r1=618101&r2=618102&view=diff == --- geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/ pom.xml (original) +++ geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/ pom.xml Sun Feb 3 14:04:38 2008 @@ -43,12 +43,6 @@ aspectjrt - -concurrent -concurrent -1.3.4 - - org.apache.geronimo.configs clustering
