On 07/28/2012 03:09 AM, Bill Shannon wrote:
> 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.
Ah, thanks for the clarification. That _does_ sound like progress.
> 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.
Given the difficulty of coming up with good semantics for merge/overlay,
that makes sense.
> 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.
I'll see who I can hunt up then. Some interesting discussion on this
appeared on a CDI bugs:
https://issues.jboss.org/browse/CDI-18
https://issues.jboss.org/browse/CDI-112
so people participating in those may be interested in this.
>> 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 haven't looked into web fragment descriptors, so I can't really
comment there. I'll have a look.
>
>> 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.
True; it's only one container to worry about.
Ideally the EE standards would mean they didn't have to worry about
that, but in reality every container's behaviour will still differ.
>> 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 like...
>
> What do others think?
>