I just downloaded GateIn-3.2.0.Final-jbossas7-preview and wondered (again) why this package needs to be buried into the AS that way.
I'm specifically interested to JBoss AS 7, which FWIK:
- can deploy packages from multiple directories,
- can be configured to look to modules from multiple directories,
- can be configured to fetch external property files at start-up, system-wide and/or for specific hosts/domains.
The JBoss AS in general is quite expensive in memory consumption and cpu cycles. 7 is better, I know. Nevertheless I often prefer not to start multiple instances of it, but instead to pack as many applications as possible in a single instance.
I often work this way: I have a directory holding a configuration-tweaked JBoss AS (actually, jboss-as-7.1.0.Final), then I have a set of directories (one for each application) apart from the jboss one. Each of these directories hold stuff needed to run the application and "expose" a deployments subdirectory holding the application's EARs and the like. A simple tweaking of the deployment-scanner subsystem configuration is made to instruct the AS to look at that subdirs for beef to deploy, while system properties and the like are set at AS startup. With some more tweaking of the run script one can even specify more module directories.
This way I strive to decouple the AS from the application(s) it is going to run, such that I can switch to new AS or application versions without messing too much with their respective boundaries.
Going back to GateIn-3.2.0, I would have produced a package like this:
In "configuration" I would have put the actual content of GateIn-3.2.0.Final-jbossas7-preview/standalone/configuration/gatein, in "modules" the actual content of GateIn-3.2.0.Final-jbossas7-preview/gatein/modules, and finally in "deployments" the stuff from GateIn-3.2.0.Final-jbossas7-preview/standalone/deployments.
Then I would have spared a readme.txt describing how to add GateIn functionality to a stock AS 7.1.0: using the -D and -P flags to set and fetch system properties from GateIn-3.2.0/configuration/configuration.properties, adding the needed <deployment-scanner> and <security-domain> elements to the jboss configuration, and modifing the -pm switch in the run script to add the modules directory. Or maybe I would have spared a script to setup these things at runtime, using the jboss-cli interface.
What else would be missing this way?
Sounds like a valid uses case. I suppose the easiest way, to try to see if current GateIn packaging can be easily converted in your preferred approach, would be to try write some shell scripts that move the directories around, apply changes to files ...
Would you be interested in giving it a shot, as you have already worked out a layout that works in real life?