Bill Shannon wrote:
>
> We already have the ability to override deployment descriptors using
> the "alt-dd" mechanism in the ear deployment descriptor. We're going
> to expand that in EE 7 to include the ability to override the ear
> deployment descriptor itself.
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
<
http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx>.
(over-engineered without a purpose
<
http://thedailywtf.com/Articles/The-Enterprisey-Null-Test.aspx>) -
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:
http://stackoverflow.com/a/6728386/398670
>
> It's easy to imagine a general override mechanism where any file in an
> "overriding" ear/war/jar file replaces the corresponding file in the
> application. One concern with that approach is that it provides too
> much "rope", and people will tend to trip over it or wrap it around
> their necks.
>
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.
>
> A related problem that we haven't yet spent enough time on is the need
> to allow tenants in a multi-tenant environment to provide
> customizations for an application they're all sharing. If we come up
> with a good way to do this, it might be usable in a non-multi-tenant
> environment as well.
Ugh. That one's over my head, I haven't had the ... pleasure ... of
dealing with multi-tenant deployments on containers.
>
> I would love some more feedback from you and others as to how we
> should solve any part of this problem. It's tempting to go with the
> quick fix of defining a general file-based override/overlay mechanism,
> but I worry about the consequences of that approach.
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.
--
Craig Ringer