[jira] [Commented] (IO-665) XmlStreamReader throws IOException stream closed on null input stream
[ https://issues.apache.org/jira/browse/IO-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082574#comment-17082574 ] Otto Fowler commented on IO-665: ok, PR up > XmlStreamReader throws IOException stream closed on null input stream > - > > Key: IO-665 > URL: https://issues.apache.org/jira/browse/IO-665 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Had to go into the debugger because when some code passed null into the > org.apache.commons.io.input.XmlStreamReader constructor it threw an > IOException with the message "Stream closed". > > This is not accurate. There was no stream. It was null. If a > NullPointerException had been thrown instead, this would have been easier to > debug. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-665) XmlStreamReader throws IOException stream closed on null input stream
[ https://issues.apache.org/jira/browse/IO-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082561#comment-17082561 ] Otto Fowler commented on IO-665: I would like to assign the jira to myself > XmlStreamReader throws IOException stream closed on null input stream > - > > Key: IO-665 > URL: https://issues.apache.org/jira/browse/IO-665 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Had to go into the debugger because when some code passed null into the > org.apache.commons.io.input.XmlStreamReader constructor it threw an > IOException with the message "Stream closed". > > This is not accurate. There was no stream. It was null. If a > NullPointerException had been thrown instead, this would have been easier to > debug. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-665) XmlStreamReader throws IOException stream closed on null input stream
[ https://issues.apache.org/jira/browse/IO-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082544#comment-17082544 ] Otto Fowler commented on IO-665: Fair enough. > XmlStreamReader throws IOException stream closed on null input stream > - > > Key: IO-665 > URL: https://issues.apache.org/jira/browse/IO-665 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Had to go into the debugger because when some code passed null into the > org.apache.commons.io.input.XmlStreamReader constructor it threw an > IOException with the message "Stream closed". > > This is not accurate. There was no stream. It was null. If a > NullPointerException had been thrown instead, this would have been easier to > debug. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-665) XmlStreamReader throws IOException stream closed on null input stream
[ https://issues.apache.org/jira/browse/IO-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082531#comment-17082531 ] Otto Fowler commented on IO-665: I think this should be an IllegalArgumentException though > XmlStreamReader throws IOException stream closed on null input stream > - > > Key: IO-665 > URL: https://issues.apache.org/jira/browse/IO-665 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Had to go into the debugger because when some code passed null into the > org.apache.commons.io.input.XmlStreamReader constructor it threw an > IOException with the message "Stream closed". > > This is not accurate. There was no stream. It was null. If a > NullPointerException had been thrown instead, this would have been easier to > debug. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-665) XmlStreamReader throws IOException stream closed on null input stream
[ https://issues.apache.org/jira/browse/IO-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082517#comment-17082517 ] Otto Fowler commented on IO-665: [~ggregory] can you add me as an io contributor, I'll do a pr > XmlStreamReader throws IOException stream closed on null input stream > - > > Key: IO-665 > URL: https://issues.apache.org/jira/browse/IO-665 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Had to go into the debugger because when some code passed null into the > org.apache.commons.io.input.XmlStreamReader constructor it threw an > IOException with the message "Stream closed". > > This is not accurate. There was no stream. It was null. If a > NullPointerException had been thrown instead, this would have been easier to > debug. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071816#comment-17071816 ] Otto Fowler commented on VFS-760: - Any help you can give would certainly be appreciated [~ggregory] > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071791#comment-17071791 ] Otto Fowler edited comment on VFS-760 at 3/31/20, 1:32 PM: --- [~belugabehr], I am pretty sure I need a review to be completed with a +1 and possibly someone to try it and confirm that it works basically. If I understand what the current thinking is, it is that since it is a separate module, it is ok not to be perfect, we would want to get something in that works and iterate. [~b.eckenfels] is that correct? I know you have done some review work. But we need a committer to +1. was (Author: ottobackwards): [~belugabehr], I am pretty sure I need a review and possibly someone to try it and confirm that it works basically. If I understand what the current thinking is, it is that since it is a separate module, it is ok not to be perfect, we would want to get something in that works and iterate. [~b.eckenfels] is that correct? If you can build my pr and try it out, it would help. > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071791#comment-17071791 ] Otto Fowler commented on VFS-760: - [~belugabehr], I am pretty sure I need a review and possibly someone to try it and confirm that it works basically. If I understand what the current thinking is, it is that since it is a separate module, it is ok not to be perfect, we would want to get something in that works and iterate. [~b.eckenfels] is that correct? If you can build my pr and try it out, it would help. > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049485#comment-17049485 ] Otto Fowler commented on VFS-760: - I'm not sure what you mean. The parent is the vfs2 project > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-627) SFTP randomly hangs when copying a file on remote server
[
https://issues.apache.org/jira/browse/VFS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046926#comment-17046926
]
Otto Fowler commented on VFS-627:
-
Apache Nifi has switch to the sshj library:
https://github.com/apache/nifi/pull/3726/files
> SFTP randomly hangs when copying a file on remote server
>
>
> Key: VFS-627
> URL: https://issues.apache.org/jira/browse/VFS-627
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Java 1.8.0_92
> VFS 2.1
> JSch 0.1.53
>Reporter: Henri Hagberg
>Priority: Major
>
> I have a process where a file is first copied over SFTP to local server and
> then on the remote server the file is copied to another location on that
> server for archiving. Both are done using {{FileObject#copyFrom}}. Now I've
> encountered twice the situation where during archiving (on remote server) the
> copy action hangs indefinitely (the process was left running for over 24
> hours). In both cases the issue happened when around 2000 files had been
> transferred (typical amount is under 100).
> The problem is difficult to reproduce since it doesn't always happen even
> with large number of files. Based on the stacktrace and random occurrences it
> might be a concurrency issue. The code using VFS however is single threaded.
> {code}
> Attaching to process ID 128021, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.92-b14
> Deadlock Detection:
> No deadlocks found.
> Thread 19073: (state = BLOCKED)
> Thread 128165: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - org.apache.commons.vfs2.cache.SoftRefFilesCache$SoftRefReleaseThread.run()
> @bci=26, line=84 (Compiled frame)
> Thread 128164: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.io.PipedInputStream.awaitSpace() @bci=23, line=273 (Compiled frame)
> - java.io.PipedInputStream.receive(byte[], int, int) @bci=31, line=231
> (Compiled frame)
> - java.io.PipedOutputStream.write(byte[], int, int) @bci=77, line=149
> (Compiled frame)
> - com.jcraft.jsch.IO.put(byte[], int, int) @bci=7, line=64 (Compiled frame)
> - com.jcraft.jsch.Channel.write(byte[], int, int) @bci=7, line=438 (Compiled
> frame)
> - com.jcraft.jsch.Session.run() @bci=1260, line=1624 (Compiled frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> Thread 128139: (state = BLOCKED)
> Thread 128138: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Compiled
> frame)
> - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Compiled frame)
> - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209
> (Interpreted frame)
> Thread 128137: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - java.lang.Object.wait() @bci=2, line=502 (Compiled frame)
> - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191
> (Compiled frame)
> - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153
> (Interpreted frame)
> Thread 128022: (state = BLOCKED)
> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be
> imprecise)
> - com.jcraft.jsch.Session.write(com.jcraft.jsch.Packet,
> com.jcraft.jsch.Channel, int) @bci=89, line=1261 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.sendWRITE(byte[], long, byte[], int, int)
> @bci=191, line=2619 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp.access$100(com.jcraft.jsch.ChannelSftp,
> byte[], long, byte[], int, int) @bci=9, line=36 (Compiled frame)
> - com.jcraft.jsch.ChannelSftp$1.write(byte[], int, int) @bci=77, line=791
> (Compiled frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=20, line=122
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> - java.io.BufferedOutputStream.flushBuffer() @bci=20, line=82 (Compiled
> frame)
> - java.io.BufferedOutputStream.write(byte[], int, int) @bci=39, line=126
> (Compiled frame)
> - org.apache.commons.vfs2.util.MonitorOutputStream.write(byte[], int, int)
> @bci=8, line=123 (Compiled frame)
> -
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream,
> int) @bci=35, line=892 (Compiled frame)
> -
> org.apache.commons.vfs2.provider.DefaultFileContent.write(java.io.OutputStream)
> @bci=5, line=865 (Compiled frame)
> -
>
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[
https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044563#comment-17044563
]
Otto Fowler commented on VFS-760:
-
[~b.eckenfels] the pr is updated with zk as it's own jar/module.
note that
{code:bash}
mvn clean site
{code}
does NOT work for me
> Add ZooKeeper File System
> -
>
> Key: VFS-760
> URL: https://issues.apache.org/jira/browse/VFS-760
> Project: Commons VFS
> Issue Type: Wish
>Reporter: David Mollitor
>Assignee: Otto Fowler
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add VFS integration for using ZooKeeper as a file system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated VFS-760: Assignee: Otto Fowler > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043954#comment-17043954 ] Otto Fowler commented on VFS-760: - I will work on breaking out to it's own module > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Assignee: Otto Fowler >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043786#comment-17043786 ] Otto Fowler commented on VFS-760: - OK, sorry, i didn't have the branch checked out and was missing it. So, it is my experience from different projects that it is better to support both having to create the client and allowing it to be passed in and managed externally. The lifecycle, for the filesystem when it owns the client is the same as any other connection file system as far as I can tell. > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043740#comment-17043740 ] Otto Fowler commented on VFS-760: - Where are you referring to with the ownsClient? I can try to do what jackrabbit did, and maintain the current coverage, which I believe is on par with the other providers > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043647#comment-17043647 ] Otto Fowler commented on VFS-760: - I expect so. And expected that feedback from [~b.eckenfels]. Can you comment on the PR? [~b.eckenfels] is there an example I can go by? Or should go by? This shouldn't be a sandbox thing though > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043582#comment-17043582 ] Otto Fowler commented on VFS-760: - s'ok. I look at is as the kind of thing that is %80 done. Since I did it out of curiosity, not need for myself, I didn't go though a lot of scenarios that might be important to you. The idea is to iterate on it, but for that to work, I can't be the only one running and trying it. That is where you can help to get what you need. Use, test and feedback > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042193#comment-17042193 ] Otto Fowler commented on VFS-760: - Reviewing the diff, i can see some issues already, things commented out. > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042190#comment-17042190 ] Otto Fowler commented on VFS-760: - https://github.com/ottobackwards/commons-vfs/tree/zkprovider > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042187#comment-17042187 ] Otto Fowler commented on VFS-760: - I think I have the tests straightened out. The diff will show. Anyways, I understand it may need some work. Another reason I didn't submit it before was that I wasn't sure anyone would want it ;) now that someone is interested, we can get some test > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042188#comment-17042188 ] Otto Fowler commented on VFS-760: - I'll throw it up and we'll see what happens :) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042180#comment-17042180 ] Otto Fowler commented on VFS-760: - [~belugabehr], if you are willing to try and review, I'll submit the PR. Obviously [~ggregory] and [~b.eckenfels] too > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041891#comment-17041891 ] Otto Fowler commented on VFS-760: - Originally, I did the work in preparation to include with VFS, but then I split it out to my org. I have updated my original branch ( zkprovider in vfs ). You can see it here: https://github.com/ottobackwards/commons-vfs/tree/zkprovider > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041368#comment-17041368 ] Otto Fowler commented on VFS-760: - This was with a snapshot build of vfs... bottom line it needs a little work but is a long way there > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041360#comment-17041360 ] Otto Fowler commented on VFS-760: - Ok, now that I go back to it, i was able to make the tests pass, but I had to change some things: /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/bin/java -Dmaven.multiModuleProjectDirectory=/Users/ottofowler/src/github/palindromicity/vfs-zookeeper-provider "-Dmaven.home=/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3" "-Dclassworlds.conf=/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3/bin/m2.conf" "-Dmaven.ext.class.path=/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven-event-listener.jar" "-javaagent:/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=56794:/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Users/ottofowler/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/193.6494.35/IntelliJ IDEA.app/Contents/plugins/maven/lib/maven3/boot/plexus-classworlds-2.6.0.jar" org.codehaus.classworlds.Launcher -Didea.version2019.3.3 test [INFO] Scanning for projects... [WARNING] The project com.github.palindromicity:vfs-zookeeper-provider:jar:0.0.1-SNAPSHOT uses prerequisites which is only intended for maven-plugin projects but not for non maven-plugin projects. For such purposes you should use the maven-enforcer-plugin. See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html [INFO] [INFO] --< com.github.palindromicity:vfs-zookeeper-provider >-- [INFO] Building vfs-zookeeper-provider 0.0.1-SNAPSHOT [INFO] [ jar ]- [WARNING] The POM for org.apache.commons:commons-vfs2:jar:2.3-SNAPSHOT is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [WARNING] The POM for org.apache.commons:commons-vfs2:jar:tests:2.3-SNAPSHOT is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ vfs-zookeeper-provider --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] [INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ vfs-zookeeper-provider --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 4 source files to /Users/ottofowler/src/github/palindromicity/vfs-zookeeper-provider/target/classes [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ vfs-zookeeper-provider --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 33 resources [INFO] [INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ vfs-zookeeper-provider --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 3 source files to /Users/ottofowler/src/github/palindromicity/vfs-zookeeper-provider/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ vfs-zookeeper-provider --- [INFO] Surefire report directory: /Users/ottofowler/src/github/palindromicity/vfs-zookeeper-provider/target/surefire-reports --- T E S T S --- Running com.github.palindromicity.vfs2.provider.zookeeper.test.ZkFileProviderTestCase Tests run: 79, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.865 sec Results : Tests run: 79, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 9.907 s [INFO] Finished at: 2020-02-20T18:23:58-05:00 [INFO] > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041349#comment-17041349 ] Otto Fowler commented on VFS-760: - Many of the tests _do_ work. Just not the tests that check if something is a folder or file explicitly ( since everything in zookeeper is a file_or_folder ) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041346#comment-17041346 ] Otto Fowler commented on VFS-760: - But to say that a submitted provider should work with the extensive and generic provider tests > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041343#comment-17041343 ] Otto Fowler commented on VFS-760: - That is not to say that the above is battle tested and ready to do in all circumstances. It is best considered initial PR quality, with the understanding that some issues will be worked through in the pr process ;) > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-760) Add ZooKeeper File System
[ https://issues.apache.org/jira/browse/VFS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041339#comment-17041339 ] Otto Fowler commented on VFS-760: - I actually wrote one of these:https://github.com/palindromicity/vfs-zookeeper-provider I was going to submit it, but there is an issue that I did not know how to tackle. The VFS system, at least at the testing level doesn't _really_ support FILE_OR_FOLDER. And I didn't know how much work there would be to do it, but it would be a lot. The provider works, but the testing code would not work in integration. > Add ZooKeeper File System > - > > Key: VFS-760 > URL: https://issues.apache.org/jira/browse/VFS-760 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > Add VFS integration for using ZooKeeper as a file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (VFS-691) Git should ignore intellij files
[ https://issues.apache.org/jira/browse/VFS-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler closed VFS-691. --- Resolution: Fixed > Git should ignore intellij files > > > Key: VFS-691 > URL: https://issues.apache.org/jira/browse/VFS-691 > Project: Commons VFS > Issue Type: Improvement >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > .idea > *.iml > *.iws -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-691) Git should ignore intellij files
Otto Fowler created VFS-691: --- Summary: Git should ignore intellij files Key: VFS-691 URL: https://issues.apache.org/jira/browse/VFS-691 Project: Commons VFS Issue Type: Improvement Reporter: Otto Fowler Assignee: Otto Fowler .idea *.iml *.iws -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753971#comment-16753971
]
Otto Fowler commented on VFS-398:
-
Here
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753969#comment-16753969
]
Otto Fowler commented on VFS-398:
-
!image-2019-01-28-07-46-13-524.png!
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753130#comment-16753130
]
Otto Fowler commented on VFS-398:
-
A PMC member should be able to get into the project dashboard and assign users
to roles. I can do this with METRON as I am on the pmc
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753114#comment-16753114
]
Otto Fowler commented on VFS-398:
-
Yeah, my Jira login pre-dates my apache id, I am in that list, but as
[o...@apache.org.|mailto:o...@apache.org.]
Who is on the PMC of commons who can give me rights in jira?
Once vfs is in git ( having gotten a couple of PRs landed ) I'll be more
comfortable doing commit then review.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752740#comment-16752740
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] I cannot close this jira. Can you check my rights?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747120#comment-16747120
]
Otto Fowler commented on VFS-398:
-
[~b.eckenfels] please see the latest, i have tried to cut down on temp object
creation, and cached the schemes.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746347#comment-16746347
]
Otto Fowler commented on VFS-398:
-
The point about getSchemes is a good one. I was more concerned with 'how to
get the schemes correctly' than that issue. Let me think about that and see if
I can make it better.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746328#comment-16746328
]
Otto Fowler commented on VFS-398:
-
maybe [~b.eckenfels]?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
[
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745563#comment-16745563
]
Otto Fowler commented on VFS-645:
-
I apologize. Please ignore. I believe that the additional failures are java
11 only.
Even though I had set my env to java 9, my $JAVA_HOME was still 11.
Sorry
> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<<
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests) Time
> elapsed: 0 sec <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve
> the certificates of
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
>
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745463#comment-16745463
]
Otto Fowler commented on VFS-398:
-
There is a new test in the URIParserTestCase for the issue reported. What
tests do you mean?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745296#comment-16745296
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] :
[https://github.com/apache/commons-vfs/pull/29/commits/c7f5944f5c6d7b3e9bba49344bf5389346982f47]
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
[ https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745287#comment-16745287 ] Otto Fowler commented on VFS-645: - OK, I managed to get java9 from AdoptOpenJDK installed, and testing fails there too: Tests in error: AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166 » FileSystem AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166 » FileSystem MultipleConnectionTestCase.testConnectRoot:55->resolveRoot:49 » FileSystem Cou... MultipleConnectionTestCase.testUnderlyingConnect:65 » SSL Unsupported or unrec... org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest Run 1: HdfsFileProviderTest.setUp:91 » NoClassDefFound Could not initialize class org... Run 2: HdfsFileProviderTest.tearDown:135 NullPointer HdfsFileProviderTestCase$HdfsProviderTestSuite>AbstractTestSuite.run:137->setUp:98 » ExceptionInInitializer Tests run: 2177, Failures: 0, Errors: 6, Skipped: 4 sample: Running org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.22 sec <<< FAILURE! - in org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase junit.framework.TestSuite@51ec2856(org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite) Time elapsed: 0.22 sec <<< ERROR! java.lang.ExceptionInInitializerError at org.apache.hadoop.util.StringUtils.(StringUtils.java:79) at org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388) at org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931) at org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:738) at org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite.setUp(HdfsFileProviderTestCase.java:98) at org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:131) at junit.framework.TestResult.runProtected(TestResult.java:142) at org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 2 at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319) at java.base/java.lang.String.substring(String.java:1874) at org.apache.hadoop.util.Shell.(Shell.java:49) ... 19 more Running org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.03 sec <<< FAILURE! - in org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest Time elapsed: 0.03 sec <<< ERROR! java.lang.NoClassDefFoundError: Could not initialize class org.apache.hadoop.util.StringUtils at org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388) at org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931) at org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807) at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:738) at org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.setUp(HdfsFileProviderTest.java:91) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
[
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745288#comment-16745288
]
Otto Fowler commented on VFS-645:
-
java -version
openjdk version "9"
OpenJDK Runtime Environment (build 9+181)
OpenJDK 64-Bit Server VM (build 9+181, mixed mode)
> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<<
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests) Time
> elapsed: 0 sec <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve
> the certificates of
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at
[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
[
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745258#comment-16745258
]
Otto Fowler commented on VFS-645:
-
[~garydgregory] I was going to test this, but found I could not install java9
and had to use java11.
With java 11 after these fixes there are still errors. Should I open up
another jira?
> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<<
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests) Time
> elapsed: 0 sec <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve
> the certificates of
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at
[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
[
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745259#comment-16745259
]
Otto Fowler commented on VFS-645:
-
note they are not the same errors
> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<<
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests) Time
> elapsed: 0 sec <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve
> the certificates of
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
> at
>
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745066#comment-16745066
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] I would like to get this in, and possibly we can talk about a
release, or other things that we want to land pursuant to a release. What do
you think?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734630#comment-16734630 ] Otto Fowler commented on VFS-685: - I have updated the javadoc. Anything else needed? > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726201#comment-16726201
]
Otto Fowler commented on VFS-398:
-
ping
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726198#comment-16726198 ] Otto Fowler commented on VFS-685: - ping > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718898#comment-16718898 ] Otto Fowler commented on VFS-685: - They should be all set now [~garydgregory] > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718900#comment-16718900
]
Otto Fowler commented on VFS-398:
-
If you look at latest, I think it is what you are looking for [~garydgregory]
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713385#comment-16713385 ] Otto Fowler commented on VFS-685: - If we wanted to say, look at reviewing a couple of in q pr's to fill out the release i would be up for helping with that > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713330#comment-16713330 ] Otto Fowler commented on VFS-685: - What would be great is if we could land this and the other things in review and get a release out. > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713329#comment-16713329 ] Otto Fowler commented on VFS-685: - Of course it should be. Not all providers will be submitted, and it is inconsistent to have the ability to extend the classes but not have all the types available. I'll javadoc them. > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: patch-available > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-685) Test classes should be public so test suits can be extended
[ https://issues.apache.org/jira/browse/VFS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713205#comment-16713205 ] Otto Fowler commented on VFS-685: - Understood. I wrote a provider for zookeeper, original in project. I was going to submit it but I'm going to release it outside the project. In order to get a FILE_OR_FOLDER type to work with the test cases, I needed to create FileOrFolder versions of a couple of the standard test cases, those classes now in my project and not in the vfs package. I cannot use these classes that extend the abstract test classes without FileInfo. Outside provider writers should be able to both run the tests, and add new tests. > Test classes should be public so test suits can be extended > --- > > Key: VFS-685 > URL: https://issues.apache.org/jira/browse/VFS-685 > Project: Commons VFS > Issue Type: Bug >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > > FileInfo and possibly other classes should be public, that way someone can > write tests for their providers that extend and are close to the same as the > project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-685) Test classes should be public so test suits can be extended
Otto Fowler created VFS-685: --- Summary: Test classes should be public so test suits can be extended Key: VFS-685 URL: https://issues.apache.org/jira/browse/VFS-685 Project: Commons VFS Issue Type: Bug Reporter: Otto Fowler Assignee: Otto Fowler FileInfo and possibly other classes should be public, that way someone can write tests for their providers that extend and are close to the same as the project tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712806#comment-16712806
]
Otto Fowler commented on VFS-398:
-
Nevermind, i was able to bring changes over from apache/VFS-398
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712758#comment-16712758
]
Otto Fowler commented on VFS-398:
-
Actually, [~garydgregory], what is this patch? It is a patch on top of my
changes, or a patch that includes my changes against trunk?
Can you do a patch of just your changes that I can apply or submit a PR to my
github branch?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712748#comment-16712748
]
Otto Fowler commented on VFS-398:
-
{noformat}
~/src/apache/forks/commons-vfs VFS-398 git apply
12950897_VFS-398-gg-00.patch
error: patch failed: pom.xml:135
error: pom.xml: patch does not apply
error: patch failed:
commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/DefaultFileSystemManager.java:764
error:
commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/DefaultFileSystemManager.java:
patch does not apply
error: patch failed:
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:16
error:
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
patch does not apply
error: patch failed:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/UriParserTestCase.java:16
error:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/UriParserTestCase.java:
patch does not apply
error: patch failed:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/local/test/FileNameTests.java:17
error:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/local/test/FileNameTests.java:
patch does not apply{noformat}
I'm going to hand apply the changes. I'll tag you in the commit
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712168#comment-16712168
]
Otto Fowler commented on VFS-398:
-
[~garydgregory] Thanks for the feedback. I will apply your patch, and get to
work on that.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709105#comment-16709105
]
Otto Fowler commented on VFS-398:
-
so, where are we at?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-398:
Assignee: Otto Fowler
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-683:
Assignee: Gary Gregory (was: Otto Fowler)
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Gary Gregory
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-683:
Assignee: Otto Fowler
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Otto Fowler
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699541#comment-16699541
]
Otto Fowler commented on VFS-683:
-
>From what I can see in past issues, this is not a defect. That is why they
>are not documented as thread safe or immutable. You can look at VFS-253 as
>well, which I just found.
I would suggest creating a Jira to explicitly state in documentation what is
and is not thread safe.
You may also want to start a [DISCUSS][VFS] thread on the commons dev mailing
list about the issue.
I am sorry if I have frustrated you, basically working through the issue to get
back to where you started.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Otto Fowler
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-683:
Assignee: (was: Otto Fowler)
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otto Fowler updated VFS-683:
Assignee: Otto Fowler
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Otto Fowler
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider
[ https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated VFS-228: Assignee: (was: Otto Fowler) > Ant regression with ClassNotFoundException for DefaultLocalFileProvider > --- > > Key: VFS-228 > URL: https://issues.apache.org/jira/browse/VFS-228 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.6.0_0" > IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) > OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) > Apache Ant version 1.7.1 compiled on October 3 2008 >Reporter: Per Hermansson >Priority: Critical > Attachments: patch, test.xml, vfs-task.diff > > > The latest version from trunk fails to work with Apache Ant resulting in this > error: > Could not load VFS configuration from > "jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml". > which was caused by > java.lang.ClassNotFoundException: > org.apache.commons.vfs.provider.local.DefaultLocalFileProvider > The cause seems to be a class loader issued introduced in rev 537717. > Reverting that change: > cd core > svn diff -c r537717 > src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | > patch -R > mvn clean install > [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir] > ant -f test.xml test > Makes my example ant file work again (worked with the 1.0 release). > The 537717 revision was intended to fix > VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch > So it might be a bit controversial to reverse that change. > Attaching patch fixing the issue and my example ant file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-228) Ant regression with ClassNotFoundException for DefaultLocalFileProvider
[ https://issues.apache.org/jira/browse/VFS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler updated VFS-228: Assignee: Otto Fowler > Ant regression with ClassNotFoundException for DefaultLocalFileProvider > --- > > Key: VFS-228 > URL: https://issues.apache.org/jira/browse/VFS-228 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.6.0_0" > IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) > OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) > Apache Ant version 1.7.1 compiled on October 3 2008 >Reporter: Per Hermansson >Assignee: Otto Fowler >Priority: Critical > Attachments: patch, test.xml, vfs-task.diff > > > The latest version from trunk fails to work with Apache Ant resulting in this > error: > Could not load VFS configuration from > "jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0-SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml". > which was caused by > java.lang.ClassNotFoundException: > org.apache.commons.vfs.provider.local.DefaultLocalFileProvider > The cause seems to be a class loader issued introduced in rev 537717. > Reverting that change: > cd core > svn diff -c r537717 > src/main/java/org/apache/commons/vfs/impl/StandardFileSystemManager.java | > patch -R > mvn clean install > [copy commons-vfs-2.0-SNAPSHOT to my test's lib dir] > ant -f test.xml test > Makes my example ant file work again (worked with the 1.0 release). > The 537717 revision was intended to fix > VFS-136: Don't force-set the classloader - Thanks to Adam Heath for the patch > So it might be a bit controversial to reverse that change. > Attaching patch fixing the issue and my example ant file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697185#comment-16697185
]
Otto Fowler commented on VFS-398:
-
Any chance anyone can ok this and land the pr? I hate having things laying
around forever.
[~garydgregory] [~b.eckenfels]
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696194#comment-16696194
]
Otto Fowler edited comment on VFS-683 at 11/22/18 10:04 PM:
The things you are dealing with here:
* Static FileSystemManager
* Threads
* Non-Thread Safe Content
* Cache
* Using the FileSystem abstractly ( not having to "know" the fs type )
There a number of different approaches, all with trade-offs, I'm sure you all
have thought of some as well.
was (Author: ottobackwards):
The things you are dealing with here:
* Static FileSystemManager
* Threads
* Non-Thread Safe Content
* Cache
* Using the FileSystem abstractly ( not having to "know" the fs type )
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696193#comment-16696193
]
Otto Fowler commented on VFS-683:
-
For example -> your code works, with the following modifications:
{code:java}
package org.apache.ottobackwards;
import org.apache.commons.vfs2.FileObject;
import org.apache.commons.vfs2.FileSystemManager;
import org.apache.commons.vfs2.FileType;
import org.apache.commons.vfs2.FileUtil;
//import org.apache.commons.vfs2.VFS;
import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
import org.apache.commons.vfs2.impl.StandardFileSystemManager;
import org.apache.commons.vfs2.provider.tar.TarFileProvider;
public class Main {
/**
* The first parameter (args[0]) should be an directory within an archive
file. For example:
* tgz:file://Users/daryl/zookeeper-3.4.13.tgz!zookeeper-3.4.13/docs
*/
public static void main(String[] args) {
try {
System.out.println("File selected is " + args[0]);
Thread[] threads = new Thread[2];
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(new FileObjectReadingThread(args[0]),
String.format("THREAD--(%d)-->",i));
threads[i].start();
}
for (int i = 0; i < threads.length; i++) {
threads[i].join(0);
}
} catch (Exception ex) {
System.out.println("Main caught " + ex.getClass().getName() + ": " +
ex.getMessage());
ex.printStackTrace(System.out);
}
}
static class FileObjectReadingThread implements Runnable {
String filePath;
FileObjectReadingThread(String pathname) {
filePath = pathname;
}
@Override
public void run() {
try {
FileSystemManager fileSystemManager = createFileSystemManager();
FileObject fileObject = fileSystemManager.resolveFile(filePath);
System.out.println("Thread " + Thread.currentThread().getName() + " " +
this + " running with FileObject " + System.identityHashCode(fileObject));
FileObject[] children = fileObject.getChildren();
for (FileObject child : children) {
if (child.getType() == FileType.FILE && child.isReadable()) {
System.out.println("Thread " + Thread.currentThread().getName() + "
" + this + " is reading " + child);
FileUtil.getContent(child);
}
Thread.sleep(1); // force a yield to other threads
}
} catch (Exception ex) {
System.out.println("Thread " + Thread.currentThread().getName() + " " +
this + " caught " + ex.getClass().getName() + ": " + ex.getMessage());
ex.printStackTrace(System.out);
}
}
private FileSystemManager createFileSystemManager() throws Exception {
DefaultFileSystemManager fileSystemManager = new
StandardFileSystemManager();
fileSystemManager.init();
return fileSystemManager;
}
}
}
{code}
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
>
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696194#comment-16696194
]
Otto Fowler commented on VFS-683:
-
The things you are dealing with here:
* Static FileSystemManager
* Threads
* Non-Thread Safe Content
* Cache
* Using the FileSystem abstractly ( not having to "know" the fs type )
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696181#comment-16696181
]
Otto Fowler commented on VFS-683:
-
I wonder if using the static vfs default manager can be an approach. So
instead of using the static, create your own per thread.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696177#comment-16696177
]
Otto Fowler commented on VFS-683:
-
Ok,
So, with your example the issue is that each time you get the tar archive input
stream, it needs to create a new stream, closing the old, so they are taking
each other out, which is because as you state the sample File object is
resolving.
In the end, the file object content and streams are not going to be thread
safe. The issue, as you thought is the cache.
Let me see what I can come up with.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696134#comment-16696134
]
Otto Fowler commented on VFS-683:
-
Thanks [~daryl.odnert], I'll take a peek and see if there is anything obvious,
that is non-usage, that can be done.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694200#comment-16694200
]
Otto Fowler commented on VFS-683:
-
As to in general... The interface for FileObject is pretty clear that there
should be only one input stream opened for any one file at any one time, at
least that is my take. It would be nice if it where more explicit from a
higher level.
You may want to send something to the commons list with a [VFS] subject.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694189#comment-16694189
]
Otto Fowler commented on VFS-683:
-
I can't speak to the intent, I'm not one of the original authors, and have only
worked with the library myself as you probably have in a couple of projects, as
well as trying to fix a couple of bugs. And I am wrong a lot ;)
Further investigation:
If you look at DefaultFileContent, it looks like we create multiple input
streams and store them per thread in thread local. And then they are closed as
such.
BUT: If this is a ZipFileObject: The java util zip library says:
{code:java}
/**
* Returns an input stream for reading the contents of the specified
* zip file entry.
*
* Closing this ZIP file will, in turn, close all input
* streams that have been returned by invocations of this method.
*
* @param entry the zip file entry
* @return the input stream for reading the contents of the specified
* zip file entry.
* @throws ZipException if a ZIP format error has occurred
* @throws IOException if an I/O error has occurred
* @throws IllegalStateException if the zip file has been closed
*/
public InputStream getInputStream(ZipEntry entry) throws IOException {
{code}
Which doesn't seem good.
Still would need to reproduce
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693974#comment-16693974
]
Otto Fowler edited comment on VFS-683 at 11/21/18 1:18 AM:
---
any kind of small sample project that can reproduce the issue would be helpful.
what the provider is, what the file is etc.
was (Author: ottobackwards):
any kind of small sample project that can reproduce the issue would be helpful.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693981#comment-16693981
]
Otto Fowler commented on VFS-683:
-
{code:java}
/**
* Returns an input stream for reading the file's content.
*
* There may only be a single input or output stream open for the file at any
time.
*
* @return An input stream to read the file's content from. The input stream is
buffered, so there is no need to
* wrap it in a {@code BufferedInputStream}.
* @throws FileSystemException If the file does not exist, or is being read, or
is being written, or on error
* opening the stream.
*/
InputStream getInputStream() throws FileSystemException;
{code}
Just from looking through things, It doesn't seem correct to have two threads
going through here.
The Resource.getBytes() call explicitly CLOSES the stream. So, it isn't
thread safe for two readers if there is only ever one stream from the same
object
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693974#comment-16693974
]
Otto Fowler commented on VFS-683:
-
any kind of small sample project that can reproduce the issue would be helpful.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto Fowler closed LANG-1373. - Resolution: Won't Fix Too complicated for lang, but the alternative of bringing back commons-monitoring is infinitely more complicated than this submittal. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16532923#comment-16532923 ] Otto Fowler commented on LANG-1373: --- oops, forgot the jira. I released this on my own > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515614#comment-16515614
]
Otto Fowler commented on VFS-398:
-
The DefaultFileSystemManager sends in the providers, see the changes to that
file.
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515103#comment-16515103
]
Otto Fowler commented on VFS-398:
-
Any chance of a review / comment / merge on this issue?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515102#comment-16515102
]
Otto Fowler commented on VFS-398:
-
PR
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-614) MonitorInputStream should not close the stream in read()
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477626#comment-16477626 ] Otto Fowler commented on VFS-614: - Yeah, I cannot close this issue, nor can I close the linked duplicated issues > MonitorInputStream should not close the stream in read() > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > Fix For: 2.2.1 > > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-614) MonitorInputStream should not close the stream in read()
[ https://issues.apache.org/jira/browse/VFS-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477589#comment-16477589 ] Otto Fowler commented on VFS-614: - [~garydgregory] although I have the linked issues assigned to me, I do not have rights to resolve them, can you resolve them? > MonitorInputStream should not close the stream in read() > > > Key: VFS-614 > URL: https://issues.apache.org/jira/browse/VFS-614 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Boris Petrov >Assignee: Otto Fowler >Priority: Critical > Fix For: 2.2.1 > > > Check the following thread for more description: > https://mail-archives.apache.org/mod_mbox/commons-user/201606.mbox/%3C90211dd5-5954-e786-e493-30187e68007b%40profuzdigital.com%3E > And the following repo with a "demo" of the bug: > https://github.com/boris-petrov/vfs-bug -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442600#comment-16442600 ] Otto Fowler commented on VFS-661: - I want to be sure I'm correct in the way you are finding and resolving the file. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442517#comment-16442517 ] Otto Fowler commented on VFS-661: - Can you post a small code sample? I want to be sure that I understand. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-661) Ability to get "real"/"native"/"physical" file name
[ https://issues.apache.org/jira/browse/VFS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441237#comment-16441237 ] Otto Fowler commented on VFS-661: - Is the issue that you can't get the real name, or that the wrong name resolves? Wouldn't the better fix be to allow on a per Provider/FS basis a setting that makes it case sensitive/insensitive? If you can 'turn it on' than it would be backward compatible. > Ability to get "real"/"native"/"physical" file name > --- > > Key: VFS-661 > URL: https://issues.apache.org/jira/browse/VFS-661 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > On case-insensitive file systems (local FS on Windows; Samba; etc) resolving > a file ignores the case that is used. For example, if there is a folder like: > *smb://localhost/share/folder* and is resolved with > *smb://localhost/share/FOLDER* it would work and return the same folder. > However, there is no method in the *FileObject* interface that allows us to > get the "real"/"physical" name of the folder - i.e. *folder*. All of the > methods would return *FOLDER* in this case. > We have a major usecase where we need that. The only solution I can think of > is getting the parent folder, going through its children and thus finding the > correct case but the performance of that would be horrible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394181#comment-16394181
]
Otto Fowler commented on VFS-398:
-
[~b.eckenfels]: Is it enough to change the DefaultFileSystemManager? any
chance you can throw a review on the PR?
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380261#comment-16380261 ] Otto Fowler commented on LANG-1373: --- I sent a mail to the list. Please comment. I'm winging it here ;) > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-654) File system events API
[ https://issues.apache.org/jira/browse/VFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380228#comment-16380228 ] Otto Fowler commented on VFS-654: - WatchEvent is very cool. The Java ( 7+) system is very similar to VFS, in that there is a provider spi for supporting file systems. I am not sure what providers are installed on what operating systems. On my mac, I only have the OSX and ZIP installed. So, to support WatchEvent for any local filesystem would seem to be possible. For other filesystems that VFS supports, it would depend on what providers where loaded, therefore these would become dependencies. INotify for hdfs could be implemented on it's own as well. Thoughts [~b.eckenfels]? > File system events API > -- > > Key: VFS-654 > URL: https://issues.apache.org/jira/browse/VFS-654 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Boris Petrov >Priority: Major > > Currently the DefaultFileMonitor walks the whole file system and notifies > when something changes. For large file systems and (near) real-time > requirements this is _extremely_ inefficient. Some file systems have an > events API which could be exposed (like *inotify*). Has any work towards that > ever been done? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379485#comment-16379485 ] Otto Fowler edited comment on LANG-1373 at 2/27/18 11:38 PM: - So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that projects current modules are for. was (Author: ottobackwards): So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that module is for. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379485#comment-16379485 ] Otto Fowler commented on LANG-1373: --- So, when I hear 'commons-testing' I think of junit, testng etc helpers, annotations, mocks, base suites etc. If you say testing is just a name ( and the fact that the first things in there are junit things is co-incidence ) then ok. We can make a module that it not for unit/integration testing, not typical mvn test scope stuff, and is for some other definition of testing. But I would find that confusing. "Testing" is a meaningful word. and it looks like that is what that module is for. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379189#comment-16379189 ] Otto Fowler commented on LANG-1373: --- [~erans], sorry, I could not find a great way to get it all working based on that bug. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379179#comment-16379179
]
Otto Fowler commented on LANG-1373:
---
By the way [~erans] [https://bugs.openjdk.java.net/browse/JDK-8130754] is the
issue i had with \{@code}
I am working on it again.
> Stopwatch based capability for nested, named, timings in a call stack
> -
>
> Key: LANG-1373
> URL: https://issues.apache.org/jira/browse/LANG-1373
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
> Labels: commons-lang,
> Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came
> across the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our
> Stellar dsl, and have have a group of related timings, such that the end
> result was the overall time of the call, and nested timings of other calls
> executed during the dsl execution of that function. These timings would all
> be named, and have a path for identification and include timing the language
> compiler/execution as well as the function execution itself. It would be
> helpful if they were tagged in some way as well, such that the consumer could
> filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it
> in a Metron PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class
> that allows callers to create multiple named and possibly nested timing
> operations.
> <…>
> This class may be more generally useful to this and other projects, but I am
> not sure where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to
> create, start and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378961#comment-16378961 ] Otto Fowler commented on LANG-1373: --- Well, this is certainly taking a turn. I don't think testing is correct for this, or stopwatch. People may want to use this in non-test builds and scenarios. I'm not sure I have a better idea, but I don't think I'd want to pull in things that I'd normally restrict to test scope into my deployments. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Assignee: Otto Fowler >Priority: Major > Labels: commons-lang, > Attachments: LANG-1373.patch > > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
