[javaee-spec users] Re: Descriptor overrides

From: Bill Shannon <>
Date: Fri, 27 Jul 2012 12:09:28 -0700

Craig Ringer wrote on 07/27/12 05:07:
> 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
> <>.
> (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:
Sorry, I wasn't clear. The "alt-dd" mechanism would apply to war files as well,
not just ear files. We definitely don't want to require people to use an ear
file for simple applications.

Also note that for applications that primarily use annotations, the deployment
descriptor augments and overrides the annotations, which gives you some of what
you're asking for. But yes, if the application has it's own deployment
descriptor and you want to use the alt-dd mechanism to customize it further, you
have to make a copy of the original and change it.

Adding the ability to have a second (external) deployment descriptor that
augments and overrides the first (packaged) deployment descriptor, which
augments and overrides annotations, is worth considering.

Still, I'm not sure that would address all your concerns.

We probably need a CDI expert to tell us what can or should be done to address
your issues with alternative beans. I know one of the things left out of the
first version of CDI was the ability to configure beans using a descriptor
instead of annotations. I don't know where we are with adding that to the next
version of CDI, nor whether that would completely address your issues.

>> 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.
Have you looked at web fragment descriptors and how merging works there? I'd
like to believe that such merging works in an "obvious" way, but the rules for
how the merging works are quite complex. I'm ok with having complex rules as
long as most people don't need to understand the details and it just works how
they expect it to 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.
Certainly ease-of-installation is part of it, but another part is that it
simplifies testing and support.

>> 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.
Most people haven't. :-) We're just starting to think about these issues as
part of the cloud support for Java EE.

>> 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.
So I guess we should talk more about what a special-purpose solution would look

What do others think?