I am not a participant in the [launcher] project at Jakarta Commons, but if I were, I would vote against such a proposal on general principles -- dependence on behavior like this is *incredibly* fragile, and is pretty much guaranteed to break the next time someone tweaks your persistence strategy (or you upgrade to a new JVM that iterates HashMap keys in a different order ... :-).
By far the better strategy would be to arrange the lifecycle of your service objects so that they had (at least) two phases: * Configuration -- property settings can occur in any desired order. This is really critical if you expect your component to be supported by development tools, and is required for maintainability even if you do not care about tools support. * Lifecycle -- some sort of a start() method that is guaranteed to not be invoked until *after* all the relevant properties have been set from the configuration information. Even if you can craft an order-dependent solution now, you are really going to kick yourself in the rear end a year from now -- my strong recommendation is to avoid that kind of pain and embarrasement :-), and start with a strategy that is scalable over the long term. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
