You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Gianny Damour <gi...@optusnet.com.au> on 2008/02/03 23:34:53 UTC
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, kevan@apache.org 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 @@
> <artifactId>aspectjrt</artifactId>
> </dependency>
>
> - <dependency>
> - <groupId>concurrent</groupId>
> - <artifactId>concurrent</artifactId>
> - <version>1.3.4</version>
> - </dependency>
> -
> <dependency>
> <groupId>org.apache.geronimo.configs</groupId>
> <artifactId>clustering</artifactId>
>
>
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Gianny Damour <gi...@optusnet.com.au>.
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 <ke...@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
>>
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Posted by Jarek Gawor <jg...@gmail.com>.
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 <ke...@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
>
Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Posted by Kevan Miller <ke...@gmail.com>.
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