[
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
> [email protected] 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)
