commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <>
Subject [jira] Resolved: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
Date Thu, 21 Jun 2007 20:02:26 GMT


Oliver Heger resolved CONFIGURATION-281.

    Resolution: Fixed

A fix was applied. Please check if this works for you.

When I find the time I would like to improve JNDIConfiguration: make it a true hierarchical
configuration, support updates of the JNDI tree, etc. This would be a good opportunity for
adding a maxDepth property.

> JNDIConfiguration::recursiveGetKeys goes out of stack
> -----------------------------------------------------
>                 Key: CONFIGURATION-281
>                 URL:
>             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:
For additional commands, e-mail:

View raw message