[jira] [Updated] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinald Verheij updated POOL-337:
-
Description:
EvictionTimer does not remove cancelled tasks from the executor, leading to an
IllegalStateException when the evictor attempts to evict.
EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
does not remove it. This is asymmetric and leads to the following exception:
{noformat}
java.lang.IllegalStateException: Pool not open
at
org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
at
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
at
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
I think the cancel would need to remember the future which returned from
{{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do something
like this (see [^EvictionTimer.java] compared to original
[^EvictionTimer.java.original-from-2.5.0.java] )
{code:java}
if (futures.containsKey(task)) {
futures.remove(task).cancel(false);
executor.purge();
}{code}
was:
EvictionTimer does not remove cancelled tasks from the executor, leading to an
IllegalStateException when the evictor attempts to evict.
EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
does not remove it. This is asymmetric and leads to the following exception:
{noformat}
java.lang.IllegalStateException: Pool not open
at
org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
at
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
at
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
I think the cancel would need to remember the future which returned from
{{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do something
like this (see [attachment|EvictionTimer.java])
{code:java}
if (futures.containsKey(task)) {
futures.remove(task).cancel(false);
executor.purge();
}{code}
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
[jira] [Updated] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinald Verheij updated POOL-337:
-
Attachment: EvictionTimer.java
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> I think the cancel would need to remember the future which returned from
> {{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do
> something like this {code}if (futures.containsKey(task)) {
> futures.remove(task).cancel(false);
> executor.purge();
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinald Verheij updated POOL-337:
-
Attachment: EvictionTimer.java.original-from-2.5.0.java
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> I think the cancel would need to remember the future which returned from
> {{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do
> something like this {code}if (futures.containsKey(task)) {
> futures.remove(task).cancel(false);
> executor.purge();
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinald Verheij updated POOL-337:
-
Description:
EvictionTimer does not remove cancelled tasks from the executor, leading to an
IllegalStateException when the evictor attempts to evict.
EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
does not remove it. This is asymmetric and leads to the following exception:
{noformat}
java.lang.IllegalStateException: Pool not open
at
org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
at
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
at
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
I think the cancel would need to remember the future which returned from
{{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do something
like this (see [attachment|EvictionTimer.java])
{code:java}
if (futures.containsKey(task)) {
futures.remove(task).cancel(false);
executor.purge();
}{code}
was:
EvictionTimer does not remove cancelled tasks from the executor, leading to an
IllegalStateException when the evictor attempts to evict.
EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
does not remove it. This is asymmetric and leads to the following exception:
{noformat}
java.lang.IllegalStateException: Pool not open
at
org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
at
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
at
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){noformat}
I think the cancel would need to remember the future which returned from
{{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do something
like this {code}if (futures.containsKey(task)) {
futures.remove(task).cancel(false);
executor.purge();
}{code}
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
>
[jira] [Updated] (VFS-650) Update Apache Commons Compress from 1.15 to 1.16.1
[ https://issues.apache.org/jira/browse/VFS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-650: - Summary: Update Apache Commons Compress from 1.15 to 1.16.1 (was: Update Apache Commons Compress from 1.15 to 1.16.) > Update Apache Commons Compress from 1.15 to 1.16.1 > -- > > Key: VFS-650 > URL: https://issues.apache.org/jira/browse/VFS-650 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Gary Gregory >Priority: Major > > Update Apache Commons Compress from 1.15 to 1.16. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMAGING-215) ArrayIndexOutOfBoundsException in DhtSegment
floyd created IMAGING-215:
-
Summary: ArrayIndexOutOfBoundsException in DhtSegment
Key: IMAGING-215
URL: https://issues.apache.org/jira/browse/IMAGING-215
Project: Commons Imaging
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 1.0
Reporter: floyd
Attachments: ArrayIndexOutOfBoundsException_DhtSegment_79.jpeg
I simply ran the Kelinci AFL-based Java fuzzer with the common immaging as
explained here (with better input files than the author, fuzzing is all about
corpus data):
[https://github.com/isstac/kelinci/tree/master/examples/commons-imaging]
I found the following issue when parsing the attached file:
{code:java}
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.commons.imaging.formats.jpeg.segments.DhtSegment$HuffmanTable.(DhtSegment.java:79)
at
org.apache.commons.imaging.formats.jpeg.segments.DhtSegment.(DhtSegment.java:173)
at
org.apache.commons.imaging.formats.jpeg.segments.DhtSegment.(DhtSegment.java:146)
at
org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.visitSegment(JpegDecoder.java:219)
at
org.apache.commons.imaging.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:89)
at
org.apache.commons.imaging.formats.jpeg.decoder.JpegDecoder.decode(JpegDecoder.java:437)
at
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getBufferedImage(JpegImageParser.java:97)
at driver.Driver.main(Driver.java:23)
{code}
The rest is as described in the link, I also used commons-imaging-1.0-RC7.tar.gz
The parser doesn't declare that an ArrayIndexOutOfBoundsException could be
thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355473#comment-16355473 ] Stefan Bodewig commented on COMPRESS-413: - all CI builds are happy, dependency will be gone in 1.17. > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355469#comment-16355469 ] Stefan Bodewig commented on COMPRESS-413: - Somehow we must have overlooked the dependency scope was not restricted to "test" when the PR was merged. It looks as if the PR wanted to replace the transitive dependency of Powermock with a more recent version. I'm not really sure why. For tests I've just removed the dependency completely and we'll see what the different CI systems say. > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RNG-40) Ready for JDK 9 ?
[
https://issues.apache.org/jira/browse/RNG-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346663#comment-16346663
]
Gilles edited comment on RNG-40 at 2/7/18 2:00 PM:
---
To do: write an example (in module {{commons-rng-examples)}} showing that all
the JARs are Java 9 module compliant.
was (Author: erans):
To do: write an example (in module {{commons-rng-examples}} showing that all
the JARs are Java 9 module compliant.
> Ready for JDK 9 ?
> -
>
> Key: RNG-40
> URL: https://issues.apache.org/jira/browse/RNG-40
> Project: Commons RNG
> Issue Type: Sub-task
>Reporter: Gilles
>Priority: Major
> Labels: java9
> Fix For: 1.1
>
>
> Cf. [this post|http://markmail.org/message/j7ki3x67kd2kpavj] on the ML.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-48) Prepare next release (v1.1)
[ https://issues.apache.org/jira/browse/RNG-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated RNG-48: -- Description: (/) Clirr: Please provide feedback in [this ML thread|http://markmail.org/message/24t4v2bsh5x366fe] (x) JDK 9 ready? (x) Modular component: Use new release plugin? was: (x) Clirr: Please provide feedback in [this ML thread|http://markmail.org/message/24t4v2bsh5x366fe] (x) JDK 9 ready? (x) Modular component: Use new release plugin? > Prepare next release (v1.1) > --- > > Key: RNG-48 > URL: https://issues.apache.org/jira/browse/RNG-48 > Project: Commons RNG > Issue Type: Task >Reporter: Gilles >Priority: Minor > Labels: distribution, jdk9, release > Fix For: 1.1 > > > (/) Clirr: Please provide feedback in [this ML > thread|http://markmail.org/message/24t4v2bsh5x366fe] > (x) JDK 9 ready? > (x) Modular component: Use new release plugin? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355425#comment-16355425 ] Dawid Weiss edited comment on COMPRESS-413 at 2/7/18 1:26 PM: -- This issue (commit 5481dd32602) introduced a transitive POM dependency on objenesis, which doesn't seem to be required (at least not for the code, maybe for the tests -- didn't check). Is this really what it ought to be? was (Author: dweiss): This commit introduced a transitive POM dependency on objenesis, which doesn't seem to be required (at least not for the code, maybe for the tests -- didn't check). Is this really what it ought to be? > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355425#comment-16355425 ] Dawid Weiss commented on COMPRESS-413: -- This commit introduced a transitive POM dependency on objenesis, which doesn't seem to be required (at least not for the code, maybe for the tests -- didn't check). Is this really what it ought to be? > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-443) Add a test that verifies Commons Compress is usable as an OSGi bundle
[ https://issues.apache.org/jira/browse/COMPRESS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-443: Description: As COMPRESS-442 COMPRESS-396 and COMPRESS-199 have shown it is way too easy for us to break the OSGi manifest without anybody noticing. See [https://lists.apache.org/thread.html/1bb1d342900ed78d7e280d9321ea38900c10c99e03241aaa11ceb6f9@%3Cdev.commons.apache.org%3E] for some hints how a test could be written. was: As COMPRESS-442 COMPRESS-396 and COMPRESS-199 have shown it is way to easy for us to break the OSGi manifest without anybody noticing. See [https://lists.apache.org/thread.html/1bb1d342900ed78d7e280d9321ea38900c10c99e03241aaa11ceb6f9@%3Cdev.commons.apache.org%3E] for some hints how a test could be written. > Add a test that verifies Commons Compress is usable as an OSGi bundle > - > > Key: COMPRESS-443 > URL: https://issues.apache.org/jira/browse/COMPRESS-443 > Project: Commons Compress > Issue Type: Test > Components: Build >Affects Versions: 1.16 >Reporter: Stefan Bodewig >Priority: Major > Fix For: 1.17 > > > As COMPRESS-442 COMPRESS-396 and COMPRESS-199 have shown it is way too easy > for us to break the OSGi manifest without anybody noticing. > See > [https://lists.apache.org/thread.html/1bb1d342900ed78d7e280d9321ea38900c10c99e03241aaa11ceb6f9@%3Cdev.commons.apache.org%3E] > for some hints how a test could be written. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-443) Add a test that verifies Commons Compress is usable as an OSGi bundle
Stefan Bodewig created COMPRESS-443: --- Summary: Add a test that verifies Commons Compress is usable as an OSGi bundle Key: COMPRESS-443 URL: https://issues.apache.org/jira/browse/COMPRESS-443 Project: Commons Compress Issue Type: Test Components: Build Affects Versions: 1.16 Reporter: Stefan Bodewig Fix For: 1.17 As COMPRESS-442 COMPRESS-396 and COMPRESS-199 have shown it is way to easy for us to break the OSGi manifest without anybody noticing. See [https://lists.apache.org/thread.html/1bb1d342900ed78d7e280d9321ea38900c10c99e03241aaa11ceb6f9@%3Cdev.commons.apache.org%3E] for some hints how a test could be written. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JEXL-250) Safe navigation operator
[
https://issues.apache.org/jira/browse/JEXL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-250.
Resolution: Fixed
Committed
https://github.com/apache/commons-jexl/commit/2aa8022c4c330a8640c7d5415d53ab5d3ab71733
> Safe navigation operator
>
>
> Key: JEXL-250
> URL: https://issues.apache.org/jira/browse/JEXL-250
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> It would be more convenient for a script writer to have a kind of safe
> navigation operator, in the form of, for example, ({{object?.property),}} for
> null pointer dereferences. I think its quite a common feature of many
> scripting (and compiled languages) now. The safe operator should work like
> basic navigation operator for non null values and should short-circuit the
> entire expression evaluation after encountering null value.
> I see the difference of new operator from the existing lenient mode
> evaluation in ability to explicitly define places in an expression where
> {{null}} deference is allowed, for example the expression
> {code}Order.Customer?.Name{code} defines that each {{Order}} should have a
> {{Customer}} and only the {{Name}} of the {{Customer}} is optional.
> The difference of new operator from the existing null coalescing {{??}}
> operator is in its ability to short-circuit evaluation.
> So, safe navigation operator would be a helpful syntaxic sugar which in my
> opinion does not overlap with an existing functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JEXL-252) Allow for interpolated strings to be used in property access operators
[
https://issues.apache.org/jira/browse/JEXL-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-252.
Resolution: Fixed
Committed
https://github.com/apache/commons-jexl/commit/2aa8022c4c330a8640c7d5415d53ab5d3ab71733
> Allow for interpolated strings to be used in property access operators
> --
>
> Key: JEXL-252
> URL: https://issues.apache.org/jira/browse/JEXL-252
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Now we have a possibility to access an object property by specifying either
> {code}object.property{code} or {code}object."property"{code} expression, but
> not {code}object.`property`{code} expression. Since interpolated strings can
> be used anywhere in scripts as ordinal strings, it would be logical to allow
> them to be used in property access operators too. It would allow to have the
> property name not necessarily to be a constant, but to be evaluated without
> using the array access operator, since property access operator and array
> access operator could be implemented (overloaded) differently for the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-568) AutoCloseInputStream crash on reset() when reading the whole stream
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355207#comment-16355207
]
Thomas Mortagne commented on IO-568:
I can work on a pull request but I would first like to know if you agree with
the need to support mark/reset even when reading the whole stream.
> AutoCloseInputStream crash on reset() when reading the whole stream
> ---
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.7
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
> Among other things it's causing TIKA-2395.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IO-568) AutoCloseInputStream crash on reset() when reading the whole stream
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated IO-568:
---
Description:
If the the inputstream support mark it should switch back from
ClosedInputStream to initial InputStream and call reset on it.
To reproduce:
{code}
AutoCloseInputStream stream = new AutoCloseInputStream(new
ByteArrayInputStream("toto".getBytes()));
stream.mark("toto".length());
while (stream.read(new byte[1]) != -1);
stream.reset();
{code}
Among other things it's causing TIKA-2395.
was:
If the the inputstream support mark it should switch back from
ClosedInputStream to initial InputStream and call reset on it.
To reproduce:
{code}
AutoCloseInputStream stream = new AutoCloseInputStream(new
ByteArrayInputStream("toto".getBytes()));
stream.mark("toto".length());
while (stream.read(new byte[1]) != -1);
stream.reset();
{code}
> AutoCloseInputStream crash on reset() when reading the whole stream
> ---
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.7
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
> Among other things it's causing TIKA-2395.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IO-568) AutoCloseInputStream crash on reset() when reading the whole does not support InputStream#stream
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated IO-568:
---
Description:
If the the inputstream support mark it should switch back from
ClosedInputStream to initial InputStream and call reset on it.
To reproduce:
{code}
AutoCloseInputStream stream = new AutoCloseInputStream(new
ByteArrayInputStream("toto".getBytes()));
stream.mark("toto".length());
while (stream.read(new byte[1]) != -1);
stream.reset();
{code}
was:
If the the inputstream support mark it should switch back from
ClosedInputStream to initial InputStream and call reset on it.
To reproduce:
{code}
> AutoCloseInputStream crash on reset() when reading the whole does not support
> InputStream#stream
>
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.7
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IO-568) AutoCloseInputStream crash on reset() when reading the whole stream
[
https://issues.apache.org/jira/browse/IO-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated IO-568:
---
Summary: AutoCloseInputStream crash on reset() when reading the whole
stream (was: AutoCloseInputStream crash on reset() when reading the whole does
not support InputStream#stream)
> AutoCloseInputStream crash on reset() when reading the whole stream
> ---
>
> Key: IO-568
> URL: https://issues.apache.org/jira/browse/IO-568
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Thomas Mortagne
>Priority: Minor
> Fix For: 2.7
>
>
> If the the inputstream support mark it should switch back from
> ClosedInputStream to initial InputStream and call reset on it.
> To reproduce:
> {code}
> AutoCloseInputStream stream = new AutoCloseInputStream(new
> ByteArrayInputStream("toto".getBytes()));
> stream.mark("toto".length());
> while (stream.read(new byte[1]) != -1);
> stream.reset();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IO-568) AutoCloseInputStream crash on reset() when reading the whole does not support InputStream#stream
Thomas Mortagne created IO-568:
--
Summary: AutoCloseInputStream crash on reset() when reading the
whole does not support InputStream#stream
Key: IO-568
URL: https://issues.apache.org/jira/browse/IO-568
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.6
Reporter: Thomas Mortagne
Fix For: 2.7
If the the inputstream support mark it should switch back from
ClosedInputStream to initial InputStream and call reset on it.
To reproduce:
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
