[jira] [Created] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
Otto Fowler created LANG-1373: - Summary: 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 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 (v6.4.14#64029)
[jira] [Commented] (VFS-651) SftpFileSystem Should not switch to root directory when not absolutely needed
[
https://issues.apache.org/jira/browse/VFS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363225#comment-16363225
]
Otto Fowler commented on VFS-651:
-
Are we sure that this is not working correctly?
Can you post a small snippet of code or a description of how you configure can
connect? And what you are trying to do that does not work if you set it to
true?
> SftpFileSystem Should not switch to root directory when not absolutely needed
> -
>
> Key: VFS-651
> URL: https://issues.apache.org/jira/browse/VFS-651
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Syed Aqeel Ashiq
>Priority: Major
> Fix For: 2.3
>
>
> Consider a user X only has read/write access to let's say /sftp and /sftp/abc
> directory on a sftp server. And default directory for user is /sftp
> In this case, we have to set userDirIsRoot to false, and thus vfs will try to
> switch to root directory, which will fail due to lack of read permission.
> This is the underlying code responsible in
> {code:java}
> org.apache.commons.vfs.provider.sftp.SftpFileSystem
> {code}
> :
> {code:java}
> Boolean userDirIsRoot =
> SftpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(getFileSystemOptions());
> String workingDirectory = getRootName().getPath();
> if (workingDirectory != null && (userDirIsRoot == null ||
> !userDirIsRoot.booleanValue())) {
> try {
> channel.cd(workingDirectory);
> } catch (SftpException e) {
> throw new
> FileSystemException("vfs.provider.sftp/change-work-directory.error",
> workingDirectory);
> }
> }{code}
> It purposelessly switches to root directory of filesystem. There is a fair
> use-case that root directory doesn't have read access.
> *Possible Fix:* It should not switch to root directory, rather it should
> switch to actual final directory. This approach would be the safest. E.g. if
> the needed directory is '/sftp/abc' then it can switch to that directory in
> above code, rather than switching to root.
> Please also see related SO question:
> https://stackoverflow.com/questions/48709971/why-apache-vfs-sftp-tries-to-switch-to-root-directory-even-when-not-needed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-651) SftpFileSystem Should not switch to root directory when not absolutely needed
[
https://issues.apache.org/jira/browse/VFS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365522#comment-16365522
]
Otto Fowler commented on VFS-651:
-
[https://commons.apache.org/proper/commons-vfs/filesystems.html#SFTP]
*URI Format*
{{sftp://[ _username_[: _password_]@] _hostname_[: _port_][ _relative-path_]}}
"By default, the path is relative to the user's home directory"
Can you try setting the user dir is root to TRUE, and making your path relative?
> SftpFileSystem Should not switch to root directory when not absolutely needed
> -
>
> Key: VFS-651
> URL: https://issues.apache.org/jira/browse/VFS-651
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Syed Aqeel Ashiq
>Priority: Major
> Fix For: 2.3
>
>
> Consider a user X only has read/write access to let's say /sftp and /sftp/abc
> directory on a sftp server. And default directory for user is /sftp
> In this case, we have to set userDirIsRoot to false, and thus vfs will try to
> switch to root directory, which will fail due to lack of read permission.
> Consider following code:
> {code:java}
> public void uploadFile(String localFilePath) throws FileSystemException {
>
> FileSystemManager manager = VFS.getManager();
> FileObject localFile = manager.resolveFile(localFilePath);
> FileSystemOptions opts = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, false);
> // I set it to false,
> // because user default dir is /sftp and it is obviously not root
> directory.
> // As a workaround, If I set it to true, it will work after also tweaking
> with
> // the file path while resolving a file, but semantics will be wrong,
> since
> // the user directory is not root.
> SftpFileSystemConfigBuilder.getInstance().setTimeout(opts, 9);
> String remoteFilePath =
> "sftp://myuser:myp...@myurl.sftpexample.com/sftp/abc/abc.txt";;
> // Exception at the following line
> FileObject remoteFile = manager.resolveFile(remoteFilePath, opts);
> // Exception at the line above line. Because this line tries to switch to
> // root directory of sftp file system, whichfails due to lack of read
> // permission on root directory. Switching to root directory is not
> // needed here at all. This is bug, although it works in most scenarios,
> // since most of times, permissions are available.
> remoteFile.copyFrom(localFile, Selectors.SELECT_SELF);
> }
> {code}
> This is the underlying code responsible in
> {code:java}
> org.apache.commons.vfs.provider.sftp.SftpFileSystem
> {code}
> :
> {code:java}
> Boolean userDirIsRoot =
> SftpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(getFileSystemOptions());
> String workingDirectory = getRootName().getPath();
> if (workingDirectory != null && (userDirIsRoot == null ||
> !userDirIsRoot.booleanValue())) {
> try {
> channel.cd(workingDirectory);
> } catch (SftpException e) {
> throw new
> FileSystemException("vfs.provider.sftp/change-work-directory.error",
> workingDirectory);
> }
> }{code}
> It purposelessly switches to root directory of filesystem. There is a fair
> use-case that root directory doesn't have read access.
> *Possible Fix:* It should not switch to root directory, rather it should
> switch to actual final directory. This approach would be the safest. E.g. if
> the needed directory is '/sftp/abc' then it can switch to that directory in
> above code, rather than switching to root.
> Please also see related SO question:
> https://stackoverflow.com/questions/48709971/why-apache-vfs-sftp-tries-to-switch-to-root-directory-even-when-not-needed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-651) SftpFileSystem Should not switch to root directory when not absolutely needed
[
https://issues.apache.org/jira/browse/VFS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365822#comment-16365822
]
Otto Fowler commented on VFS-651:
-
UserDirIsRoot should be taken as "The user directory is the "root" of all the
paths.
/home/foo -> user dir
userDirIsRoot = true
/folder/file.txt is passed in
/home/foo/folder/file.txt is what you are going to get
> SftpFileSystem Should not switch to root directory when not absolutely needed
> -
>
> Key: VFS-651
> URL: https://issues.apache.org/jira/browse/VFS-651
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Syed Aqeel Ashiq
>Priority: Major
> Fix For: 2.3
>
>
> Consider a user X only has read/write access to let's say /sftp and /sftp/abc
> directory on a sftp server. And default directory for user is /sftp
> In this case, we have to set userDirIsRoot to false, and thus vfs will try to
> switch to root directory, which will fail due to lack of read permission.
> Consider following code:
> {code:java}
> public void uploadFile(String localFilePath) throws FileSystemException {
>
> FileSystemManager manager = VFS.getManager();
> FileObject localFile = manager.resolveFile(localFilePath);
> FileSystemOptions opts = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, false);
> // I set it to false,
> // because user default dir is /sftp and it is obviously not root
> directory.
> // As a workaround, If I set it to true, it will work after also tweaking
> with
> // the file path while resolving a file, but semantics will be wrong,
> since
> // the user directory is not root.
> SftpFileSystemConfigBuilder.getInstance().setTimeout(opts, 9);
> String remoteFilePath =
> "sftp://myuser:myp...@myurl.sftpexample.com/sftp/abc/abc.txt";;
> // Exception at the following line
> FileObject remoteFile = manager.resolveFile(remoteFilePath, opts);
> // Exception at the line above line. Because this line tries to switch to
> // root directory of sftp file system, whichfails due to lack of read
> // permission on root directory. Switching to root directory is not
> // needed here at all. This is bug, although it works in most scenarios,
> // since most of times, permissions are available.
> remoteFile.copyFrom(localFile, Selectors.SELECT_SELF);
> }
> {code}
> This is the underlying code responsible in
> {code:java}
> org.apache.commons.vfs.provider.sftp.SftpFileSystem
> {code}
> :
> {code:java}
> Boolean userDirIsRoot =
> SftpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(getFileSystemOptions());
> String workingDirectory = getRootName().getPath();
> if (workingDirectory != null && (userDirIsRoot == null ||
> !userDirIsRoot.booleanValue())) {
> try {
> channel.cd(workingDirectory);
> } catch (SftpException e) {
> throw new
> FileSystemException("vfs.provider.sftp/change-work-directory.error",
> workingDirectory);
> }
> }{code}
> It purposelessly switches to root directory of filesystem. There is a fair
> use-case that root directory doesn't have read access.
> *Possible Fix:* It should not switch to root directory, rather it should
> switch to actual final directory. This approach would be the safest. E.g. if
> the needed directory is '/sftp/abc' then it can switch to that directory in
> above code, rather than switching to root.
> Please also see related SO question:
> https://stackoverflow.com/questions/48709971/why-apache-vfs-sftp-tries-to-switch-to-root-directory-even-when-not-needed
--
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
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366257#comment-16366257
]
Otto Fowler commented on VFS-398:
-
resolveName takes a base name and the name.
The issue is that the code was written to support the base name bing a full URI
as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it
needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first
':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a
scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(),
dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(),
"file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix
is to have the parse schema function be a little smarter.
> 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
>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&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] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366257#comment-16366257
]
Otto Fowler edited comment on VFS-398 at 2/15/18 9:05 PM:
--
resolveName takes a base name and the name.
The issue is that the code was written to support the base name being a full
URI as opposed to being 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it
needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first
':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a
scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(),
dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(),
"file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix
is to have the parse schema function be a little smarter.
was (Author: ottobackwards):
resolveName takes a base name and the name.
The issue is that the code was written to support the base name being a full
URI as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it
needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first
':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a
scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(),
dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(),
"file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix
is to have the parse schema function be a little smarter.
> 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
>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&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plai
[jira] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366257#comment-16366257
]
Otto Fowler edited comment on VFS-398 at 2/15/18 9:05 PM:
--
resolveName takes a base name and the name.
The issue is that the code was written to support the base name being a full
URI as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it
needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first
':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a
scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(),
dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(),
"file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix
is to have the parse schema function be a little smarter.
was (Author: ottobackwards):
resolveName takes a base name and the name.
The issue is that the code was written to support the base name bing a full URI
as opposed to bing 'just' a name.
So it supports both:
base -> foo://test/data
name ->bar
AND
base -> foo://test/data
name -> foo://test/data/bar
It therefore needs to get the scheme from the 'name' so it can decide if it
needs to prepend the base or not.
The issue is that the code to extract the schema just searches for the first
':' as the schema marker.
Therefore IF you pass in a 'name' parameter that is NOT a full URI,
base -> foo://test/data
name -> b:ar
You will see this because we then try to normalize the uri, thinking it has a
scheme but it doesn't.
If you have a full URI parameter, then you will probably not see this.
I ran this test in LocalProviderTestCase, FileNameTest
{code:java}
public void testColonNames() throws Exception {
final FileObject readFolder = getReadFolder();
final FileObject dirOfDeath = readFolder.resolveFile("dirOfDeath");
Assert.assertTrue("Missing dirOfDeath", dirOfDeath.exists());
final FileName noBoom = getManager().resolveName(dirOfDeath.getName(),
dirOfDeath.getURL() + "/file:GoBoom");
System.out.println("Made it!");
try {
final FileName boom = getManager().resolveName(dirOfDeath.getName(),
"file:GoBoom");
}catch(Exception e) {
Assert.assertTrue(false);
}
}
{code}
{code:java}
Made it!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.provider.local.test.FileNameTests.testColonNames(FileNameTests.java:60)
{code}
So there is no need to mark up the names, or override. I think the correct fix
is to have the parse schema function be a little smarter.
> 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
>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&revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plai
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366353#comment-16366353
]
Otto Fowler commented on VFS-398:
-
Would propose the following implementation/changes UriParser :
I can do a PR if the change is acceptable.
{code:java}
public static String extractScheme(final String uri, final StringBuilder
buffer) {
if (buffer != null) {
buffer.setLength(0);
buffer.append(uri);
}
// search for :/ for the scheme marker
// we look for both because some filesystems
// support : in the name
final int maxPos = uri.length();
boolean markColon = false;
for (int pos = 0; pos < maxPos; pos++) {
final char ch = uri.charAt(pos);
if (ch == ':') {
markColon = !markColon;
continue;
}
if (ch == '/') {
// this is the second slash in :/
if (markColon) {
// Found the end of the scheme
final String scheme = uri.substring(0, pos - 1);
if (scheme.length() <= 1 && Os.isFamily(Os.OS_FAMILY_WINDOWS)) {
// This is not a scheme, but a Windows drive letter
return null;
}
if (buffer != null) {
buffer.delete(0, pos);
}
return scheme.intern();
} else {
break;
}
}
if(markColon) {
// : not followed by a /
// no scheme
break;
}
if ((ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z')) {
// A scheme character
continue;
}
if (pos > 0 && ((ch >= '0' && ch <= '9') || ch == '+' || ch == '-' ||
ch == '.')) {
// A scheme character (these are not allowed as the first
// character of the scheme, but can be used as subsequent
// characters.
continue;
}
// Not a scheme character
break;
}
// No scheme in URI
return null;
}
{code}
> 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
>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&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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366566#comment-16366566
]
Otto Fowler commented on VFS-398:
-
Actually, I needed to read the spec again, the above is wrong wrt the spec. My
apologies.
> 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
>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&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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366599#comment-16366599
]
Otto Fowler commented on VFS-398:
-
OK.
After further reflection and review, here it is:
The code wants to support a string the may be a url or may not be at the same
time.
The issue is, that no matter what we do we can never know if the ':' is the
scheme marker or part of the file name.
each scheme by definition supports a different scheme part ( the part after the
: ) and some don't even have one.
Add to this, that the scheme is used in the system to map to a provider, and
those can be registered with whatever scheme a developer wants.
My proposal is to limit the recognized scheme's returned by extractScheme to
those registered in the system. I believe this is the most correct way to do
this.
* it is only way to be sure that it is a scheme and not just a ':'
* the system can only support registered schemes anyway
I all system tests passing ( along with new tests for this issue ) with the
following replacement method being used in place of extractScheme
{code:java}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri) {
return extractSupportedScheme(supportedScheme, uri, null);
}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri, StringBuilder buffer) {
if (buffer != null) {
buffer.setLength(0);
buffer.append(uri);
}
for(String schema : supportedScheme) {
if(uri.startsWith(schema + ":")) {
if (buffer != null) {
buffer.delete(0, uri.indexOf(':') + 1);
}
return schema;
}
}
return null;
}
{code}
Thoughts? Improvements?
> 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
>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&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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366602#comment-16366602
]
Otto Fowler commented on VFS-398:
-
A note on this, is that another layer of checks may be necessary.
Because each scheme has a different scheme part but we do not verify that
ftp:FOO and [ftp://foo|ftp://foo/] will both resolve to ftp scheme, but
ftp:FOO is not a valid ftp url by definition.
I think it is correct that we extract scheme this way, and level the invalid
url error for later, but someone may disagree
> 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
>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&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] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366599#comment-16366599
]
Otto Fowler edited comment on VFS-398 at 2/16/18 4:39 AM:
--
OK.
After further reflection and review, here it is:
The code wants to support a string the may be a url or may not be at the same
time.
The issue is, that no matter what we do we can never know if the ':' is the
scheme marker or part of the file name.
each scheme by definition supports a different scheme part ( the part after the
: ) and some don't even have one.
Add to this, that the scheme is used in the system to map to a provider, and
those can be registered with whatever scheme a developer wants.
My proposal is to limit the recognized scheme's returned by extractScheme to
those registered in the system. I believe this is the most correct way to do
this.
* it is only way to be sure that it is a scheme and not just a ':'
* the system can only support registered schemes anyway
I have all system tests passing ( along with new tests for this issue ) with
the following replacement method being used in place of extractScheme
{code:java}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri) {
return extractSupportedScheme(supportedScheme, uri, null);
}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri, StringBuilder buffer) {
if (buffer != null) {
buffer.setLength(0);
buffer.append(uri);
}
for(String schema : supportedScheme) {
if(uri.startsWith(schema + ":")) {
if (buffer != null) {
buffer.delete(0, uri.indexOf(':') + 1);
}
return schema;
}
}
return null;
}
{code}
Thoughts? Improvements?
was (Author: ottobackwards):
OK.
After further reflection and review, here it is:
The code wants to support a string the may be a url or may not be at the same
time.
The issue is, that no matter what we do we can never know if the ':' is the
scheme marker or part of the file name.
each scheme by definition supports a different scheme part ( the part after the
: ) and some don't even have one.
Add to this, that the scheme is used in the system to map to a provider, and
those can be registered with whatever scheme a developer wants.
My proposal is to limit the recognized scheme's returned by extractScheme to
those registered in the system. I believe this is the most correct way to do
this.
* it is only way to be sure that it is a scheme and not just a ':'
* the system can only support registered schemes anyway
I all system tests passing ( along with new tests for this issue ) with the
following replacement method being used in place of extractScheme
{code:java}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri) {
return extractSupportedScheme(supportedScheme, uri, null);
}
public static String extractSupportedScheme(final Set supportedScheme,
final String uri, StringBuilder buffer) {
if (buffer != null) {
buffer.setLength(0);
buffer.append(uri);
}
for(String schema : supportedScheme) {
if(uri.startsWith(schema + ":")) {
if (buffer != null) {
buffer.delete(0, uri.indexOf(':') + 1);
}
return schema;
}
}
return null;
}
{code}
Thoughts? Improvements?
> 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
>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&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.apa
[jira] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366602#comment-16366602
]
Otto Fowler edited comment on VFS-398 at 2/16/18 4:41 AM:
--
A note on this, is that another layer of checks may be necessary.
Because each scheme has a different scheme part but we do not verify that
ftp:FOO and [ftp://foo|ftp://foo/] will both resolve to ftp scheme, but
ftp:FOO is not a valid ftp url by definition.
I think it is correct that we extract scheme this way, and leavel the invalid
url error for later, but someone may disagree
was (Author: ottobackwards):
A note on this, is that another layer of checks may be necessary.
Because each scheme has a different scheme part but we do not verify that
ftp:FOO and [ftp://foo|ftp://foo/] will both resolve to ftp scheme, but
ftp:FOO is not a valid ftp url by definition.
I think it is correct that we extract scheme this way, and level the invalid
url error for later, but someone may disagree
> 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
>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&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] [Commented] (VFS-651) SftpFileSystem Should not switch to root directory when not absolutely needed
[
https://issues.apache.org/jira/browse/VFS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366859#comment-16366859
]
Otto Fowler commented on VFS-651:
-
Oh, tweaking. Right.
I'm sorry [~aqeel613], I'm not a committer or even a contributor on this
project. I use it on my apache project and saw your mail on the list and was
curious so I thought I would take a look.
As far as I can see it is working as designed. It makes sense to me for a file
system to work like this, but if this where just a sftp client maybe it would
be different.
Maybe someone who participated in the design will be able to explain the
reasons better than what I can say just from going through the code and
documentation.
> SftpFileSystem Should not switch to root directory when not absolutely needed
> -
>
> Key: VFS-651
> URL: https://issues.apache.org/jira/browse/VFS-651
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Syed Aqeel Ashiq
>Priority: Major
> Fix For: 2.3
>
>
> Consider a user X only has read/write access to let's say /sftp and /sftp/abc
> directory on a sftp server. And default directory for user is /sftp
> In this case, we have to set userDirIsRoot to false, and thus vfs will try to
> switch to root directory, which will fail due to lack of read permission.
> Consider following code:
> {code:java}
> public void uploadFile(String localFilePath) throws FileSystemException {
>
> FileSystemManager manager = VFS.getManager();
> FileObject localFile = manager.resolveFile(localFilePath);
> FileSystemOptions opts = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, false);
> // I set it to false,
> // because user default dir is /sftp and it is obviously not root
> directory.
> // As a workaround, If I set it to true, it will work after also tweaking
> with
> // the file path while resolving a file, but semantics will be wrong,
> since
> // the user directory is not root.
> SftpFileSystemConfigBuilder.getInstance().setTimeout(opts, 9);
> String remoteFilePath =
> "sftp://myuser:myp...@myurl.sftpexample.com/sftp/abc/abc.txt";;
> // Exception at the following line
> FileObject remoteFile = manager.resolveFile(remoteFilePath, opts);
> // Exception at the line above line. Because this line tries to switch to
> // root directory of sftp file system, whichfails due to lack of read
> // permission on root directory. Switching to root directory is not
> // needed here at all. This is bug, although it works in most scenarios,
> // since most of times, permissions are available.
> remoteFile.copyFrom(localFile, Selectors.SELECT_SELF);
> }
> {code}
> This is the underlying code responsible in
> {code:java}
> org.apache.commons.vfs.provider.sftp.SftpFileSystem
> {code}
> :
> {code:java}
> Boolean userDirIsRoot =
> SftpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(getFileSystemOptions());
> String workingDirectory = getRootName().getPath();
> if (workingDirectory != null && (userDirIsRoot == null ||
> !userDirIsRoot.booleanValue())) {
> try {
> channel.cd(workingDirectory);
> } catch (SftpException e) {
> throw new
> FileSystemException("vfs.provider.sftp/change-work-directory.error",
> workingDirectory);
> }
> }{code}
> It purposelessly switches to root directory of filesystem. There is a fair
> use-case that root directory doesn't have read access.
> *Possible Fix:* It should not switch to root directory, rather it should
> switch to actual final directory. This approach would be the safest. E.g. if
> the needed directory is '/sftp/abc' then it can switch to that directory in
> above code, rather than switching to root.
> Please also see related SO question:
> https://stackoverflow.com/questions/48709971/why-apache-vfs-sftp-tries-to-switch-to-root-directory-even-when-not-needed
--
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
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16367321#comment-16367321
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] ?
> 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
>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&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] [Commented] (VFS-614) MonitorInputStream should not close the stream in "read"
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16367536#comment-16367536 ] Otto Fowler commented on VFS-614: - in your test, you are reading from an empty file. Both the stream detect and EOF read, but the difference is, as you have guessed the wrapped VFS stream closes on EOF. If you change your test such that the file does have something in it, and you are NOT reading to EOF then it will work. I don't think VFS should close the stream through, it should act as the BufferedOutputStream that is it's base does > MonitorInputStream should not close the stream in "read" > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Priority: Critical > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-614) MonitorInputStream should not close the stream in "read"
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated VFS-614: Assignee: Otto Fowler > MonitorInputStream should not close the stream in "read" > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-398:
Assignee: Otto Fowler
> 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&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] [Updated] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated LANG-1373: -- Assignee: Otto Fowler > 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)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&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] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Issue Comment Deleted] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371433#comment-16371433
]
Otto Fowler commented on VFS-525:
-
These tests illustrate the issue.
I believe they will both fail as written. The first one certainly does.
Interestingly, if they are run in the same test file, the second one will fail
in setup. This is because the bug also causes the test prep to fail trying to
delete the existing files for a clean test, and it still thinks the deleted
'a.txt' exists and tried to delete it. Kind of funny.
{code:java}
public void testDetectFileDoesNotExistAfterExternalDelete() throws Exception {
final FileObject scratchFolder = createScratchFolder();
final FileObject file = scratchFolder.resolveFile("dir1/a.txt");
// use canonical file to delete
File testDirFile = getTestDirectoryFile();
File writeDirFile = new File(testDirFile,"write-tests");
File dir1File = new File(writeDirFile,"dir1");
File fileUnderTest = new File(dir1File,"a.txt");
assertTrue(file.exists());
fileUnderTest.delete();
assertFalse(fileUnderTest.exists());
file.refresh();
assertFalse(file.exists());
scratchFolder.close();
file.close();
}
public void testDetectExternalChangeInFileSizeAfterExternalMod() throws
Exception {
final FileObject scratchFolder = createScratchFolder();
final FileObject file = scratchFolder.resolveFile("dir2/b.txt");
// use canonical file to delete
File testDirFile = getTestDirectoryFile();
File writeDirFile = new File(testDirFile,"write-tests");
File dir1File = new File(writeDirFile,"dir2");
File fileUnderTest = new File(dir1File,"b.txt");
assertTrue(file.exists());
long size = file.getContent().getSize();
long oldFileSize = fileUnderTest.length();
assertEquals(size,oldFileSize);
try (FileOutputStream fileOutputStream = new
FileOutputStream(fileUnderTest)) {
fileOutputStream.write("Addition".getBytes());
fileOutputStream.flush();
}
long newFileSize = fileUnderTest.length();
assertFalse(newFileSize == oldFileSize);
file.refresh();
assertEquals(newFileSize,file.getContent().getSize());
}
{code}
I am not sure I can sum up the issues. But the caching vs. getting current
data is broken fundamentally.
> 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
>
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371448#comment-16371448 ] Otto Fowler commented on LANG-1373: --- [~erans] would you mind commenting in the PR? > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371449#comment-16371449 ] Otto Fowler commented on LANG-1373: --- also I'm in IRC if chat would help > 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)
[jira] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371497#comment-16371497
]
Otto Fowler commented on VFS-525:
-
For the size() changes : there is no way to 'clear' content once it is
retrieved. So once it is read it will not be read again. Even if you close,
the fileInfo is retrieved from the parent and it is cached and we get the size
from that
Not being able to invalidate the parent cache ( when you want to react to
external events ) is an issue here.
Maybe there needs to be an explicit 'Poll' api for this type of operation?
[~garydgregory]?
> 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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371500#comment-16371500
]
Otto Fowler commented on VFS-525:
-
Also, closing a FTPFileObject doesn't invalidate it's cached FTPFile (
fileInfo), since it doesn't override close. Even if you do override close, you
just get the cached from the parent again.
> 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] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371506#comment-16371506 ] Otto Fowler commented on LANG-1373: --- Ok, I understand what you mean. The issue with the name is I want to build paths out of the names. Basically concat them. So I don't know what the utility of having them be generic would be. Tags as generic is super interesting though. I like that a lot. Let me think it through > 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)
[jira] [Comment Edited] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371497#comment-16371497
]
Otto Fowler edited comment on VFS-525 at 2/21/18 2:57 PM:
--
For the size() changes : there is no way to 'clear' content once it is
retrieved. So once it is read it will not be read again. Even if you close,
the fileInfo is retrieved from the parent and it is cached and we get the size
from that
Not being able to invalidate the parent cache ( when you want to react to
external events ) is an issue here.
Maybe there needs to be an explicit 'Poll' api for this type of operation?
Or a "DecoratedPollingFileObject" or something
[~garydgregory]?
was (Author: ottobackwards):
For the size() changes : there is no way to 'clear' content once it is
retrieved. So once it is read it will not be read again. Even if you close,
the fileInfo is retrieved from the parent and it is cached and we get the size
from that
Not being able to invalidate the parent cache ( when you want to react to
external events ) is an issue here.
Maybe there needs to be an explicit 'Poll' api for this type of operation?
[~garydgregory]?
> 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] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371540#comment-16371540
]
Otto Fowler commented on LANG-1373:
---
[~erans]
So, varargs + generics is a Bad Thing™
I used varargs to make the call interface nice and easy. Who likes to have to
do
{code:java}
foo(var1,var2,new String[]{"foo","bar"}){code}
instead of
{code:java}
foo(var1,var2,"foo", "bar") or foo(var1, var2){code}
Generics would be useful, but I'd have to redo the interface to take
Iterable or something and put it back on the callers.
Do you have any thoughts on that type of interface? Is there a way that sucks
less?
> 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371544#comment-16371544 ] Otto Fowler commented on LANG-1373: --- [~erans] you are right, the names could just be tracked as a list and the caller could put them back together as they like. That is certainly more flexible. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371556#comment-16371556 ] Otto Fowler commented on LANG-1373: --- Although, that would mean that we would be passing N[] as parent paths around through all the children or create a new wrapper type. How can we do this without it getting too complicated? > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371666#comment-16371666
]
Otto Fowler commented on LANG-1373:
---
When I say put it back on the callers, I mean what they need to do when calling:
{code:java}
watch.startTiming("One", "OneFunc", "Classifier");
{code}
callers have to
{code:java}
watch.startTiming("One", new String[]{"OneFunc", "Classifier});
{code}
> 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371765#comment-16371765 ] Otto Fowler commented on LANG-1373: --- [~erans] thank you for your feedback. I agree with your point on the utility. I just want us to work through the right balance of utility and api ease of use. I hope it doesn't seem like I'm stonewalling. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372131#comment-16372131 ] Otto Fowler commented on LANG-1373: --- So, I have made the changes such that generics are used to tags. Shall I post a patch? I am not in love with the changes, I'd like some feedback before committing. I have not updated the java doc stuff though [~erans] ? > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372352#comment-16372352 ] Otto Fowler commented on LANG-1373: --- [https://github.com/ottobackwards/commons-lang/tree/stackwatch_gen] For the Tag as Generic. I am going to think about the fluent api. I wrote this to be simple, and something that wouldn't have a lot to do to pepper it through the code. Both generics and fluent api, seem to make it more complex to me. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372755#comment-16372755 ] Otto Fowler commented on LANG-1373: --- I tried the varargs, but didn't think we would want the @safevargs marker, because of the type erasure issues. It didn't seem commons-y to me. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372756#comment-16372756 ] Otto Fowler commented on LANG-1373: --- Having said that, searching the project I do see places where it is used, that I can use as an example. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372764#comment-16372764 ] Otto Fowler commented on LANG-1373: --- Would having both the current interface ( with generics ) *and* the fluent be viable? > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372799#comment-16372799 ] Otto Fowler commented on LANG-1373: --- yeah. I'm going to take another stab at generics with @safevarargs then. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373175#comment-16373175 ] Otto Fowler commented on LANG-1373: --- ok, generic tags is in. Please take a look. If we are agreeable, I'll go ahead and rebase down to a single commit. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373251#comment-16373251 ] Otto Fowler commented on LANG-1373: --- In my use case, I want to explicitly name and tag all timings, with minimal overhead. The user doesn't have to figure out a naming scheme. They just have to give the timing a name. Can I ask why the preference for inner classes? > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373352#comment-16373352 ] Otto Fowler commented on LANG-1373: --- Working on the inner classes > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373518#comment-16373518 ] Otto Fowler commented on LANG-1373: --- OK, Inner class rework done, java doc and test coverage holding ;) To sum up what I think are the other suggestions/questions: * I don't think throwing an exception or ? to get the Stack info just to keep from naming a timing is in line with the purpose of the feature, for performance reasons. If there is a really slick and performant way in commons already I'd like to see it? * I think a fluid interface adds more complexity than required at this time * I think Generic timingName values are also a little too complex Two other things: * Thank you [~kinow] and [~erans] for the review, I always learn a lot from these, and I think it is better now than when I started for sure * [~erans], how do you pronounce your name? I'd like to say it right in my head when I read it ;) > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374279#comment-16374279 ] Otto Fowler commented on LANG-1373: --- # It throws an exception in the background to get the stacktrace # Doing it this way limits it to one timing per function, and that limitation is not my intent. Say you have a decent size function that services one or more stacks like part of a antlr generated language. You may want to time execution of different branches of execution within the same function, and give them each a name. The simplification you suggest is also a limitation in practice. What if it is called more than once in the same function? Then we have to add a number? Know how many times in the same function? Just leave it and let there be multiple inside the function? That is yucky. I think I'll a special function that you'll obviously only call once. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374312#comment-16374312 ] Otto Fowler commented on LANG-1373: --- Actually, it just fills in the stacktrace, making a native call ( I checked the code ). Sorry. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374340#comment-16374340 ] Otto Fowler commented on LANG-1373: --- I have added startFunctionTiming() which should give you what you are looking for, but have a clear api differential that I want. I also noted effects on parent timing in the java doc. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374343#comment-16374343 ] Otto Fowler commented on LANG-1373: --- I'm not sure why you are uncomfortable. I didn't invent using String's for naming things ;) It is a common, and unsurprising way to do this. That should be comfortable. If you can imagine a scenario where being limited to a String for the name, especially now that you can the tags and put whatever there, would be a deal breaker, I'd like to hear it. Maybe it will help me see why this should be more complicated as it is. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374528#comment-16374528 ] Otto Fowler commented on LANG-1373: --- So, because the names are strings, I can safely create a path, built up using the parent names etc. if the same function with a timing is called within the scope of two different timing parent, then the path will be unique. Since it is a queue/stack of timings, the parentage is important. I can't really wrap my head around how to do that if it is just T, unless I pass the path around as a List where LAST is timing name or something. Can you help me with that? FOO/BAR/Baztiming ZIP/ZAP/Baztiming Access to the 'path' of the timing is important. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374536#comment-16374536 ] Otto Fowler commented on LANG-1373: --- Let me put it differently. Because I used strings, I could easily build the path and have it available with the node when visited. It seemed easy to do. I could just allow for the name, and 'do away' with paths, and let the caller/visitor have to worry about constructing the paths. > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374651#comment-16374651 ] Otto Fowler commented on LANG-1373: --- I'll look. I am already done making names and getting rid of the path though, just testing and checking the reports > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374706#comment-16374706 ] Otto Fowler commented on LANG-1373: --- And since name is I took out startFunctionTiming() > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374871#comment-16374871 ] Otto Fowler commented on LANG-1373: --- No, names and tags are independent types. > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374957#comment-16374957 ] Otto Fowler commented on LANG-1373: --- I do not have any changes that I'm going to make at the moment now that the generic names are in. [~erans] > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374966#comment-16374966 ] Otto Fowler commented on LANG-1373: --- I like the suffix idea, but I don't like the disconnect between the type declaration and the autogenerated names. They would only work is 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375002#comment-16375002
]
Otto Fowler commented on VFS-525:
-
I think more properly the question is where *DOES* VFS _ever_ detect external
changes?
> 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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375025#comment-16375025
]
Otto Fowler commented on VFS-525:
-
OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
> 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] [Comment Edited] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375025#comment-16375025
]
Otto Fowler edited comment on VFS-525 at 2/23/18 10:34 PM:
---
OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
BUT: the FTP provider, because it is written to speed up access is implemented
in such a way that the monitor doesn't work.
was (Author: ottobackwards):
OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
> 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();
[jira] [Issue Comment Deleted] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
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: OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
BUT: the FTP provider, because it is written to speed up access is implemented
in such a way that the monitor doesn't work.
)
> 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] [Issue Comment Deleted] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
[
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: I think more properly the question is where *DOES* VFS _ever_ detect
external changes?
)
> 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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375094#comment-16375094
]
Otto Fowler commented on VFS-525:
-
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception {
System.out.println(event.getFile().getName().getPath()+" Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception {
System.out.println(event.getFile().getName().getPath()+" Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception {
System.out.println(event.getFile().getName().getPath()+" Changed.");
}
});
fm.setRecursive(true);
fm.addFile(file);
fm.start();
{code}
This code is the correct method, I *think,* to monitor files the way you want
to.
This works with Local files, *and* with SFTP, but not with FTP. Those where the
only three I tried.
I think that accessing the file content may also have something to do with this
> 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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375097#comment-16375097
]
Otto Fowler commented on VFS-525:
-
Hi [~garydgregory]. I'm trying to walk through this an play catch up ( as you
can tell by my suggesting that there needed to be a file monitor like thing,
without knowing there is one already ).
I'll keep looking through it when I may.
I think that the changes to speed up ftp ( diff sftp v. ftp file objects ) and
never resetting the content have something todo with it.
I'm first time through here, so I'm going to look a little stupid. Stay with
me.
> 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
[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375098#comment-16375098
]
Otto Fowler commented on VFS-525:
-
I don't know for example if the bug is as stated, or that the FileMonitor
pattern should be used, and that THAT doesn't work...
> 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] [Updated] (VFS-119) Stream closed by the monitor
[
https://issues.apache.org/jira/browse/VFS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-119:
Assignee: Otto Fowler
> Stream closed by the monitor
>
>
> Key: VFS-119
> URL: https://issues.apache.org/jira/browse/VFS-119
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Philippe Poulard
>Assignee: Otto Fowler
>Priority: Major
>
> java.io.IOException: Stream closed
> is thrown when processing a local file
> 1-create a local file file:///exemple.txt
> 2-get the input stream : is
> 3-set a mark : is.mark(1024)
> 4-read the file until the end
> 5-reset the mark : is.reset()
> the exception is thrown
> here is a sample code :
> InputStream is = f.getInputStream();
> is.mark( 1024 );
> while (true) {
> int data = is.read();
> if (data == -1) break;
> }
> is.reset();
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-119) Stream closed by the monitor
[
https://issues.apache.org/jira/browse/VFS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375577#comment-16375577
]
Otto Fowler commented on VFS-119:
-
There is a PR for VFS-614
> Stream closed by the monitor
>
>
> Key: VFS-119
> URL: https://issues.apache.org/jira/browse/VFS-119
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Philippe Poulard
>Assignee: Otto Fowler
>Priority: Major
>
> java.io.IOException: Stream closed
> is thrown when processing a local file
> 1-create a local file file:///exemple.txt
> 2-get the input stream : is
> 3-set a mark : is.mark(1024)
> 4-read the file until the end
> 5-reset the mark : is.reset()
> the exception is thrown
> here is a sample code :
> InputStream is = f.getInputStream();
> is.mark( 1024 );
> while (true) {
> int data = is.read();
> if (data == -1) break;
> }
> is.reset();
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-301) MonitorInputStream doesn't correctly support 'mark'
[
https://issues.apache.org/jira/browse/VFS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375578#comment-16375578
]
Otto Fowler commented on VFS-301:
-
VFS-614 has a PR
> MonitorInputStream doesn't correctly support 'mark'
> ---
>
> Key: VFS-301
> URL: https://issues.apache.org/jira/browse/VFS-301
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0, 2.0
>Reporter: Ronan KERDUDOU
>Priority: Major
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Message I posted on the mailing list on Sat, 20 Feb, 14:37 (dev-118064)
> and Ralph Goers answered to create a jira (dev-118068 )
> Here is a serious issue in the
> org.apache.commons.vfs.util.MonitorInputStream (and so it is also in
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentInputStream)
> FileContentInputStream extends MonitorInputStream extends BufferedInputStream
> So they support < mark > (stream.markSupported() returns true)
> But in MonitorInputStream.read(), when reaching the end of the stream, there
> is a call to close() regardless if 'mark' is positioned.
> To respect BufferedInputStream specifications we shouldn't close the stream
> in order to be able to call reset() on the stream and return in the state it
> was when we called mark().
> Usually doing the folowing before using mark feature :
> {code}
> if (!stream.markSupported()) {
> stream = new BufferedInputStream(stream);
> }
> {code}
> Won't work with a VFS stream.
> So what i did :
> {code}
> if (!stream.markSupported() || stream instanceof MonitorInputStream) { //Hack
> to solve a VFS issue
> stream = new BufferedInputStream(stream);
> }
> {code}
> I inform you also that in the BufferedInputStream.close() doc, it'written :
> " Once the stream has been closed, further read(), available(), reset(), or
> skip() invocations will throw an IOException. "
> And in the MonitorInputStream, if we call read() after close() it returns
> '-1'.
> Thank you in advance for solving this issue (may be somewhat difficult not to
> break compatibility with code that uses this specific usage)
> IMHO,
> I think "end-of-stream monitoring" doesn't mean "close when reach the end"
> but should mean "propose a way to execute some code when reaching the end"
> but anyway if we put a call to close() in this code it breaks the habillity
> to call reset().
> As this class consequently modify the comportment from the super class it
> should be more documented and explain what it does.
> I would say that this class is currently doing "end-of-stream autoClose and
> after-close monitoring".
> Maybe it shouldn't extends BufferedInputStream to avoid confusion and don't
> try to support 'mark' (respond false in markSupported()) as it doesn't seem
> to serve internally in VFS Project. (Can a power-developer of VFS confirm it
> ?)
> Regards,
> KERDUDOU Ronan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-301) MonitorInputStream doesn't correctly support 'mark'
[
https://issues.apache.org/jira/browse/VFS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-301:
Assignee: Otto Fowler
> MonitorInputStream doesn't correctly support 'mark'
> ---
>
> Key: VFS-301
> URL: https://issues.apache.org/jira/browse/VFS-301
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0, 2.0
>Reporter: Ronan KERDUDOU
>Assignee: Otto Fowler
>Priority: Major
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Message I posted on the mailing list on Sat, 20 Feb, 14:37 (dev-118064)
> and Ralph Goers answered to create a jira (dev-118068 )
> Here is a serious issue in the
> org.apache.commons.vfs.util.MonitorInputStream (and so it is also in
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentInputStream)
> FileContentInputStream extends MonitorInputStream extends BufferedInputStream
> So they support < mark > (stream.markSupported() returns true)
> But in MonitorInputStream.read(), when reaching the end of the stream, there
> is a call to close() regardless if 'mark' is positioned.
> To respect BufferedInputStream specifications we shouldn't close the stream
> in order to be able to call reset() on the stream and return in the state it
> was when we called mark().
> Usually doing the folowing before using mark feature :
> {code}
> if (!stream.markSupported()) {
> stream = new BufferedInputStream(stream);
> }
> {code}
> Won't work with a VFS stream.
> So what i did :
> {code}
> if (!stream.markSupported() || stream instanceof MonitorInputStream) { //Hack
> to solve a VFS issue
> stream = new BufferedInputStream(stream);
> }
> {code}
> I inform you also that in the BufferedInputStream.close() doc, it'written :
> " Once the stream has been closed, further read(), available(), reset(), or
> skip() invocations will throw an IOException. "
> And in the MonitorInputStream, if we call read() after close() it returns
> '-1'.
> Thank you in advance for solving this issue (may be somewhat difficult not to
> break compatibility with code that uses this specific usage)
> IMHO,
> I think "end-of-stream monitoring" doesn't mean "close when reach the end"
> but should mean "propose a way to execute some code when reaching the end"
> but anyway if we put a call to close() in this code it breaks the habillity
> to call reset().
> As this class consequently modify the comportment from the super class it
> should be more documented and explain what it does.
> I would say that this class is currently doing "end-of-stream autoClose and
> after-close monitoring".
> Maybe it shouldn't extends BufferedInputStream to avoid confusion and don't
> try to support 'mark' (respond false in markSupported()) as it doesn't seem
> to serve internally in VFS Project. (Can a power-developer of VFS confirm it
> ?)
> Regards,
> KERDUDOU Ronan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-614) MonitorInputStream should not close the stream in "read"
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375580#comment-16375580 ] Otto Fowler commented on VFS-614: - I marked the others duplicates, to link them up I also commented that there is a PR in for this issue. https://github.com/apache/commons-vfs/pull/30 > MonitorInputStream should not close the stream in "read" > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- 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
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375585#comment-16375585 ] Otto Fowler commented on LANG-1373: --- Can I ask why getChildren() should be public? I assume you mean add it to the timing interface? There is no reason for someone walking to have access to other nodes > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375623#comment-16375623 ] Otto Fowler commented on LANG-1373: --- OK, I have addressed the feedback with one exception, I kept the node package private so I could keep the tests and the coverage. Also, path is back, but we just create and pass as part of visitation. I think this gets everyone what they want. Let me know [~erans] > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375667#comment-16375667 ] Otto Fowler commented on LANG-1373: --- have you tried that when there are generics? give it a try. Notice your example isn't Map. what is the output you get? the wrong path appended? > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375668#comment-16375668 ] Otto Fowler commented on LANG-1373: --- I'll try the private thing again, and if I can't get 100% coverage I'm sure you'll still +1 > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375923#comment-16375923
]
Otto Fowler commented on LANG-1373:
---
I have fixed the visit issue, and done the javadoc using the hybrid and
\{@code} approach.
> 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
> Attachments: LANG-1373.patch
>
>
> 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375954#comment-16375954 ] Otto Fowler commented on LANG-1373: --- Ok, I think all feedback ( short the autogeneration of names ) has been addressed. > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375956#comment-16375956 ] Otto Fowler commented on LANG-1373: --- Maybe we are both watching the ODI cricket? [~kinow]! Hopefully we are on track with this. > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376070#comment-16376070 ] Otto Fowler commented on LANG-1373: --- I was thinking about that, honestly, I didn't think this would get reviewed and in before the metron pr would. I may close it, and update the METRON ticket to be 'take latest release of commons-lang and use Stackwatch' or something. > 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 > Attachments: LANG-1373.patch > > > 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)
[jira] [Updated] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated LANG-1373: -- Labels: commons-lang, (was: ) > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376101#comment-16376101 ] Otto Fowler commented on LANG-1373: --- I have rebased down to a single clean commit per discussions with [~kinow] just in case ;) > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376318#comment-16376318
]
Otto Fowler commented on LANG-1373:
---
Sorry, I'll look at the path stuff again.
[~erans]: when I do just \{@code } I get errors doing mvn clean site during the
java doc part.
That is why it was the way it was.
> 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
> Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376319#comment-16376319 ] Otto Fowler commented on LANG-1373: --- latested should be all set with paths. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376841#comment-16376841 ] Otto Fowler commented on LANG-1373: --- [~kinow], I *think* so. We *may* take [~erans] last comment as an implicit +1, but I would feel better if he were to be more explicit about it ;) > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378933#comment-16378933 ] Otto Fowler commented on VFS-654: - Not that I have seen, but I've only recently been paying attention. Besides HDFS ( which is still @unstable ) what other filesystems do you have in mind? > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- 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
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378961#comment-16378961 ] Otto Fowler commented on LANG-1373: --- Well, this is certainly taking a turn. I don't think testing is correct for this, or stopwatch. People may want to use this in non-test builds and scenarios. I'm not sure I have a better idea, but I don't think I'd want to pull in things that I'd normally restrict to test scope into my deployments. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379179#comment-16379179
]
Otto Fowler commented on LANG-1373:
---
By the way [~erans] [https://bugs.openjdk.java.net/browse/JDK-8130754] is the
issue i had with \{@code}
I am working on it again.
> 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
> Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379189#comment-16379189 ] Otto Fowler commented on LANG-1373: --- [~erans], sorry, I could not find a great way to get it all working based on that bug. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379485#comment-16379485 ] Otto Fowler commented on LANG-1373: --- So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that module is for. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Comment Edited] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379485#comment-16379485 ] Otto Fowler edited comment on LANG-1373 at 2/27/18 11:38 PM: - So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that projects current modules are for. was (Author: ottobackwards): So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that module is for. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16380228#comment-16380228 ] Otto Fowler commented on VFS-654: - WatchEvent is very cool. The Java ( 7+) system is very similar to VFS, in that there is a provider spi for supporting file systems. I am not sure what providers are installed on what operating systems. On my mac, I only have the OSX and ZIP installed. So, to support WatchEvent for any local filesystem would seem to be possible. For other filesystems that VFS supports, it would depend on what providers where loaded, therefore these would become dependencies. INotify for hdfs could be implemented on it's own as well. Thoughts [~b.eckenfels]? > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- 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
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16380261#comment-16380261 ] Otto Fowler commented on LANG-1373: --- I sent a mail to the list. Please comment. I'm winging it here ;) > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394181#comment-16394181
]
Otto Fowler commented on VFS-398:
-
[~b.eckenfels]: Is it enough to change the DefaultFileSystemManager? any
chance you can throw a review on the PR?
> 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&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] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441237#comment-16441237 ] Otto Fowler commented on VFS-661: - Is the issue that you can't get the real name, or that the wrong name resolves? Wouldn't the better fix be to allow on a per Provider/FS basis a setting that makes it case sensitive/insensitive? If you can 'turn it on' than it would be backward compatible. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442517#comment-16442517 ] Otto Fowler commented on VFS-661: - Can you post a small code sample? I want to be sure that I understand. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442600#comment-16442600 ] Otto Fowler commented on VFS-661: - I want to be sure I'm correct in the way you are finding and resolving the file. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-614) MonitorInputStream should not close the stream in read()
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477589#comment-16477589 ] Otto Fowler commented on VFS-614: - [~garydgregory] although I have the linked issues assigned to me, I do not have rights to resolve them, can you resolve them? > MonitorInputStream should not close the stream in read() > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > Fix For: 2.2.1 > > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-614) MonitorInputStream should not close the stream in read()
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477626#comment-16477626 ] Otto Fowler commented on VFS-614: - Yeah, I cannot close this issue, nor can I close the linked duplicated issues > MonitorInputStream should not close the stream in read() > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > Fix For: 2.2.1 > > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- 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
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515102#comment-16515102
]
Otto Fowler commented on VFS-398:
-
PR
> 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&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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515103#comment-16515103
]
Otto Fowler commented on VFS-398:
-
Any chance of a review / comment / merge on this issue?
> 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&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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16515614#comment-16515614
]
Otto Fowler commented on VFS-398:
-
The DefaultFileSystemManager sends in the providers, see the changes to that
file.
> 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&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] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532923#comment-16532923 ] Otto Fowler commented on LANG-1373: --- oops, forgot the jira. I released this on my own > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
[jira] [Closed] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler closed LANG-1373. - Resolution: Won't Fix Too complicated for lang, but the alternative of bringing back commons-monitoring is infinitely more complicated than this submittal. > 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 > Labels: commons-lang, > Attachments: LANG-1373.patch > > > 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)
