[ https://issues.apache.org/jira/browse/DERBY-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520824#comment-17520824 ]
Richard N. Hillegas commented on DERBY-7138: -------------------------------------------- Attaching org.apache.derbyTesting.functionTests.tests.derbynet.Z. This test demonstrates the following: 1) When you bring up a Derby JUnit test with a SecurityManager, then the NetworkServerControl.getMaxThreads() method behaves correctly, regardless of whether you create the NetworkServerControl with host set to the loopback address InetAddress.getByName("localhost") or with host set to the real host name InetAddress.getLocalHost(). 2) However, when you bring up the test WITHOUT a SecurityManager, then NetworkServerControl.getMaxThreads() fails with a "Connection refused" exception if you create the NetworkServerControl with the real host name InetAddress.getLocalHost(). I tripped across this behavior in NetworkServerControlApiTest.test_04_MaxThreads_0() when I changed the test to NOT bring up a SecurityManager. Maybe this behavior is caused by something environmental on my machine. I am also attaching DerbyServerTest. This program demonstrates that NetworkServerControl.getMaxThreads() behaves correctly provided that the server is started with the same host that was used to instantiate NetworkServerControl. For the record, at my current location InetAddress.getByName("localhost") is host localhost/127.0.0.1 and InetAddress.getByName("localhost") is host Richards-MacBook-Pro-3.local/10.0.0.125 My inclination is to change NetworkServerControlApiTest so that it creates NetworkServerControl with the loopback address InetAddress.getByName("localhost"). > Remove references to the Java Security Manager > ---------------------------------------------- > > Key: DERBY-7138 > URL: https://issues.apache.org/jira/browse/DERBY-7138 > Project: Derby > Issue Type: Task > Components: Build tools, Documentation > Affects Versions: 10.16.0.0 > Reporter: Richard N. Hillegas > Assignee: Richard N. Hillegas > Priority: Major > Attachments: DerbyServerTest.java, Z.java, > derby-7138-01-aa-removeSecurityManagerFromOldHarnessTests.diff, > derby-7138-02-ab-moveMethodsToTestConfiguration.diff, > derby-7138-03-aa-removePermissionsTests.diff > > > The Open JDK team has deprecated the Java Security Manager and indicated that > it will be removed in a future release of Java. See > https://openjdk.java.net/jeps/411. In an email thread titled "protecting > security-sensitive operations on multi-tenant servers" on the > security-...@openjdk.java.net mailing list, Alan Bateman indicated that > developers should containerize their applications instead. > This issue tracks work needed to remove Derby's references to the Java > Security Manager. > At a minimum, the following work needs to be done: > o The tests should be adjusted so that they don't install a SecurityManager. > o References to the SecurityManager should be removed from product code. > o We should remove the SecurityManager section of the Derby Security Guide. > In its place, we should recommend that developers containerize their Derby > applications. -- This message was sent by Atlassian Jira (v8.20.1#820001)