DO NOT REPLY [Bug 12403] New: - Deploy via XML descriptors

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12403>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12403

Deploy via XML descriptors

           Summary: Deploy via XML descriptors
           Product: Avalon
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Phoenix
        AssignedTo: avalon-phoenix-dev@jakarta.apache.org
        ReportedBy: donaldp@apache.org


It would be useful to have Phoenix scan the apps directory and deploy 
applications from xml descriptors as well as the .sar files. The xml descriptor 
could specify all the required parameters for an application rather than having 
Phoenix deduce them from the .sar file. 

For example it could look something like

<application name="foo" protected="true">
  <homeDirectory>/some/dir</homeDirectory>
  <workDirectory>/tmp</workDirectory>
  <assembly>/opt/myapp/assembly.xml</assembly>
  <config>/opt/myapp/config.xml</config>
  <environment>/opt/myapp/environment.xml</environment>

  <resources>
    <!-- map some container resources into 
         blocks context -->
    <resource key="keyUsedByBlocks" 
              name="nameInKernel"
              type="javax.jmx.MBeanServer"/>
  <resources>

  <!-- see excalibur-loader project for format of this -->
  <classpath ... />
</application> 

The deployer would then handle either xml files or .sar files.

The advantage of this would be that it makes it easy to allow alternative 
deployment formats which is useful when you are developing an IDE and don't 
want to rebuild sar in each development cycle. It is also useful when 
integrating with existing systems that have particular filesystem requirements.


For an example system that implements something like this have a look at the 
Tomcat 4.1 product.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>