Hi Jason,
I understand the need for a clear configuration layout and a centralized configuration file is clearly an advantage, but I'm quite shocked about the rigidness of the implementation. Why not give developers the alternative to choose what fits best for them? Erasing any alternatives or options has a significant impact on the whole deployment process.
While now (using JBoss 5) Datasources and JMS-Destinations can ship predefined by the developers and packed within the application. There are no server alterations required. If server alterations such as memory, pools sizes, messaging configuration etc. are recommended, they can be done once and in advance of any deployment.
After the server ist installed, we distribute the application as an EAR and a script to replace the minimal set of configuration placeholder (basically the datasource connection). At the customer side the EAR is run through the script and deployed just by copying it into the deploy directory. Some customers deploy this EAR even multiple times (each with its own datasources, queues, caches etc). They don't need any knowledge of the internals (Topics, Queues, Datasource Names etc.) and they do not need to modify the server configuration again.
If we migrate to JBoss 7, the process will become much more complicated. We will have to provide detailed instructions of all the internally required ressources and how to name and configure them properly. Yet, these customers are not experts, they are only interested in our software to run - some do not know much more than how to start a JBoss with a deployed EAR! If they do anything wrong, maybe just a mispelled queue, then the server wont start and they have to get back to us.
To prevent this, we would have to come up with additional scipts which have to start editing all the same configuration file or provide completely new customized installation tools. That's certainly a huge amount of work for a much more complicated and error-prone workflow.
You said
Also another requirement was that anything you can configure you can manage remotely via scripting languages, java clients, and a CLI. Deployment driven resources contradict all of this.
Why? What is the difference between a java client managing resources and a deployer using a configuration file? I don't see any. Why eliminate a perfectly convinient solution instead of just providing an alternative? If the centralized configuration is better in all cases, developers will migrate to this anyway, but in cases where it's not you will cause your users serious headaches...