You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2004/02/15 12:20:53 UTC

DO NOT REPLY [Bug 26534] - JNDIConfiguration and union configuration

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26534>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26534

JNDIConfiguration and union configuration

epugh@upstate.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED



------- Additional Comments From epugh@upstate.com  2004-02-15 11:20 -------
Oliver,

I fixed the immediate bug that makes this fail.  However, I have another 
question.  When loading the configuration from the Configuration Factory, it 
seems like the underlying configs are NOT preserved, but instead a new 
CompositeConfig is made from their values:
 CompositeConfiguration cc = (CompositeConfiguration)config;
        // Currently fails, should be 4?  Only 2?
        //assertEquals(4,cc.getNumberOfConfigurations());

This I think could be a problem because if I add a config that doesn't load 
all the values at startup time, but instead at runtime, then it will miss 
values.  I think that is why the JNDIConfiguration value never makes it in:
    // Fails, because we don't seem to reach the underlying 
JNDIConfiguraiton        
        //assertNotNull(config.getProperty("test.boolean"));

Becasue there is no JNDIConfiguration object left..

Maybe this is okay, but we need to define explicitly in the docs that 
configuration values are looked up and stored at startup time, not at runtime..

I have committed the files, so the unit tests (except the commented out ones) 
pass.

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org