loom

Deploy via XML descriptors

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: future
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

t would be useful to have Loom 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 Loom 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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
peter royal added a comment -

I think it would be useful to specify the resources in a separate file. the idea being that once created, the "application definition" file wouldn't need to change

Show
peter royal added a comment - I think it would be useful to specify the resources in a separate file. the idea being that once created, the "application definition" file wouldn't need to change
Hide
Permalink
peter royal added a comment -

Resources could be something like:

<contents>
<jar name="jetty" version="4.1.2" forBlock="jetty-sevak"/>
<resource name="my-webapp" version="1.0" mount="webapps/my-webapp"/>
<resource name="static-content" version="1.0" mount="htdocs"/>
</contents>

where <jar> entries reference classpath entries (probably need to deal with a ClassLoader tree somewhere, but might be able to hide that complexity), and the <resource> entries declare the content that lives outside of SAR-INF in the current model.

a forBlock attribute on the <jar> can associate a jar with a specific block, and if that jar is updated, trigger a redeploy of that block.

Show
peter royal added a comment - Resources could be something like: <contents> <jar name="jetty" version="4.1.2" forBlock="jetty-sevak"/> <resource name="my-webapp" version="1.0" mount="webapps/my-webapp"/> <resource name="static-content" version="1.0" mount="htdocs"/> </contents> where <jar> entries reference classpath entries (probably need to deal with a ClassLoader tree somewhere, but might be able to hide that complexity), and the <resource> entries declare the content that lives outside of SAR-INF in the current model. a forBlock attribute on the <jar> can associate a jar with a specific block, and if that jar is updated, trigger a redeploy of that block.
Hide
Permalink
Peter Donald added a comment -

I don' think resources as specified in this file are relevent anymore. They were primarily focused on exporting container oriented services into the Context but if our path forward is to place all services into ServiceMnagaer/ResourceLocator then this no longer seems relevent. The kernel resources/services can be mapped in from the assembly.xml using some special syntax.

Show
Peter Donald added a comment - I don' think resources as specified in this file are relevent anymore. They were primarily focused on exporting container oriented services into the Context but if our path forward is to place all services into ServiceMnagaer/ResourceLocator then this no longer seems relevent. The kernel resources/services can be mapped in from the assembly.xml using some special syntax.
Hide
Permalink
Peter Donald added a comment -

Are you aware that you can already define the location of all your jars/class dirs and which classloaders they are loaded into via the classloader configuration stuff ClassMan. I would point you at a config file but sourceforge is down again.

Show
Peter Donald added a comment - Are you aware that you can already define the location of all your jars/class dirs and which classloaders they are loaded into via the classloader configuration stuff ClassMan. I would point you at a config file but sourceforge is down again.
Hide
Permalink
peter royal added a comment -

agreed,the original <resources> can be lost. i just need to deal with non-java code that can live in the SAR.

I found the ClassMan example: http://spice.sourceforge.net/classman/sample.html

At what level (if at all) has this been integrated into loom? i can see each block having two classloaders, one for its API the other for its implementation + dependent classes.. and each block getting a join'd classloader containing the api of all of its dependencies.

Can ClassMan be introspected to see what jars are associated with each ClassLoader so that hot-redeploy of classes can be done?

Show
peter royal added a comment - agreed,the original <resources> can be lost. i just need to deal with non-java code that can live in the SAR. I found the ClassMan example: http://spice.sourceforge.net/classman/sample.html At what level (if at all) has this been integrated into loom? i can see each block having two classloaders, one for its API the other for its implementation + dependent classes.. and each block getting a join'd classloader containing the api of all of its dependencies. Can ClassMan be introspected to see what jars are associated with each ClassLoader so that hot-redeploy of classes can be done?
Hide
Permalink
Peter Donald added a comment -

The ClassMan toolkit config is integrated into environment.xml via classloaders tag IIRC. It seems to work well and supports enough that I can have servlet-api unable to see phoenix-api except both aggregated for block loading.

However LOOM-7 has not been integrated which is essentially allowing blocks to have different classloader but now they all use the default classloader.

Show
Peter Donald added a comment - The ClassMan toolkit config is integrated into environment.xml via classloaders tag IIRC. It seems to work well and supports enough that I can have servlet-api unable to see phoenix-api except both aggregated for block loading. However LOOM-7 has not been integrated which is essentially allowing blocks to have different classloader but now they all use the default classloader.

People

  • Assignee:
    Unassigned
    Reporter:
    Mauro Talevi
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: