[jira] [Commented] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385726#comment-16385726
]
Henri Biestro commented on JEXL-255:
New commit; separated cancellation and interruption. The 'cancelled' property
is global to the script, the 'interrupted' flag local to a thread.
Should perform as intended, sorry for the mishap (do *not* commit late on
Sundays :-) ).
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385649#comment-16385649
]
Dmitri Blinov edited comment on JEXL-255 at 3/5/18 6:40 AM:
The test code I'm using is like this
{code:java}
@timeout(5) {sleep(1); return 0}; return 42
{code}
At the moment the code returns neither 0 nor 42, but throws
{{JexlException.Cancel}}
The {{Context.processAnnotation()}} code correctly catches
{{JexlException.Cancel}}
exception that was thrown during {{sleep()}} invocation, and then returns
null, since it was a timeout; The script nevertheless throws
{{JexlException.Cancel}}
at the end, once again. The expected behaviour is to return 42
was (Author: dmitri_blinov):
The test code I'm using is like this
{code}
@timeout(5) {sleep(1); return 0}; return 42
{code}
At the moment the code returns neither 0 nor 42, but throws
{{JexlException.Cancel}}
The {{Context.processAnnotation()}} code correctly catches
{{JexlException.Cancel}}
exception that was thrown during {{sleep()}} invocation, and then returns null,
since it was a timeout; The script nevertheless throws {{JexlException.Cancel}}
at the end, once again.
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385649#comment-16385649
]
Dmitri Blinov commented on JEXL-255:
The test code I'm using is like this
{code}
@timeout(5) {sleep(1); return 0}; return 42
{code}
At the moment the code returns neither 0 nor 42, but throws
{{JexlException.Cancel}}
The {{Context.processAnnotation()}} code correctly catches
{{JexlException.Cancel}}
exception that was thrown during {{sleep()}} invocation, and then returns null,
since it was a timeout; The script nevertheless throws {{JexlException.Cancel}}
at the end, once again.
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NET-658) FTPClient.retrieveFile hang due to data connection failure
[ https://issues.apache.org/jira/browse/NET-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinfeng.Chen resolved NET-658. -- Resolution: Not A Bug I inspected the codes and found that there is a method which can set port range to avoid this. Sorry! > FTPClient.retrieveFile hang due to data connection failure > -- > > Key: NET-658 > URL: https://issues.apache.org/jira/browse/NET-658 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Server: > FileZilla Server 0.9.60 beta > windows 10 x64 > > Client: > Linux 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 > x86_64 GNU/Linux > java 1.8.0_11 > > >Reporter: Xinfeng.Chen >Priority: Major > Attachments: 2018-3-2 17-02-57.png > > > When retrieving files from FTP server, the client will open a data connection > with an in-use port and failed in server, but the client hung in this > function(no error, no exception, even the connection is closed due to timeout > by server). This will occur after successfully getting hundreds of files (I > have more than 4000 small files to be transferred, it will fail after 100+ or > 300+ or 400+ files. It always fail to FTP 4000 small files.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (NET-658) FTPClient.retrieveFile hang due to data connection failure
[ https://issues.apache.org/jira/browse/NET-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinfeng.Chen closed NET-658. This is not a bug, misreported. > FTPClient.retrieveFile hang due to data connection failure > -- > > Key: NET-658 > URL: https://issues.apache.org/jira/browse/NET-658 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Server: > FileZilla Server 0.9.60 beta > windows 10 x64 > > Client: > Linux 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 > x86_64 GNU/Linux > java 1.8.0_11 > > >Reporter: Xinfeng.Chen >Priority: Major > Attachments: 2018-3-2 17-02-57.png > > > When retrieving files from FTP server, the client will open a data connection > with an in-use port and failed in server, but the client hung in this > function(no error, no exception, even the connection is closed due to timeout > by server). This will occur after successfully getting hundreds of files (I > have more than 4000 small files to be transferred, it will fail after 100+ or > 300+ or 400+ files. It always fail to FTP 4000 small files.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-255:
---
Fix Version/s: 3.2
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-255:
---
Assignee: Henri Biestro
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JEXL-255) Ability to continue interrupted scripts
[
https://issues.apache.org/jira/browse/JEXL-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385384#comment-16385384
]
Henri Biestro commented on JEXL-255:
I've committed some test code accessible through git (
https://github.com/apache/commons-jexl/commit/d7fb538233920b8de8deca98d9251c846df7db5a
)
Let me know if this is what you're after.
> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> I'm trying to implement the {{@timeout}} annotation that should work like the
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
> {code}
> The idea is to protect part of the script code from being executed
> indefinitely or more than allowed by business rules. The script should
> continue its evaluation after the {{@timeout}} annotation regardless of
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which
> should invoke {{Thread.interrupt()}} for the thread executing the script. The
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed
> inside the {{processAnnotation()}} method, and if the guard thread has fired,
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is
> processed inside {{processAnnotation()}} code, but the script nevertheless
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow
> script to continue its evaluation once {{InterruptedException}} or
> {{JexlException.Cancel}} is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMPRESS-445) Zip Bomb Detection
PJ Fanning created COMPRESS-445: --- Summary: Zip Bomb Detection Key: COMPRESS-445 URL: https://issues.apache.org/jira/browse/COMPRESS-445 Project: Commons Compress Issue Type: Improvement Components: Archivers Reporter: PJ Fanning It would be a nice feature if ZipFile had support for detecting Zip Bombs. Apache Poi has an implementation based on the java util ZipFile but this relies on Reflection and changes in Java 10 mean this code will not work in that version. [https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/openxml4j/util/ZipSecureFile.java] One option would be to add equivalent change support in commons-compress and for Poi to use the commons version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMMONSRDF-75) Migrate to Java 9 using JPMS
[
https://issues.apache.org/jira/browse/COMMONSRDF-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385283#comment-16385283
]
Gilles commented on COMMONSRDF-75:
--
FTR, I mention here the discussion that started in COMMONSSITE-103.
> Migrate to Java 9 using JPMS
>
>
> Key: COMMONSRDF-75
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-75
> Project: Apache Commons RDF
> Issue Type: New Feature
> Components: api, build, jena, jsonld-java, parser, rdf4j, simple
>Reporter: Kamila Molina
>Priority: Minor
> Labels: gsoc2018, library
>
> Add module-info.java for each module. JPMS allows to create libraries with
> strong encapsulation; however, this migration will bring with many effects
> that can potentially break code. For example, JDK 9 doesn't gives access for
> internal types such as {{sun.misc.BASE64Encoder.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385260#comment-16385260
]
Kamila Molina edited comment on COMMONSSITE-103 at 3/4/18 6:11 PM:
---
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|https://github.com/apache/commons-rdf] provides an API
for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
BTW, I created a new
[issue|https://issues.apache.org/jira/browse/COMMONSRDF-75] about this thread
in commons-rdf.
was (Author: kamila.molina97):
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|https://github.com/apache/commons-rdf] provides an API
for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am
[jira] [Created] (COMMONSRDF-75) Migrate to Java 9 using JPMS
Kamila Molina created COMMONSRDF-75:
---
Summary: Migrate to Java 9 using JPMS
Key: COMMONSRDF-75
URL: https://issues.apache.org/jira/browse/COMMONSRDF-75
Project: Apache Commons RDF
Issue Type: New Feature
Components: api, build, jena, jsonld-java, parser, rdf4j, simple
Reporter: Kamila Molina
Add module-info.java for each module. JPMS allows to create libraries with
strong encapsulation; however, this migration will bring with many effects that
can potentially break code. For example, JDK 9 doesn't gives access for
internal types such as {{sun.misc.BASE64Encoder.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385260#comment-16385260
]
Kamila Molina edited comment on COMMONSSITE-103 at 3/4/18 5:55 PM:
---
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|https://github.com/apache/commons-rdf] provides an API
for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
was (Author: kamila.molina97):
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|[https://github.com/apache/commons-rdf]] provides an
API for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto
[jira] [Commented] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385260#comment-16385260
]
Kamila Molina commented on COMMONSSITE-103:
---
Hi [~ajs6f], [~erans], and [~stain],
Well, I see [commons-rdf|[https://github.com/apache/commons-rdf]] provides an
API for implementations of RDF frameworks. The idea would be use JPMS for each
module already in commons rdf.
The module system is thought not only for internal uses of Java, but also for
API developers or applications in general. This gets rid of the classpath and
uses a module-path, which solves some problems that classpath introduces,
specially at runtime.
About multi-version jars, I don't see it as a problem. The module system
doesn't store versions. Management tools such as maven in this case will handle
versioning. Of course, we can define versions as in the case of java-se@9, but
these work mostly as a tag to recognize the module, correct me if I am wrong
please.
We don't need to create a set of jars both for Java 8 and Java 9. If we just
move to Java 9, using JPMS those jars will be functional in older versions.
Java is characterized for backward compatibility.
The intent of my proposal will be to migrate commons-rdf to Java 9. In other
words, add module-info.java for each module in commons-rdf. With this, we
should to see which classes a user of commons-rdf will have access, and which
ones will be for internal purposes, for example.
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto as I have been quite involved in
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding
> support for rot13?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
