Jason Greene wrote:
You know exactly what resources are in use, what all the things you can tune are, and what you can lock down because you have one place to look.
I see your point now. Thanks for the detailed explanation Jason. I really appreciate this.
There is certainly value to have one place to look for configuration. We now often have to look in /conf, /deploy/ and /deployers/somedir, so uniting this to one location will certainly be for the better.
With respect to resources in deployments, you perhaps might not always want to consider those pure configuration. Take the JMS queue example from above. Is this really configuration at the server level? Or is it a datastructure the application internally defines?
Is a declaration like:
<queue name="aQueue">
<entry name="/queue/aQueue" />
</queue>
really conceptually much different from:
public class Something {
public static myQueue Queue<String> = new ConcurrentLinkedQueue<String>();
}
? (given that aQueue is purely an internal queue for the application and doesn't need any kind of external management)
In a certain way this discussion is perhaps not entirely unlike annotations vs XML deployment descriptors. XML puts everything in once place, but annotations make it more clear to what something applies. There are two camps with each of them valid arguments. The Java EE spec decided to support them both, which is great I think.
this applies to jms queues, and any other globally manageable resource as well.
Does this also imply that any kind of mbean (-services.xml) and POJO (-jboss-beans.xml) can not longer be defined in an EAR?
Over the years I've seen countless applications doing exactly that. I guess some of those usages could be replaced by @Startup @Singleton beans, but if all of this indeed also needed to be rewritten, the cost of upgrading to AS7 may be exceptionally high.