Will Tatam wrote:
We deploy many different self contained versions or our application to the same application server. This is required as it would be a waste of resources to use a single instance of jboss for each application.
Although I sympathize with your situation and see it as 'proof' that there are many different use-cases in the wild for having such configuration inside an EAR, I would like to mention that typically a single instance of JBoss AS for each application version (production, qa, dev) is actually highly recommended.
Unless you're a startup with extreme budgetary problems, I would not deploy a QA or DEV version on the same JBoss AS instance that runs the production version. I'm not sure how long you have running in this setup, but it's mostly a recipe for disaster. Even in the startups with the least amount of resources that I've seen, people were able to cobble together a €500 workstation and bless it as the 'server' to be used for QA.
More typically, I've seen companies running one application per single JBoss AS instance per single (Linux) virtualized server. The overhead of this in relation to the current sizes of disks and memory isn't that much anymore.
Our application's EAR contains the configuration for the JMS resources needed for each app (multiple topics and queues per instance of the app)
Do note that even if the EAR contains the configuration for these resources, they are still deployed globally. You probably must know this already and I guess every version of the application uses (slightly) different names?
I vaguely remember that there once was talk on the JBoss dev forum about having an option for resources like JMS destinations and datasources to be EAR scoped (so one EAR cannot see the resources of another EAR). I wonder what ever happened to this idea?
The "global" configuration introduced in AS7 works fine in the case where you only have a single application in any given jboss instance as it can be pre-configured by the system admins and then the app deployed.
In this case I would almost say that the deployable unit is not the EAR anymore, but JBoss AS itself with the EAR embedded inside it. The 'server' is then the plain JVM. Of course, Jesper's proposed CLI archive will change this for the better, but it doesn't yet exists.
It also currently requires that system admins know more about the "internals" of the application as they now need to build the JMS resources, rather than let the developers deal with these. So this now requires that system administrators need to re-config the application server for a specific version of our app for example if the latest version adds a new JMS queue
Yes, that has been my argument for a long time.
There is some school of thought that preaches EAR based applications should be deployed with unresolved dependencies, and that teams of system administrators having both intimate knowledge about the application server and about resources like JMS and Datasources are dedicated to wiring applications to the production environment.
This school of thought is not wrong per se, but it's mostly applicable to *very* large enterprises. There's a huge section in between, where system administrators mostly have knowledge about Linux, firewalls, XEN installations, apt-get, DNS, routing etc etc, but where their knowledge about Java and JBoss typically does not extend much beyond using '/etc/init.d/jboss restart' to restart the server. In these cases, developers or devops people know about JMS destinations and are the ones who can judge whether a new JMS queue is allowed or not in the application etc.
About that last thing, the "unresolved dependency"-approach typically seems to work the other way around. An application can not just add a new JMS queue. In this setup developers are often considered to be irresponsible cowboys who constantly endanger the stability of the production system, while the system administrator is the wise and knowledgeable 'defender' of said system. It's thus the system administrator who dictates what data sources are JMS queues are available and the developers just have to build the application around that.
What I've seen in practice is that in such restricted environments developers then simply resort to shipping a different application server *inside* the EAR. In the majority of the cases this different application server is Spring.
You probably do now want to know how many organizations run on Websphere (which strongly advocates the unresolved dependency approach) and decree that developers go to system administrators for resource definitions and upgrades of the server, but then base their EAR completely on Spring so that all Websphere functionality and 99% of the role of the system administrator is completely by-passed. It's scary and to be honest fairly depressing.