[jira] [Created] (COLLECTIONS-675) Modify IteratorUtils.peekingIterator to return PeekingIterator

[Matthew Knight (JIRA)]

Matthew Knight created COLLECTIONS-675:
--

 Summary: Modify IteratorUtils.peekingIterator to return 
PeekingIterator
 Key: COLLECTIONS-675
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-675
 Project: Commons Collections
  Issue Type: Improvement
  Components: Iterator
Affects Versions: 4.1
Reporter: Matthew Knight


IteratorUtils.peekingIterator currently returns java.util.Iterator, which 
requires casts or assumptions in order to make use of peek method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
E-mail sent. See the latest messages in the Commons Developers mailing 
list, with the tag [lang]. There should be one from me about this PR and your 
JIRA ticket, asking for more reviews.

Thanks for being so patient @ottobackwards !!

Bruno


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
E-mail sent. See the latest messages in the Commons Developers mailing 
list, with the tag [lang]. There should be one from me about this PR and your 
JIRA ticket, asking for more reviews.

Thanks for being so patient @ottobackwards !!

Bruno


---

[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LANG-1373:
--

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
Pull request looks good. Toyed with the code a bit 
(https://gist.github.com/kinow/c0873daf069c2e64bc69d6305400e610), and I like 
the current design.

@ottobackwards let's ask in the ML if anybody else would like to review it, 
and if nobody replies by the weekend, consider it merged. During the merge, I'd 
like to squash the commits to keep the commit history/tree simpler. Would you 
mind squashing the commits and updating the pull request to one single commit 
(or a few if you think it's necessary), please?

Cheers
B


> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
>
> While working on adding some timing functionality to a Metron feature, I came 
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our 
> Stellar dsl, and have have a group of related timings, such that the end 
> result was the overall time of the call, and nested timings of other calls 
> executed during the dsl execution of that function. These timings would all 
> be named, and have a path for identification and include timing the language 
> compiler/execution as well as the function execution itself. It would be 
> helpful if they were tagged in some way as well, such that the consumer could 
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it 
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have 
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class 
> that allows callers to create multiple named and possibly nested timing 
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am 
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to 
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results 
> after the completion of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/311
  
Pull request looks good. Toyed with the code a bit 
(https://gist.github.com/kinow/c0873daf069c2e64bc69d6305400e610), and I like 
the current design.

@ottobackwards let's ask in the ML if anybody else would like to review it, 
and if nobody replies by the weekend, consider it merged. During the merge, I'd 
like to squash the commits to keep the commit history/tree simpler. Would you 
mind squashing the commits and updating the pull request to one single commit 
(or a few if you think it's necessary), please?

Cheers
B


---

[jira] [Issue Comment Deleted] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion

[Otto Fowler (JIRA)]

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

Otto Fowler updated VFS-525:

Comment: was deleted

(was: VFS-210 broke this, when it removed the call to getInfo(true) in 
refresh().

 
{code:java}
/**
 * @throws FileSystemException if an error occurs.
 */
@Override
public void refresh() throws FileSystemException {
if (!inRefresh) {
try {
inRefresh = true;
super.refresh();

synchronized (getFileSystem()) {
this.fileInfo = null;
}

/*
 * VFS-210 try { // this will tell the parent to recreate its 
children collection getInfo(true); } catch
 * (IOException e) { throw new FileSystemException(e); }
 */
} finally {
inRefresh = false;
}
}
}

{code})

> FtpFileObject.exists() output not impacted by refresh() after file deletion
> ---
>
> Key: VFS-525
> URL: https://issues.apache.org/jira/browse/VFS-525
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows 7 [Version 6.1.7601]
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
> commonc vfs 2.0
> commons net 3.3
>Reporter: Volker Bergmann
>Priority: Critical
>  Labels: FTP,, cache, exists
>
> Context: I store a file in an FTP directory and poll the FTP file (using 
> FtpFileObject.exists()) until it is imported by another system and deleted on 
> the FTP folder.
> Issue: On the first lookup, the file is present and FtpFileObject.exists() 
> returns true correctly. That's OK, but after the file has been deleted, 
> FtpFileObject.exists() continues to return true, even when using 
> CacheStrategy.MANUAL and calling FtpFileObject.refresh().
> Observations: Upon refresh() there is a complex interaction between the file 
> and parent folder object as well as the code of AbstractFileObject and 
> FtpFileObject. The issue seems to stem from the fact that for the existence 
> check of a file, its parent file object is queried for its #children 
> attribute which caches the child entries. On the one hand, the child file 
> seems to clear the link to the parent folder, causing a detach() of the 
> parent, but since the parent folder already is in detached state, it does not 
> clear its #children attribute. 
> By the way: I consider it a poor inheritance design if a child class 
> attribute 
> FtpFileObject: private Map children
> shadows a parent class attribute
> AbstractFileObject: private FileName[] children
> At least it makes debugging more cumbersome.
> Workaround: The issue stems from the fact that the parent FtpFileObject is 
> not cleared correctly because attached==false. Thus I use a call to the 
> parent's getType() method which causes an attach() and, finally, attached== 
> true and then call refresh() on the parent and the child:
> // This is a workaround for VFS 2.0's flaws in the 
> // handling of attached/detached state and caching:
> FileObject parent = file.getParent();
> parent.getType(); // assure that parent folder is attached
> parent.refresh(); // detach parent folder and clear child object cache 
> // (works only if attached before)
> // ...end of workaround
> file.refresh();
> System.out.println("File.exists(): {}", file.exists());



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370910#comment-16370910
 ] 

Otto Fowler commented on VFS-525:
-

VFS-210 broke this, when it removed the call to getInfo(true) in refresh().

 
{code:java}
/**
 * @throws FileSystemException if an error occurs.
 */
@Override
public void refresh() throws FileSystemException {
if (!inRefresh) {
try {
inRefresh = true;
super.refresh();

synchronized (getFileSystem()) {
this.fileInfo = null;
}

/*
 * VFS-210 try { // this will tell the parent to recreate its 
children collection getInfo(true); } catch
 * (IOException e) { throw new FileSystemException(e); }
 */
} finally {
inRefresh = false;
}
}
}

{code}

> FtpFileObject.exists() output not impacted by refresh() after file deletion
> ---
>
> Key: VFS-525
> URL: https://issues.apache.org/jira/browse/VFS-525
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows 7 [Version 6.1.7601]
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
> commonc vfs 2.0
> commons net 3.3
>Reporter: Volker Bergmann
>Priority: Critical
>  Labels: FTP,, cache, exists
>
> Context: I store a file in an FTP directory and poll the FTP file (using 
> FtpFileObject.exists()) until it is imported by another system and deleted on 
> the FTP folder.
> Issue: On the first lookup, the file is present and FtpFileObject.exists() 
> returns true correctly. That's OK, but after the file has been deleted, 
> FtpFileObject.exists() continues to return true, even when using 
> CacheStrategy.MANUAL and calling FtpFileObject.refresh().
> Observations: Upon refresh() there is a complex interaction between the file 
> and parent folder object as well as the code of AbstractFileObject and 
> FtpFileObject. The issue seems to stem from the fact that for the existence 
> check of a file, its parent file object is queried for its #children 
> attribute which caches the child entries. On the one hand, the child file 
> seems to clear the link to the parent folder, causing a detach() of the 
> parent, but since the parent folder already is in detached state, it does not 
> clear its #children attribute. 
> By the way: I consider it a poor inheritance design if a child class 
> attribute 
> FtpFileObject: private Map children
> shadows a parent class attribute
> AbstractFileObject: private FileName[] children
> At least it makes debugging more cumbersome.
> Workaround: The issue stems from the fact that the parent FtpFileObject is 
> not cleared correctly because attached==false. Thus I use a call to the 
> parent's getType() method which causes an attach() and, finally, attached== 
> true and then call refresh() on the parent and the child:
> // This is a workaround for VFS 2.0's flaws in the 
> // handling of attached/detached state and caching:
> FileObject parent = file.getParent();
> parent.getType(); // assure that parent folder is attached
> parent.refresh(); // detach parent folder and clear child object cache 
> // (works only if attached before)
> // ...end of workaround
> file.refresh();
> System.out.println("File.exists(): {}", file.exists());



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370895#comment-16370895
 ] 

Otto Fowler commented on VFS-398:
-

https://github.com/apache/commons-vfs/pull/29

> FtpFileObject.getChildren() fails when a folder contains a file with a colon 
> in the name
> 
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme() 
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path 
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using 
> AbstractFileName.checkName()
> Sample code:
> FileObject fo = 
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is 
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException: 
> Invalid descendent file name "PREFIX:SUFFIX".
>   at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (DIGESTER-189) Wrong release notes

[Jeremie Van renterghem (JIRA)]

Jeremie Van renterghem created DIGESTER-189:
---

 Summary: Wrong release notes
 Key: DIGESTER-189
 URL: https://issues.apache.org/jira/browse/DIGESTER-189
 Project: Commons Digester
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Jeremie Van renterghem


It seems that the release notes for commons-digester 2.0 points to the wrong 
file:

[https://commons.apache.org/proper/commons-digester/commons-digester-2.0/RELEASE-NOTES.txt]

"

Commons Digester Package Version 3.1 Release Notes

"

=> seems to be release notes for 3.1

 

I have checked in svn:

[http://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER_2_0/RELEASE-NOTES.txt]
 

...and the source seems correct. This is probably a bug in the web site.

 

2.0 is an old version, but it is useful to have the complete chain of release 
notes to plan an upgrade.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [jira] [Created] (IO-569) Incorrect documentation for cloning repository

[Kerri Reynolds]

FUCK off

On Feb 19, 2018 11:47 PM, "Michael Ernst (JIRA)"  wrote:

> Michael Ernst created IO-569:
> 
>
>  Summary: Incorrect documentation for cloning repository
>  Key: IO-569
>  URL: https://issues.apache.org/jira/browse/IO-569
>  Project: Commons IO
>   Issue Type: Bug
> Affects Versions: 2.6
> Reporter: Michael Ernst
>
>
> https://commons.apache.org/proper/commons-io/source-repository.html
> says:
>
> > Anonymous Access
> >
> > The source can be checked out anonymously from Git with this command:
> >
> > git clone --branch commons-io-2.6 http://git-wip-us.apache.org/
> repos/asf/commons-io.git
>
> However, when I run that command, I get:
>
> % git clone --branch commons-io-2.6 http://git-wip-us.apache.org/
> repos/asf/commons-io.git
> Cloning into 'commons-io'...
> warning: redirecting to https://git1-us-west.apache.
> org/repos/asf/commons-io.git/
> fatal: Remote branch commons-io-2.6 not found in upstream origin
>
> The tags include these:
>
> commons-io-2.5
> commons-io-2.5-RC1
> commons-io-2.5-RC2
> commons-io-2.5-RC3
> commons-io-2.5-RC4
> commons-io-2.6-RC1
> commons-io-2.6-RC2
> commons-io-2.6-RC3
>
> but there is no tag for commons-io-2.6.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>

[jira] [Commented] (COLLECTIONS-674) Add Collections Drain Method

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on COLLECTIONS-674:


Sounds like a good idea. I think Scala has something similar (not too familiar 
with Scala, but tried learning it a few times - 
[https://www.scala-lang.org/api/current/scala/collection/mutable/ArrayStack.html#drain(f:T=%3EUnit):Unit]
 ?). And Guava as well in the Queues I think 
([https://github.com/google/guava/blob/fd919e54a55ba169dc7d9f54b7b3485aa7fa0970/android/guava/src/com/google/common/collect/Queues.java#L270)]
 ?

 

 

> Add Collections Drain Method
> 
>
> Key: COLLECTIONS-674
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-674
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Collection
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
>
> Add a {{Collections.drain()}} method which removes the first N elements from 
> the collection and returns them.  This method would have the side-effect of 
> modifying the input collections (due to removal).
>  
> {code:java}
> // Some suggestions
> void Collections.drain(Collection from, Collection to, int count);
> Collection Collections.drain(Collection from, int count);{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)