Adam Bien wrote on 09/11/11 05:21 AM:
>
> On 10.09.2011, at 01:11, Bill Shannon wrote:
>
>> We have the ability to supply an "alternative" deployment descriptor when
>> you deploy an application. Is that sufficient for configuring and
>> overriding the things that you can specify in a deployment descriptor?
>>
>> If the application is handling other app-specific configuration by (e.g.)
>> reading properties from a properties file, then having the ability to
>> specify an overriding or augmenting property file at deployment time
>> (packaged separately from the app) might be reasonable.
>
> But it should not be required.
Of course not. If you don't want to override the properties, you don't have to.
> IMHO: the additional configuration can be
> packaged with or without the application.
You can already package properties with your application. The enhancement
would be the ability to override those properties with something that's
*not* packaged with your application.
>> Is that the sort of thing you're looking for?
>>
>> Would it help if we made it possible to specify JNDI environment entries in
>> a property file instead of in XML in a deployment descriptor?
>
> Yes. But why just property files? If we specify a simple API we could use any
> format we like.
I don't understand.
An API to *set* the properties?
Or an API to *read* the properties?
We already have the latter.
Above I was suggesting a properties file to set the JNDI environment entries.
If you want to bypass JNDI, and use whatever API you want to read
"configuration" information from a file/resource, we could generalize what I
proposed to allow allow providing a file/resource that replaces what's
packaged with the application. Without knowing anything about the file
format, it's impossible for the container to know how to merge or override
particular entries; all it can give you is a complete new file.
Maybe I don't understand what you mean when you say "we could use any format
we like". Who is "we"? Application developers? Sure, then let's cut the
container out of the picture as much as possible. App server vendors? Well,
yes, but then how would you package a portable application if each vendor
can make a different choice about the file format?