[
https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543628
]
Rick Hillegas commented on DERBY-3083:
--------------------------------------
Right now the default policy file grants permissions to the following codebases:
${derby.install.url}derby.jar
${derby.install.url}derbynet.jar
${derby.install.url}derbytools.jar
${derby.install.url}derbyclient.jar
${derby.install.url}derbytesting.jar
At boot time, the server sets the value of the derby.install.url property
before installing a SecurityManager. We could refine our codebase declarations
to something like this:
${derby.install.derby.jar.url}
${derby.install.derbynet.url}
${derby.install.derbytools.url}
${derby.install.derbyclient.url}
${derby.install.derbytesting.url}
Then the server could set the values of these properties using a heuristic like
this:
${derby.install.derby.jar.url} - the jar where EmbeddedDriver lives
${derby.install.derbynet.url} - the jar where NetworkServerControl lives
${derby.install.derbytools.url} - the jar where ij lives
${derby.install.derbyclient.url} - the jar where ClientDriver lives
${derby.install.derbytesting.url} - the jar where BaseTestCase lives
For extra credit, we could use this strategy to clean up the multiple
permission grants needed to handle sysinfo. That is, the policy file could
grant those permissions to one code base:
${derby.install.sysinfo.jar.url} - the first jar where sysinfo lives
Does this sound like an acceptable solution?
> Network server demands a file called "derbynet.jar" in classpath
> ----------------------------------------------------------------
>
> Key: DERBY-3083
> URL: https://issues.apache.org/jira/browse/DERBY-3083
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.3.1.4
> Reporter: Aaron Digulla
> Attachments: derby-716-10-datatypesCollation-aa.diff
>
>
> The network server will not start if the derbynet jar is added under a
> different name than "derbynet.jar" to the classpath. This makes it impossible
> to use it in maven projects where the jar is renamed to
> "derbynet-10.3.1.4.jar".
> This did work with 10.2.2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
