[jira] Commented: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506670 ] Oliver Heger commented on CONFIGURATION-281: I did some testing and could reproduce the problem with mock objects. 1) fixed the problem, assuming that the involved Context objects have a meaningful implementation of equals() and hashCode(). Why would 2) be necessary in addition to 1)? JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506696 ] Michiel Kalkman commented on CONFIGURATION-281: --- Cool, thanks. I guess #2 is less important, and therefore not necessary, however I just thought that adding maxDepth might reduce the max size of a jndi context tree, and therefore reduce the nr of keys that are returned. Just in case some app decides to be creative with jndi contexts. JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
