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

[Otto Fowler (JIRA)]

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

Otto Fowler updated VFS-525:

Comment: was deleted

(was: 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] [Issue Comment Deleted] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion

[Otto Fowler (JIRA)]

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

Otto Fowler updated VFS-525:

Comment: was deleted

(was: 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] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

I fetched the latest version of the PR.
I think that you forgot to make {{TimingNode}} generic.

While at it, I suggest the following changes:
* {{getTimingName()}} -> {{getName()}}
* {{TimingNode}} (private inner class) -> {{TimingNodeInternal}}
* {{StackWatchTiming}} (interface) -> {{Timing}} ("StackWatch" is redundant 
with the outer class name)
* Make the node class private (not just package-private) and static
* Make {{getChildren()}} public
* {{T[]}} ("tags" field) -> {{ArrayList}} (the current copy is not defensive)

> 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

[Gary Gregory (JIRA)]

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

Gary Gregory commented on VFS-525:
--

There are a lot of good questions here. TBH, I have not been in the depth of 
VFS for a few months now, and I cannot take the time to dig in FTP ATM.

If there are specific patches for specific bugs, let's get these in ASAP, with 
unit tests of course ;) It's too easy to get regression bugs at this point.

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



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

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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

As I noted earlier, one can use {{toString()}} on any {{Object}}, so the suffix 
can be added as part of a utility method that would return all 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
> 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] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Closed] (FILEUPLOAD-289) rererer

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels closed FILEUPLOAD-289.
--
   Resolution: Invalid
Fix Version/s: (was: 1.0 Final)

> rererer
> ---
>
> Key: FILEUPLOAD-289
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-289
> Project: Commons FileUpload
>  Issue Type: Test
>Affects Versions: 1.0 Final
>Reporter: dmytro r
>Priority: Trivial
>  Labels: BB2015-05-TBR
> Attachments: А.01.2000х1000х!!!1,2.0029.gcode
>
>   Original Estimate: 612h
>  Remaining Estimate: 612h
>
> *MODEL ARAMIS_LTC75  
> ;SHEETS 1
> ;PARTS 110
> ;DATT1 
> M06 G43 H1
> T1 
> M06 G43 H1
> T1 
> M06 G43 H1
> *MODEL ARAMIS_LTC75  
> ;SHEETS 1
> ;PARTS 110
> ;DATE NOV 20 2017 
> ;*SHEET 2000.000 1000.000 1.2
> ;MAT Steel 1.2 
> ;*T100  B 0.200  N=2  
> G90  
> G68  
> G108 
> M80
> $JumpHeight_L =8.000 
> $JumpHeight_M =12.000 
> $JumpHeight_H =20.000 
> ;#_Pen 1  ;(IGNORE_SIMULATION)
> ;# Low   ;(IGNORE_SIMULATION)
> $WorkF_L =5000.000 
> $JumpF_L =0.000  
> $LONDelay_L =0.000  
> $LaserPower_L =550  
> $GasPressure_L =7.000   
> $ModulationT_L =4000 
> $ModulationW_L =1000 
> $CALimit_L =350.000   
> $CCLimit_L =350.000  
> $Accel_L =350 
> ;#_Pen 2  ;(IGNORE_SIMULATION)
> ;# Medium   ;(IGNORE_SIMULATION)
> $WorkF_M =5000.000 
> $JumpF_M =0.000  
> $LONDelay_M =0.000  
> $LaserPower_M =550  
> $GasPressure_M =7.000   
> $ModulationT_M =4000 
> $ModulationW_M =4000 
> $CALimit_M =350.000   
> $CCLimit_M =350.000  
> $Accel_M =350 
> ;#_Pen 3  ;(IGNORE_SIMULATION)
> ;# High   ;(IGNORE_SIMULATION)
> $WorkF_H =5000.000 
> $JumpF_H =0.000  
> $LONDelay_H =0.000  
> $LaserPower_H =550  
> $GasPressure_H =7.000   
> $ModulationT_H =4000 
> $ModulationW_H =4000 
> $CALimit_H =350.000   
> $CCLimit_H =350.000  
> $Accel_H =350 
> ;#_Pen 4  ;(IGNORE_SIMULATION)
> ;# Ultra High   ;(IGNORE_SIMULATION)
> $WorkF_U =5000.000 
> $JumpF_U =0.000  
> $LONDelay_U =0.000  
> $LaserPower_U =550  
> $GasPressure_U =7.000   
> $ModulationT_U =4000 
> $ModulationW_U =4000 
> $CALimit_U =350.000   
> $CCLimit_U =350.000  
> $Accel_U =350 
> ;#_Pen 5  ;(IGNORE_SIMULATION)
> ;# Engrave  ;(IGNORE_SIMULATION)
> $WorkF_E =1700.000 
> $JumpF_E =0.000  
> $LONDelay_E =0.000  
> $LaserPower_E =160  
> $GasPressure_E =0.600   
> $ModulationT_E =4000 
> $ModulationW_E =4000 
> $CALimit_E =350.000   
> $CCLimit_E =350.000  
> $Accel_E =350 
> ;#_Pen 6  ;(IGNORE_SIMULATION)
> ;# Vaporize   ;(IGNORE_SIMULATION)
> $WorkF_V =5000.000 
> $JumpF_V =0.000  
> $LONDelay_V =0.000  
> $LaserPower_V =90  
> $GasPressure_V =7.000   
> $ModulationT_V =4000 
> $ModulationW_V =4000 
> $CALimit_V =350.000   
> $CCLimit_V =350.000  
> $Accel_V =350 
> M6$JumpHeight_L =8.000 
> $JumpHeight_M =12.000 
> $JumpHeight_H =20.000[TechCodes]
> *MODEL ARAMIS_LTC75  
> ;SHEETS 1
> ;PARTS 110
> ;DATT1 
> M06 G43 H1
> T1 
> M06 G43 H1
> T1 
> M06 G43 H1
> *MODEL ARAMIS_LTC75  
> ;SHEETS 1
> ;PARTS 110
> ;DATE NOV 20 2017 
> ;*SHEET 2000.000 1000.000 1.2
> ;MAT Steel 1.2 
> ;*T100  B 0.200  N=2  
> G90  
> G68  
> G108 
> M80
> $JumpHeight_L =8.000 
> $JumpHeight_M =12.000 
> $JumpHeight_H =20.000 
> ;#_Pen 1  ;(IGNORE_SIMULATION)
> ;# Low   ;(IGNORE_SIMULATION)
> $WorkF_L =5000.000 
> $JumpF_L =0.000  
> $LONDelay_L =0.000  
> $LaserPower_L =550  
> $GasPressure_L =7.000   
> $ModulationT_L =4000 
> $ModulationW_L =1000 
> $CALimit_L =350.000   
> $CCLimit_L =350.000  
> $Accel_L =350 
> ;#_Pen 2  ;(IGNORE_SIMULATION)
> ;# Medium   ;(IGNORE_SIMULATION)
> $WorkF_M =5000.000 
> $JumpF_M =0.000  
> $LONDelay_M =0.000  
> $LaserPower_M =550  
> $GasPressure_M =7.000   
> $ModulationT_M =4000 
> $ModulationW_M =4000 
> $CALimit_M =350.000   
> $CCLimit_M =350.000  
> $Accel_M =350 
> ;#_Pen 3  ;(IGNORE_SIMULATION)
> ;# High   ;(IGNORE_SIMULATION)
> $WorkF_H =5000.000 
> $JumpF_H =0.000  
> $LONDelay_H =0.000  
> $LaserPower_H =550  
> $GasPressure_H =7.000   
> $ModulationT_H =4000 
> $ModulationW_H =4000 
> $CALimit_H =350.000   
> $CCLimit_H =350.000  
> $Accel_H =350 
> ;#_Pen 4  ;(IGNORE_SIMULATION)
> ;# Ultra High   ;(IGNORE_SIMULATION)
> $WorkF_U =5000.000 
> $JumpF_U =0.000  
> $LONDelay_U =0.000  
> $LaserPower_U =550  
> $GasPressure_U =7.000   
> $ModulationT_U =4000 
> $ModulationW_U =4000 
> $CALimit_U =350.000   
> $CCLimit_U =350.000  
> $Accel_U =350 
> ;#_Pen 5  ;(IGNORE_SIMULATION)
> ;# Engrave  ;(IGNORE_SIMULATION)
> $WorkF_E =1700.000 
> $JumpF_E =0.000  
> $LONDelay_E =0.000  
> $LaserPower_E =160  
> $GasPressure_E =0.600   
> $ModulationT_E =4000 
> $ModulationW_E =4000 
> $CALimit_E =350.000   
> $CCLimit_E =350.000  
> $Accel_E =350 
> ;#_Pen 6  ;(IGNORE_SIMULATION)
> ;# Vaporize   ;(IGNORE_SIMULATION)
> $WorkF_V =5000.000 
> $JumpF_V =0.000  
> $LONDelay_V =0.000  
> $LaserPower_V =90  
> 

[jira] [Created] (FILEUPLOAD-289) rererer

[dmytro r (JIRA)]

dmytro r created FILEUPLOAD-289:
---

 Summary: rererer
 Key: FILEUPLOAD-289
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-289
 Project: Commons FileUpload
  Issue Type: Test
Affects Versions: 1.0 Final
Reporter: dmytro r
 Fix For: 1.0 Final
 Attachments: А.01.2000х1000х!!!1,2.0029.gcode

*MODEL ARAMIS_LTC75  
;SHEETS 1
;PARTS 110
;DATT1 
M06 G43 H1
T1 
M06 G43 H1
T1 
M06 G43 H1
*MODEL ARAMIS_LTC75  
;SHEETS 1
;PARTS 110
;DATE NOV 20 2017 
;*SHEET 2000.000 1000.000 1.2
;MAT Steel 1.2 
;*T100  B 0.200  N=2  
G90  
G68  
G108 
M80
$JumpHeight_L =8.000 
$JumpHeight_M =12.000 
$JumpHeight_H =20.000 
;#_Pen 1  ;(IGNORE_SIMULATION)
;# Low   ;(IGNORE_SIMULATION)
$WorkF_L =5000.000 
$JumpF_L =0.000  
$LONDelay_L =0.000  
$LaserPower_L =550  
$GasPressure_L =7.000   
$ModulationT_L =4000 
$ModulationW_L =1000 
$CALimit_L =350.000   
$CCLimit_L =350.000  
$Accel_L =350 
;#_Pen 2  ;(IGNORE_SIMULATION)
;# Medium   ;(IGNORE_SIMULATION)
$WorkF_M =5000.000 
$JumpF_M =0.000  
$LONDelay_M =0.000  
$LaserPower_M =550  
$GasPressure_M =7.000   
$ModulationT_M =4000 
$ModulationW_M =4000 
$CALimit_M =350.000   
$CCLimit_M =350.000  
$Accel_M =350 
;#_Pen 3  ;(IGNORE_SIMULATION)
;# High   ;(IGNORE_SIMULATION)
$WorkF_H =5000.000 
$JumpF_H =0.000  
$LONDelay_H =0.000  
$LaserPower_H =550  
$GasPressure_H =7.000   
$ModulationT_H =4000 
$ModulationW_H =4000 
$CALimit_H =350.000   
$CCLimit_H =350.000  
$Accel_H =350 
;#_Pen 4  ;(IGNORE_SIMULATION)
;# Ultra High   ;(IGNORE_SIMULATION)
$WorkF_U =5000.000 
$JumpF_U =0.000  
$LONDelay_U =0.000  
$LaserPower_U =550  
$GasPressure_U =7.000   
$ModulationT_U =4000 
$ModulationW_U =4000 
$CALimit_U =350.000   
$CCLimit_U =350.000  
$Accel_U =350 
;#_Pen 5  ;(IGNORE_SIMULATION)
;# Engrave  ;(IGNORE_SIMULATION)
$WorkF_E =1700.000 
$JumpF_E =0.000  
$LONDelay_E =0.000  
$LaserPower_E =160  
$GasPressure_E =0.600   
$ModulationT_E =4000 
$ModulationW_E =4000 
$CALimit_E =350.000   
$CCLimit_E =350.000  
$Accel_E =350 
;#_Pen 6  ;(IGNORE_SIMULATION)
;# Vaporize   ;(IGNORE_SIMULATION)
$WorkF_V =5000.000 
$JumpF_V =0.000  
$LONDelay_V =0.000  
$LaserPower_V =90  
$GasPressure_V =7.000   
$ModulationT_V =4000 
$ModulationW_V =4000 
$CALimit_V =350.000   
$CCLimit_V =350.000  
$Accel_V =350 
M6$JumpHeight_L =8.000 
$JumpHeight_M =12.000 
$JumpHeight_H =20.000[TechCodes]
*MODEL ARAMIS_LTC75  
;SHEETS 1
;PARTS 110
;DATT1 
M06 G43 H1
T1 
M06 G43 H1
T1 
M06 G43 H1
*MODEL ARAMIS_LTC75  
;SHEETS 1
;PARTS 110
;DATE NOV 20 2017 
;*SHEET 2000.000 1000.000 1.2
;MAT Steel 1.2 
;*T100  B 0.200  N=2  
G90  
G68  
G108 
M80
$JumpHeight_L =8.000 
$JumpHeight_M =12.000 
$JumpHeight_H =20.000 
;#_Pen 1  ;(IGNORE_SIMULATION)
;# Low   ;(IGNORE_SIMULATION)
$WorkF_L =5000.000 
$JumpF_L =0.000  
$LONDelay_L =0.000  
$LaserPower_L =550  
$GasPressure_L =7.000   
$ModulationT_L =4000 
$ModulationW_L =1000 
$CALimit_L =350.000   
$CCLimit_L =350.000  
$Accel_L =350 
;#_Pen 2  ;(IGNORE_SIMULATION)
;# Medium   ;(IGNORE_SIMULATION)
$WorkF_M =5000.000 
$JumpF_M =0.000  
$LONDelay_M =0.000  
$LaserPower_M =550  
$GasPressure_M =7.000   
$ModulationT_M =4000 
$ModulationW_M =4000 
$CALimit_M =350.000   
$CCLimit_M =350.000  
$Accel_M =350 
;#_Pen 3  ;(IGNORE_SIMULATION)
;# High   ;(IGNORE_SIMULATION)
$WorkF_H =5000.000 
$JumpF_H =0.000  
$LONDelay_H =0.000  
$LaserPower_H =550  
$GasPressure_H =7.000   
$ModulationT_H =4000 
$ModulationW_H =4000 
$CALimit_H =350.000   
$CCLimit_H =350.000  
$Accel_H =350 
;#_Pen 4  ;(IGNORE_SIMULATION)
;# Ultra High   ;(IGNORE_SIMULATION)
$WorkF_U =5000.000 
$JumpF_U =0.000  
$LONDelay_U =0.000  
$LaserPower_U =550  
$GasPressure_U =7.000   
$ModulationT_U =4000 
$ModulationW_U =4000 
$CALimit_U =350.000   
$CCLimit_U =350.000  
$Accel_U =350 
;#_Pen 5  ;(IGNORE_SIMULATION)
;# Engrave  ;(IGNORE_SIMULATION)
$WorkF_E =1700.000 
$JumpF_E =0.000  
$LONDelay_E =0.000  
$LaserPower_E =160  
$GasPressure_E =0.600   
$ModulationT_E =4000 
$ModulationW_E =4000 
$CALimit_E =350.000   
$CCLimit_E =350.000  
$Accel_E =350 
;#_Pen 6  ;(IGNORE_SIMULATION)
;# Vaporize   ;(IGNORE_SIMULATION)
$WorkF_V =5000.000 
$JumpF_V =0.000  
$LONDelay_V =0.000  
$LaserPower_V =90  
$GasPressure_V =7.000   
$ModulationT_V =4000 
$ModulationW_V =4000 
$CALimit_V =350.000   
$CCLimit_V =350.000  
$Accel_V =350 
M6$JumpHeight_L =8.000 
$JumpHeight_M =12.000 
$JumpHeight_H =20.000[TechCodes]



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

[jira] [Commented] (LANG-1380) FastDateParser too strict on abbreviated short month symbols

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LANG-1380:


The month name Strings are returned by 
{{java.util.Calendar.getDisplayNames(int, int, Locale)}}. I am not sure it 
would be a good idea to try to perform additional processing on those values. 
This is all done programatically. There might be room for adding more values 
based on an optional resource bundle which matches up with the French locale.

What do you all (the reported [~markus17] and the community) think?

> FastDateParser too strict on abbreviated short month symbols
> 
>
> Key: LANG-1380
> URL: https://issues.apache.org/jira/browse/LANG-1380
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.7
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 3.8
>
> Attachments: LANG-1380.patch
>
>
> The date format symbols of the French locale adds a . (dot) when short month 
> names are really abbreviated.
> {code}
> janv.
> févr.
> mars
> avr.
> mai
> juin
> juil.
> août
> sept.
> oct.
> nov.
> déc.
> {code}
> But in real world examples, the dot is frequently omitted.
> FastDateParser should be lenient in the case where the dot isn't there, e.g. 
> "14 avr 2014".



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

[jira] [Comment Edited] (COLLECTIONS-677) Modify IteratorUtils.objectGraphIterator signature to return ObjectGraphIterator

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on COLLECTIONS-677 at 2/23/18 5:07 PM:
---

What does this fix? IOW, since the {{ObjectGraphIterator}} has no other public 
methods than the ones defined by {{Iterator}}, what would you do with an 
{{ObjectGraphIterator}} that you cannot do with an {{Iterator}}? While this 
change seems harmless, I am trying to minimize changes.


was (Author: garydgregory):
What does this fix? IOW, since the {{ObjectGraphIterator}} has no other public 
methods than the ones defined by {{Iterator}}, what would you do with an 
{{ObjectGraphIterator}} that you cannot do with an {{Iterator}}?

> Modify IteratorUtils.objectGraphIterator signature to return 
> ObjectGraphIterator
> 
>
> Key: COLLECTIONS-677
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-677
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Core, Iterator
>Affects Versions: 4.1
>Reporter: Matthew Knight
>Priority: Trivial
>  Labels: signature
>
> IteratorUtils.objectGraphIterator currently says it returns java.util.Iterator



--
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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

Do you mean that "name" and "tags" share the same type?

I don't understand why getting rid of the path since it is always possible to 
get a String representation of any {{Object}}.

> 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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

I forgot to answer that easy one:
bq. Gilles, how do you pronounce your name? 

[Here it is|https://www.youtube.com/watch?v=ul8tS0--og4]. :)

> 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] (JXPATH-192) missing JXPath dependencies in pom 1.0

[sonia boulares (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374079#comment-16374079
 ] 

sonia boulares commented on JXPATH-192:
---

Hello,

ok, then there is no solution for 1.0.

Thanks for your help,

Regards

> missing JXPath dependencies in pom 1.0
> --
>
> Key: JXPATH-192
> URL: https://issues.apache.org/jira/browse/JXPATH-192
> Project: Commons JXPath
>  Issue Type: Bug
>Affects Versions: 1.0 Final
>Reporter: sonia boulares
>Priority: Blocker
>  Labels: maven
> Attachments: pom.xml
>
>
> Hello,
> Maven cannot resolve commons-jxpath  v 1.0 dependencies. So when i checked 
> the pom.xml, i found that jxpath dependencies (groupId, artifactId) are 
> missing. 
> Your help would be appreciated.
>  



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

[jira] [Closed] (JXPATH-192) missing JXPath dependencies in pom 1.0

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels closed JXPATH-192.
--
Resolution: Won't Fix

You can add the dependencies manually to your project. But using a more recent 
version is a good idea anyway.

> missing JXPath dependencies in pom 1.0
> --
>
> Key: JXPATH-192
> URL: https://issues.apache.org/jira/browse/JXPATH-192
> Project: Commons JXPath
>  Issue Type: Bug
>Affects Versions: 1.0 Final
>Reporter: sonia boulares
>Priority: Blocker
>  Labels: maven
> Attachments: pom.xml
>
>
> Hello,
> Maven cannot resolve commons-jxpath  v 1.0 dependencies. So when i checked 
> the pom.xml, i found that jxpath dependencies (groupId, artifactId) are 
> missing. 
> Your help would be appreciated.
>  



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

[jira] [Commented] (JXPATH-192) missing JXPath dependencies in pom 1.0

[sonia boulares (JIRA)]

[ 
https://issues.apache.org/jira/browse/JXPATH-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374084#comment-16374084
 ] 

sonia boulares commented on JXPATH-192:
---

I don't have dependencies' name in the uploaded file, there are just versions,

Regards

> missing JXPath dependencies in pom 1.0
> --
>
> Key: JXPATH-192
> URL: https://issues.apache.org/jira/browse/JXPATH-192
> Project: Commons JXPath
>  Issue Type: Bug
>Affects Versions: 1.0 Final
>Reporter: sonia boulares
>Priority: Blocker
>  Labels: maven
> Attachments: pom.xml
>
>
> Hello,
> Maven cannot resolve commons-jxpath  v 1.0 dependencies. So when i checked 
> the pom.xml, i found that jxpath dependencies (groupId, artifactId) are 
> missing. 
> Your help would be appreciated.
>  



--
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

[Gilles (JIRA)]

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

Gilles updated LANG-1373:
-
Attachment: LANG-1373.patch

> 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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

It's not the naming part, it's the (supposedly _unique_) identifier part.  See 
your own examples (in the unit tests): identifying the timings is fragile (it's 
easy to create two timings with the same name) and often redundant. I can't 
think of a "deal breaker"; the functionality itself seems quite fine; it's the 
usage part which I suspect is not as good as it could; but once the API is 
released, it is fairly difficult to correct the course in "Commons": fixing a 
single interface often requires changing all (even if "just" by renaming the 
top-level package).
Perhaps the "name" should be a "prefix" (set at construction of the 
{{StackWatch}} and the watch would append an increment to form a unique name at 
each call to {{startTiming}} (?). 

> 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] (COLLECTIONS-677) Modify IteratorUtils.objectGraphIterator signature to return ObjectGraphIterator

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on COLLECTIONS-677 at 2/23/18 4:53 PM:
---

What does this fix? IOW, since the {{ObjectGraphIterator}} has no other public 
methods than the ones defined by {{Iterator}}, what would you do with an 
{{ObjectGraphIterator}} that you cannot do with an {{Iterator}}?


was (Author: garydgregory):
What does this fix?

> Modify IteratorUtils.objectGraphIterator signature to return 
> ObjectGraphIterator
> 
>
> Key: COLLECTIONS-677
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-677
> Project: Commons Collections
>  Issue Type: Improvement
>  Components: Core, Iterator
>Affects Versions: 4.1
>Reporter: Matthew Knight
>Priority: Trivial
>  Labels: signature
>
> IteratorUtils.objectGraphIterator currently says it returns java.util.Iterator



--
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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

bq. Access to the 'path' of the timing is important.

I do not propose to change anything about that.

I've attached what I've been playing with; please have a look.
Using method {{startNamedTiming(String name, T ... tags)}}, path are built with 
user-selected names (as per your original goal); using method {{startTiming(T 
... tags)}}, path are named according to the sequence of function calls and a 
counter (in order to cater for the case when multiple counters are used within 
the same method). See the console output of two unit tests that print the paths.

WDYT?

> 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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

It however looks like a good idea to decouple the watch from the path 
construction if you found out a way to do 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
> 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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Gilles (JIRA)]

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

Gilles commented on LANG-1373:
--

bq. throws an exception in the background

Interesting.  How do you see that?

bq. not my intent

OK (that's why I asked about use-case).
However, I'm still uncomfortable about using {{String}} as an "identifier".
Moreover, don't you think that there should be a way to allow the simpler usage 
which I suggested (no name triggers auto-name)?
Just wondering: What about
{code}
public void startTiming(Object id, T ... tags) {
 final String name = id.toString();
 // ...
}
{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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)