Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would somehow assemble WARs
and EJB beans to make a working app, presumably through some GUI that
required the same work to be repeated every release.
If you are doing lots of late binding tuning to the WAR file, then
perhaps build time is the wrong place to do it; it should really be
done as part of the deployment process, where per machine
optimisations can go in. In this world what you want from the outset
is the exploded WAR, which is then taken with server-specific options
to create the target WAR for the target system.
Pardon me for saying so, but this is just nuts. In my environment our
CM folks do the build and then make it available for operations. Noone
after CM is allowed to modify the parts. Any modifiable configuration
has to be placed outside the webapp. Furthermore, CM prefers that no
exploded webapps be used, since it is much easier to distrubute wars.
FWIW, at work we've moved to a post-war mechanism where I bring up
Jetty and do late binding configuration/deployment. Admittedly , I do
work on the smartfrog deployment framework where such tuning is
possible, but I got fed up with trying to add different servlets and
log4j options to different systems. On my desk, I want log4j to go to
the console, whereas in production log4j saves to rolling HTML files
in a directory that is served up. There's no way to do that in WAR
files without separate builds for each artifact.
We use our own logging framework that doesn't have this problem.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
