I'm trying to figure out the best way to package/deploy an extended application based on JBoss Portal. Our app consists of application portlets and JBoss service components (some application-specific, others replacing the stock JBP services like UserModule). Ideally I'd like to come up with a deployment packaging structure that minimizes production-time dependencies while also allowing individual modules to be hot-deployed during development. The portlets have to be packaged in a standard JSR168 .WAR archive, of course, but I'm struggling trying to figure out how to organize the service components and how to relate those to the .WAR. Seems like my options include:
- service beans in their own .SAR file, deploy in parallel with the .WAR file to the top-level "deploy" folder. Because some of my service beans depend on classes in jboss-portal.sar, I need to name my modules carefully to make sure the deployer sees the portal classes first. also, because my .WAR depends on classes in the .SAR, I need to manually reploy the former if I update the latter.
- use separate service .SAR and .WAR files, but organized into a common folder under the top-level folder (same naming tricks as #1). If I understand the URLDeploymentScanner behavior, as long as the subfolder doesn't have a period in its name, I can hot deploy either of the individual components. Same issue with manually tracking dependencies.
- everything in a single .SAR file (service beans in a "lib" folder?), with the WAR as a sub-deployment within the war. Seems to be the "cleanest" semantically. But if I deploy as an exploded .SAR folder, will the SARDeployer recognize if I change the .WAR submodule, or do I have to redeploy the entire .SAR archive every time?
Some of my confusion stems from an incomplete understanding of the SAR archive format (the packaging structure, not the jboss-service.xml deployment descriptor). Is this documented anywhere?
Appreciate any suggestions.