Replacing default FileSystemProvider
Michael Hall
mik3hall at gmail.com
Sun Mar 28 16:40:12 UTC 2021
> On Mar 28, 2021, at 10:17 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 28/03/2021 15:44, Michael Hall wrote:
>>
>> Simple reproducing test case…
>>
>> import org.apache.hc.client5.http.impl.classic.HttpClientBuilder;
>> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient;
>>
>> public class TestREST {
>>
>>
>> public static void main(String[] args) {th
>> try (CloseableHttpClient client = HttpClientBuilder.create().build();) {
>> }
>> catch (ClassCastException cce) {
>> System.out.println("as cce");
>> cce.printStackTrace();
>> }
>> catch (java.io.IOException ioex) {
>> System.out.println("as ioex");
>> }
>> }
>> }
>>
> My guess is that this CCE is due to somewhere in the custom file system provider that isn't wrapping or unwrapping consistently. I've run several tests based on the TestProvider that I linked to and I couldn't duplicate the issue.
>
> The SO post that you linked to seems to be something else. The cryptographic jurisdiction policy defaults to "unlimited" since JDK 9 so I wouldn't expect any issues there, unless conf/security/java.security has been changed to set crypto.policy to "limited" and I doubt that is the case.
>
> -Alan.
Could be difficult to track down if I’m letting a Unix through. I’m not quite sure how since that isn’t even the platform provider. But I’ll try to figure it out.
It looks like UnixPath is the only builtin Path implementation present. No MacOSX or Bsd. So it would have to be somewhere I defer to platform that instantiates or returns a Path instance I would guess.
The SO I indicated just ended up with an identical result when it couldn’t access files in the conf directory. I think mine is the same in that regard. I think somehow in HttpClient trying to access something in that directory the CCE is thrown.
Thanks for the reply and confirmation you didn’t reproduce.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210328/c2e3dcb2/attachment.htm>
More information about the nio-dev
mailing list