Bill Shannon wrote:|
In my view this is part of the problem, it's not a solution. It might still be very useful for big, complex deployments, but it won't solve an usability, learning curve or complexity problems.
Many in the Java EE world appears to think in terms of there always being a dedicated "assembler/deployer" individual who understands EAR packaging and descriptors and is comfortable bundling a .war into a .ear with some additional descriptors before deployment. This person probably works as part of an operations team of more than one person, and is probably not also the developer. This person is certainly not an end user.
IMO It's a really unpleasant, clunky and archaic way to deploy software, and it makes the stand-alone web archive concept of EE 5/6 much less useful. It makes the use of EE application servers and containers much less accessible to people who simply want to deploy a .war they bought/downloaded onto a container they've just installed and use it. It all feels very Enterprisey. (over-engineered without a purpose) - though I'm sure a purpose is actually served for big, complex deployments..
If there is anything to be learned from the success of the PHP / MySQL crowd, from Rails, from Heroku, etc it's that easy-to-deploy and easy-to-configure is vital for a significant and growing group.
I think that to make standalone web archives more useful some of the basics need to be configurable without the baggage of a fixed EAR wrapper. At the very least a standard way to configure datasources, beans.xml, etc that can be done without repacking the war, wrapping it an ear, or hacking around with container-specific deployment descriptors would help.
As I understand it, currently you have to repackage the war to override an alternative bean, and you can't change the EE standard data source descriptors without a wrapper EAR or without unpacking a war to edit web.xml . They can't be deployed directly - though you can make a new .ear or .war with just the descriptor in it and give the datasource a global name.
I'd love to improve this process so simple, common tasks like selecting alternative beans or setting up a data source in a container-independent way don't require repackaging.
This isn't how to make EE look attractive to new teams, developers and companies who need to get products built:
I tend to agree there, especially since merging of XML descriptors rather than copy-and-edit would be desirable - but the semantics and details of merging would be utterly descriptor specific. I'm not sure overrides are really the right answer, as I've been thinking about them and haven't been able to come up with a good way to make them work.
I'd instead like to look at why descriptor overrides are even coming up for discussion. The deployment archive contains (a) application code, and (b) site specific configuration, all mashed into a single archive, and that's why there's a need to override some of it. Some deployment descriptors (which often contain site- or deployment-specific information) should perhaps not be inside the application archive in the first place.
I suspect that was the line of reasoning that led to the EAR and the layered descriptor model it uses, but it's pretty clunky way to do things. People seem to avoid it in favour of simply bundling their application with a built-in servlet container and a config file. Look at, eg, Sonatype Nexus.
It's just too hard to make an easy-to-use deployment that someone can download, deploy, and use. The fact that it appears to be easier or more usable to do what Sonatype has done, rather than just ship a .war where the container does much of the hard work for you, suggests that the EE configuration and deployment model isn't fitting the needs of at least one group of application developers, those who want to ship an easy-to-use product.
Ugh. That one's over my head, I haven't had the ... pleasure ... of dealing with multi-tenant deployments on containers.
Having thought more about it and read your comments I have to agree with the latter part. An overlay isn't a good general-purpose solution. It might be an extremely handy tool, but it isn't the answer to the configuration problem, and there's probably no need to standardise it.
[javaee-spec users] Re: Descriptor overrides