I've never liked the vision of unpacking an EAR (and the WARs and EJBs within) 
to fiddle with
deployment descriptors.  That's the kind of thing that mandates some kind of 
GUI tool to be
workable, since you'll tie your fingers in knots unpacking, editting and 
repacking all that.

I would rather see a parallel directory structure that would contain overrides 
for information in
those descriptors, i.e.

/overrides/myapp.ear/application.xml

Would override the application.xml inside

/deploy/myapp.ear

Or something along these lines.  Perhaps that data is in a database, or comes 
from multiple sources,
or is managed by a GUI.  The point is, leave the original artifacts (EARs, 
WARs, JARs) alone, and
augment them from the outside.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Erin Mulder [mailto:[EMAIL PROTECTED] 
> Sent: Friday, August 08, 2003 2:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: One True Way (TM) of handling configuration files
> 
> 
> Alex Blewitt wrote:
> > >  From an administrator's PoV, it would be nicer if all 
> configuration 
> > > could be done via an admin console, and for the repository to be 
> > > stored in a not-necessarily-human-readable form which was 
> updated as 
> > > the config was changed via the admin console (e.g. Web app)
> 
> Robert Responded
> > While this may be a matter of some personal preference, I 
> tend to like 
> > config files over an admin cosole/webapp. Being able to 
> > administer/maintain via a command line is imporant to me.
> 
> I am all in favor of a good admin console, but everything 
> should still be accessible through XML config files and the 
> command line.
> 
> One of the most common complaints about Websphere (4.x at 
> least) is the way it obfuscates all the configuration files.  
> GUI tools are great for
> administration of shared servers, but not for development.   
> I want a good
> record of any configuration changes I make and an easy, 
> legible way to share them with other developers (see the 
> "User Friendliness" thread).
> 
> Erin
> 

Reply via email to