Jesper Pedersen wrote:
To quote a former colleague "You're doing it wrong".
Jesper, I know the discussion, but IMO it's largely based on opinions, just like e.g. some people prefer slim entities (containing only data), while others prefer entities that do their own persistence.
The classic Java EE approach is to have only references to resources in your EAR, and let the environment to which this EAR is deployed provide definitions for them. This seems to assume a division between developers and operations, where an operations team administrates these resources. No doubt this approach works for some teams, but for other teams this is not the most natural fit.
Most places where I worked don't have this separation, but indeed have people more akin to the role "devops". These are developers who write the code and thus create the resources (datasources, jms destinations) and also configure these resources with the correct parameters for the different stages. Such a developer is also part of the operations team, and thus knows about the addresses of e.g. the database being used in production and the QA stages.
A pure operations team member in this setup does not have intimate knowledge about JBoss AS or about JMS, XA, etc. He or she maintains the servers at e.g. the Linux level, operates the firewall, the switches etc.
So, what happens in this case is that the developer/devops person has to create the various -ds.xml files anyway, but instead of being near the code these now have to be maintained somewhere else. I've seen among others CF-ENGINE being used for this. The problem then is that developers don't really see these files. Since CF-ENGINE also contains tons of other system files (like firewall settings, apache settings, etc) they probably don't have access to this.
Over time, this then runs out of sync. Developers remove datasources from their local config (since the code isn't using it anymore), but this change isn't propagated to the other stages, since the developer simply can't access these. Of course, there can be process put into place that requires developers to write tickets for operations people to make these changes. But since the operations people don't have knowledge about these changes, they merely copy the changes the developer puts in the ticket. Worse, since the developer doesn't see the complete file anymore (he only communicates the changes), he or she doesn't see whether the end result over time is still sane.
In my opinion the EAR-with-resource-references-only assumes a situation where developers are mostly irresponsible cowboys, while operations are sensible, responsible people.
For shops where this is indeed the case, I fully agree that the classic EAR-with-resource-references-only is a sane approach. Huge enterprises are probably the main target audience here. For universal EARs that should be shipped to different clients this approach also makes sense.
However, for smaller and leaner shops with a devops culture where development is for an in-house operated platform, this separation only poses an amount of needless overhead. It's much, much clearer if the EAR contains all configuration for the multiple stages. If for instance a JMS queue needs to be added or removed, this can be trivially done.
To illustrate, our structure is now such:
EAR
conf
local
some-ds.xml
some-hornetq-jms.xml
dev
some-ds.xml
some-hornetq-jms.xml
live
some-ds.xml
some-hornetq-jms.xml
some-universal-queue-hornetq-jms.xml
lib
...
META-INF
jboss-app.xml
jboss-app.xml is parameterized as follows:
<module>
<service>conf/${our.staging}/some-ds.xml</service>
</module>
I've seen this structure, or a structure much like it, at many places. If you search your own forums here you might come across multiple posts where people ask how to include various things in their EAR and stress the importance of being able to do so.
It's not just a structure that we started to use because we don't yet understand how deployments should work. We thought a lot about this and had discussions with various people from various backgrounds (from entry developers to hardened devops, etc) about what would suit their requirements best.
There are simply multiple approaches that work for different situations. An important asset of JBoss AS has always been that it supported both approaches. If you just throw out the support for one of those, because (uhm, because of what reason exactly?), then I really think this does not improve the attractiveness of JBoss AS.
I also wonder how many shops all over the world greatly depend on this feature and will run into major troubles when eventually upgrading to AS 7.
(yes, I guess we could write scripts that unpacks the EAR first and copies the config files from the EAR to the JBoss deploy directory, but this does require such scripts to be able to run on deployment where we now simply do a copy of the EAR and that's it)
Sorry for the long text, but I hope it offers some insight into why packing resources with an EAR can be important to some.