Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-23 Thread Xeno Amess
I put it in dev-list because I really donot know wether it be a bug or not.
If it be a but then I'm actually willing for help.
But it seems by design but not a bug here, so I apologize.
Still, some questions hold.

/**
 * Returns a URL representing this file.
 *
 * @return the URL for the file.
 * @throws FileSystemException if an error occurs.
 */
URL getURL() throws FileSystemException;
that is the comments on getURL()
And IMO that is quite confusing actually.
You see if we use the same URL class and return it in such a public
method, it be normally to think it fit Java's standard, and can use
.URI if the protocol should be able to.
But the truth is the standard we used in vfs is sometimes different than Java.
The word [Sometimes] here is very dangerous and might be a bug causer,
because it can pass most tests and make users feel "Oh, it just return
a normal URL, and it really works right."
So IMO at least we shall add some more warning about "not using this
returned URL's some functions,including to URL, they might be
dangerous" or "we use different standard about file:// than Java's
file://"

Besides, I wonder why we must use a same URL class in vfs, if we
cannot guarantee it works consistently to Java lib?
Is it a better thought to create a new VFSURL class for URL in vfs?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-23 Thread Bernd Eckenfels
Hello,

I am not sure I understand what the actual difference is, but you are right, 
the URL should actually be useable. However there are a lot of inconsistencies 
and backward compatibilities to look out for (even File itself has different 
URL/URI methods and never defined how Windows drives are to be handled). So can 
you give us an example path and what it looks like in URL from VFS and from 
java.io, so we can check if there is something to tweak.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Xeno Amess 
Gesendet: Thursday, January 23, 2020 2:40:59 PM
An: Commons Developers List 
Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about 
commons-vfs2 make me confused.)

I put it in dev-list because I really donot know wether it be a bug or not.
If it be a but then I'm actually willing for help.
But it seems by design but not a bug here, so I apologize.
Still, some questions hold.

/**
 * Returns a URL representing this file.
 *
 * @return the URL for the file.
 * @throws FileSystemException if an error occurs.
 */
URL getURL() throws FileSystemException;
that is the comments on getURL()
And IMO that is quite confusing actually.
You see if we use the same URL class and return it in such a public
method, it be normally to think it fit Java's standard, and can use
.URI if the protocol should be able to.
But the truth is the standard we used in vfs is sometimes different than Java.
The word [Sometimes] here is very dangerous and might be a bug causer,
because it can pass most tests and make users feel "Oh, it just return
a normal URL, and it really works right."
So IMO at least we shall add some more warning about "not using this
returned URL's some functions,including to URL, they might be
dangerous" or "we use different standard about file:// than Java's
file://"

Besides, I wonder why we must use a same URL class in vfs, if we
cannot guarantee it works consistently to Java lib?
Is it a better thought to create a new VFSURL class for URL in vfs?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-23 Thread Xeno Amess
Collector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at
org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:248)
at
org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$5(DefaultLauncher.java:211)
at
org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
at
com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)


Process finished with exit code 0

We can skip the log4j part, then you can see, the url parser in javaio
cannot deal with " ", and " " must be transcoded to "%20", and if not do so
in URL, then url.toURI() will fail.



Bernd Eckenfels  于2020年1月24日周五 上午4:21写道:

> Hello,
>
> I am not sure I understand what the actual difference is, but you are
> right, the URL should actually be useable. However there are a lot of
> inconsistencies and backward compatibilities to look out for (even File
> itself has different URL/URI methods and never defined how Windows drives
> are to be handled). So can you give us an example path and what it looks
> like in URL from VFS and from java.io, so we can check if there is
> something to tweak.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________
> Von: Xeno Amess 
> Gesendet: Thursday, January 23, 2020 2:40:59 PM
> An: Commons Developers List 
> Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about
> commons-vfs2 make me confused.)
>
> I put it in dev-list because I really donot know wether it be a bug or not.
> If it be a but then I'm actually willing for help.
> But it seems by design but not a bug here, so I apologize.
> Still, some questions hold.
>
> /**
>  * Returns a URL representing this file.
>  *
>  * @return the URL for the file.
>  * @throws FileSystemException if an error occurs.
>  */
> URL getURL() throws FileSystemException;
> that is the comments on getURL()
> And IMO that is quite confusing actually.
> You see if we use the same URL class and return it in such a public
> method, it be normally to think it fit Java's standard, and can use
> .URI if the protocol should be able to.
> But the truth is the standard we used in vfs is sometimes different than
> Java.
> The word [Sometimes] here is very dangerous and might be a bug causer,
> because it can pass most tests and make users feel "Oh, it just return
> a normal URL, and it really works right."
> So IMO at least we shall add some more warning about "not using this
> returned URL's some functions,including to URL, they might be
> dangerous" or "we use different standard about file:// than Java's
> file://"
>
> Besides, I wonder why we must use a same URL class in vfs, if we
> cannot guarantee it works consistently to Java lib?
> Is it a better thought to create a new VFSURL class for URL in vfs?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-23 Thread Xeno Amess
ne.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:248)
> at
> org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$5(DefaultLauncher.java:211)
> at
> org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
> at
> com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
>
>
> Process finished with exit code 0
>
> We can skip the log4j part, then you can see, the url parser in javaio
> cannot deal with " ", and " " must be transcoded to "%20", and if not do so
> in URL, then url.toURI() will fail.
>
>
>
> Bernd Eckenfels  于2020年1月24日周五 上午4:21写道:
>
>> Hello,
>>
>> I am not sure I understand what the actual difference is, but you are
>> right, the URL should actually be useable. However there are a lot of
>> inconsistencies and backward compatibilities to look out for (even File
>> itself has different URL/URI methods and never defined how Windows drives
>> are to be handled). So can you give us an example path and what it looks
>> like in URL from VFS and from java.io, so we can check if there is
>> something to tweak.
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Xeno Amess 
>> Gesendet: Thursday, January 23, 2020 2:40:59 PM
>> An: Commons Developers List 
>> Betreff: Re: Getting File of FileObject (was: some questions (/bug?)
>> about commons-vfs2 make me confused.)
>>
>> I put it in dev-list because I really donot know wether it be a bug or
>> not.
>> If it be a but then I'm actually willing for help.
>> But it seems by design but not a bug here, so I apologize.
>> Still, some questions hold.
>>
>> /**
>>  * Returns a URL representing this file.
>>  *
>>  * @return the URL for the file.
>>  * @throws FileSystemException if an error occurs.
>>  */
>> URL getURL() throws FileSystemException;
>> that is the comments on getURL()
>> And IMO that is quite confusing actually.
>> You see if we use the same URL class and return it in such a public
>> method, it be normally to think it fit Java's standard, and can use
>> .URI if the protocol should be able to.
>> But the truth is the standard we used in vfs is sometimes different than
>> Java.
>> The word [Sometimes] here is very dangerous and might be a bug causer,
>> because it can pass most tests and make users feel "Oh, it just return
>> a normal URL, and it really works right."
>> So IMO at least we shall add some more warning about "not using this
>> returned URL's some functions,including to URL, they might be
>> dangerous" or "we use different standard about file:// than Java's
>> file://"
>>
>> Besides, I wonder why we must use a same URL class in vfs, if we
>> cannot guarantee it works consistently to Java lib?
>> Is it a better thought to create a new VFSURL class for URL in vfs?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>


Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-24 Thread Bernd Eckenfels
Hello,

I think FileObject#getURL() suffers from the same(similar) encoding problems as 
File#toURL did. It proofed to be hard to change file, so we should I guess not 
do it for FileObject:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=61794

One option would be to add a FileObject#getURI()?

Having said that, I would still use new 
File(FileObject.getName().getPathDecoded()) instead.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Xeno Amess 
Gesendet: Thursday, January 23, 2020 11:45:21 PM
An: Commons Developers List 
Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about 
commons-vfs2 make me confused.)

class org.apache.commons.httpclient.HttpClient
interface org.apache.jackrabbit.webdav.client.methods.DavMethod
log4j: Parsing for [root] with value=[DEBUG,DEBUG_LOG,ERROR_LOG].
log4j: Level token is [DEBUG].
log4j: Category root set to DEBUG
log4j: Parsing appender named "DEBUG_LOG".
log4j: Parsing layout options for "DEBUG_LOG".
log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
%t:%r ] - [ %p ]  %m%n].
log4j: End of parsing for "DEBUG_LOG".
log4j: Setting property [threshold] to [DEBUG].
log4j: Setting property [file] to [logs/logs.log].
log4j: Setting property [append] to [true].
log4j: setFile called: logs/logs.log, true
log4j: setFile ended
log4j: Appender [DEBUG_LOG] to be rolled at midnight.
log4j: Parsed "DEBUG_LOG" options.
log4j: Parsing appender named "ERROR_LOG".
log4j: Parsing layout options for "ERROR_LOG".
log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
%t:%r ] - [ %p ]  %m%n].
log4j: End of parsing for "ERROR_LOG".
log4j: Setting property [file] to [logs/error.log].
log4j: Setting property [threshold] to [ERROR].
log4j: Setting property [append] to [true].
log4j: setFile called: logs/error.log, true
log4j: setFile ended
log4j: Appender [ERROR_LOG] to be rolled at midnight.
log4j: Parsed "ERROR_LOG" options.
log4j: Finished configuring.
File : file:/D:/1%201.txt
FileObject : file:///D:/1 1.txt
D:\1 1.txt
java.net.URISyntaxException: Illegal character in path at index 12:
file:///D:/1 1.txt
at java.base/java.net.URI$Parser.fail(URI.java:2936)
at java.base/java.net.URI$Parser.checkChars(URI.java:3107)
at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3189)
at java.base/java.net.URI$Parser.parse(URI.java:3137)
at java.base/java.net.URI.(URI.java:623)
at java.base/java.net.URL.toURI(URL.java:1048)
at FileManagerTest.test(FileManagerTest.java:66)
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:567)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:205)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:201)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:137)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescripto

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-24 Thread Xeno Amess
File(FileObject.getName().getPathDecoded())

yep I use this now.
it works correctly(at least in my usecase)

Bernd Eckenfels  于 2020年1月24日周五 下午5:02写道:

> Hello,
>
> I think FileObject#getURL() suffers from the same(similar) encoding
> problems as File#toURL did. It proofed to be hard to change file, so we
> should I guess not do it for FileObject:
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=61794
>
> One option would be to add a FileObject#getURI()?
>
> Having said that, I would still use new
> File(FileObject.getName().getPathDecoded()) instead.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Xeno Amess 
> Gesendet: Thursday, January 23, 2020 11:45:21 PM
> An: Commons Developers List 
> Betreff: Re: Getting File of FileObject (was: some questions (/bug?) about
> commons-vfs2 make me confused.)
>
> class org.apache.commons.httpclient.HttpClient
> interface org.apache.jackrabbit.webdav.client.methods.DavMethod
> log4j: Parsing for [root] with value=[DEBUG,DEBUG_LOG,ERROR_LOG].
> log4j: Level token is [DEBUG].
> log4j: Category root set to DEBUG
> log4j: Parsing appender named "DEBUG_LOG".
> log4j: Parsing layout options for "DEBUG_LOG".
> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
> %t:%r ] - [ %p ]  %m%n].
> log4j: End of parsing for "DEBUG_LOG".
> log4j: Setting property [threshold] to [DEBUG].
> log4j: Setting property [file] to [logs/logs.log].
> log4j: Setting property [append] to [true].
> log4j: setFile called: logs/logs.log, true
> log4j: setFile ended
> log4j: Appender [DEBUG_LOG] to be rolled at midnight.
> log4j: Parsed "DEBUG_LOG" options.
> log4j: Parsing appender named "ERROR_LOG".
> log4j: Parsing layout options for "ERROR_LOG".
> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}  [
> %t:%r ] - [ %p ]  %m%n].
> log4j: End of parsing for "ERROR_LOG".
> log4j: Setting property [file] to [logs/error.log].
> log4j: Setting property [threshold] to [ERROR].
> log4j: Setting property [append] to [true].
> log4j: setFile called: logs/error.log, true
> log4j: setFile ended
> log4j: Appender [ERROR_LOG] to be rolled at midnight.
> log4j: Parsed "ERROR_LOG" options.
> log4j: Finished configuring.
> File : file:/D:/1%201.txt
> FileObject : file:///D:/1 1.txt
> D:\1 1.txt
> java.net.URISyntaxException: Illegal character in path at index 12:
> file:///D:/1 1.txt
> at java.base/java.net.URI$Parser.fail(URI.java:2936)
> at java.base/java.net.URI$Parser.checkChars(URI.java:3107)
> at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3189)
> at java.base/java.net.URI$Parser.parse(URI.java:3137)
> at java.base/java.net.URI.(URI.java:623)
> at java.base/java.net.URL.toURI(URL.java:1048)
> at FileManagerTest.test(FileManagerTest.java:66)
> 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:567)
> at
>
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
> at
>
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
>
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
>
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
>
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
>
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
>
> or

Re: Getting File of FileObject (was: some questions (/bug?) about commons-vfs2 make me confused.)

2020-01-24 Thread Xeno Amess
also suggest adding come comments for toURL to aware users of this problem.

Xeno Amess  于 2020年1月24日周五 下午5:51写道:

> File(FileObject.getName().getPathDecoded())
>
> yep I use this now.
> it works correctly(at least in my usecase)
>
> Bernd Eckenfels  于 2020年1月24日周五 下午5:02写道:
>
>> Hello,
>>
>> I think FileObject#getURL() suffers from the same(similar) encoding
>> problems as File#toURL did. It proofed to be hard to change file, so we
>> should I guess not do it for FileObject:
>>
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=61794
>>
>> One option would be to add a FileObject#getURI()?
>>
>> Having said that, I would still use new
>> File(FileObject.getName().getPathDecoded()) instead.
>>
>> Gruss
>> Bernd
>>
>>
>> --
>> http://bernd.eckenfels.net
>> ____________
>> Von: Xeno Amess 
>> Gesendet: Thursday, January 23, 2020 11:45:21 PM
>> An: Commons Developers List 
>> Betreff: Re: Getting File of FileObject (was: some questions (/bug?)
>> about commons-vfs2 make me confused.)
>>
>> class org.apache.commons.httpclient.HttpClient
>> interface org.apache.jackrabbit.webdav.client.methods.DavMethod
>> log4j: Parsing for [root] with value=[DEBUG,DEBUG_LOG,ERROR_LOG].
>> log4j: Level token is [DEBUG].
>> log4j: Category root set to DEBUG
>> log4j: Parsing appender named "DEBUG_LOG".
>> log4j: Parsing layout options for "DEBUG_LOG".
>> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}
>> [
>> %t:%r ] - [ %p ]  %m%n].
>> log4j: End of parsing for "DEBUG_LOG".
>> log4j: Setting property [threshold] to [DEBUG].
>> log4j: Setting property [file] to [logs/logs.log].
>> log4j: Setting property [append] to [true].
>> log4j: setFile called: logs/logs.log, true
>> log4j: setFile ended
>> log4j: Appender [DEBUG_LOG] to be rolled at midnight.
>> log4j: Parsed "DEBUG_LOG" options.
>> log4j: Parsing appender named "ERROR_LOG".
>> log4j: Parsing layout options for "ERROR_LOG".
>> log4j: Setting property [conversionPattern] to [%-d{-MM-dd HH:mm:ss}
>> [
>> %t:%r ] - [ %p ]  %m%n].
>> log4j: End of parsing for "ERROR_LOG".
>> log4j: Setting property [file] to [logs/error.log].
>> log4j: Setting property [threshold] to [ERROR].
>> log4j: Setting property [append] to [true].
>> log4j: setFile called: logs/error.log, true
>> log4j: setFile ended
>> log4j: Appender [ERROR_LOG] to be rolled at midnight.
>> log4j: Parsed "ERROR_LOG" options.
>> log4j: Finished configuring.
>> File : file:/D:/1%201.txt
>> FileObject : file:///D:/1 1.txt
>> D:\1 1.txt
>> java.net.URISyntaxException: Illegal character in path at index 12:
>> file:///D:/1 1.txt
>> at java.base/java.net.URI$Parser.fail(URI.java:2936)
>> at java.base/java.net.URI$Parser.checkChars(URI.java:3107)
>> at java.base/java.net.URI$Parser.parseHierarchical(URI.java:3189)
>> at java.base/java.net.URI$Parser.parse(URI.java:3137)
>> at java.base/java.net.URI.(URI.java:623)
>> at java.base/java.net.URL.toURI(URL.java:1048)
>> at FileManagerTest.test(FileManagerTest.java:66)
>> 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:567)
>> at
>>
>> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
>> at
>>
>> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>> at
>>
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
>> at
>>
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
>> at
>>
>> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
>> at
>>
>> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(Executa