Hello all,
I am working on a flexible deployment model for Nuxeo5.
I already implemented it and now I am testing and integrating it with
nuxeo projects.
Using this model I deployed a minimal nuxeo5 application (without web
layer) -> that can be used
for remote access (from eclipse or remote tests)
There are still some problems because of the JBoss doesn't allow custom
ordering of EAR subdeployments.
There is already a discussion on this:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78376&postdays=0&postorder=asc&start=0
so I think this will be fixed in next JBoss versions
Anyway for now the deployment works thanks to NXRuntime components that
can define dependencies on other components and thus delay the component
registration until all prerequisites are meet..
One good news is that with the new deployment model the deployment.order
file and the custom URLComparator will not be needed anymore.
I will explain here how the deployment works.
The goal of the new deployment model is to have a 'real' modular
application - to be able to deploy EAR or WAR modules independently one
of each other or from the EAR / WAR container.
This means you can add a new WAR module (using the same web context)
later without modifying the existing deployed WAR.
Each deployable module is self containing its deployment information as
its requirements and what parent resources should be updated and how.
This is done by extending the JBoss EARDeployer and adding a
preprocessing step before doing the init step of the deployment
In this preprocessing step all modules that contains a
OSGI-INF/deployment-fragment.xml file are considered as deployable
fragments and
are merged into the container (the parent deployment module) by
following instructions in the fragment file.
For now only one instruction is supported: "extension" that add a
contribution to a parametrized resource from the parent container
The container should contains an OSGI-INF/deployment-container.xml file
that is defining the parametrizable resources it provides.
The resources listed here can be updated by any sub-module using a
deployment-fragment.xml file
Parametrizable resources are usually files that should be updated by
sub-modules (file templates).
The top level container is a parametrized .EAR and must have the
extension .ecm or .nux
I will give you here a simple example:
Let's say we have a parametrized EAR: nuxeo.ecm that contains the
following files:
- META-INF
- OSGI-INF
- templates
- application.xml
- jboss-app.xml
- deployment-container.xml
- NXCore.jar
- NXCore.rar
- NXDirectory.jar
The deployment-container.xml file contains the following:
<?xml version="1.0"?>
<container>
<template name="application" src="OSGI-INF/templates/application.xml"
installPath="META-INF/application.xml" required="true"/>
<template name="jboss-app" src="OSGI-INF/templates/jboss-app.xml"
installPath="META-INF/jboss-app.xml" required="true"/>
</container>
So, it declares 2 templates (parametrizable files): application and
jboss-app
These files may be updated by sub-modules and the result will be write
into a file in the location indicated by installPath.
Let's see how the application.xml file template look like:
<?xml version="1.0" encoding="UTF-8"?>
<application version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd";>
<display-name>Nuxeo5</display-name>
%{MODULE}%
</application>
The template defines one update point named MARKER. Sub-modules can use
this point to append or prepend new text inside the file
So the update mechanism is similar to the nxruntime extension points but
it works with file templates and text.
The EAR has 3 modules:
NXCore.jar
NXCore.rar
NXDirectory.jar
This is hte deployment-fragment.xml defined by NXCore.jar:
<?xml version="1.0"?>
<fragment>
<extension target="application#MODULE">
<module>
<java>NXCoreAPI.jar</java>
</module>
</extension>
</fragment>
This file tells to the deployment preprocessor that the text
<module>
<java>NXCoreAPI.jar</java>
</module>
should be inserted after (appended) the MODULE insertion point in the
"application" template
so the result of the preprocessing will be to create a file
META-INF/application.xml having the following content:
<?xml version="1.0" encoding="UTF-8"?>
<application version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd";>
<display-name>Nuxeo5</display-name>
<module>
<java>NXCoreAPI.jar</java>
</module>
</application>
Of course this is a simple example ...
I will add in future new preprocessing instructions like "copy" if needed.
Some notes:
1. If a template is marked as required it means that a file will be
created at the installPath location even if no contributions was made by
a sub-module. In this case the content of the file will be the same as
with the template file but with the marker %{MODULE}% removed.
If the template is not required and no contributions were made then it
will be ignored.
2. You can use the require tag inside a fragment to control the order
used when updating templates.
For example in this way you can control the order that EAR modules will
be appended inside application.xml
For now JBoss it is not preserving the deployment order for modules
listed inside application.xml - but I think this will be fixed in future.
Example: <require>NXCore</require>
3. You can deploy standalone fragments using an XML file ending in
-fragment.xml
Bogdan
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
