[Phoenix] Breaking apart environment.xml

[Peter Donald <pe...@realityforge.org>]

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [Phoenix] Breaking apart environment.xml

[Ulrich Mayring <ul...@mayring.de>]

Peter Donald wrote:
> 
> 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 ;)

I can't speak for other users, but I personally don't mind when
something is changed for the better if it is documented properly. By
that I mean that it is explained exactly how the new system works and
what should be done to an old application to make it work with the new
system. In other words:

Something doesn't work anymore and I don't know why: -1

Something continues to work and I don't know why (i.e. the change was
backwards compatible, but I don't know about the new feature): -0

Something doesn't work anymore, but I know why and what to do about it: +0

Something continues to work (backwards compatible change) and I know
what I have to do to make it work even better (using the new feature): +1

Ulrich


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

Re: [Phoenix] Breaking apart environment.xml

[Peter Royal <pr...@apache.org>]

On Saturday, March 1, 2003, at 05:15  AM, Peter Donald wrote:
> 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.

+1
-pete


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