[
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]
