[jira] Commented: (PNIX-10) Break apart Environment.xml

[ji...@codehaus.org]

The following comment has been added to this issue:

     Author: Mauro Talevi
    Created: Sat, 22 Mar 2003 2:10 PM
       Body:
Having separate files is preferable in many respects. 
It also clarifies better the scope of each file.  Environment is 
probably too generic in scope and name. 
Also having schemas for each file add to user understanding. 
And having not to define or write files for scopes (eg classloader or
policy) that are not needed is good - provided that it is well documented that they have the option to do so. 

---------------------------------------------------------------------
View the issue:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=PNIX-10


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: PNIX-10
    Summary: Break apart Environment.xml
       Type: Improvement

     Status: Assigned
   Priority: Major

 Time Spent: Unknown
   Estimate: 0 minutes

    Project: phoenix
 Components: 
             Deployment Archive Format
   Fix Fors:
             4.1
   Versions:
             4.1

   Assignee: Peter Donald
   Reporter: Peter Donald

    Created: Sat, 22 Mar 2003 12:24 AM
    Updated: Sat, 22 Mar 2003 12:24 AM

Description:
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.

See thread: http://marc.theaimsgroup.com/?t=104651287700002&r=1&w=2


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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