The upcoming 5.4 releases of Nuxeo EP and DM will support JBoss AS 5.1 as well as JBoss EAP 5.0.1. In addition to the existing dynamic deployment mode, this version of Nuxeo now supports a standard JEE deployment as a standalone EAR on JBoss 5.
But before explaining what has changed, we need to briefly explain how Nuxeo Deployment works.
Dynamic and Modular Nuxeo Deployment
Basically, it means that the Nuxeo application (EAR or WAR) is not a monolithic application:
you can download additional plugins that will provide new screens and new features
you can download customization packages from Nuxeo Studio to have your own business solution
you can contribute XML configuration or java code
you can choose the features you need and the one you don't
This approach does not easily fit into JEE standard where some part of the deployment process assumes the application is one unique bloc with singleton descriptors (web.xml, application.xml ...).
Standard JEE deployment
Further more, Nuxeo software parts are packaged as OSGi bundles containing components, services and extension points (see platform explorer). So part of the deployment process is the Nuxeo Runtime initialization that will bind all software parts together in the right order.
This model allows the platform to run on several platforms (JUnit, Embedded mode, OSGi ...) but the downside is that JEE deployment is a little bit more complicated.
Basically a Nuxeo deployment on JBoss 4.2 involves 4 steps:
the template system runs and pre-configures the system settings (DB parameters, LDAP access, Virtual Hosting ...)
the custom deployer starts the Nuxeo pre-processing that will assemble JEE descriptors (web.xml, application.xml, war archive ...)
the custom deployer initializes the Runtime that will activate and assemble the bundles (ordering, activation, contribution ...)
the standard JBoss deployer deploys what it thinks to be a 100% static EAR
Nuxeo EP JEE deployment
About 5.4 deployment
5.4 release includes several improvements on how we deploy Nuxeo on top of Application Servers.
Nuxeo deployment in JBoss 5
The JBoss 5 deployer model is very modular, but also very different from the JBoss 4 model. We used this new model to rewrite the Nuxeo custom deployer and align it with the same principles used in other target platforms (mainly Tomcat WAR deployer).
Nuxeo EP now runs as an exploded EAR with only one external lib for the deployer and its declaration.
This means it's now very simple to install a nuxeo.ear in a vanilla JBoss AS 5.1 or JBoss EAP 5.0.1:
copy 2 files (EAR + 1 jar)
edit an XML file
Nuxeo as a static standalone EAR in JBoss 5
The new default JBoss deployment is now simpler than before, but it's still as dynamic as before: you can still add/remove/modify/update/configure components without having to rebuild a complete EAR.
But in some cases this flexibility is not the top priority.
It can be true for a production delivery:
because the standard tools and procedures don't fit with exploded EAR + external jar
because your administration team may be scared by an exploded EAR
because your want to be sure to run on an unmodified JBoss that is also used by other applications
For theses use cases, our local Runtime/JBoss wizard (aka : Chief Bogdan) added the possibility to cook a fully static EAR from an existing Nuxeo installation.
Basically, from nuxeoctl you can now run a command that will snapshot your Nuxeo configuration and create a static EAR from it.
This cooking process includes:
reorganizing the EAR content to avoid the need of any custom deployer
embedding the Runtime Activator inside the EAR and trigger it internally at EAR deployment time
extracting configuration that should stay outside (DB config ...)
creating the zipped EAR
Static EAR packaging generation
Thanks to this system, you can enjoy the flexibility of Nuxeo model during Dev and Test phases, but still provide a fully static "standard" EAR to the production guys.
An other interesting point is that this new static packaging is easier to port to other Application Servers because we only have to provide an activator and not a full custom deployer ...
Why upgrading from JBoss 4.2 to JBoss AS 5.1 / EAP 5.0.1
To upgrade infrastructure and avoid changes in the App Server
We have been using JBoss 4.2 for a long time now and we had to tweak JBoss 4.2 a lot:
remove some old libs so we can embed newer versions in Nuxeo (JSF, JBossWS replaced by Metro ...)
bug fixes or back-ports for some AS features (interceptors, remoting ...)
So, we ended up with our home brew version of JBoss AS and it was difficult (but possible) to install a Nuxeo DM on top of a vanilla JBoss 4.2.
By upgrading to JBoss AS 5.1, we automatically solve part of these issues:
a lot of third party libs are automatically upgraded
we can drop fixes and back-ports
To run on a supported version of JBoss
An other motivation for this upgrade was to be able to run on a supported Application server. We do believe that using OpenSource software with support from the people making the software is the right model :)
This means that people that are using RedHat Linux and JBoss EAP 5 will have the possibility to deploy Nuxeo on top of it and have a fully OpenSource and fully supported stack ECM solution.