Configuration is not now, nor ever has been meant as a replacement for DOM/JDOM/etc. Please take the time to look through the archives (you might have to go as far back as 2000), and you will see all the arguments for and against Configuration providing access to a parent.
There are other ways of accomplishing what you want to accomplish than messing with the current Configuration contracts. An alteration of current contracts requires more justification than "it would make my life easier" because it affects existing code. Existing code makes assumptions based on the contract in affect at the time. If a contract change as fundamental as this is made, an existing system has to change its codebase to protect against a type of attack that was not previously available at the time. That is another reason for my -1 of the proposed change. If you want to be able to traverse up and down the heirarchy, use a DOM based API--not Configuration. In order to incorporate that into your system, you need to use the Extension mechanism that is the same between Fortress and Merlin in your code. I personally don't see the advantage of using a full DOM based approach for configuration information. I will need some convincing. If we do need a full DOM based approach, then we use JDOM or something similarly easy to use but do not change existing contracts with the configuration object. > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > > As far as I can see, the proposal violates Avalon's IoC/SoC > patterns. The > code providing the Configuration is supposed to have control > and knowledge > over what it is providing. IF it wants to provide parent > information, it > can. > > On another line of reasoning, I think it is safer (and more > consistent) for > it to explicitly provide what it wants, than to need to deny. > For example, > consider schema evolution. I might not have confidential > information in a > parent configuration at the moment, so I might not think of > preventing the > parent from being accessed. I might not remember, in the > future, when I add > confidential information. On the other hand, if I am > explicitly passing the > configuration as part of the contract, then I am more likely > to be aware of > the issue. > > --- Noel > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
