Date: Sat, 10 Sep 2011 16:39:58 +0200
That kind of properties file sounds quite similar to what we practiced in
those recent projects.
Regarding Bill's earlier questions, especially the external tools to change
configuration at runtime, that goes a bit into "DevOps" terrain, while
systems like WLS have special scripting languages, too. More interesting
than the actual language to manipulate such entries is the format and
structure how such resources are defined.
Allowing to externally override or "inject" those settings, so the actual
deployment remains untouched is crucial.
Speaking of properties, I remember one piece of legacy code used a Spring
standard mechanism to load properties as ResourceBundles. They then had to
duplicate the files for servers with a US vs. UK locale. What caused
troubles and was actually unnecessary in that case may in some way be used
for the better, let's say you take the stage or tenant into consideration[?]
Werner
On Sat, Sep 10, 2011 at 1:39 AM, Jeff Genender <jgenender_at_savoirtech.com>wrote:
>
> On Sep 9, 2011, at 5:11 PM, 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. Is that the
> > sort of thing you're looking for?
> >
>
> Yep.
>
> > 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?
> >
>
> Yep. As long as its override-able, we are good ;-)
>
> Jeff
(image/gif attachment: 347.gif)