[
https://issues.apache.org/jira/browse/DERBY-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925197#action_12925197
]
Dag H. Wanvik commented on DERBY-4815:
--------------------------------------
Looks right to me. +1
> Override mechanism for modules.properties works backwards
> ---------------------------------------------------------
>
> Key: DERBY-4815
> URL: https://issues.apache.org/jira/browse/DERBY-4815
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.6.1.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: d4815.diff
>
>
> It is possible to override the properties in
> org/apache/derby/modules.properties by putting your own version of it
> somewhere on the classpath. BaseMonitor.getDefaultModuleProperties()
> apparently intends to use values from the first modules.properties file that
> mentions a property:
> String key = (String) newKeys.nextElement();
> if( moduleList.contains( key))
> // RESOLVE how do we localize messages before
> we have finished initialization?
> report( "Ignored duplicate property " + key +
> " in " + modulesPropertiesURL.toString());
> else
> moduleList.setProperty( key,
> otherList.getProperty( key));
> However, moduleList.contains(key) doesn't look for a key in moduleList, it
> looks for a property value. This code should have used containsKey() instead.
> Beacuse of this, the last modules.properties on the classpath will take
> precedence over the ones earlier on the classpath. So if you for example have
> two different versions of derby.jar in the classpath, the engine will use the
> classes from the first jar and modules.properties from the last jar.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
