On Tue, May 07, 2013 at 01:17:40PM -0400, Jesse Barnum wrote: > On May 7, 2013, at 9:40 AM, "Mark H. Wood" <mw...@iupui.edu> wrote: > > Well, the developer can simply pack into the app. whatever internal > > configuration is needed, since he has ready access to the interior of > > the app and can deposit on the classpath *.properties, *.xml, or > > anything else he wants. He can have no certain knowledge of the app's > > runtime environment and should not assume, only specify requirements, > > and provide sensible defaults when there are some. > > > > The deployer, OTOH, has ready access to the app's environment, > > including its Context, but should not be assumed to have such access > > to the interior of the app. > > > > So this division of labor depends on the developer's discipline in > > distinguishing internal vs. external configuration and coding the > > app. to look in the proper place for each. I don't see a good way for > > the container to make up for incorrect design in this area. > > > > -- > > Mark H. Wood, Lead System Programmer mw...@iupui.edu > > Machines should not be friendly. Machines should be obedient. > > Mark, can you give me an example of a use case where it is useful for the > deployer to modify parameter values in the META-INF/context.xml file? Assume > that at some point, a new version of the application will be deployed, and > also assume that the deployer does not wish to re-apply the same > customizations with each release.
Well, not really. My point was that things the deployer will want to
modify should not be in META-INF/context.xml; they should be in
${CATALINA_BASE}/conf/[enginename]/[hostname]/[appname].xml where they
are easy for the deployer to get at without digging in the
app. itself. I can't think of anything I would want to put in
META-INF/context.xml, really. The developer doesn't need that layer
of mapping; he knows where all the internal bits are and what they are
called, because he decrees them.
Keeping the Context descriptor outside of the app. means that it won't
be replaced when you deploy a new release (provided that you don't put
the app. in appBase). That's why I do it.
> Without getting into the pros and cons of your first paragraph (which places
> all responsibility for managing app preferences on the developer), would you
> agree that the current approach (leaving the context.xml file in the web app)
> is not fulfilling one of its intended purposes, which is allowing the
> deployer to customize the application behavior?
I would. I suspect that what people had in mind was that some
installer program would automagically customize META-INF/context.xml,
so that the app. actually deployed is not quite the app. which is
shipped. I happen to think that 'tar', 'unzip', and 'cp' are the
three best installers out there, and would rather put my per-instance
settings somewhere outside the app. altogether. I very much
appreciate the way that Tomcat makes that possible.
I'm not sure what you mean by "places all responsibilities for
managing app preferences on the developer". I thought that this
division requires that the developer *not* manage preferences, which I
take to be deployment details such as "where's my database?" or
"what's the name of this business?" Those are the responsibility of
the deployer; the developer is responsible for supplying values which
are invariant across instances, but which might be convenient to
gather into a .properties or some such.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
