Jason Greene wrote:
henk de boer wrote:
Currently in our setup developers simply clone a project from the Hg repository and via JBoss tools they deploy it to JBoss AS. This almost can't be simpler
So you never change a single server setting, like performance impacting web connector pool sizes etc (note that these can't be deployed)?
Well, certainly this would not often be needed for development on a local workstation, would it? Many projects I worked on, developers indeed deployed to a stock JBoss AS, or to a JBoss AS with only the ROOT.war removed. Why should it be any more complicated than that?
For other projects, a JBoss AS was slimmed down and then archived again. This same archive was then used for all stages. I have not yet had to change the web connector pool size, or any of the container thread pool sizes. If that would be needed, I'm fairly sure this would again be done once and the same archive with those changes would be used throughout all stages.
Of course I respect that such an approach would not suit every deployment out there, but this is the entire point I'm trying to make. There are various different usage scenarios out there. Some companies mandate that deployment happens to an absolutely stock application server, as-if it was say a JDK where you also don't change internal files. Others do slight modifications and use the same modified instance throughout all stages, while yet others consider the JDK as the deployment platform and ship a *heavily* modified JBoss AS with an EAR embedded inside it as the deployment unit.
And yes, I know that there's also the scenario where an EAR is shipped with unresolved resource dependencies, and where the deployer has to resolve these when deploying it to a JBoss AS instance that may or may not be otherwise tuned. I'm sure this is a very reasonable strategy for some, but just not for all.
If someone can provide a good use case why the general EE stuff can't be used then we can do it.
Some posts above I put a considerate amount of effort in describing the use case. Here I would just like to add that simply a lot of people use this feature. Removing it will make it unreasonably hard for us that use it to upgrade to JBoss AS 7.