Hi, While writing the last email an old thought came back to me. Currently we store all sorts of stuff in environment.xml like policy definition, classloader definition, logging definition etc. And in the future it is conceivable that we will be including things like interceptor definitions, management declarations etc.
So what I was thinking is that we could break each aspect out into a separate file. At the moment that would mean files such as SAR-INF/logging.xml SAR-INF/classloaders.xml SAR-INF/policy.xml We could do it in a backwards compatabile fashion by first scanning environment.xml before looking for new config files. In most applications these configuration files can simply be ommitted and default values will be supplied (much like is done now). So no need to specify SAR-INF/classloaders.xml or SAR-INF/policy.xml unless you really want to define them. The advantages of this approach is that the configuration files become much much easier to validate using Schemas/DTDs as the config files are not mixed. It is also more future proof as we can simply add new config files as we need them if a new aspect warrants it. I can't see any disadvantages except that it is a change. However if we support the old format for a year or more we should not disrupt any users ... hopefully ;) -- Cheers, Peter Donald *------------------------------------------------* | Those who know how to think need no teachers. | | - Gandhi | *------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
