[jira] [Commented] (COLLECTIONS-593) Compilation errors (generics) with JDK9

2016-10-20 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15594179#comment-15594179
 ] 

Gary Gregory commented on COLLECTIONS-593:
--

Can this ticket be closed then?

> Compilation errors (generics) with JDK9
> ---
>
> Key: COLLECTIONS-593
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-593
> Project: Commons Collections
>  Issue Type: Bug
>Affects Versions: 4.x
> Environment: Java 9b125
>Reporter: Vincent Privat
>  Labels: generics, jdk9, josm-found
>
> Current codebase does not compile with JDK9 (build 125): 28 errors below.
> I am not sure if this is a bug of JDK9 of a stricter compilation rule with 
> generics.
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/BagUtils.java:98:
>  error: incompatible types: Bag cannot be converted to Bag
> [javac] return UnmodifiableBag.unmodifiableBag(bag);
> [javac]   ^
> [javac]   where E is a type-variable:
> [javac] E extends Object declared in method unmodifiableBag(Bag extends E>)
> [javac]   where CAP#1 is a fresh type-variable:
> [javac] CAP#1 extends E from capture of ? extends E
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:795:
>  error: incompatible types: Collection cannot be converted to 
> Collection
> [javac] final Collection resultCollection = 
> collect(collection, transformer);
> [javac]   ^
> [javac]   where C is a type-variable:
> [javac] C extends Object declared in method 
> transform(Collection,Transformer)
> [javac]   where CAP#1 is a fresh type-variable:
> [javac] CAP#1 extends C from capture of ? extends C
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:1835:
>  error: incompatible types: Collection cannot be converted to 
> Collection
> [javac] return 
> UnmodifiableCollection.unmodifiableCollection(collection);
> [javac] ^
> [javac]   where C is a type-variable:
> [javac] C extends Object declared in method 
> unmodifiableCollection(Collection)
> [javac]   where CAP#1 is a fresh type-variable:
> [javac] CAP#1 extends C from capture of ? extends C
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/FluentIterable.java:311:
>  error: incompatible types: FluentIterable cannot be converted to 
> FluentIterable
> [javac] return of(IterableUtils.transformedIterable(iterable, 
> transformer));
> [javac]  ^
> [javac]   where O,E are type-variables:
> [javac] O extends Object declared in method 
> transform(Transformer)
> [javac] E extends Object declared in class FluentIterable
> [javac]   where CAP#1 is a fresh type-variable:
> [javac] CAP#1 extends O from capture of ? extends O
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:429:
>  error: incompatible types: Iterator cannot be converted to Iterator
> [javac] return 
> IteratorUtils.transformedIterator(iterable.iterator(), transformer);
> [javac] ^
> [javac]   where O,I are type-variables:
> [javac] O extends Object declared in method 
> transformedIterable(Iterable,Transformer)
> [javac] I extends Object declared in method 
> transformedIterable(Iterable,Transformer)
> [javac]   where CAP#1 is a fresh type-variable:
> [javac] CAP#1 extends O from capture of ? extends O
> [javac] 
> /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:833:
>  error: no suitable method found for 
> partition(Iterable,Factory>,Predicate[])
> [javac] return partition(iterable, factory, predicates);
> [javac]^
> [javac] method IterableUtils.partition(Iterable O#1>,Predicate) is not applicable
> [javac]   (cannot infer type-variable(s) O#1
> [javac] (actual and formal argument lists differ in length))
> [javac] method IterableUtils.partition(Iterable O#2>,Predicate...) is not

[jira] [Resolved] (COLLECTIONS-597) Correction of Javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure

2016-10-20 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved COLLECTIONS-597.
--
   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 4.2

In SVN trunk.

> Correction of Javadoc for 
> org.apache.commons.collections4.functors.CatchAndRethrowClosure
> -
>
> Key: COLLECTIONS-597
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-597
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Functor
>Affects Versions: 4.0, 4.1
>Reporter: Enrique
>Assignee: Gary Gregory
>Priority: Trivial
>  Labels: documentation
> Fix For: 4.2
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Correct the javadoc for 
> org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing:
> CollctionUtils.forAllDo(strList, writer);
> by:
> CollectionUtils.forAllDo(strList, writer);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COLLECTIONS-597) Correction of Javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure

2016-10-20 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated COLLECTIONS-597:
-
Summary: Correction of Javadoc for 
org.apache.commons.collections4.functors.CatchAndRethrowClosure  (was: 
Correction of javadoc for 
org.apache.commons.collections4.functors.CatchAndRethrowClosure)

> Correction of Javadoc for 
> org.apache.commons.collections4.functors.CatchAndRethrowClosure
> -
>
> Key: COLLECTIONS-597
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-597
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Functor
>Affects Versions: 4.0, 4.1
>Reporter: Enrique
>Priority: Trivial
>  Labels: documentation
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Correct the javadoc for 
> org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing:
> CollctionUtils.forAllDo(strList, writer);
> by:
> CollectionUtils.forAllDo(strList, writer);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COLLECTIONS-594) Web site spelling error: MultiValuedMapeList

2016-10-20 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated COLLECTIONS-594:
-
Summary: Web site spelling error: MultiValuedMapeList  (was: Website 
spelling error: MultiValuedMapeList)

> Web site spelling error: MultiValuedMapeList
> 
>
> Key: COLLECTIONS-594
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-594
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 4.1
>Reporter: Javen O'Neal
>Assignee: Gary Gregory
>Priority: Trivial
>  Labels: Website
> Fix For: 4.2
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> On http://commons.apache.org/proper/commons-collections/history.html 
> Collections 4.1 section
> -MultiValuedMapeList
> +MultiValuedMapList



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-196) The 1.0 SNAPSHOT is not available in the repository you reported

2016-10-20 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IMAGING-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved IMAGING-196.
--
Resolution: Fixed

SNAPSHOTs are deployed here to 
https://repository.apache.org/content/repositories/snapshots/

For example, for Commons Imaging, this is  
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-imaging/

Please verify and close.

> The 1.0 SNAPSHOT is not available in the repository you reported
> 
>
> Key: IMAGING-196
> URL: https://issues.apache.org/jira/browse/IMAGING-196
> Project: Commons Imaging
>  Issue Type: Bug
>Reporter: valib
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IMAGING-196) The 1.0 SNAPSHOT is not available in the repository you reported

2016-10-20 Thread valib (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IMAGING-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

valib updated IMAGING-196:
--
Summary: The 1.0 SNAPSHOT is not available in the repository you reported  
(was: The 1.0 SNAPSHOT is not available in the repositoty you reported)

> The 1.0 SNAPSHOT is not available in the repository you reported
> 
>
> Key: IMAGING-196
> URL: https://issues.apache.org/jira/browse/IMAGING-196
> Project: Commons Imaging
>  Issue Type: Bug
>Reporter: valib
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IMAGING-196) The 1.0 SNAPSHOT is not available in the reporitoty you reported

2016-10-20 Thread valib (JIRA) 
valib created IMAGING-196:
-

 Summary: The 1.0 SNAPSHOT is not available in the reporitoty you 
reported
 Key: IMAGING-196
 URL: https://issues.apache.org/jira/browse/IMAGING-196
 Project: Commons Imaging
  Issue Type: Bug
Reporter: valib
Priority: Critical






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DAEMON-356) prunsrv in exe mode (not Java or JVM) passes arguments in double quotes

2016-10-20 Thread Mike Conner (JIRA) 
Mike Conner created DAEMON-356:
--

 Summary: prunsrv in exe mode (not Java or JVM) passes arguments in 
double quotes
 Key: DAEMON-356
 URL: https://issues.apache.org/jira/browse/DAEMON-356
 Project: Commons Daemon
  Issue Type: Improvement
  Components: Procrun
Affects Versions: 1.0.15
 Environment: Running on Windows 2012
Reporter: Mike Conner


I created service the using StartParams argument (contains spaces and other 
special characters).  Called process (StartImage argument as either bat script 
& exe) receive the arguments surrounded by double quotes.  This requires a 
wrapper to remove the quotes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LANG-1277) StringUtils#getLevenshteinDistance reduce memory consumption

2016-10-20 Thread Pascal Schumacher (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1277.
-
Resolution: Fixed

Pull request merged. Thanks!

> StringUtils#getLevenshteinDistance reduce memory consumption
> 
>
> Key: LANG-1277
> URL: https://issues.apache.org/jira/browse/LANG-1277
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> see [https://github.com/apache/commons-lang/pull/189] for details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1277) StringUtils#getLevenshteinDistance reduce memory consumption

2016-10-20 Thread Pascal Schumacher (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1277:

Component/s: lang.*

> StringUtils#getLevenshteinDistance reduce memory consumption
> 
>
> Key: LANG-1277
> URL: https://issues.apache.org/jira/browse/LANG-1277
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> see [https://github.com/apache/commons-lang/pull/189] for details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #189: new impl of LevenshteinDistance

2016-10-20 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/189
  
@yufcuy: Thanks for the pull request. :+1: 

@kinow: Thanks for the review. I have added the link and replaced tabs with 
spaces after merging. Feel free to change/improve anything.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang pull request #189: new impl of LevenshteinDistance

2016-10-20 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/189


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (LANG-1277) StringUtils#getLevenshteinDistance reduce memory consumption

2016-10-20 Thread Pascal Schumacher (JIRA) 
Pascal Schumacher created LANG-1277:
---

 Summary: StringUtils#getLevenshteinDistance reduce memory 
consumption
 Key: LANG-1277
 URL: https://issues.apache.org/jira/browse/LANG-1277
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 3.5
Reporter: Pascal Schumacher
Assignee: Pascal Schumacher
 Fix For: 3.6


see [https://github.com/apache/commons-lang/pull/189] for details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LANG-1070) ArrayUtils#add confusing example in javadoc

2016-10-20 Thread Pascal Schumacher (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher resolved LANG-1070.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.6

I have fixed the javadoc examples. Wether the behavior is correct is a 
different issue in my option.

> ArrayUtils#add confusing example in javadoc
> ---
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Assignee: Pascal Schumacher
>Priority: Trivial
> Fix For: 3.6
>
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an 
> exception.
> Either remove this line from documentation, or rewrite it to explicitly 
> mention the exception. Maybe there are other related methods with similar 
> problem in the docs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1070) ArrayUtils#add confusing example in javadoc

2016-10-20 Thread Pascal Schumacher (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1070:

Summary: ArrayUtils#add confusing example in javadoc  (was: confusing 
example in ArrayUtils.add() javadoc)

> ArrayUtils#add confusing example in javadoc
> ---
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an 
> exception.
> Either remove this line from documentation, or rewrite it to explicitly 
> mention the exception. Maybe there are other related methods with similar 
> problem in the docs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1070) confusing example in ArrayUtils.add() javadoc

2016-10-20 Thread Pascal Schumacher (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Schumacher updated LANG-1070:

Summary: confusing example in ArrayUtils.add() javadoc  (was: confusing 
example in ArrayUtils.add())

> confusing example in ArrayUtils.add() javadoc
> -
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an 
> exception.
> Either remove this line from documentation, or rewrite it to explicitly 
> mention the exception. Maybe there are other related methods with similar 
> problem in the docs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (POOL-316) Evictor periodically throws NullPointerExceptions

2016-10-20 Thread Caleb Cittadino (JIRA) 
Caleb Cittadino created POOL-316:


 Summary: Evictor periodically throws NullPointerExceptions
 Key: POOL-316
 URL: https://issues.apache.org/jira/browse/POOL-316
 Project: Commons Pool
  Issue Type: Bug
Affects Versions: 2.4.2
Reporter: Caleb Cittadino


When the logging level is set to WARN or INFO we see the following NPE 
peridically:
{code}
[2016-10-20 13:26:38,646 | WARN  | org.apache.commons.dbcp2.BasicDataSource] An 
internal object pool swallowed an Exception.
java.lang.Exception: java.lang.NullPointerException
   at 
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:787)
 [commons-pool2-2.4.2.jar:2.4.2]
   at 
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1036)
 [commons-pool2-2.4.2.jar:2.4.2]
   at java.util.TimerThread.mainLoop(Unknown Source) [na:1.8.0_25]
   at java.util.TimerThread.run(Unknown Source) [na:1.8.0_25]
Caused by: java.lang.NullPointerException: null
   at 
org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:781)
 [commons-pool2-2.4.2.jar:2.4.2]
   ... 3 common frames omitted
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COLLECTIONS-597) Correction of javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure

2016-10-20 Thread Enrique (JIRA) 
Enrique created COLLECTIONS-597:
---

 Summary: Correction of javadoc for 
org.apache.commons.collections4.functors.CatchAndRethrowClosure
 Key: COLLECTIONS-597
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-597
 Project: Commons Collections
  Issue Type: Bug
  Components: Functor
Affects Versions: 4.1, 4.0
Reporter: Enrique
Priority: Trivial


Correct the javadoc for 
org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing:
CollctionUtils.forAllDo(strList, writer);
by:
CollectionUtils.forAllDo(strList, writer);




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code:collapsible=false}
import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code:linenumbers}
import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code:bar=false}
import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code|bar=false}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code}
import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code}
import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{
pool.close();

[jira] [Commented] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15591435#comment-15591435
 ] 

Buğra Gedik commented on POOL-315:
--

I updated the bug report with example code that illustrates the problem.

> GenericObjectPool close() does not wait for the current eviction task
> -
>
> Key: POOL-315
> URL: https://issues.apache.org/jira/browse/POOL-315
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Buğra Gedik
>
> The {{close}} method is implemented as follows:
> {code}
> public void close() {
> if(!this.isClosed()) {
> Object var1 = this.closeLock;
> synchronized(this.closeLock) {
> if(!this.isClosed()) {
> this.startEvictor(-1L);
> this.closed = true;
> this.clear();
> this.jmxUnregister();
> this.idleObjects.interuptTakeWaiters();
> }
> }
> }
> }
> {code}
> The line {{this.startEvictor(-1L);}} calls 
> {{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and 
> that in turn calls the following method in {{EvictionTimer}}:
> {code}
> static synchronized void cancel(TimerTask task) {
> task.cancel();
> --_usageCount;
> if(_usageCount == 0) {
> _timer.cancel();
> _timer = null;
> }
> }
> {code}
> Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the 
> documentation of it, you'll see that it does not block on the currently 
> executing task. Even though {{task.cancel()}} is called, there is no code to 
> wait for it to complete. The end result is that, even if you close the pool, 
> there may still be an eviction thread running. Yes, it will eventually go 
> away, but in some rare cases it takes a bit of time to go away.
> When running code under Tomcat, this results in the 
> {{"commons-pool-EvictionTimer"}} thread (created in the class 
> {{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
> This happens rarely, since most of the time the timer thread goes away before 
> Tomcat checks for leaking threads.
> In my opinion a fix can be put into {{startEvictor}} in 
> {{BaseGenericObjectPool}}:
> {code}
> final void startEvictor(long delay) {
> synchronized (evictionLock) {
> if (null != evictor) {
> EvictionTimer.cancel(evictor);
> // HERE: evictor.waitForCompletion();
> evictor = null;
> evictionIterator = null;
> }
> if (delay > 0) {
> evictor = new Evictor();
> EvictionTimer.schedule(evictor, delay, delay);
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Description: 
The {{close}} method is implemented as follows:

{code}
public void close() {
if(!this.isClosed()) {
Object var1 = this.closeLock;
synchronized(this.closeLock) {
if(!this.isClosed()) {
this.startEvictor(-1L);
this.closed = true;
this.clear();
this.jmxUnregister();
this.idleObjects.interuptTakeWaiters();
}
}
}
}
{code}

The line {{this.startEvictor(-1L);}} calls 
{{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and that 
in turn calls the following method in {{EvictionTimer}}:

{code}
static synchronized void cancel(TimerTask task) {
task.cancel();
--_usageCount;
if(_usageCount == 0) {
_timer.cancel();
_timer = null;
}
}
{code}

Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the documentation 
of it, you'll see that it does not block on the currently executing task. Even 
though {{task.cancel()}} is called, there is no code to wait for it to 
complete. The end result is that, even if you close the pool, there may still 
be an eviction thread running. Yes, it will eventually go away, but in some 
rare cases it takes a bit of time to go away.

When running code under Tomcat, this results in the 
{{"commons-pool-EvictionTimer"}} thread (created in the class 
{{EvictionTimer}}) to be reported as leaking, despite the pool being closed. 
This happens rarely, since most of the time the timer thread goes away before 
Tomcat checks for leaking threads.

In my opinion a fix can be put into {{startEvictor}} in 
{{BaseGenericObjectPool}}:

{code}
final void startEvictor(long delay) {
synchronized (evictionLock) {
if (null != evictor) {
EvictionTimer.cancel(evictor);
// HERE: evictor.waitForCompletion();
evictor = null;
evictionIterator = null;
}
if (delay > 0) {
evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}
{code}

Here is an example that illustrates the problem:
{code}
package com.unscrambl.drive;

import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{

[jira] [Commented] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15591433#comment-15591433
 ] 

Buğra Gedik commented on POOL-315:
--

{code}
package com.unscrambl.drive;

import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{
pool.close();
}
}
final Thread[] threads = new Thread[Thread.activeCount()];
Thread.enumerate(threads);
for (final Thread thread : threads)
{
if (thread == null)
{
continue;
}
assertFalse(thread.getName()
.contains(COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME));
}
}
}
{code}

> GenericObjectPool close() does not wait for the current eviction task
> -
>
> Key: POOL-315
> URL: https://issues.apache.org/jira/browse/POOL-315
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Buğra Gedik
>
> The {{close}} method is implemented as follows:
> {code}
> public void close() {
> if(!this.isClosed()) {
> Object var1 = this.closeLock;
> synchronized(this.closeLock) {
> if(!this.isClosed()) {
> this.startEvictor(-1L);
> this.closed = true;
> this.clear();
> this.jmxUnregister();
> this.idleObjects.interuptTakeWaiters();
> }
> }
> }
> }
> {code}
> The line {{this.startEvictor(-1L);}} calls 
> {{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and 
> that in turn calls the following method in {{EvictionTimer}}:
> {code}
> static synchronized void cancel(TimerTask task) {
> task.cancel();
> --_usageCount;
> if(_usageCount == 0) {
> _timer.cancel();
> _timer = null;
> }
> }
> {code}
> Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the 
> documentation of it, you'll see that it does not block on the currently 
> executing task. Even though {{task.cancel()}} is called, there is no code to 
> wait for it to complete. The end result is that, even if you close the pool, 
> there may still be an eviction thread running. Yes, it will eventually go 
> away, but in some rare cases it takes a bit of time to go away.
> When running code under Tomcat, this results in the 
>

[jira] [Issue Comment Deleted] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Comment: was deleted

(was: {code}
package com.unscrambl.drive;

import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{
pool.close();
}
}
final Thread[] threads = new Thread[Thread.activeCount()];
Thread.enumerate(threads);
for (final Thread thread : threads)
{
if (thread == null)
{
continue;
}
assertFalse(thread.getName()
.contains(COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME));
}
}
}
{code})

> GenericObjectPool close() does not wait for the current eviction task
> -
>
> Key: POOL-315
> URL: https://issues.apache.org/jira/browse/POOL-315
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Buğra Gedik
>
> The {{close}} method is implemented as follows:
> {code}
> public void close() {
> if(!this.isClosed()) {
> Object var1 = this.closeLock;
> synchronized(this.closeLock) {
> if(!this.isClosed()) {
> this.startEvictor(-1L);
> this.closed = true;
> this.clear();
> this.jmxUnregister();
> this.idleObjects.interuptTakeWaiters();
> }
> }
> }
> }
> {code}
> The line {{this.startEvictor(-1L);}} calls 
> {{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and 
> that in turn calls the following method in {{EvictionTimer}}:
> {code}
> static synchronized void cancel(TimerTask task) {
> task.cancel();
> --_usageCount;
> if(_usageCount == 0) {
> _timer.cancel();
> _timer = null;
> }
> }
> {code}
> Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the 
> documentation of it, you'll see that it does not block on the currently 
> executing task. Even though {{task.cancel()}} is called, there is no code to 
> wait for it to complete. The end result is that, even if you close the pool, 
> there may still be an eviction thread running. Yes, it will eventually go 
> away, but in some rare cases it takes a bit of time to go away.
> When running code under Tomcat, this results in the 
>

[jira] [Issue Comment Deleted] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated POOL-315:
-
Comment: was deleted

(was: {code}
package com.unscrambl.drive;

import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{
pool.close();
}
}
final Thread[] threads = new Thread[Thread.activeCount()];
Thread.enumerate(threads);
for (final Thread thread : threads)
{
if (thread == null)
{
continue;
}
assertFalse(thread.getName()
.contains(COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME));
}
}
}
{code})

> GenericObjectPool close() does not wait for the current eviction task
> -
>
> Key: POOL-315
> URL: https://issues.apache.org/jira/browse/POOL-315
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Buğra Gedik
>
> The {{close}} method is implemented as follows:
> {code}
> public void close() {
> if(!this.isClosed()) {
> Object var1 = this.closeLock;
> synchronized(this.closeLock) {
> if(!this.isClosed()) {
> this.startEvictor(-1L);
> this.closed = true;
> this.clear();
> this.jmxUnregister();
> this.idleObjects.interuptTakeWaiters();
> }
> }
> }
> }
> {code}
> The line {{this.startEvictor(-1L);}} calls 
> {{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and 
> that in turn calls the following method in {{EvictionTimer}}:
> {code}
> static synchronized void cancel(TimerTask task) {
> task.cancel();
> --_usageCount;
> if(_usageCount == 0) {
> _timer.cancel();
> _timer = null;
> }
> }
> {code}
> Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the 
> documentation of it, you'll see that it does not block on the currently 
> executing task. Even though {{task.cancel()}} is called, there is no code to 
> wait for it to complete. The end result is that, even if you close the pool, 
> there may still be an eviction thread running. Yes, it will eventually go 
> away, but in some rare cases it takes a bit of time to go away.
> When running code under Tomcat, this results in the 
>

[jira] [Commented] (POOL-315) GenericObjectPool close() does not wait for the current eviction task

2016-10-20 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/POOL-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15591432#comment-15591432
 ] 

Buğra Gedik commented on POOL-315:
--

{code}
package com.unscrambl.drive;

import static org.junit.Assert.assertFalse;

import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.PooledObjectFactory;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.junit.Test;

public class PoolTest
{
private static final CharSequence COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME =
"commons-pool-EvictionTimer";
private static final long EVICTION_PERIOD_IN_MILLIS = 100;

private static class Foo
{
}

private static class PooledFooFactory implements PooledObjectFactory
{
private static final long VALIDATION_WAIT_IN_MILLIS = 1000;

@Override
public PooledObject makeObject() throws Exception
{
return new DefaultPooledObject<>(new Foo());
}

@Override
public void destroyObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public boolean validateObject(
PooledObject pooledObject)
{
try
{
Thread.sleep(VALIDATION_WAIT_IN_MILLIS);
}
catch (final InterruptedException e)
{
Thread.interrupted();
}
return false;
}

@Override
public void activateObject(
PooledObject pooledObject) throws Exception
{
}

@Override
public void passivateObject(
PooledObject pooledObject) throws Exception
{
}
}

@Test
public void testPool() throws Exception
{
final GenericObjectPoolConfig poolConfig =
new GenericObjectPoolConfig();
poolConfig.setTestWhileIdle(true /* testWhileIdle */);
final PooledFooFactory pooledFooFactory = new PooledFooFactory();
GenericObjectPool pool = null;
try
{
pool = new GenericObjectPool<>(pooledFooFactory, poolConfig);
pool.setTimeBetweenEvictionRunsMillis(EVICTION_PERIOD_IN_MILLIS);
pool.addObject();
try
{
Thread.sleep(EVICTION_PERIOD_IN_MILLIS);
}
catch (final InterruptedException e)
{
   Thread.interrupted();
}
}
finally
{
if (pool != null)
{
pool.close();
}
}
final Thread[] threads = new Thread[Thread.activeCount()];
Thread.enumerate(threads);
for (final Thread thread : threads)
{
if (thread == null)
{
continue;
}
assertFalse(thread.getName()
.contains(COMMONS_POOL_EVICTIONS_TIMER_THREAD_NAME));
}
}
}
{code}

> GenericObjectPool close() does not wait for the current eviction task
> -
>
> Key: POOL-315
> URL: https://issues.apache.org/jira/browse/POOL-315
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Buğra Gedik
>
> The {{close}} method is implemented as follows:
> {code}
> public void close() {
> if(!this.isClosed()) {
> Object var1 = this.closeLock;
> synchronized(this.closeLock) {
> if(!this.isClosed()) {
> this.startEvictor(-1L);
> this.closed = true;
> this.clear();
> this.jmxUnregister();
> this.idleObjects.interuptTakeWaiters();
> }
> }
> }
> }
> {code}
> The line {{this.startEvictor(-1L);}} calls 
> {{EvictionTimer.cancel(this.evictor);}} from {{BaseGenericObjectPool}} and 
> that in turn calls the following method in {{EvictionTimer}}:
> {code}
> static synchronized void cancel(TimerTask task) {
> task.cancel();
> --_usageCount;
> if(_usageCount == 0) {
> _timer.cancel();
> _timer = null;
> }
> }
> {code}
> Here, {{_timer}} is a {{java.util.TimerTask}}. If you look at the 
> documentation of it, you'll see that it does not block on the currently 
> executing task. Even though {{task.cancel()}} is called, there is no code to 
> wait for it to complete. The end result is that, even if you close the pool, 
> there may still be an eviction thread running. Yes, it will eventually go 
> away, but in some rare cases it takes a bit of time to go away.
> When running code under Tomcat, this results in the 
>

[jira] [Updated] (LANG-1276) [lang] ArrayIndexOutOfBoundsException StrBuilder replace

2016-10-20 Thread Benedikt Ritter (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated LANG-1276:
--
Fix Version/s: 3.6
   Patch Needed

> [lang] ArrayIndexOutOfBoundsException StrBuilder replace
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1276) [lang] ArrayIndexOutOfBoundsException StrBuilder replace

2016-10-20 Thread Benedikt Ritter (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590997#comment-15590997
 ] 

Benedikt Ritter commented on LANG-1276:
---

Patches welcome!

> [lang] ArrayIndexOutOfBoundsException StrBuilder replace
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IMAGING-195) Incorrect Maven coordinates on project website

2016-10-20 Thread Benedikt Ritter (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IMAGING-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated IMAGING-195:

Summary: Incorrect Maven coordinates on project website  (was: Maven 
documentation mistake)

> Incorrect Maven coordinates on project website
> --
>
> Key: IMAGING-195
> URL: https://issues.apache.org/jira/browse/IMAGING-195
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.97
> Environment: website
>Reporter: Keith Strydom
>Priority: Trivial
>  Labels: newbie
> Fix For: 1.0
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Two blocks of maven XML are not well formed on this web page: 
> https://commons.apache.org/proper/commons-imaging/
> The closing tags need slashes added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IMAGING-195) Incorrect Maven coordinates on project website

2016-10-20 Thread Benedikt Ritter (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IMAGING-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved IMAGING-195.
-
   Resolution: Fixed
Fix Version/s: (was: 0.97)
   1.0

{code}
~/w/a/c/imaging > svn ci -m "IMAGING-195: Incorrect Maven coordinates on 
project website. Thanks to Keith Strydom."
Sendingsrc/changes/changes.xml
Sendingsrc/site/xdoc/index.xml
Transmitting file data ..done
Committing transaction...
Committed revision 1765753.
{code}

Thank you!

> Incorrect Maven coordinates on project website
> --
>
> Key: IMAGING-195
> URL: https://issues.apache.org/jira/browse/IMAGING-195
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.97
> Environment: website
>Reporter: Keith Strydom
>Priority: Trivial
>  Labels: newbie
> Fix For: 1.0
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Two blocks of maven XML are not well formed on this web page: 
> https://commons.apache.org/proper/commons-imaging/
> The closing tags need slashes added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #195: LANG-1160 StringUtils.abbreviate() to support 'cust...

2016-10-20 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/195
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1160) StringUtils.abbreviate() to support "custom ellipses" parameter

2016-10-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590975#comment-15590975
 ] 

ASF GitHub Bot commented on LANG-1160:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/195
  
+1


> StringUtils.abbreviate() to support "custom ellipses" parameter
> ---
>
> Key: LANG-1160
> URL: https://issues.apache.org/jira/browse/LANG-1160
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.4
>Reporter: Hendy Irawan
>Priority: Trivial
>
> {{abbreviateMiddle()}} supports custom replacement string.
> {{abbreviate()}} needs to also support this, for example to to use "…" 
> Unicode character instead of three "..."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)