Why don't you save this files in another folder???
Well, that's what I did for now. But, I want to be as much free as possible with possible security issues associated with saving the files to different directory and etc.
You can unpack your deployment.
Basically create directories called myapp.war instead of
an archive but with the same structure.
To redeploy, touch the deployment descriptor.
The unpacked deployment is deployed in place rather
than copying to tmp. It is not deleted at undeployment.
Everything has to be unpacked.
It isn't considered good practice to write back
into a deployment.
The unpacked deployment is intended for development.
Thanks for tips. I will try that for now.
J2EE is supposed to provide improved responsiblity
delineation. If a runtime administrator wants to change
a run-time parameter like "maxExemption" or "taxRate"
on a production server, why must he rebuild and re-deploy
an ear file? (I know "why" in the sense that the mods
are in the web.xml or ejb-jar.xml file, but why have
run-time variables buried 2-levels deep inside an ear
This would be a trivial text file edit with a conventional
UNIX daemon program. IMO, production-only setups should
not require build-tools like ant to be present.
Am I missing some reason why embedding JNDI or other
mappings is somehow better than progams like inetd,
sshd (and in some cases httpd), that re-read independent
text config files when you give them a HUP signal?
I think the intent was to make distribution and deployment as easy as possible. It's hard to go wrong with just one file. As for the deployment descriptors, they can either be edited with a GUI tool that automatically unpacks the archive and repacks it with the updated descriptors. Alternatively, you could manually unpack, edit, and repack. Ant is certainly not needed -- just some familiarity with either the GUI deployment tool or the jar command and an editor.